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

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.