Towards a Contract Service Provider Model for Virtual Assets and VASPs
TTowards a Contract Service Provider Modelfor Virtual Assets and VASPs
Thomas Hardjono Alexander Lipton Alex PentlandMIT Connection Science & EngineeringMassachusetts Institute of TechnologyCambridge, MA 02139, USA [email protected] [email protected] [email protected]
September 15, 2020
Abstract
We introduce the contract service provider (CSP) model as an analog of the success-ful Internet ISP model. Our exploration is motivated by the need to seek alternativeblockchain service-fee models that departs from the token-for-operations (gas fee) modelfor smart contracts found on many popular blockchain platforms today. A given CSPcommunity consisting of multiple CSP business entities (VASPs) form a contract domain which implement well-defined contract primitives, policies and contract-ledger. The nodesof the members of CSP community form the blockchain network. We discuss a numberof design principles borrowed from the design principles of the Internet Architecture, andwe discuss the interoperability of cross-domain (cross-chain) transfers of virtual assets inthe context of contract domains.
Keywords : Blockchains, smart contracts, virtual assets, contract service providers, con-tract domains. a r X i v : . [ c s . CR ] S e p ontents Introduction
The recent rise in the cost of transactions on Bitcoin and Ethereum illustrates the realitythat the virtual asset industry is still in its nascency and that further consideration needs tobe placed on the long-term feasibility of the tokenized operations model (i.e. gas fee model).The gas-fee model has a number of unintended side effects, including platform capture of end-users, unsafe smart contracts and the lack of incentives to solve the blockchain interoperabilityproblem [1, 2].In this paper we explore the notion of a contract service provider (CSP) model as ananalog of the decades-old Internet Service Provider (ISP) model that has enabled the Internetto expand and flourish. Our CSP model is driven by a number of design principles thatborrow from the design principles of the Internet Architecture [3, 4]. We discuss these designprinciples towards the end of the paper in order to first discuss the CSP model.We seek to make the paper readable to a wide audience, and as such have sought to limitthe usage of technical jargon. However, we assume the reader is at least familiar with Bitcoin,cryptocurrencies, and distributed ledgers generally.
A Contract Service Provider (CSP) is a regulated service provider who collaborates with otherCSPs in making available on distributed nodes one or more smart contract primitives thatconsists of simple operations applicable to certain virtual assets issued by an authoritativelegal entity . Collectively, the group of CSPs offers contract services to one or more regulatedcustomers , which may include individuals and organizations. The contract primitives andthe supported types of assets are chosen by the CSPs prior to deployment, and the set ofprimitives are not user-programmable. The goal of the contract service is to execute fixed setof functions on virtual assets, as invoked by the customers of the CSPs. As such, the CSPparadigm is similar to the
Function as a Service (FaaS) model [5].There are number of motivations for the contract service paradigm: • Alternative fee-for-service business model : The contract service model provides an op-portunity for a classic fee-for-service model for processing transfers of different typesof regulated virtual assets. Since the primitives are simple and since the blockchainis not user-programmable, there is a deterministic and predictable cost for a serviceprovider to participate in a CSP group. The CSPs determine the operating rules ofthe community, the amount of computing resources each CSP must put forward, andthe CSPs can monitor each other with regards to the performance of the contractualobligations of members of the CSP community.This approach is a departure from the gas fee model used in the Ethereum platform [6]where the price of the Ether has been shown to fluctuate dramatically depending onthe popularity of certain contracts (e.g. DeFi [7, 8]) and where the overall throughputof the blockchain may be affected by popular contracts (e.g. CryptoKitty [9, 10])3hat negatively influence the availability of other contracts unrelated to the popularcontracts. • Reduction of fees by separation of business logic from contract primitives : Enablingend-users to freely program complex code logic directly on the blockchain nodes usinga fully-fledged object language (e.g. Solidity [11]) fulfills the intended goal of manyplatform providers, namely platform capture of customers. The more complex the codelogic, the more operations consumed and the higher the total gas fees obtained overallby the platform owners. However, as the fees climb higher this encourages Ponzi-likeschemes where new entrants boost the profits of existing participants by driving demandfor tokens [12].Platform capture disincentivize interoperability of blockchain networks, and results indelays in the broad adoption of smart contracts technologies by the financial sector.Other negative side effects of on-chain complex code designs is the higher likelihood ofhuman error and intentional abusive programming (e.g. DAO Hack due to reentrancyvulnerabilities [13, 14, 15]). • Support for interoperability across blockchain systems : The use of simple contract prim-itives for specific types of assets generally lends itself more readily for interoperabilityof blockchain systems. When two blockchain systems employ semantically equivalentconstructions of contract-primitives – albeit using different syntaxes (different program-ming languages) – with their ledgers capturing comparable data structures representingsimilar transactional behaviors, this results in the higher likelihood of business interop-erability across blockchain systems based on technical interoperability.
The following is a summary of the terminology we use in the current work, with furtherexpansion in the following sections: • Contract Service : Smart contract services defined by the set of primitive operationsimplemented on-chain and the asset-types processed through the primitives. • Contract Service Provider (CSP): A regulated service provider (e.g. registered business)that participates in making available contract services to its customers. • CSP Community : A group of CSPs offering contract services on a blockchain networkconsisting of their nodes. • Contract Domain : The various computing resources required to implement a contractservice, including contract-specific functional components (i.e. primitives, contract-ledger, consensus algorithm and domain policies) and the other technological constructsthat implement the domain. 4
Virtual Asset Service Provider (VASP) : Entity dealing with virtual assets covered underthe FATF definition for virtual assets and the Travel Rule (see [16, 17]).The contract service provider (CSP) model is based on the following design principlesthat takes into account code complexity considerations and the provider’s deployment con-siderations:(a)
Contract simplicity principle : Each smart contract should implement a simple andmodular well-defined function, following classic object-oriented design principles. Thisis also referred to as the decentralized primitives principle.(b)
Constrained authorship principle : Each contract must be made available only by acontract service provider (CSP) entity within the group of CSPs.(c)
Node diversity principle : A contract service blockchain network must employ a diversenode-technology implementations and be owned/operated by a diverse set of providers.(d)
Mediated oracle principle : Any representation of value that originates from outside thecontract service (contract domain) must enter (be introduced) into the contract servicethrough the mediation of a contract service provider.(e)
Opaque ledgers assumption : Any cross-chain or cross-domain asset transfer protocolmust be designed based on the assumption that the ledgers of the respective blockchainsare not externally readable/writeable.We discuss the design principles in more in detail in Section 7.
We define a
CSP community as a group of regulated contract service providers offering asset-related smart contract services on a blockchain network whose nodes are composed of thecomputing resources of the members of the CSP community. The notion of a communityis contract-centric in that the CSPs in a community agree to allocate computing resourcesfor a given smart contract service. A given CSP community may be constituted to providecontract services for a single smart contract or for several related smart contracts on thesame blockchain network. A contract service is defined by the set of contract primitives implemented on-chain and the asset-types processed through those primitives. An entity(individual or organization) is considered to be a regulated customer of a CSP by virtueof purchasing access to the smart contract services through that CSP. For a given contractservice, an entity should be a customer of one CSP only in the CSP community. The CSPcommunity must clearly define beforehand the contract primitives and the asset-types thatconstitute the contract-service, in order to prevent confusion on the part of customers.From a legal perspective, a CSP community must be founded on a legal contractualagreement that defines the obligations and liabilities of each of the members to the community5igure 1: Simple example of three (3) CSP communities viewed from a contract-centricperspectiveand to the customers of members. The community defines a service level agreement (SLA)for the customers of the members. This approach is akin to multi-lateral peering agreementsused by Internet Service Providers (ISPs), which defines common data routing responsibilitiesacross multiple networks.A simple example of three (3) CSP communities is shown in Figure 1. Community C1are CSPs providing contract service SCS1, the Community C2 providing contract serviceSCS2, while Community C3 the contract service SCS3. The CSP X is active in all threecommunities, where in each case it makes available computing resources (nodes) to eachcommunity. In two cases (the intersection areas of Figure 1) the CSP X is using contractmulti-tenancy on the same nodes.
We use the notion of the contract domain in order to reason more accurately about thevarious technical and implementation aspects of a contract service, including access to thecomponents of the contract service (e.g. contract calling APIs, ledger, etc). A contractdomain is defined by a CSP community through a combination of the following: (i) theset of contract-primitives that constitute the contract service together with the contractledger and consensus algorithm for the ledger; (ii) the policies regarding the asset typespermitted to be transacted in the jurisdiction of operation of the CSP community; (iii) thenodes infrastructure that implements the contract-primitives and enforces policies. This isshown in Figure 2. For simplicity, we use the term domain functions in a domain to referto the technical components (i.e. contract-primitives, contract-ledger, consensus algorithmand domain policies) and the other technological constructs that implement the domain (e.g.membership management, asset validation, etc).A contract domain coincides with the CSP community in that both represent the same6igure 2: Overview of a contract domainparticipating business entities (e.g. CSPs) and the resources (i.e nodes) dedicated by thebusiness entities to establish the contract service. Thus, for business reasons a given CSPentity may be member of different CSP communities simultaneously at any given moment,where it allocates the computing resources required for each community (e.g. minimal M nodes). In each community, the contract domain structure ensures that a separate ledgerand consensus mechanism is used to record the asset transactions in that contract domain.Figure 3 illustrates a case in which some CSPs are participating in several contract domainssimultaneously. For example, CSP-A is participating contract-domains CD1, CD2 and CD3,while CSP-C is participating in domains CD2 and CD3 only. This means that CSP-A, CSP-Band CSP-C share a common contract-ledger for CD3 and jointly participate in the consensusmechanism to maintain that contract-ledger. The CSP-A, CSP-C and CSP-D a commoncontract-ledger for domain CD2.There are several aspects worth noting about a contract domain and the resources (nodes)implementing the contract domain: • Per contract-domain consensus algorithm and decentralized ledger : The nodes that im-plement the contract service in a domain employ a separate consensus algorithm andcontract-ledger specifically for that the contract service. The choice of consensus algo-rithm and form of the ledger blocks is defined by the CSP community through theirformative the legal agreements.Thus, in Figure 3 there is a separate ledger for contract service SCS1, SCS2 and SCS3.The provider CSP A participates in maintaining three (3) separate ledger for each ofthese three contract-domains. • Opaque ledgers and contracts to non-customers : When a customer obtains services from7igure 3: Illustration of CSP participation in several contract domainsa CSP who is a member of a CSP community, the customer has visibility only into therelevant resources (e.g. contract ledger) for that CSP community. This follows from theopaque ledgers principle (described below in Section 7.5). A given CSP may participate(i.e. dedicate nodes) in multiple CSP-communities (contract domains), each of whichdeploys a distinct consensus algorithm and ledger.Using Figure 3, if a customer of CSP-A purchases access to contract-service SCS3(domain CD3), the customer has visibility only to the ledger for SCS3 (i.e. no accessto ledgers for SCS1 and SCS2).In the remainder of this paper, we will use the term “CSP community” when discussing thebusiness and legal aspects of contract services by a CSP, and we shall use “contract domains”when discussing the technical aspects of the contracts, nodes, ledgers and blockchain.
The goal of the simple primitives principle is to ensure that smart contract services implementsimple primitive functions that can be used by (i.e. called by) higher layer applications thatcontains the complex business logic. Although there are several possible primitives that acontract-service may use, we believe the following represents the minimal primitives whichmust be implemented in a contract domain: • Asset transfer from one customer to another : This operation moves the ownership of avirtual asset from one customer to a second customer, both of which must have beenpreviously onboard by a CSP in the community. This is equivalent to Bitcoin’s paymentto public key (or to a hash of public key).8
Asset escrow to another customer or to CSP : This operation conditionally moves theownership of a virtual asset from one customer to another, or to a CSP in the commu-nity.The choice of which the escrow CSP is determined by the operating rules of the CSPcommunity (e.g. random choice). The escrows are time-limited, meaning that if thecondition fails to be satisfied within the specified time, the asset reverts back to thecustomer. • Asset ingress into blockchain : This operation introduces a regulated virtual asset intothe contract domain, making it available to trade for customers. This event maybe atthe request of a customer of a CSP. This operation is available only to a CSP becausethe CSP must validate the legal status of the asset prior to introducing it into thecontract domain. A customer cannot introduce virtual assets on their own. • Asset egress from blockchain : This operation removes a regulated virtual asset fromthe contract domain, making it no longer available to customers. This operation isavailable only to a CSP. It marks the ledger to indicate that the asset has moved toanother contract domain and therefore unavailable for further use.Other contract primitives possible include those pertaining to key management and toand different types of virtual assets. For example, the key management tasks include: intro-duction of a customer (new customer) public-key into the contract domain; key-rotation (orrevocation) of customer’s public-key; introduction of a new CSP public-key; key-rotation (orrevocation) of CSP’s public-key; and so on. Asset related tasks include: introduction of anew asset-type (e.g. new stablecoin, etc.), removal of an existing asset-type; and so on. Theseare beyond the current work and are dependent on the contract service and CSP communitythat implements the contract service.
The computing resource to be allocated by each CSP in a CSP-community, the specificationsof the technical mechanisms (e.g. protocols) to be used in the community, as well as otheroperational aspects of the contract domain is expressed in the
CSP community membershipagreement document, which is a legally binding contractual agreement. The specifications ofthe technical mechanisms for a given contract domain is referred to as the contract domainprofile document.The community membership agreement may also specify the number of CSP entitiesminimally required to implement the contract domain, and the methods to add or subtractthe CSP membership. The agreement may also place a time duration commitment on CSPs,meaning that once a contract service is made operational by a CSP community the CSPs arebound to be a member (i.e. allocate nodes and computing resources) until the end of theduration. 9rom a revenue perspective, the CSP community membership agreement must specifythe revenue sharing structure of the CSPs in that community. For example, for each newcustomer brought by a CSP entity, the CSP may be mandated to share a certain percentageof the fees paid that customer. Other revenue sharing models may be based on the numberof transactions transmitted from customers of CSPs.Although beyond the scope of the current work, the notion of a nodes diversity index couldbe defined in the CSP community membership agreement as a measure of the diversity ofthe node-implementation technologies [18]. The node diversity index may provide customerswith a tangible indicator of the resiliency of the blockchain network as a whole.
One of the main decision factors for a CSP as a business entity is the amount of comput-ing resources it needs to allocate to a contract domain. CSPs have the freedom to im-plement nodes using various technologies (e.g. bare metal computers; private cloud-basedcompute units; public-cloud hosted virtual machines, and so on). An example is shownin Figure 4. Certain contract domains (CSP communities) may require that the contract-ledger be readable/writeable only to other CSPs in the same contract domain (i.e. privatecontract-ledger), while other contract domains may require that the contract-ledger merelybe member-writeable (but publicly readable). In choosing its node implementation strat-egy, a CSP must cognizant of these community specific requirements as describe in the CSPcommunity membership agreement.For a CSP it is useful to logically divide the functions and resources needed for theimplementation of a contract domain following a layered architecture: • Contract primitives layer : The constructs at this layer include the contract-code, public-keys, digital certificates, signed claims (regarding data sources) by CSPs, and others. • Transaction data layer : The resources at this layer include CPU for processing trans-actions, storage for historical blocks of confirmed transactions, data sharding mecha-nisms [19] and other transaction-related events data. • Consensus mechanisms layer : The resources at this layer include code implementationsof the consensus mechanism chosen by the CSP community for the contract domain(e.g. Proof of Work [20], Proof of Stake [6, 21], and others [22, 23]). • Contract policies layer : The constructs at this layer include the policies related to thecontract domain and mechanisms implementing and enforcing these policies. • Node network layer : The resources at this layer include IP network connectivity, dis-covery of nodes in the CSP community, topology management, new transaction prop-agation, and others. 10igure 4: Example of node implementation strategies for CSPs • Hardware identification and node attestations layer : In this layer, hardware-relatedcapabilities information are exposed to higher layer functions as a means to establishattestations by nodes [5, 24] regarding the trustworthiness of the node implementation.Figure 4 provides a high level node-centric illustration of the various strategies CSPs mayemploy to realize a contract domain. The configuration (i) shows a “bare metal” implemen-tation of a node where the CSP-A owns and operates the full stack. In configuration (ii)the CSP-B participates in two contract domains (CD1 and CD2) each associated with twodistinct communities. In configuration (iii), the CSPs employ a third-party cloud providerthat offers multi-tenancy.
The contract service provider model assumes that value associated with virtual assets origi-nate from outside the contract domain, and that an authoritative legal entity has accordeda denominated value to a virtual asset prior to the asset being ingested into the contract do-main (mediated by one or more CSPs in the domain). This philosophy is consistent with ourstated motivations of exploring alternative fee-for-service models that does not rely on utilitytokens for operations fee (i.e. gas fee), which has a number of downsides for customers [7, 8].The method to determine the value of an asset is outside of the current work, and severalmechanisms have been proposed (e.g. see [25, 26] for a proposed taxonomy).The function of issuing virtual assets based on real-world assets or other denominationalvalue is assumed to be performed by an asset
Issuer authority. The function converting virtualassets into its denomination equivalent is assumed to be performed by an asset
Acquirer authority. This assumption is consistent also with a number of exploratory projects that11igure 5: Sources of value for virtual assets external to the contract-domainhave been reported (e.g. Project Ubin Phase-5 in Singapore [27]; Project Whitney at theDTCC [28, 29]).Figure 5 two general uses cases where two CSPs in two asset compatible contract-domains(CD1 and CD2) are involved in the transfer of assets. In Figure 5(a) both CSP-A and CSP-X reside within the same legal jurisdiction J1 (eg. same country) and therefore both CSPscan rely on the same issuer/acquirer of the virtual asset. When the virtual asset has beenintroduced into the contract-domain CD1, it is transferable within CD1 in the usual manner.When an asset is to be transferred cross-domain from CSP-A to CSP-X, the CSP-X caneasily validate the legal status of the asset to the same issuer/acquirer because domains CD1and CD2 are under the same jurisdiction J1. In Figure 5(b), the contracts domains CD1and CD2 are under different jurisdictions J1 and J2 respectively. In this case, when an assetis to be transferred cross-domain from CSP-A to CSP-X, the CSP-X must rely on its localissuer/acquirer IA2. As such, the two issuer/acquirers (IA1 and IA2) must have a businessand legal relationship that permits CSPs to query the status of virtual assets prior to transferscross-domain.The interaction model in Figure 5(b) is referred as the 4-corners model, and the term“issuer” and “acquirer” has been used for nearly two decades in the credit card paymentsindustry. In the cards payment world, the consumer (card-holder) obtains a credit card fromthe Issuer, which is often also a bank or related financial institutions. When the customeruses the card at a merchant (e.g. to purchase goods at a Point of Service (POS) terminal) themerchant forwards the transactions details to the Acquirer, which is typically the merchant’sbank or financial institution. The Acquirer then obtains payment from the Issuer bank (e.g.debited from the customer’s bank account). This model is called the 4-corners paymentsmodel because of the four entities involved [30]. It has been very successful as evident fromthe global reach of the card payments industry. The 4-corners paradigm is useful in the12ontext of a contract domain because (i) it permits the CSP role to be separated from therole of asset Issuer/Acquirer, and (ii) it permits the notion of global jurisdictions to comeinto the picture by recognizing that the issuers of virtual assets may reside in different legaljurisdictions (countries), and different degrees of compliance to the Travel Rule.
Generally speaking, all computer systems and networks operate based on some “rules” orpolicies that maybe intrinsic to their design (e.g. hardware level instruction set), or definedby the user and/or administrator of the system (e.g. file access policies). This is also trueof nodes in a blockchain network. In considering a node as a computer system composedof hardware and software components, it is helpful to view a node as compute unit made oflogical layers. This separation of functions based on logical layers provides the context withinwhich to reason about the “rules” or policies applicable to each layer. Each functional layermay have both non-configurable and configurable parameters, where the later that can beadjusted by the user/administrator.In this section we focus on policies in the contract domain, focusing specifically on thosethat affect the execution of contracts. Without going into details of a policy state-machinemodel , the basic notion is that nodes in a contract domain must react (take action) withregards to changes in conditions, which may originate externally from the domain.We use the term contract policies for rules pertaining to virtual assets and contract execu-tions within a contract domain. These are rules that are inherent within a contract domain,but which can be triggered by conditions outside the contract domain. To prevent termi-nology confusion, we use the term community core operating rules in the sense of [31] forrules and policies that pertain to the operations of the node infrastructure that implementthe contract domain by the CSP community. The core operating rules must be part of theCSP community membership agreement document (Section 4.3), which is a legally bindingcontractual agreement.
As described earlier, a key goal of the contract simplicity principle to establish a properseparation between primitive operations encoded in a contract from complex business logic(Section 7.1). In many cases, business logic become complex and intricate because it incor-porates business policies relevant to the organization.The following are some illustrative examples of policies arranged according to their con-dition/response categories: • Policies regarding changes to the condition of virtual assets : These are the set of rulespertaining to actions to be taken by a CSP should there occur a change to the externalstatus of virtual asset that is currently present within the contract domain.13xample of an external change to a virtual asset includes the Issuer going out of businessor temporarily halting operations (e.g. Issuer under legal investigation). In this case,the contract domain that has customers holding this virtual asset may choose to alsotemporarily cease all transactions related to that virtual asset. • Policies regarding changes to the condition of customers : These are the set of rulespertaining to actions to be taken by a CSP should a change occur to the status acustomer.For example, a customer of a CSP may face legal issues that necessitate the customer’sassets in the contract domain being frozen temporarily. Faced with a legal notificationfrom the relevant authority (e.g. SAR warrant) the CSP community may then tem-porarily suspend the customer’s account and/or issue an asset-lock on the customer’sassets on the contract-ledger (see Section 6.4). • Policies regarding changes to the condition of CSP membership in a community : Theseare the set of rules pertaining to actions to be taken by a CSP in response to changesin the membership composition of its CSP community.For example, assuming that a CSP is a VASP under the Travel Rule [16], if a CSP hasits VASP business license revoked by the relevant authorities then other CSPs in thatcommunity must respond as defined in the policies (e.g. ignore all new transactionsand block-confirmations from the revoked CSP). • Policies regarding cross-domain transactions : These are the set of rules pertaining toasset transfers involving an external contract domain.For example, a customer of a CSP may wish to have their virtual assets transferredout of the current contract-domain to a different contract-domain in a different CSPcommunity. In cases such as this, the policies of the contract domain may require theasset to be temporarily suspended in contract domain until it has been successfullymoved to the external contract-domain.
The core operating rules for a CSP community defines the rules of interaction of the nodes ofthe CSPs in the community across the functional layers of the nodes. As mentioned previously,we view the functional layers of a node’s resources to consist of the contract primitives layer,the transactions data layer, consensus layer, the network layer and the hardware identificationand attestation layer (see Section 4.4).Given the decentralized transaction processing model of many blockchain networks, it isnecessary to view these core rules as being applied to distributed resources with distributedpolicy enforcement model. One key component of distributed policy enforcement is the setprivileges parameters [32] that take into account the actors/roles, contract operations, assettypes and jurisdictions. 14igure 6: Policy decision points and enforcement points in a decentralized topologyFigure 6 attempts to illustrate this distributed policy enforcement model where the “poli-cies” here are the core operating rules in the CSP community. The nodes as the endpointswhich enforce the core rules must also be equipped to perform decision-making on their own– with an assumed regular synchronization to the central policy-administration point [33].Thus, the nodes as endpoints must be equipped with both PDP and PEP capabilities (Pol-icy Decision Point, and Policy Enforcement Point) [34, 35]. The core rules and subsequentupdates to those rules must originate from the governance organization of the CSP commu-nity. In Figure 6, a centralized entity called the Policy Administration Point (PAP) for thecontract domain distributes these rule-updates.
The notion of policy-driven access control to resources is not a new idea, and has in factevolved since the early days of the networked organizations over three decades ago. Tradi-tional Enterprise IT infrastructures demarcate access to resources (e.g. file-servers, printers,network elements, etc.) through the notion of access control domains [36, 37]. Thus, allsubjects, roles, objects (resources), actions, and rules (policies) are defined for the entitiesand the services that reside within the access control domain. Subjects with privileges inmultiple domains are accorded different roles when accessing resources in those domains.The differentiation between centralized and distributed networks is important from theperspective of the development of privileges architecture that govern access to resources ac-cessible to participants in the network [38]. Within traditional enterprise networked sys-tems, policy-driven access control evolved in enterprise organizations starting in the 1990s.15s shared resources (e.g. file servers) within an enterprise were made available within thenetwork (i.e. Local Area Networks (LAN)), the issue of controlling access to these sharedresources became increasingly crucial for the survival of the enterprise network, and theenterprise as a whole.The access control model that became predominant in enterprise networks was the Belland LaPadula Model (BLP) [39]. In this model, access control is defined in terms of subjects possessing different security levels , seeking access to objects (i.e. system resources). Thus, forexample, in the BLP model a subject (e.g. user) is permitted to access an object (e.g. file)if the subject’s security level (e.g. “Top Secret”) is higher than security level of the object(e.g. “Secret”). The notion of roles or capacities was added to this model, leading to the
Role-Based Access Control (RBAC) model. Here, as a further refinement of the BLP model,a subject (user) may have multiple roles or capacities within a given organization. Thus,when the subject is seeking access to an object, he or she must indicate the role within whichthe request is being made. The formal model for RBAC was defined by NIST in 1992 [40].The same RBAC model applies also to corporate resources attached to the corporateLAN. Corporate security policies was therefore expressed in terms of access-control policiesas applied to subjects in certain roles seeking access to objects residing within a given ad-ministrative domain. This problem was often referred to as Authentication, Authorizationand Audit (AAA) in the 1990s [34]. Part of the AAA model developed during the 1990s wasan abstraction of functions pertaining to deciding access rules, from functions pertaining to enforcing them. Entities which authored policies were referred to as
Policy AdministrationPoints (PAP), those who decided on access-rules were denoted as
Policy Decision Points (PDP), while entities that enforced these access-rules were denoted as
Policy EnforcementPoints (PEP)[35]. This policy-based access control model is foundational to many systems de-ployed within enterprises today, where privileges management is performed typically throughdirectory services (e.g. Microsoft Active Directory [41]) that maintains the list of valid em-ployees of the enterprise. This approach is very common in mid to large organizations,including notably those in the financial industry.
The notion of a CSP-community is based in the successful model of Internet Service Provider(ISP) communities, which implement a number of proven design principles of the InternetArchitecture [3, 4]. Two of the fundamental principles are autonomous system (AS) principleand the end-to-end principle.Each CSP-community implementing a contract domain is an autonomous system in thesense that the nodes of the CSPs can operate independently from other blockchain networks.The contract domain observes the end-to-end principle by externalizing the source of valueof virtual assets to the end-points. Thus, the contract domain is oblivious to the value ormonetary aspect of the virtual assets flowing within contract domain. This is in contrast toblockchain platforms that operate based on users purchasing tokens that are endogenous to16igure 7: Overview of transfers of virtual assets across two contract-domainsthe blockchain [42], thereby effecting platform-capture for its users.The Internet in reality is a “stitched” collection of islands of IP networks owned by ISPs,and they are able to interoperate at the technical level due to standardized protocols andinteroperate at the business and legal level due to peering agreements (bilateral agreementsand group-agreements). Similarly, CSP communities will need to develop peering agreementswith other CSP communities in order for virtual assets to be able to enter and leave contract-domains in an efficient and regulated manner.
The constrained authorship principle (see Section 7.2) means that customers (end-users) areprohibited from publishing their own contracts onto the nodes of the contract domain. Onlythe CSPs in the group are permitted to author and publish the contract primitives. Thishas the advantage that control over a smart contract [43] is unambiguously in the hands ofthe publishing CSP in the CSP-community. This means that quality and safety of smartcontracts is the clear responsibility of the CSP-community as whole. This, in turn, providesa sound basis to begin addressing the challenges around cross-domain asset transfers.There are a number of functional requirements for cross-domain transfers of virtual assetsbetween two contract-domains: • Asset validation before transfer : There must be some means for the recipient entity (inthe destination contract-domain) to validate the asset type and legal status prior to17ngaging with the transfer. This function is represented as the asset attester/verifierfunction in Figure 5 and in Figure 7). • Commitment atomicity : Cross-domain asset transfers must employ an atomic com-mitment scheme that prevents (detect) the same asset being present on two contract-domains (e.g. using 2-Phase Commit Protocol (2PC) [44, 45]).There are several efforts today to reuse the atomic commitment protocols from thefield of distributed databases and concurrency control (e.g. see [46]). The overall aimof many of these schemes is to interpret (re-cast) the ACID properties (atomicity, con-sistency, isolation, durability) [47] of these protocols to the context of asset transfers,at least for unidirectional transfers (nb. database transactions are typically unidirec-tional). Additional properties (e.g. safety, liveliness) have also been suggested (e.g.cross-chain deals [48]). • Transfer non-repudiability : There must be sufficient evidence regarding the finality andsettlement at both contract domains to obviate disputes by either a CSP or a customer(in one or both domains).Evidence of settlement can consist of the combinations of confirmed transactions onthe blocks on both contract-ledgers, local signed-logs by the nodes handling the cross-domain transfer, logs from the commitment layer, and so on. Evidence needed fordisputes between two CSP-communities must be specified in their peering agreementdocument. • Policy federation as part of peering agreements : Contract domains need compatible poli-cies along several axes, including: (i) the type of regulated asset being transferred; (ii)the legal jurisdiction of operations of the contract-domain; (iii) the type of operationspermitted (e.g. unidirectional unconditional transfers only, conditional transfer, etc),(iv) the agreed commitment protocol and non-repudiation protocol to be used (or ne-gotiated from a common standard list), and (v) the configuration of the nodes handlingthe transfers on both sides based on the node-device attestation evidence (see [24, 49]for a discussion on node device identities and node attestations). • Publication of peering-points : Similar to BGP-routers in IP networks, a given CSPcommunity implementing a contract-domain must determine the peering-points to beused in cross-domain asset transfers. The peering-points configuration and location(e.g. IP address and port-number) should part of the peering agreement. CSPs shouldgenerally standardize on a common notation and configuration for peering-points as ithelps all CSPs to know the first port of call for remote (foreign) CSPs.
The method used by a contract domain to select the node in the domain that will performthe cross-domain transfer is determined by the configuration rules in the domain’s core op-erational policies. Some consensus protocol (e.g. in the family of BFT protocols [23, 22])18mplement a leader election mechanism that chooses one node out of the network to performthe designated computation (e.g. forging a block in Ethereum). In the context of asset trans-fers that involve an external or foreign contract-domain, we refer to that chosen node as the gateway node .However, there are several possible strategies with regards to determining the gateway-nodes that will perform cross-domain transfers. For example, a CSP community may requireeach of its CSP members to nominate one or more of their respective nodes as gateway nodes,thereby reducing the number of possible gateway nodes from the total population of nodes inthat community. These handful of gateway nodes can be equipped with special capabilities(e.g. trusted hardware [24]) to deal with the cross-domain transfer.The gateway node in an origin contract-domain must use the published well-known peeringpoint in the destination contract-domain to communicate its intent to commence a cross-domain transfer. The endpoint in the destination contract-domain may either handle thecall itself (if it is equipped and authorized to do so), it could redirect the call to the relevantgateway-node in that domain. Figure 7 provides a high level illustration of some of thefunctions and capabilities needed for cross-domain asset transfers.
Each autonomous systems (AS) in the Internet is allocated a globally unique AS-number.For example, in the United States this task is managed by the American Registry for InternetNumbers (ARIN) [50]. For the EU the organization is RIPE, for Africa it is AFRINIC, forAsia-Pacific it is APNIC and so on [51].Today the VASP and virtual asset industry globally has yet to agree on a common VASPnumbering scheme and customer identification scheme. The notion of a unique VASP numberhas been proposed in [52, 53], while other mechanisms have been contemplated, such as usingthe VASP’s Legal Entity Identifier (LEI) [54] within the VASP KYC-Certificate [55]. In thecurrent work we assume that a contract-domain has a globally unique identifier that allowsit to be distinguished easily from other contract-domains and VASPs.When a customer of a CSP in a contract-domain invokes the asset transfer contract usinga beneficiary address (public-key) or PayID address [56] that is not an entity (customer)in the same contract-domain, then an address resolver mechanism is needed to map fromthe beneficiary address to the contract-domain (blockchain network) where the beneficiaryresides. This topic is discussed further in [49].
A requirements for cross-domain asset transfers is preventing double-spend of the asset (inad-vertently or otherwise) on the part of the customer who owns it. In this case, a double-spendwould consist of a customer requesting a cross-domain transfer of their asset while at the sameusing the same asset in a different transaction (e.g. locally in the same contract domain). Inthe current model, cross-domain transfers are performed by nodes belonging to CSPs in the19SP community.One approach to solve this dilemma is for the processing node (gateway node) to tem-porarily lock the asset while the transfer process is underway. The notion of “locking” isborrowed from the classic field of database transaction and concurrency-control [57, 44, 45].In transactional database systems, locking techniques are used to “mark” a data item (e.g.database row) as undergoing an update by one process. Other processes are unable to access(write to) the data item until the lock is released.Given the diversity of blockchain transaction processing models (e.g. UTXO in Bitcoin;external-owned accounts and smart contract accounts in Ethereum; etc.) we believe that(i) the contract-ledger is the only reliable shared-state and synchronization method for allthe nodes in a blockchain network [58, 59], and therefore that (ii) the lock-state informationfor cross-domain transfers must be recorded on the contract-ledger so that the lock-state isvisible to all nodes in the same contract-domain. From an audit and security perspective, therecording of lock/unlock information on the contract-ledger provides the benefit of historicaltraceability of cross-domain events in the case of disputes between CSP-communities.The specific lock/unlock mechanism is dependent on the cross-domain atomic commit-ment protocol used by gateway nodes. However, in general they must perform the followingtasks: • Asset locked transaction : This transaction marks an asset associated with a customerpublic-key as being in a locked-state and therefore will not be processed by other nodes.A time duration may be set in the transaction header denoting the duration of validity ofthe lock, after which the lock automatically expires and the asset considered unlocked. • Asset unlock transaction : This is an explicit unlock transaction that marks the asset asbeing “free” (unlocked state) on the ledger. An asset-unlock transaction must matchan existing asset-lock transaction, and it is typically issued by the same entity (CSPnode) that issued the lock. The purpose of an explicit unlock is to terminate a lockbefore the expiration of its timer. This feature is useful for cases such as an abortedcross-domain transaction (e.g. abort request from customer). • Asset lock-committed transaction : This transaction marks a virtual asset as being hence-forth permanently unavailable due to the asset exiting (transferred out of) the contract-domain. Typically, this transaction must refer to (include a hash of) a previous asset-locked transaction confirmed on the contract-ledger. It may include an identifier thatpoints to the new home (destination contract-domain) of the virtual asset [1, 5].Although the specific locking mechanism is beyond the current work, in general lock/unlocktransactions must include at least the following parameters: the identifier of the asset beinglocked, the address (public key) of the current holder (customer), the timestamp value (ortimer), and the hash of the confirmed transaction on the contract-ledger where the asset waslast used. Similarly, an asset unlock transaction must include a hash of the earlier confirmedasset locked transaction. 20igure 8: Summary of flows in a cross-domain transfer
An example of the flows that occur in a cross-domain transfer between two contract domainsin shown in Figure 8. The gateway nodes are shown as G1 (owned by CSP-B) in domain CD1,and G2 (owned by CSP-X) in domain CD2 respectively. Alice is the originator, while Bobis the beneficiary. Since gateway G1 belongs to CSP-B, the CSP-B is the Originator-VASP.Similarly, CSP-X that owns G2 is the Beneficiary-VASP.The transfer consists of four (4) general phases, including the commitment protocol em-bedded in the flows:
Phase 1:
Initiation of transaction and policy validation . There are a number of pre-transfertasks that need to occur in this phase: • The processing node (gateway G1) must locate the correct destination contractdomain CD2 where the beneficiary (Bob) is thought to reside. • Gateway G1 must validate that gateway G2 is owned by a registered CSP (VASP),and vice versa. • Gateway G1 must request gateway G2 to seek consent from the beneficiary (Bob)to receive the asset to be transferred. This protects the beneficiary and G2 (CSP-X) by giving them exculpatory evidence. An explicit consent from a beneficiaryis a requirement in some jurisdictions (e.g. see FINMA [60]). • Gateway G2 must validate that the virtual asset to be transferred from G1 iscompatible with the core operating rules of the contract domain CD2. • The gateway G2 must validate the legal status of this asset to its Asset Is-suer/Acquirer. (In the previous Figure 7, this is shown as Line-2 from G1 to212, and Line-3 from G2 to its Asset Issuer/Acquirer). • If all is well, gateway G2 transmits an acknowledgment to G1 that the transfercan proceed.
Phase 2:
Local locking of asset . In this phase the gateway G1 issues a local asset-lockedtransaction on ledger L1 to the asset in question. This prevents double-spending onthe part of the originator. Optionally, gateway G2 may indicate an incoming asset byissuing a candidate-lock on its ledger L2. The candidate-lock is not binding, but servesas an audit trail in case of disputes between the two CSP communities.
Phase 3:
Preparation to commit . In this phase gateway G1 acting as the coordinator inthe 2PC protocol [44, 45] signals readiness to commit to gateway G2.
Phase 4:
Finalization of commit . In this phase the gateway G1 as coordinator signals togateway G2 to perform the global commitment on ledger L2. Gateway G1 then issuesan asset lock-committed transaction on ledger L1 to close its previous asset-lockedtransaction in Phase 2.Gateway G2 records the new asset on its local ledger L2, assigning it to the public-keyof the beneficiary Bob. If G2 employed a candidate-lock transaction on L2 previously inPhase 2, then G2 can also close that transaction with its own asset-locked transactionon ledger L2.The astute reader may recognize that Phase 2 to Phase 4 constitutes a variant of the 2PCcommitment protocol, often referred to as 3PC (i.e. three phase commit). In distributeddatabases this occurs through the use of a commit-prepare message followed by a global-commit message sent from the coordinator (node G1) to all recipient (in this case, node G2).The topic of reliability of commitment protocols have been extensively addressed in variousliterature over the past two decades (e.g. see [57]).
The contract service provider (CSP) model is based on the following design principles thattakes into account code complexity considerations and the provider’s deployment considera-tions:(a)
Contract simplicity principle : Each smart contract should implement a simple andmodular well-defined function, following classic object-oriented design principles. Thisis also referred to as the decentralized primitives principle.(b)
Constrained authorship principle : Each contract must be made available only by acontract service provider (CSP) entity within the group of CSPs.(c)
Node diversity principle : A contract service blockchain network must employ a diversenode-technology implementations and be owned/operated by a diverse set of providers.22d)
Mediated oracle principle : Any representation of value that originates from outside thecontract service (contract domain) must enter (be introduced) into the contract servicethrough the mediation of a contract service provider.(e)
Opaque ledgers assumption : Any cross-chain or cross-domain asset transfer protocolmust be designed based on the assumption that the ledgers of the respective blockchainsare not externally readable/writeable.We discuss these design principles in the following.
The goal of this principle is to re-orient the notion of DApps (decentralized applications) intothe proper separation between primitive operations from complex business logic. Followingthe classic object-oriented design philosophy, complex applications are created using layersof modular objects, where each object implements rudimentary functions. This means thatsmart contracts must implement simple primitive functions that can be used (i.e. called) byhigher layer applications, which may be complex and involve access to off-chain data sources.Such business applications should be implemented off-chain, with APIs providing access tothe on-chain primitives.This principle seeks to address the following challenges: • Cost of on-chain operations : The use of contracts that implement simple primitive func-tions means that the number (cost) of on-chain operations is limited. This factor is animportant consideration for CSPs who choose to use shared platforms (e.g. Ethereum)in implementing their nodes. • Interoperability at the protocol layer : The use of simple primitives in one blockchainsystem provides the highest likelihood that semantically near-identical primitives arealso used in other blockchain systems. • Privacy of business logic and data flows : Many organizations in the financial sectorand other industries have developed complex business applications that often embodybusiness decision-making strategies. Some of these applications can be considered pro-prietary and some may access internal data-sources (e.g. private data stores in theorganization).By employing simple contract primitives that record shared state on the ledger butplacing sensitive application-logic off-chain, organizations can retain their intellectualproperty while adding to the application’s integrations capabilities.
The goal of the constrained authorship principle is to address the quality and provenanceissues with regards to smart contracts. In many permissionless blockchains today, the identity23f the author of a smart contract is unknown because the contract is bound only to a public-key.Although the paradigm of permitting anyone to anonymously publish a contract on ablockchain platform (e.g. Ethereum) – as long as they pay the operations fees (i.e. gas) – maybe beneficial for the platform owners, this paradigm is unrealistic from business organizations’security and survivability. Most (all) medium to large Enterprise organizations have strictaccess policies with regards to the resources accessible to employees on the corporate network.Similarly, Internet access providers and ISPs maintain the availability and uptime of theirnetwork by strictly controlling access to the network elements (e.g. routers, switches, VPNs,etc). Demarcating the physical boundary of an ISP network (which is also a legal boundary)is therefore core to the business survivability of the ISP.In practical terms, the constrained authorship principle means that for a given CSPcommunity sharing a contract-ledger, only smart contracts (set of primitives) authored by aCSP member of the community is permitted to be published on the blockchain (i.e. on all thenodes and shared ledger). This has the advantage that contracts can be carefully designed,tested and implemented by CSPs within the contained environment of the contract domain.This principle seeks to address the following challenges: • Demarcation of computational boundary, and business & legal responsibilities : Simi-lar to ISPs who need to demarcate their physical network boundary, contract serviceproviders (CSP) need to demarcate their computational boundary as well as their busi-ness and legal liabilities. By limiting the origins and authorship of contracts to onlyCSP entities, the CSP-community members have a clear demarcation of their respon-sibilities to their customers.This is in radical contrast to the permissionless philosophy that leads to overall blockchainperformance unpredictability and the need for users to verify every contract that theuser wishes to call (i.e. verify manually or using formal verification tools). • Quality and safety of smart contracts : Contract service providers are responsible forthe functional quality and safety of their smart contract. This permits customers tomake use the contract for the appropriate asset types, with assurance that the contracthas been tested, analyzed and staged by the authoring CSP. • Code provenance and authorship identification : Most (all) business applications haveknown authorship, and therefore known code provenance. In contrast, many smartcontracts permissionless blockchains today are of unknown origin and is “posted” onthe nodes of the blockchain using a public-key whose ownership is unidentifiable. Theseanonymous smart contracts are simply too risky for many legitimate businesses.
The Internet consists of a number of autonomous systems that together provide IP commu-nications end-to-end from the sender to receiver. The diversity of ISPs and the networks that24orm the Internet provide one of the key strength of the Internet. A similar strategy is neededfor contract domains, where CSP diversity and node-technology diversity [18] provides thebest strategy for survivability of the blockchain network as a whole.Cyberattacks on blockchain networks can range from crude network-level denial attacks(i.e. DDOS attacks), to more sophisticated attacks based on the manipulation of consensus(e.g. in the case of anonymous nodes) and of smart contracts. Although theft of keys haveoccurred primarily on client endpoints (i.e. wallets), nodes (e.g. mining or forging nodes)which hold private-keys can also be a target of attacks.This principle seeks to address the following challenges: • Node implementation diversity : The uniform implementation of the node software stackin homogeneous platforms (e.g. Bitcoin, Ethereum) means that malware designed totarget that specific software stack will affect all nodes in the network. • Service provider diversity : Platforms that are directly or indirectly controlled (owned)by one or few dominating entities leads to poor levels of services overtime.
Smart contracts today are “blind” to data sources that are external to the platform thatimplement the smart contract. As such, developers of blockchain platforms have resortedto naming external data sources as oracles of truth – a reference to the Oracle of Delphi inGreek mythology. In practice, this means that any external data must be made present onthe ledger in order for a smart contract to read and act upon it. Since the same copy ofa smart contract is present on all nodes, this means that the invocation of any copy of thesmart contract must read the same data item on the local copy of the ledger.However, a key issue here is in deciding which external source of data is “trustworthy” tothe user (caller) of the smart contract to begin with. This is one of the seemingly inherentcontradictions of the “trustless” blockchain model: on one hand no single entity is trustedto execute the smart contract (hence the decentralized copies of the smart contract on eachnode); on the other hand, any meaningful use of smart contracts requires the importationof a digital representation of the real-world asset issued by a centralized “oracle” entity. Itis this centralized entity that “binds” the digital representation to the real-world asset bycryptographically signing the assertion data-structure (e.g. signed JSON file, signed digitalcertificate, etc). The centralized entity stands behind its assertion (by signing it) and therebytakes-on legal liability.At the heart of the oracle problem is the inherent limitations of the smart contractsabstraction [58, 59]. The abstraction is based on the classic object-oriented programmingconstructs of methods and local data (i.e. scoped variables), where a special constructor method instantiates (in memory) the methods (local functions) and the variables (local data)defined by the class of the object. When this programming abstraction is mapped onto amulti-node blockchain system – as is the case with Ethereum and Solidity [11] – with a sharedglobal state (i.e. blocks of the ledger) and shared code visibility (i.e. copy of smart contract25s on every node), the limitations of the method/scope-variable paradigm become readilyapparent. Just as methods (local functions) in an object is limited in its visibility to datadefined in its scope (i.e. data in its local memory), a smart contract is limited in its visibilityto data found on the shared ledger. As far as a smart contract is concerned, anything not onthe ledger does not exist.The principle of mediated oracles seeks to address the practical limitations of the currentform of oracles by ensuring that at least one CSP in a contract domain is verifying thetruthfulness of the external oracle’s assertions (virtual assets) prior to introducing the virtualasset into the contract domain: • All oracle assertions pre-validated by CSP : Any digital representations of assets assertedby an external oracle must be validated a CSP before the CSP introduces it into thecontract domain shared by the CSP community. A customer of a CSP seeking tomove their virtual assets into a contract domain must request its CSP to perform thisimportation.The CSP must (i) validate the source-authenticity of the virtual asset and its legalstatus, (ii) validate the expiration date of the virtual asset (if any), and (iii) obtainsufficient evidence that the virtual asset is not used in other blockchain systems. • All oracle assertions co-signed by CSP upon entry : The CSP that validates the digitalrepresentations of assets (asserted by an external oracle) must also digitally sign theassertion when introducing it into the CSP community. This ensures liability lies withthe CSP, and therefore deters the CSP from malicious behavior.
The structure of a contract service provider (CSP) community is based on the classic notionof a bounded IP network routing domain and observes two fundamental principles of theInternet architecture. These two principles are: (i) networks as bounded autonomous system (AS), and (ii) communications-context (meaning) as a higher layer function that exists at theedges end-to-end [3, 4]. These two principles represent pillars of the Internet architecture thathas allowed the Internet to grow through the addition of independent autonomous networkswhere the interior of each network is opaque to the next network [1].A key aspect of the autonomous system principle in the Internet architecture is thatrouting-data (e.g. interior route advertisements) belonging to an ISP is opaque (invisible) toother ISPs and external entities. This provides the freedom for an ISP to innovate withinthe confines of its own network (e.g. using new routing protocols and routers), while notimpacting other ISPs. The ISP-to-ISP interaction occurs through the deployment of anexterior inter-domain routing protocol (e.g. BGPv4) that acts as a standardized interfacebetween networks.We believe a similar design assumption is needed for contract-domains and blockchainnetworks. We refer to this assumption as the opaque ledgers assumption , which states that anycross-chain or cross-domain asset transfer protocol must be designed based on the assumption hat the ledgers of the respective blockchains are not externally readable/writeable . A well-designed protocol that permits asset transfer across two blockchains with opaque ledgers willinvariably work also for blockchains with non-opaque ledgers.Note that the opaque ledgers assumption has implications on contract-level cross-chainconditionals, such as cross-chain hash-locks [61] and time-locks – which assume that theledgers on both sides of the cross-chain transfer are readable/writeable (e.g. see [62, 46, 63,64]). This means that for the CSP model and contract domains, any conditional-transferconstructs must be an artifact of the upper layer application that implements the businesslogic as mentioned earlier. Today there is a great interest on the possible use of digital currencies as the national level, inthe form of Central Bank Digital Currencies (CBDC) and fiat-backed Stablecoins. There area number of possible strategies to implement CBDCs, including a non-blockchain approachfollowing the classic Chaum design (e.g. GNU Taler).Today the lack of interoperability among popular blockchain platforms and the risingcost of transactions on platforms employing the gas-fee model may discourage the use ofblockchain-based solutions for CBDCs. As such, alternative models are needed that canretain the technological benefits of blockchain systems while using a different fee-for-servicebusiness model that does not rely on the tokenization of operations.In this paper have proposed the Contract Service Provider (CSP) model as one suchalternative.
References [1] T. Hardjono, A. Lipton, and A. Pentland, “Towards an Interoperability ArchitectureBlockchain Autonomous Systems,”
IEEE Transactions on Engineering Management ,pp. 1–12, 2019, doi:10.1109/TEM.2019.2920154. [Online]. Available: https://arxiv.org/abs/1805.05934[2] J. Martin, “Vitalik Proposes Solution to Embarrassing Lack of Bitcoin–EthereumBridge,”
Cointelegraph , March 2020. [Online]. Available: https://cointelegraph.com/news/vitalik-proposes-solution-to-embarrassing-lack-of-bitcoinethereum-bridge[3] D. Clark, “The Design Philosophy of the DARPA Internet Protocols,”
ACM ComputerCommunication Review – Proc SIGCOMM 88 , vol. 18, no. 4, pp. 106–114, August 1988.[4] J. Saltzer, D. Reed, and D. Clark, “End-to-End Arguments in System Design,”
ACMTransactions on Computer Systems , vol. 2, no. 4, pp. 277–288, November 1984.[5] T. Hardjono and N. Smith, “Decentralized Trusted Computing Base for BlockchainInfrastructure Security,”
Frontiers Journal - Special Issue on Finance, Money & lockchains , vol. 2, December 2019. [Online]. Available: https://doi.org/10.3389/fbloc.2019.00024[6] V. Buterin, “Ethereum: A Next-Generation Cryptocurrency and Decen-tralized Application Platform,” Bitcoin Magazine, Report, January 2014,https://bitcoinmagazine.com/articles/ethereum-next-generation-cryptocurrency-decentralized-application-platform-1390528211/.[7] Z. Voell and W. Foxley, “Decentralized Finance FrenzyDrives Ethereum Transaction Fees to All-Time Highs,” Coin-desk
Coindesk
BBC News
Wall Street Journal $
50 as Ethereum feesskyrocket,”
Cointelegraph , September 2020. [Online]. Available: https://cointelegraph.com/news/using-a-defi-protocol-now-costs-more-than-50-as-ethereum-fees-skyrocket[13] D. Siegel, “Understanding The DAO Attack,”
Coindesk
Coindesk
Data Science and Intelligent Applications: Proceedingsof ICDSIA 2020 . Singapore: Springer Singapore, June 2020, pp. 363–374. [Online].Available: https://doi.org/10.1007/978-981-15-4474-3 40[23] W. Wang, D. T. Hoang, P. Hu, Z. Xiong, D. Niyato, P. Wang, Y. Wen, and D. I. Kim,“A Survey on Consensus Mechanisms and Mining Strategy Management in BlockchainNetworks,”
IEEE Access , vol. 7, pp. 22 328–22 370, 2019.[24] T. Hardjono and N. Smith, “An Attestation Architecture for Blockchain Networks,”May 2020, available at https://arxiv.org/abs/2005.04293.[25] P. Tasca and C. J. Tessone, “Taxonomy of Blockchain Technologies: Principles ofIdentification and Classification,”
Ledger Journal , vol. 4, February 2019. [Online].Available: 10.5195/ledger.2019.140[26] T. Ankenbrand, D. Bieri, R. Cortivo, J. Hoehener, and T. Hardjono, “Proposalfor a Comprehensive (Crypto) Asset Taxonomy,” in
Proceedings of the 2020 CryptoValley Conference on Blockchain Technology (CVCBT)
ACM Trans. Comput. Syst. , vol. 10, no. 4, p. 265?310,1992. [Online]. Available: https://doi.org/10.1145/138873.138874[33] T. Hardjono, “Federated Authorization over Access to Personal Data for DecentralizedIdentity Management,”
IEEE Communications Standards Magazine – The Dawn of theInternet Identity Layer and the Role of Decentralized Identity , vol. 3, no. 4, December2019. [Online]. Available: https://doi.org/10.1109/MCOMSTD.001.1900019[34] B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn,G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen,S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu,H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, and E. Jaques, “Criteria forevaluating aaa protocols for network access,” November 2000, RFC2989. [Online].Available: http://tools.ietf.org/rfc/rfc2989.txt[35] R. Yavatkar, D. Pendarakis, and R. Guerin, “A framework for policy-based admissioncontrol,” January 2000, RFC2753. [Online]. Available: http://tools.ietf.org/rfc/rfc2753.txt[36] J. G. Steiner, B. C. Neuman, and J. I. Schiller, “Kerberos: An authentication servicefor open network systems,” in
Proceedings of the USENIX Winter Conference. Dallas,Texas, USA, January 1988 . USENIX Association, 1988, pp. 191–202.[37] J. Kohl and C. Neuman, “The kerberos network authentication service (v5),” September1993, RFC1510. [Online]. Available: http://tools.ietf.org/rfc/rfc1510.txt[38] J. H. Saltzer, “Protection and the Control of Information Sharing in MULTICS,”
Com-munications of the ACM , vol. 17, no. 7, pp. 388–402, July 1974.3039] D. E. Bell and L. J. LaPadula, “Secure Computer Systems: Mathematical Foundations,”The MITRE Corporation, Technical Report MTR-2547 I ESD-TR-73?278, (Vol. I-II),November 1973.[40] D. F. Ferraiolo and D. R. Kuhn, “Role-Based Access Controls,” in
Proc. 15thNational Computer Security Conference , Baltimore, October 1992, pp. 554–563,https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf.[41] Microsoft Corporation, “Microsoft Privilege Attribute Certificate Data Structure,” Mi-crosoft Corporation, MS-PAC Specification v20140502, May 2014.[42] P. De Filippi and A. Wright,
Blockchain and the Law
IBM Research Report , vol. RJ2555, 1979.[45] J. Gray, “The Transaction Concept: Virtues and Limitations,” in
Very Large Data Bases– Proceedings of the 7th International Conference , Cannes, France, September 1981, pp.144–154.[46] V. Zakhary, D. Agrawal, and A. E. Abbadi, “Atomic Commitment Across Blockchains,”June 2019. [Online]. Available: https://arxiv.org/pdf/1905.02847.pdf[47] T. Haerder and A. Reuter, “Principles of Transaction-Oriented Database Recovery,”
ACM Computing Surveys , vol. 15, no. 4, p. 287?317, December 1983. [Online].Available: https://doi.org/10.1145/289.291[48] M. Herlihy, B. Liskov, and L. Shrira, “Cross-chain Deals and AdversarialCommerce,”
Proceedings of VLDB
Concurrency Control and Recovery inDatabase Systems . New York: Addison-Wesley, 1987.[58] T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding Concurrency toSmart Contracts,” in
Proceedings of the ACM Symposium on Principles of DistributedComputing PODC’17 . New York, NY, USA: Association for Computing Machinery,2017, pp. 303–312. [Online]. Available: https://doi.org/10.1145/3087801.3087835[59] M. Herlihy, “Blockchains From a Distributed Computing Perspective,”
Communicationsof the ACM ∼ /media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20190826-finma-aufsichtsmitteilung-02-2019.pdf[61] T. Nolan, “Alt chains and atomic transfers,” May 2013. [Online]. Available:https://bitcointalk.org/index.php?topic=193281.msg2224949 Proceedings of the 1st Workshop on Cryptocurrenciesand Blockchains for Distributed Systems (CryBlock?18) . New York, NY, USA:32ssociation for Computing Machinery, 2018, p. 36?41. [Online]. Available: https://doi.org/10.1145/3211933.3211940[63] M. Herlihy, “Atomic Cross-chain Swaps,” in