Companies move workloads into confidential computing to answer one question: who can see my data? Increasingly their customers, auditors and regulators ask a second one: how do you know the data your service acted on was complete and current? A payments ledger, a KYC register, a consent database or an AI audit trail is only as trustworthy as the storage it reads from, and in the cloud that storage belongs to somebody else. An enclave keeps its memory encrypted, but everything it persists goes to the host machine, and everything it reads comes back from the host machine. Encryption stops the host reading those records. It cannot stop the host returning last week's version of them, or omitting the record that would have failed the check.
The industry has partial answers. Provider certifications such as SOC 2 and ISO 27001 attest that an operator follows sound processes, which is valuable, but they are statements about the operator, verified annually, with nothing a relying party can check per transaction. Database audit logs record what happened, but they are written by the same infrastructure they are meant to police. Ledger databases such as Amazon QLDB brought cryptographic verification to managed storage, and they still ask you to trust the service operator's execution environment, with no binding between the data proof and the identity of the code that produced it. Each of these tools answers part of the question. None of them lets a customer verify, from the outside, that a specific attested program is serving a specific, untampered dataset.
What the Merkle store adds
The Merkle store is the authenticated storage layer of Enclave OS (Mini), our runtime for SGX enclaves. It condenses an enclave's entire persistent state into a single 32-byte root value held inside the enclave, and makes that value do the compliance work:
- Every read is verified before it is used. A record returns to the application only after its path hashes up to the root, its encryption tag verifies, and its plaintext re-derives the stored commitment. Stale data, dropped keys and resurrected deletes become errors the application sees, never wrong answers it silently acts on.
- The state fingerprint travels with the code identity. Enclave OS embeds the current root and version in the enclave's attested TLS certificate, alongside the code and configuration measurements we described in Binding Attestation to the TLS Session. A connecting client can pin which program it is talking to and which data state that program is serving, in the same handshake, and monitor the root's continuity across connections.
- Proofs are portable. For any key the store produces a compact proof that the key holds a given value, or that it holds nothing at all, verifiable by a pure function against just the root. An auditor does not need access to the enclave, the storage, or Privasys to check one. Proofs of absence matter as much as proofs of presence: "this sanctioned party was not in the approved list" is exactly the kind of claim a compliance team needs to evidence.
- History is versioned and retention is deliberate. Commits create immutable versions; historical roots remain readable and provable until an operator prunes them against a retention window. Point-in-time queries for an investigation and deletion for a data-minimisation policy are both first-class operations.
The engineering underneath
The structure is a versioned sparse Merkle tree in the lineage of the Jellyfish Merkle Tree from the Diem project, adapted to an enclave reading from untrusted storage. Records are immutable and copy-on-write: a commit rewrites only the touched paths and lands as one atomic batch, so the store is never observable in a half-updated state, even across a crash. Lookups touch about five records at a million keys, and a warm verified read costs around four backend reads at a hundred thousand keys, because verification runs against an immutable-record cache that removes I/O without removing checks.
One design decision carries the product story: the root is a pure function of the logical data and a commitment key, independent of the encryption underneath. Each deployment encrypts its records with its own storage key and fresh nonces, yet any two instances that share the commitment key produce byte-identical roots for identical data. Two immediate benefits follow. The host learns nothing from the tree's shape, since paths and commitments are keyed hashes, so it cannot dictionary-attack predictable keys or spot duplicate values. And entire datasets can be compared, migrated or replicated by comparing one (version, root) pair, without the instances ever sharing disk formats or encryption keys.
For application developers none of this machinery is visible. Enclave OS runs confidential applications as WebAssembly components, the model we introduced in WebAssembly Inside Enclaves, and an application reaches the Merkle store through a small transactional interface: read, write, delete, all against a fork of the last committed state. If the code completes, its changes commit atomically and the root advances; if it traps, nothing happened. Operators interact with the store through a role-gated JSON API for reads, proofs, batched writes and pruning, and choose per table between the Merkle store and the plain sealed key-value store, which remains the right tool for high-churn private state where staleness is tolerable and write amplification is not.
Costs and limits
Authenticated storage is not free, and the boundaries are worth stating. A commit writes on the order of tree-depth records instead of one, which is the price of the root; workloads that cannot pay it belong on the sealed KV store. A host that snapshots the entire store together with its encrypted checkpoint and replays both across a restart is not detectable by the enclave alone; this is the same residual that applies to SGX sealing generally, it is narrowed by clients that pin roots across sessions, and it is closed by replication, where state continuity is confirmed by a quorum of machines instead of asserted by one. The binding from historical versions to their roots is currently host-held, so point-in-time proofs are strongest for recent, pinned roots. And the implementation is open source and reproducible, but it has not yet been independently audited.
The near-term roadmap is replication: the encryption-independent root exists so that several enclaves on several machines can hold the same logical dataset and prove it to each other. That system, Enclave Cluster, is the subject of the next post.
The Merkle store ships in Enclave OS (Mini) under the AGPL-3.0 licence. The full design, API and freshness model are documented on the Merkle Store page.