Library Confidential compute2019Design paperCorpus record

Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts

Oasis. Raymond Cheng, Fan Zhang, Jernej Kos, Ari Juels, Andrew Miller, Dawn Song and collaborators.

The Ekiden paper: smart contracts that execute inside trusted hardware, with the ledger checking attestations rather than re-executing the private code. Oasis Network is the later production system in this line. The paper is the academic statement of the approach.

Ekiden's paper runs a smart contract's private state inside a hardware enclave, and puts the public chain in charge of ordering and of recording the enclave's attestation, so the chain never sees the secret.

The five-minute read

The enclave is the computer that is allowed to see the data

A trusted execution environment decrypts state, runs the contract, and produces an attestation. The host operating system is assumed to be unable to read the enclave's memory.

The chain is the ordering and the audit log

Consensus nodes do not execute the private contract. They order requests and store the resulting commitment and attestation. Separation of compute and consensus is the architecture.

Attestation is how a user knows which program ran

The hardware signs a statement that a particular binary, with a particular measurement, produced the output. Trust moves from 'the operator' to 'the hardware and the measurement'.

Keys are a first-class problem

The paper has to say how contract keys are created, sealed to an enclave, and recovered. A lost key is a lost contract. A key that can be extracted is a failed privacy story.

Hardware trust is not 'trustless'

The paper's own model includes a manufacturer and a class of side channels. Calling the result trustless is a misuse of the word. The accurate word is relocated.

One action, walked through

A contract is loaded into an enclave. The hardware produces an attestation of the binary's measurement.
A user encrypts inputs to the contract key and submits them. Consensus orders the request.
The enclave decrypts the relevant state, executes, and emits a new state commitment plus an attestation.
Consensus nodes record that output. They do not receive the plaintext state.
A later enclave with the same contract key can pick up the sealed state. A verifier checks the attestation against the measurement they expected.

The argument, unpacked

The manufacturer is in the trust root

Attestations are worth what the hardware signature is worth. A broken enclave, a leaked attestation key, or a compelled manufacturer changes the meaning of every proof. The paper does not hide this. Summaries often do.

Side channels are in scope

A correct attestation does not stop an observer from learning secrets from timing, memory access or power, if the implementation leaks them. The paper's security theorem and a careless implementation are different objects. A review should ask what leakage was actually measured.

Private state still has public effects

The output that goes back to the chain, the size of a transaction, and the pattern of calls can describe the secret. Confidentiality of state is not confidentiality of the fact that a particular user called. Application design has to minimise what the output says.

What has to be true

The enclave implementation matches the paper's threat model, including the side channels the user cares about.
Attestation keys and the expected measurement are the ones the verifier has pinned. A verifier who skips the check has trusted the host.
Key backup and recovery do not create a plaintext copy 'for safety' outside the enclave.
Consensus availability is separate. A halted chain freezes the private contract even if the enclave is healthy.

What happened after the paper

Oasis and other systems drew on Ekiden's split between enclave execution and a consensus log. Hardware attestation has also had a rough public decade, which is a reason to read the threat model carefully rather than a reason to pretend the paper claimed trustlessness. The paper is the checklist: who computes, what the chain verifies, and which manufacturer those verifiers must trust.

What to check before you use the idea

Which enclave, and which measurement, is the verifier supposed to pin?
Where are contract keys sealed, and who can recover them?
What does the public output reveal about the private state?
What side channels has this implementation actually closed?

Terms

Enclave: A hardware-isolated execution environment that is supposed to hide its memory from the host.
Attestation: A hardware-backed statement that a particular program produced a result.
Sealed state: Encrypted contract state that an enclave with the right key can reopen and the chain cannot read.
Measurement: The hash of the program the enclave claims to be running. Verifiers pin this value.

The problem the paper names

Re-executing a contract on every node publishes the contract's inputs, and multi-party computation is expensive for general programs. Ekiden's bet is that a small set of compute nodes can run the contract inside a trusted execution environment, and that the chain only needs to check that the right binary, on plausible hardware, produced the output.

What the design proposes

Compute nodes produce attestations. Consensus nodes order and record results. The roles are split.
The ledger does not see the secret state. It sees a commitment and a hardware attestation.
Key management and attestation freshness are part of the security argument, not operational trivia.

How the mechanism is specified

Trust moves to the hardware manufacturer and to the attestation verification, plus the usual consensus assumptions.
A side-channel or a broken enclave breaks the privacy claim even if the ledger is honest. The paper's model has to be read with that in mind.
Oasis's later ParaTime architecture is an implementation choice beyond the paper.

What this page does not treat as proven

Trusted hardware is a trust assumption. Calling the result trustless is inaccurate.
The paper is not an endorsement of any particular chip, and not a current Oasis status report.
Confidentiality of state is not confidentiality against a user who is supposed to receive the output.

Why a venture studio still reads it

When a venture proposes 'confidential contracts' for businesses, Ekiden is the checklist: who computes, what the chain actually verifies, and which manufacturer those verifiers must trust. If the pitch cannot name the enclave, it does not have this design.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.