A Structured Semantic Domain for Smart Contracts Extended Abstract

Smart contract languages provide a new paradigm for coding business workflows that span multiple untrusted actors. Their semantics are given in terms of transactions, updates to a model of a ledger that is shared between the actors. A distributed system then implements this semantic model and provides users with the distributed ledger. Most models follow the ideas of Bitcoin [5] or Ethereum [6]. In Bitcoin, a transaction is described by two sets: the spent immutable coin inputs and the produced immutable coin outputs; the ledger state consists of the unspent outputs (UTXOs). In Ethereum, the ledger state, so-called “world state”, maps addresses to values, and transactions mutate this mapping. Both approaches suffer from confidentiality, privacy, and scalability issues [2], [3]. In this abstract, we sketch how adding more structure to the semantic domain yields a more secure programming model for smart contracts, and allows for distributed implementations with better confidentiality, privacy, and scalability properties. We identify five distributed ledger desiderata that the UTXO and world state models lack. They are motivated by typical use cases for smart contract platforms like trading assets between multiple actors, e.g., a delivery-versus-payment (DvP) swap in a financial market. Here, Alice transfers an asset A to Bob and Bob transfers an asset B to Alice. The desiderata are: a) Compositionality: Small ledger updates should be composable into larger updates. For example, given an update for transferring an asset from the owner to another party, we can combine two of them into a DvP update. The composition must be atomic: one asset is transferred if and only if the other asset is transferred. Lack of atomicity is a systemic problem for conventional financial systems: when Bob defaults between the two transfers, Alice has already given up her asset without getting anything in return. Intermediaries can take over this risk, but Alice and Bob must trust them to correctly execute the swap on their behalf and to not default while doing so. b) Authorization: As the ledger is shared between untrusted actors, every ledger update must be properly authorized. For example, an asset owner must authorize the transfer to another party, and both parties must have agreed to the DvP swap. For compositionality, authorization should support delegation of rights. As part of a DvP contract, e.g., Alice can delegate to Bob her right to transfer her asset to Bob, so that Bob can execute the swap without involving Alice. When the digital assets represent off-ledger obligations, authorization is crucial in ensuring that these obligations are entered into voluntarily. c) Confidentiality: As ledger updates may contain sensitive data such as trade secrets and GDPR-relevant data, they should only be visible to the parties that have a stake in it. For example, an unrelated third party Eve should not learn which assets were exchanged in a swap between Alice and Bob. Ideally, confidentiality can be maintained at the level of sub-updates. That is, if ownership of Alice’s asset is tracked by the registry R, then R should be involved only in the transfer of Alice’s asset. In particular, R should not learn what is exchanged in the other leg, i.e., what Alice gets in return. d) Privacy: Not only must the business details remain confidential. Also the parties involved in one sub-update should remain hidden from parties involved only in unrelated sub-updates. For example, the registry R need not learn who is the registry in the other leg. e) Scalability: Scaling needs sharding and parallel processing. A ledger based on a global shared state limits scaling.