Views and View Addresses for Secure Asset Transfer
draft-ramakrishna-satp-views-addresses-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Venkatraman Ramakrishna , Vinayaka Pandit , Ermyas Abebe , Sandeep Nishad , Krishnasuri Narayanam | ||
| Last updated | 2024-01-08 | ||
| Replaces | draft-ramakrishna-sat-views-addresses | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
GitHub Organization GitHub Username: VRamakrishna |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ramakrishna-satp-views-addresses-02
Internet Engineering Task Force Venkatraman Ramakrishna
Internet-Draft IBM Research
Intended status: Informational Vinayaka Pandit
Expires: July 8, 2024 IBM Research
Ermyas Abebe
Consensys
Sandeep Nishad
IBM Research
Krishnasuri Narayanam
IBM Research
January 8, 2024
Views and View Addresses for Secure Asset Transfer
draft-ramakrishna-satp-views-addresses-02
Abstract
With increasing use of DLT (distributed ledger technology) systems,
including blockchain systems and networks, for virtual assets, there is a
need for asset-related data and metadata to traverse system boundaries
and link their respective business workflows. Core requirements for such
interoperation between systems are the abilities of these systems to
project views of their assets to external parties, either individual
agents or other systems, and the abilities of those external parties to
locate and address the views they are interested in. A view denotes the
complete or partial state of a virtual asset, or the output of a function
computed over the states of one or more assets, or locks or pledges made
over assets for internal or external parties. Systems projecting these
views must be able to guard them using custom access control policies,
and external parties consuming them must be able to verify them
independently for authenticity, finality, and freshness. The end-to-end
protocol that allows an external party to request a view by an address
and a DLT system to return a view in response must be DLT-neutral and
mask the interior particularities and complexities of the DLT systems.
The view generation and verification modules at the endpoints must obey
the native consensus logic of their respective systems.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2024.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
1. Introduction
Blockchain systems, especially those of the permissioned variety, are a
heterogeneous mix, fulfilling a diverse range of needs and built on
several different DLT stacks that are not compatible with each other.
Yet, in an interconnected world, the business processes running on each
system cannot afford to remain isolated and the virtual assets they
manage cannot afford to remain in siloes. These systems must be
interoperable so that assets can move, and their properties can be
reflected across network boundaries, and so that business processes can
span multiple systems. Interoperability will, in effect, mimic a larger
or scaled up, blockchain system composed of smaller blockchain systems
without explicitly requiring those systems to coalesce.
At the core of any cross-blockchain system transaction is the ability of
a system to project a view of assets and associated data recorded on its
ledger to external parties, be they individual agents or other blockchain
systems. On the reverse, a blockchain system must also have the ability
to identify and address views of assets or associated data in another
system, and further, to validate that view before its business process
consumes it. View projection, addressing, and consumption, must
eliminate or minimize the role of third parties to avoid loss of data
privacy, control over business process, or diminishment of autonomy.
This document specifies formats for views and view addresses on
distributed ledgers. Similar to the notion of database views, distributed
ledger views reflect what a given network wishes to expose to external
parties, typically through scripts, as well as access control
considerations. In contrast to conventional databases, exposure and
access control considerations must be decided through decentralized
consensus. Also, in contrast to a conventional database, the consumer of
the view, who may be a DLT system, must be able to independently validate
it as the consensus view of the providing network. Hence, a view
incorporates the notion of a proof made against a claim. The view address
must encapsulate the view request, and optionally carry a policy
that circumscribes the construction of proof.
The protocol to communicate view requests and responses is beyond the
scope of this draft and will be specified in a separate draft.
2. Terminology
There following are some terminologies used in the current document:
o Blockchain system: Blockchains are distributed digital ledgers of
cryptographically signed transactions that are grouped into
blocks. Each block is cryptographically linked to the previous
one (making it tamper evident) after validation and undergoing a
consensus decision. As new blocks are added, older blocks become
more difficult to modify (creating tamper resistance). New blocks
are replicated across copies of the ledger within the network, and
any conflicts are resolved automatically using established rules
[NIST].
o Blockchain network: This is a blockchain system that is built on a
network of nodes that maintain a common shared copy of the blockchain
using a consensus protocol.
o Distributed ledger technology (DLT) system: Technology that
enables the operation and use of distributed ledgers, where the
ledger is shared (replicated) across a set of DLT nodes and
synchronized between the DLT nodes using a consensus mechanism
[ISO]. Every blockchain system is also a DLT system, and so we
will mostly use the latter term in this draft when discussing
protocols for cross-system interactions.
o Distributed ledger network: This is a DLT system that is built on a
network of nodes that maintain a shared copy of the ledger or portions
of it on different subsets of nodes using a consensus protocol.
o Resource Domain: The collection of resources and entities
participating within a blockchain or DLT system. The domain
denotes a boundary for permissible or authorized actions on
resources.
o Interior Resources: The various interior protocols, data
structures and cryptographic constructs that are a core part of a
blockchain or DLT system. Examples of interior resources include
the ledger (blocks of confirmed transaction data), public keys on
the ledger, consensus protocol, incentive mechanisms, transaction
propagation networks, etc.
o Exterior Resources: The various resources that are outside a
blockchain or DLT system, and are not part of the operations of
the system. Examples include data located at third parties such
as asset registries, ledgers of other blockchain/DLT systems, PKI
infrastructures, etc.
o Nodes: The nodes of the blockchain or DLT system which form the
peer-to-peer network, which collectively maintain the shared
ledger in the system by following a consensus algorithm.
o Gateway nodes: The nodes of the blockchain or DLT system that are
functionally capable of acting as a gateway in an asset transfer.
A gateway node conforms to the Secure Asset Transfer Architecture
[SATA] and implements the Secure Asset Transfer Protocol (SATP)
[SATP]. Being a node on the blockchain/DLT system, a gateway has at
least read access to the interior resources (e.g., ledger) of the
blockchain. Optionally, it may have write access to the ledger and
also the ability to participate in the consensus mechanism deployed
for the system. Depending on the blockchain/DLT system
implementation, some or all of the nodes may be gateway-capable.
o Clients: Entities are permitted to invoke smart contracts to read
or update ledger state in a blockchain or DLT system. They possess
unique identities in the form of public keys. In a permissioned
system, identity certificates are issued by the system's internal
providers (or certificate authorities).
o Wallets: Collection of client identities represented by public-
private key pairs, and optionally certificate issued by a
blockchain or DLT system's identity providers (or certificate
authorities).
o Virtual Asset: A virtual asset is a digital representation of
value that can be digitally traded, or transferred as defined by
the FATF [FATF].
o Virtual Asset Service Provider (VASP): Legal entity handling
virtual assets as defined by the FATF [FATF].
o Ledger state: A snapshot of the information held in a distributed
shared ledger, typically (though not necessarily) as a set of
blockchain or DLT system. Examples of interior resources include
key-and-value pairs. This information includes records of virtual
assets and the state of business processes that are meaningful to
the DLT system's participants and clients. State elements and
subsets may be scoped under the namespaces of given smart contracts,
thereby being accessible only through invocations on those contracts.
o Smart contracts: Business workflows written in programming languages
that manage the states of assets and business processes on a shared
ledger in a DLT system. These contracts constrain the ability of
system clients to modify ledger state and embed guards around state
elements. Contracts can be invoked to read from, or write, to, a
ledger. They can be deployed on several system nodes, who must
agree on a given ledger state update via a consensus protocol.
o Consensus protocol/mechanism: Process by which nodes agree on a
ledger state update, typically (though not mandatorily) through a
smart contract invocation.
o Local transaction: A transaction triggered by a client to update
the ledger state in a blockchain or DLT system, typically (though not
mandatorily) through a smart contract invocation.
o View: A projection of a blockchain or DLT system's ledger state
for external consumption, i.e., for parties outside that system.
This can be a single element, a subset of the state, or a function
over a subset.
o View Address: A unique identifier or locator for a view into a
blockchain or DLT system's ledger. This is analogous to an HTTP URL.
o Source system: Blockchain or DLT system governing the ledger from
which a view is produced.
o Destination system: System in which a view is consumed. This can
be a blockchain or DLT system.
o Remote system: Counterparty system in a view request-response
protocol instance. From the vantage point of the source system,
this refers to the destination system, and vice versa.
o View requestor: Person or organization triggering a view request
from a source network.
o Proof: A data structure containing evidence linking a view to its
source system's blockchain, or more generally, ledger. The evidence
may be probabilistic and in some cases cryptographically verifiable.
o Access/exposure policy: Set of rules governing the release of a view
to an external party (i.e., outside the source system), held in
consensus by nodes on the source system's ledger.
o Verification policy: Rules for validation of proofs associated with
views maintained in a destination system. If the destination system
is a blockchain or DLT system, these rules are held in consensus by
nodes on the that system's ledger.
o View Request: A request for a made by an external party to a source
blockchain or DLT system. The external party may be a client in
a destination blockchain or DLT system. The request consists of a
view address and various metadata, including optionally a
verification policy.
o Asset locking or escrow: The conditional mechanism used within a
blockchain or DLT system to make an asset temporarily unavailable
for use by its owner. The condition of the asset release can be
based on a duration of time (e.g., hash time locks) or other
parameters.
Further terminology definitions can be found in [NIST] and [ISO].
The term 'blockchain' and 'distributed ledger technology' (DLT) are
used interchangeably in this document.
3. Assumptions and Principles
The addressing of a DLT system’s assets and asset-related data as well as
the exposure of such data to a foreign DLT system assumes the presence of
one or more gateways that are either part of the system or working on
behalf of it. These gateways are ultimately responsible for generating
and interpreting both addresses and data, hiding any DLT- or network-
specific protocol considerations from each other. All DLT- and network-
specific software artifacts that are exchanged among gateways will be
encapsulated in generic (or DLT-neutral) software artifacts. The gateways
are assumed to be interoperable using a protocol that corresponds to the
design principles of the Internet architecture. The specification of this
protocol is beyond the scope of this draft and will be described in a
separate draft.
4. Ledger State Views and Proofs
4.1. Abstraction of Distributed Ledger States
A distributed ledger system maintains a set of ledgers, akin to
databases. Each such ledger is organized and addressable in a
hierarchical namespace with the identifier of the distributed ledger
system being the root. A ledger is shared among a subset of members of
the network that the system, which maintains the distributed ledger, is
built on. These subsets of members may overlap or be mutually exclusive,
depending on the precepts of the given DLT, but for the purpose of this
document, the distinction is not relevant. For example, the Hyperledger
Fabric blockchain platform maintains a set of channels, where each
channel is shared exclusively by a subset of members [Andr18]. In
contrast, the Corda platform allows each data item to be shared by an
arbitrary subset of members, in effect creating databases privy to
mutually overlapping member sets [Hear19]. The Ethereum Mainnet has a
dynamic group of members maintaining a single global ledger with open, or
public, access.
Each shared ledger within a system maintains a snapshot of the latest, or
current, state, determined through consensus (or agreement) by the
members sharing it. In addition, a tamper-evident history of the current
state, which can be a blockchain or any other form of a transaction log,
is also maintained by the members sharing that database. The state of the
distributed ledger system as a whole is the union of states of the
ledgers it comprises of.
Finally, any data item within a ledger can be retrieved, or any processed
data extracted, using its native logic and interfaces. As a ledger is a
traditional database in most respects, it supports extraction and
processing the same way a database does. For example, data in a SQL
database can be extracted using record keys and schema attributes,
whereas in a No-SQL database, data is extracted using knowledge of key
value pairs and overlaid schema. Just as views and stored procedures are
used to extract information from a database, UTXO scripts (in Bitcoin
[Naka2008]) or smart contracts (in Ethereum [Ethe22], and several
permissioned DLTs like Hyperledger Fabric and Corda) are used to extract
information from a ledger. An interface is provided to give the user the
ability to query or update ledger data. As UTXO scripts are just simple
forms of smart contracts, we will assume in our abstraction that each
ledger within a DLT system possesses a smart contract interface.
4.2. Distributed Ledger System Views
A view into a distributed ledger system state is similar in concept to a
traditional database view but has certain additional features because the
backing state is maintained in a different way than state in a
traditional database is. Fundamentally, a DLT system view is information
that is derived from that system's ledger. We define it as an abstract
representation of state projected from a ledger that is consumable by
entities, who may or may not belong to the network or possess credentials
to access raw ledger state. Views are uniquely addressable within a DLT
system. A view can be static, i.e., referring to information derived from
a point-in-time (or historical) state, or dynamic, i.e., referring to
information derived from the current state.
Semantically, a view represents the what and not the how, i.e., it
projects information from a ledger but not the details of the process
through which that information came into being. This process has multiple
facets, from the consensus and commitment protocols through which raw
data was recorded on the ledger to the smart contract procedure through
which information was extracted from the raw ledger data. These
procedures are specific to DLT implementations, which we wish to keep
opaque from the cross-system communication infrastructure, specifically
the systems' gateways. This will allow the communication infrastructure
to ignore details of ledger implementations while managing state when a
view is communicated from a system to an external entity. Therefore, we
specify the view as a package with a generic structure, independent of a
specific DLT implementation. Internally, a view will contain data that
has a DLT-specific representation, but we will leave the interpretation
of this to modules internal to the systems. In this document, we will
specify the formats of the DLT-independent portions of a view that will
be handled by the communication infrastructure and provide suggestive
sample view contents for prominent DLTs.
There is a caveat to the above definition, arising from a fundamental
difference between a traditional database and a DLT system. This is the
fact that state in the former is maintained by a single authority whereas
state in the latter is maintained collectively, and held in agreement, by
a peer group of entities, each of which can fail or be malicious.
Therefore, a DLT system view is incomplete without an associated proof of
it being derived from state agreed to by the group as a whole. In
practice, this does not require unanimity but rather enough
representation from group members to overcome failure of individual
peers' failures and to assure an external client that the system as a
whole will not repudiate that view, in accordance with the consensus
rules of the source ledger, at a later time. Theoretically, we can
quantify the nature of this proof under certain models. If peers are
susceptible only to crash failures, an agreement over state from more
than 50% of the peers will qualify as sufficient proof. If peers can be
malicious, i.e., fail in Byzantine ways, a consistent state view is
required from more than 2/3 of the peers. More generally, the nature of
proof, or determining what is sufficient, can be derived from the
consensus mechanism used by the system.
The proof associated with a view represents two things. One is an
assurance that the view is a group, or consensus, view of the ledger held
by the DLT system as a whole. The other is evidence of authenticity of
the state projection that the view represents. And though the
construction of a proof is very DLT-specific, the notion that a proof may
be supplied with a view can be embodied in a DLT-independent
specification, thereby adhering to the principle of DLT opacity to the
communication infrastructure. Finally, proofs are also consistent with
the "what, not how" principle because they certify that a view represents
state at a given point in time and not the history of events that led to
that state.
Now we can look at the structure of a view in more detail. At a high
level, a view consists of the following:
o Request Id: a unique value corresponding to the request for a view
made by an external entity to the DLT system.
o Data: ledger state projection, or derived information, with proof.
o Metadata: attributes of the payload used to unpack and interpret it.
Data consists of the following:
o View Address: this is supplied by an external entity, and is the
equivalent of a "getter function" that can be used to uniquely
identify (or derive) projection into a DLT system state.
o Information: this is the actual ledger state projection.
o Schema: this described the Information data structure and can be used
to unpack (or unmarshal) it. It is optional if the ledger schema is
well-known.
o Proof: This is a structure that validates the Information. It is
optional, though recommended for DLT system views.
o Proof Schema: this describes the Proof data structure. It is optional
if the proof schema is well-known.
Metadata consists of the following:
o View Type: this tells us whether the view is a singleton data item, a
collection of data items, or a computation over data items that are
part of the DLT system state.
o Protocol Type: this denotes a unique value associated with a given DLT
protocol; e.g., Bitcoin, Ethereum, Hyperledger Fabric, Corda, Solana.
o Timestamp: this denotes the time at which the view was produced.
o Proof Type: this denotes the type, or category, of proof being
supplied, e.g., Notarizations/certifications (also called proof of
authority), Simplified Payment Verifications, Zero Knowledge Proof,
Proof of Proof-of-Work.
o Serialization Format: this denotes the format used to serialize the
view data, e.g., XML, JSON, protocol buffer.
o Commitments: these are commitments made on the view by authorities or
infrastructure (e.g., the Ethereum Mainnet) external to the DLT
system.
4.3. Simple Views
A simple DLT view is any unit of a database within a DLT system that is
exposable through interfaces programmed over that database. More
concretely, any blockchain or smart contract system provides the ability
to write scripts or procedures that can act on the raw ledger (database)
data, accompanied by interfaces to trigger those scripts or procedures to
query or update ledger state. In such a system, a simple view is any
information that can be obtained directly through an invocation of this
interface, e.g., any transaction exposed by a smart contract deployed on
a ledger within the system.
In the DLT view structure specified earlier, the View Type within
Metadata will be set to SIMPLE if such a view is requested by an external
entity. The content of the view address (described later in this draft)
can be interpreted to know if the external entity is requesting a simple
view.
4.4. Aggregate Views
An aggregate DLT view is a collection of addressable units of databases
within a DLT system. In effect, it is an array of simple views, which can
be derived through multiple invocations of different scripts or smart
contract transactions acting on raw ledger data. In the DLT view
structure specified earlier, the View Type within Metadata will be set to
AGGREGATE if such a view is requested by an external entity. The content
of the view address (described later in this draft) can be interpreted to
know if the external entity is requesting an aggregate view.
4.5. Complex or Processed Views
A complex or processed DLT view is the output of a function computed over
a set of addressable units of databases within a DLT system. In effect,
it is a function computed over an aggregate view. In the DLT view
structure specified earlier, the View Type within Metadata will be set to
AGGREGATE if such a view is requested by an external entity. The content
of the view address (described later in this draft) can be interpreted to
know if the external entity is requesting a complex view, and the
function to be computed will also be specified in the view address.
4.6. View Proofs
Proof within a view must ratify the view’s contents as the consensus over
a projection of ledger state by members of the DLT system. Because the
projection of state is itself DLT-specific, though it can be wrapped in
DLT-neutral structures as we have described earlier, the proof also takes
DLT-specific shapes. But we can list the set of attributes any proof must
contain in abstract terms as follows:
o Association of response with request: a connection (ideally,
cryptographically secure) between the request supplied in the view
address with the ledger state projection as inferred by the source
system. For instance, this can take the form of a signature over a
common structure consisting of both the request and the response.
o Authenticity of response: a connection (ideally, cryptographically
secure) between a member generating a ledger state projection and its
DLT system. For instance, this can take the form of a certificate
chain associating the signer with the DLT system’s membership
authorities. This is necessary for a permissioned DLT system and is
optional for open (or permissionless) DLT systems.
o Evidence of consensus: information showing that the view contents are
agreed upon by the network as a whole. For a permissioned DLT system,
this typically implies that an identical and authentic ledger state
projection must be provided by a large enough quorum of its members so
that the view cannot be repudiated in the future. In an open (or
permissionless) system, this can simply be the portion of a mined
block that shows why it belongs to the longest chain; i.e., proof-of
work or succinct versions of it (like Proof-of-Proof-of-Work [Naka08],
or PoPoW [Kiay16][Kiay17]). In any DLT system, such evidence can
optionally pass a policy check, where the policy rule is supplied by
the view requestor and typically embodies the consensus logic that led
to the commitment of the ledger state projection being requested.
5. Ledger State View Addresses
To request a view from a DLT system, an external entity must be able to
unambiguously specify the information it seeks in the form of a view
address. The use of the term “address” follows from the abstraction of a
DLT system as a repository of data resources that can be retrieved and
computed on. A view address in blockchain or distributed ledger systems
is equivalent to URLs [RFC1630] (for example, specified as an HTTP
address [RFC2616]), which are used to address resources offered by
Internet and World Wide Web servers [RFC1738].
From a functional perspective, a view address can also be thought of as
an interface over a “getter”, which is a standard software pattern used
to fetch data values in a computer program. The schematic representation
of a getter is dependent on the protocol followed by the underlying
distributed ledger system, but is conceptually abstracted away by the
view address. An external entity can create and manipulate a view address
without understanding its semantics and usage, which are hidden by the
DLT system. This allows the system to use alternate representations for
getters internally without requiring external entities to understand the
implementations of these operators. The view address states the “what”
and not the “how”.
A view address must be a globally unique identifier of a view on a
distributed ledger system, because global interoperability is our goal.
Therefore, as with DNS addresses for Internet servers and URLs for World
Wide Web resources, a view address is a hierarchical address, with
different segments identifying units of decreasing size and increasing
specificity in sequence. The syntax is as follows:
address = location-segment "/"
ledger-segment "/"
view-segment
; distributed-ledger-system/ledger/data-projection
The location-segment provides identification and reachability information
for the distributed ledger system. The ledger-segment identifies a unique
ledger within this system, and the view-segment identifies a view or
state projection from that ledger.
Decentralized ledger systems don’t have a single location as they are
built on networks of peer nodes. Maintainers of these systems may expose
one or more endpoints for external entities to access views, which can be
hosted on the network nodes themselves or on designated gateways.
Gateways form the communication infrastructure for cross-system
interactions and can be deployed in different configurations: a single
system may possess multiple gateways, or a single gateway may serve
multiple systems. Therefore, to formulate a view address, one needs to
know the set of endpoints that lead to a given distributed ledger system
and a unique identifier for the network that hosts that system. In
certain systems and gateways, an identifier that represents a set of
endpoints can be used instead of explicitly enumerating those endpoints.
Also, if the specified set of endpoints is known to serve a single
system, the network identifier can be omitted. The syntax of the
location-segment is as follows:
location-segment = gateway ["/" network-id]
gateway = endpoint *(";" endpoint) / name
endpoint = host [":" port]
host = hostname / IP-address
port = 1*DIGIT
network-id = name
hostname = name 1*("." name)
name = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-")
IP-address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
A single gateway serving a given distributed ledger system (network) can
be represented as follows:
location-segment = gateway.trade.com:7542/trade-network
\____________________/ \___________/
| |
endpoint network
Multiple gateways serving a network can be represented as follows:
location-segment = gateway1.trade.com:7542; \
gateway2.trade.com:7542; |--gateway (endpoints)
gateway3.trade.com:7542 /
/trade-network
\___________/
|
network
Gateways serving a single well-known network can be represented as
follows:
location-segment = gateway1.trade.com:7542;gateway2.trade.com:7542
\_____________________________________________/
|
gateway (endpoints)
The ledger-segment names either the ledger, if that ledger has a distinct
identifier within the system, or a procedure to access a ledger, which
represents a common set of facts shared by a subset of members of the
network that maintains the distributed ledger. These subsets may overlap;
i.e., certain nodes may maintain more than one ledger in the system. The
procedure name can take the form of an identifier that represents, say, a
decentralized application spanning certain nodes, or an explicit
enumeration of the identifiers of the nodes themselves. The ledger
segment syntax is as follows:
ledger-segment = *1(
(ALPHA / "_")
1*(ALPHA / DIGIT / "_" / "-" / ";" / “:”)
)
The ledger-segment can be blank if the distributed ledger system has a
single ledger. This is the norm in open blockchain systems like Bitcoin
or the Ethereum Mainnet, and in private Ethereum-based systems like
Quorum and Hyperledger Besu.
Examples are as follows:
ledger-segment = trade-channel
\___________/
|
ledger name
ledger-segment = paymentsDapp
\___________/
|
procedure/app name
ledger-segment = paymentsDappNode1:9005;paymentsDappNode2:9005
\____________________/ \____________________/
| |
procedure/app node procedure/app node
The view-segment uniquely identifies a view within a ledger. Features
particular to a distributed ledger technology will determine how to
encode this segment, but we can draw out common abstractions across DLTs
to create a generic specification. All such technologies offer a
procedural interface to access and manipulate data, typically (but not
always) in the form of a smart contract. The exposed interface offers
multiple functions to generate views based on the provided input. Hence,
we can specify the view-segment as being composed of a contract, a
function, and a list of input arguments. In the most general case, a
default contract may be assumed, and arguments may be unnecessary, and so
these can be omitted. The function, which can either be a procedural
identifier, or a direct reference to a data item or collection of data
items, or a programming instruction, must be specified. The view-segment
syntax is as follows:
view-segment = [contract-id] ":"
function-spec *(":" input-argument)
contract-id = (ALPHA / "_") 1*(ALPHA / DIGIT / "_")
function-spec = name
input-argument = name
name = *HEXDIGIT ; hex-encoded ASCII string
An example of a view-segment for a Hyperledger Fabric ledger is:
view-segment = trade-chaincode:getBillOfLading:bill-10012
\_____________/ \_____________/ \________/
| | |
contract function argument
An example for a Corda ledger is:
view-segment = :com.trade.dapp.flows.GetDocumentByTypeAndId:C:5
\_________________________________________/ \_/
| |
function arguments
An example of a complete view address is as follows:
gw.trade.com:7542/traden/tradel/tradec:getBill:bill-10012
\______________________/ \____/ \_______________________/
| | |
location-segment ledger-segment view-segment
6. Ledger State View Verification Policies
A verification policy for a ledger state view is a set of rules that the
proof within the view can be validated against (or filtered through). The
condition embedded within a rule can be arbitrary, though in practice, it
should embody the process by which that ledger’s state was updated and
consented to in a decentralized manner by the network of peers
maintaining it. In permissioned networks built on DLTs like Hyperledger
Fabric or Corda, a policy typically requires evidence of attestations
made by a sufficiently large, or representative, portion of the peer
network maintaining the ledger. This takes the form of a set of
signatures and is crucial to validating views generated by networks built
on DLTs like Hyperledger Fabric and Corda. In open networks, we can
envision policies that require validation of the view data being derived
from a block in the longest chain, for example. But in this
specification, we will consider only attestation-based policies and leave
more general policies to future drafts.
The structure of a verification policy is as follows:
o Security Domain: a unique identifier for the distributed ledger system
(or network maintaining it) projecting the ledger state view.
o Rules: a set of rules, each governing the validation of artifacts
exposed through a particular category of views within the Security
Domain.
Each Rule consists of the following:
o View Pattern: a regular expression that can match a set of views.
o Policy: a policy rule/filter governing all views that match View
Pattern.
Each Policy consists of the following:
o Type: an identifier or flag denoting the type of this policy rule. For
attestation-based policies, this should be set to “Signature”, and
other identifiers can be created for other policy types in future
drafts.
o Criteria: a Boolean expression with ANDs and ORs, where the principals
consist of (1) the name of a DLT system unit/stakeholder (typically
corresponding to a subset of nodes in the peer network), and (2) the
number of signatures requires from this unit.
7. Ledger State View Request
A view request is a message sent to a distributed ledger system by any
external entity. It consists of the following:
o View Address: uniquely identifies the data sought by the requester.
o Verification Policy: indicates the proof criteria for the requested
view.
8. Ledger State View Access Control Policies
An access control policy for a ledger state view is a set of rules
governing the exposure of the view to an external entity. Each rule maps
a set of principals to a set of views. The structure of an access control
policy is as follows:
o Security Domain: a unique identifier for the entity (which can be a
distributed ledger system itself) requesting a ledger state view.
o Rules: a set of rules, each governing access from some entity within
Security Domain to artifacts exposed through a particular category of
views.
Each Rule consists of the following:
o Principal: a string that can match a set of subjects or principals,
which can represents an individuals or an organization or a subgroup
within an organization identified by role or attribute set (profile).
o Principal Type: a keyword that denotes the nature of the principal.
This can be one of the following:
o PUBLIC-KEY: indicates that the principal is a public key associated
with an individual member of the Security Domain.
o CA: indicates that the principal is a certification authority for
an organization within the Security Domain.
o ROLE: indicates that the principal identifies a role within the
Security Domain.
o ATTRIBUTE: indicates that the principal identifies a set of
attributes, or a profile for a member, within the Security Domain.
o ‘*’: indicates that the principal can be any member of the Security
Domain. The Principal can be left blank in this case.
o Resource: a regular expression that can match a set of views, which
identifies the objects governed by this rule.
o Read: a Boolean flag indicating whether this rule is currently active.
9. Related Open Issues
This draft provides a specification for views and how to addresses them.
It further describes a protocol whereby one system can request a view
from another through gateways. But there are several aspects of the end
to-end process, which are extraneous to the data sharing protocol yet
crucial to its successful completion. Though detailed specifications of
these are beyond the scope of this draft, we list them in this section
for readers’ considerations.
9.1. Forms of proof
Though we have tried to be agnostic of the nature of the proof associated
with a view in this draft, the data sharing protocol implicitly assumes
that the proof takes the form of a quorum of digital signatures from
parties belonging to a permissioned distributed ledger system. But
several other proof types can exist, each suitable to the type of system
that is exporting a view and the technology stack and consensus mechanism
it is built on [Naka08][Kiay16][Kiay17][PoS][PoET][PoA].
9.2. Temporal guarantees of view authenticity
The view address as specified in this draft has no temporal component,
implicitly conveying a request for the latest or “freshest” state
projection from a shared ledger. Even apart from expanding the
specification of the view address to include, for example, an absolute or
relative timestamp, we will need to augment the data sharing protocol
with a mechanism to convey proof of temporal veracity of a view. Work
done on verifiable observation of shared ledgers using a public bulletin
board [Abebe21] can be taken as the starting point for such a
specification.
10. References
10.1. Normative References
[FATF] FATF, "International Standards on Combating Money
Laundering and the Financing of Terrorism and
Proliferation - FATF Revision of Recommendation 15",
October 2018, <http://www.fatf-
gafi.org/publications/fatfrecommendations/documents/fatf-
recommendations.html>.
[ISO] ISO, "Blockchain and distributed ledger technologies-
Vocabulary (ISO:22739:2020)", July 2020,
<https://www.iso.org>.
[NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
Blockchain Technology Overview (NISTR-8202)", October
2018, <https://doi.org/10.6028/NIST.IR.8202>.
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW, IETF
RFC 1630", June 1994,
<https://datatracker.ietf.org/doc/html/rfc1630>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL), IETF RFC 1738", December 1994,
<https://datatracker.ietf.org/doc/html/rfc1738>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1, IETF RFC 2616", June 1999,
<https://datatracker.ietf.org/doc/html/rfc2616>.
[SATA] Hardjono, T., Hargreaves, M., Smith, N., and V. Ramakrishna,
"Secure Asset Transfer (SAT) Interoperability Architecture,
IETF, draft-ietf-satp-architecture-02.", January 2024,
<https://datatracker.ietf.org/doc/draft-ietf-satp-
architecture/>.
[SATP] Hargreaves, M., Hardjono, T., and R. Belchior,
"Secure Asset Transfer Protocol (SATP), IETF,
draft-ietf-satp-core-02.", July 2023,
<https://datatracker.ietf.org/doc/draft-ietf-satp-core/>.
10.2. Informative References
[Abebe21] Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit, V.,
Ramakrishna, V., and J. Yu, "Verifiable Observation of
Permissioned Ledgers, IEEE International Conference on
Blockchain and Cryptocurrency (ICBC) 2021", May 2021,
<https://arxiv.org/abs/2012.07339>.
[Andr18] Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,
Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,
Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C.,
Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti, A.,
Stathakopoulou, C., Vukolic, M., Weed Cocco, S., and J.
Yellick, "Hyperledger Fabric: A Distributed Operating System
for Permissioned Blockchains, Eurosys", January 2018,
<https://arxiv.org/abs/1801.10228>.
[BVGC20] Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
Correia, "A Survey on Blockchain Interoperability: Past,
Present, and Future Trends", May 2020,
<https://arxiv.org/abs/2005.14282v2>.
[Clar88] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols, ACM Computer Communication Review, Proc SIGCOMM
88, vol. 18, no. 4, pp. 106-114", August 1988.
[Ethe22] "Ethereum Whitepaper", September 2022,
<https://ethereum.org/en/whitepaper/>.
[Gray81] Gray, J., "The Transaction Concept: Virtues and
Limitations, in VLDB Proceedings of the 7th International
Conference, Cannes, France, September 1981, pp. 144-154",
September 1981.
[Hear19] Hearn, M., and R. G. Brown, "Corda: A Distributed Ledger,
Corda Technical Whitepaper | R3", December 2019,
<https://www.r3.com/blog/corda-technical-whitepaper/>.
[Herl19] Herlihy, M., "Blockchains From a Distributed Computing
Perspective, Communications of the ACM, vol. 62, no. 2,
pp. 78-85", February 2019,
<https://doi.org/10.1145/3209623>.
[HLP19] Hardjono, T., Lipton, A., and A. Pentland, "Towards and
Interoperability Architecture for Blockchain Autonomous
Systems, IEEE Transactions on Engineering Management",
June 2019, <https://doi:10.1109/TEM.2019.2920154>.
[HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted
Computing Base for Blockchain Infrastructure Security,
Frontiers Journal, Special Issue on Blockchain Technology,
Vol. 2, No. 24", December 2019,
<https://doi.org/10.3389/fbloc.2019.00024>.
[Kiay16] Kiayias, A., Lamprou, N., and A.-P. Stouka, "Proofs of proofs
of work with sublinear complexity, International Conference on
Financial Cryptography and Data Security, pages 61–78,
Springer", 2016.
[Kiay17] Kiayias, A., Miller, A., and D. Zindros, "Non-Interactive
Proofs of Proof-of-Work, Cryptology ePrint Archive, Paper
2017/963", September 2017, <https://eprint.iacr.org/2017/963>.
[Naka08] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System,
Decentralized Business Review", October 2008,
<https://bitcoin.org/bitcoin.pdf>.
[PoA] Antolin, M., "What Is Proof-of-Authority? Understanding PoA
Consensus Mechanisms, CoinDesk", June 2022,
<https://www.coindesk.com/learn/what-is-proof-of-authority/>.
[PoET] Bowman, M., Das, D., Mandal, A., and H. Montgomery, "On
Elapsed Time Consensus Protocols, Cryptology ePrint Archive,
Paper 2021/086", 2021, <https://eprint.iacr.org/2021/086>.
[PoS] "Proof-of-Stake (PoS) | ethereum.org", September 2022,
<https://ethereum.org/en/developers/docs/consensus-
mechanisms/pos/>.
[SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
in System Design, ACM Transactions on Computer Systems,
vol. 2, no. 4, pp. 277-288", November 1984.
Contributors
The authors would like to thank Dhinakaran Vinayagamurthy of IBM
Research, India, for discussing and brainstorming the ideas and
specifications presented in this draft, and subsequently reviewing this
draft and providing constructive suggestions for its improvement.
Authors' Addresses
Venkatraman Ramakrishna
IBM Research
Bangalore, India
Email: vramakr2@in.ibm.com
Vinayaka Pandit
IBM Research
Bangalore, India
Email: pvinayak@in.ibm.com
Ermyas Abebe
Consensys
Melbourne, Australia
Email: ermyas.abebe@consensys.net
Sandeep Nishad
IBM Research,
Bangalore, India
Email: sandeep.nishad1@ibm.com
Krishnasuri Narayanam
IBM Research
Bangalore, India
Email: knaraya3@in.ibm.com