Execution Transparency — Hosted smart contracts using secure, append-only logs

The Vitra research project now has a whitepaper¹ and I wanted to give a high level of what it’s on about, a premise I call Execution Transparency or ET.

This is a personal research project and it hasn’t undergone any formal review, so bear that in mind as you read.

Background

The purpose of Execution Transparency is to created hosted smart contracts. Most people don’t know what a smart contract is or assume they require blockchains, so let’s start with some definitions².

• Smart Contract. A program which executes transactions according to a shared agreement among participants.
• Blockchain. A database which uses strong cryptographic properties and a decentralized consensus protocol to execute transactions on open network.

When you typically run a networked program, your clients have no insight into its execution. The API may enumerate the available operations but the actual program is a black box. As a consequence, you the owner have free reign to change the code or state however you see fit.

A smart contract opens the black box. Not only is the code made available to clients but the state transitions are as well. Importantly, the protocols for smart contracts make it impossible for the state transitions to deviate from the rules of the program code. Whereas traditional networked programs give no guarantees on behaviors, a smart contract gives strong guarantees.

This can be extremely useful when foul play could have bad consequences. A cryptographic key registry is a good example: changing a name ⇒ pubkey mapping could result in a security breach. A smart contract will ensure both that you receive the correct mapping and that mutations are visible and constrained by the contract’s rules.

Don’t smart contracts need blockchains?

Most smart contracts are either executed on a blockchain (as in Ethereum) or secured against a blockchain (“Layer 2 Rollups”). The general idea is that all state transitions are validated against the contract code and only included in a new block if all conditions are met.

Verifying a state transition is straight-forward. You have some initial state A and a transaction t that should result in a new state B. The contract specifies a pure function F(A,t)⇒B . Since repeated executions of F(A,t) will always produce the same output of B, you can verify a proposed state transition by just running the function yourself.

Blockchains provide two useful properties for running smart contracts:

1. Consensus on the state and its history.
2. A network of devices for executing state transitions and producing new state.

All of the nodes verify the state transition, so if some device produces a block which fails validation, the network will simply reject it.

The core idea of Vitra is that we can remove the second property and still get a useful system in the form of hosted smart contracts. The way we do that is by maintaining consensus on the state and its history using verifiable append-only logs.

This is the same premise used by Certificate Transparency (CT). CT uses verifiable logs to publicize all issuances of TLS certificates. By tailing the CT logs, certificate holders can ensure that new certificates for their domains aren’t being issued to some third party. It’s essentially a public auditing system.

The idea of Execution Transparency is that we can generalize CT to provide auditable execution of arbitrary programs. The host of the contract, called the executor, records all state transitions in a verifiable log and then publishes the log to the network. Any other party can tail the log and compare the transitions to the published contract. If a transition violates the contract, they can publish an inclusion proof of the incorrect change and share the violation as a breach notice.

This leads to one of the key differences from blockchains: if a breach occurs, a blockchain will just drop the bad block, but ET has no such solution. Instead the response is manual intervention: the clients stop transacting with the executor and move to a new contract host. This makes ET an informally reputational system; an executor that violates a contract loses the community’s trust.

The upside compared to blockchains is that ET can eject decentralized consensus protocols, which makes the system cheaper, faster, and somewhat simpler. It’s also worth noting that an ET contract can have multiple participants but only one executor, and it’s only the executor who could breach the contract. Participants are strongly bound by its rules.

What are the limits?

As it’s currently modeled, ET only secures mutations to a shared database. This is subtle but important; it means that “side effects” are not secured.

Suppose you want to create a DAO which manages a bitcoin wallet — the DAO’s treasury — so you setup the ET contract, add each member as a participant, and then create a “wallet bot” participant which controls the bitcoin keys. You write the contract so that a majority vote results in a new “send funds” record, which your bot observes and enacts.

Our hypothetical DAO does work, but it’s trusting the person who runs the wallet bot. All the bot-owner needs to do to drain the funds is shell into the device and create a transaction manually. This is because the wallet bot is operating as a side-effect of the database and therefore isn’t secured by it.

It should be possible to solve this issue, for instance by using bitcoin multisig and distributing the constituent keys among the members, but the DAO creators will need to be conscious of this limitation and write additional programs to execute the multisig transaction.

Another consideration is the time-sensitivity of a breached contract. ET ensures that a breach by the executor can be detected; it makes no guarantee on when. If a breach can have irreversible consequences before it can be detected and handled then ET is not securing you from bad behavior. A simple solution to this is to verify the contract’s state before acting on it.

Could this be better?

Here are some of the areas where I think ET could be improved upon:

• Rather than relying on log-replay against the contract, it should be possible to use ZK-SNARKs to verify the correctness of the state. I’m still new to ZK-SNARKs so I can’t comment intelligently on the idea, but I understand this would make contracts significantly cheaper to execute since you wouldn’t need to retain transaction histories.
• Closed-group consensus models (ie Paxos) could be used to split execution among multiple executors. Based on some cursory reading, I think this may be the idea behind federated blockchains, but I’m still digging into it.
• Cross-contract calls could make ET more useful. This would likely require a wire protocol for contract participants to communicate with each other, and due to spam concerns you’d need to find a way to trust or limit the channel. I think this could be solved by manually building channels between systems.
• The reference implementation uses Javascript as the contract language. WASM is where most of these ecosystems are headed, and the only reason I chose to use JS is because WASM hasn’t finalized its interface types proposal which makes it hard to write an “unopinionated” runtime.

There are probably other improvements that could happen and I’d be happy to hear about them!

Links

• Vitra, a reference implementation of Execution Transparency
• The whitepaper.
• Another blogpost explaining Vitra.
• Another blogpost looking at why we might want something like blockchains but not bother with decentralized consensus.
• Where you can yell at me.

— Paul

—

¹ By “whitepaper” I mean I converted some markdown to a PDF.
² These are my definitions and I imagine they could be litigated, but I think they stand up to argument. Smart contracts were first theorized as a automated legal contracts, but thanks to Ethereum they’ve colloquially shifted to include non-legal purposes and that’s the definition I give.