Post-quantum Ethereum · leanPQ

leanSeal

Time-lock encryption from hashes alone. Seal a transaction so that anyone can open it after a fixed amount of sequential hashing, or at once when its sender reveals the key.

Vitalik Buterin · Quang Dao · Justin Drake

The sender knows every link and runs its chains side by side. Anyone else must run them one after another, because each chain's starting link is hidden under the end of the previous chain. The sender's parallel width becomes everyone else's delay. The puzzle carries the first link in the clear, the n − 1 masked links and a commitment to the key.

30 s

reference delay, against an attacker computing one chained SHA-256 every 3.5 ns

512 B

added to a sealed transaction: a 452-byte puzzle and 60 bytes of encryption

21 s

to build the puzzle on all cores of a MacBook Air (Apple M4), before the transaction exists

12 ms

to open it when the sender reveals the key, the normal case

Why

In an encrypted mempool, block builders order transactions before they can read them, so they cannot front-run or sandwich a transaction based on its contents. The transactions must then be opened. A committee that holds a decryption key must be trusted not to collude and to stay online. A trusted execution environment moves that trust to the hardware vendor and its resistance to side channels. A sender that reveals its own key can withhold it when the ordering is unfavorable. Efficient time-lock puzzles avoid both, but rely on RSA or class groups, which need a trusted setup or are broken by quantum computers.

leanSeal uses nothing but SHA-256. The sender still reveals its own key after the ordering, and in the normal case no puzzle is solved. If the sender withholds the key, anyone can solve the attached puzzle and recover it, so the transaction of a sender that built its puzzle honestly is disclosed even if that sender goes offline or changes its mind.

Disclosure is not execution. By the time a puzzle is solved, the transaction may have expired or may revert, so withholding can still delay or cancel it, and a deposit forfeited on a missed reveal must deter that, as in plain commit–reveal. No efficient check of puzzles is known either, so a sender that plans to withhold can attach a puzzle that never opens. The paper sets out what the puzzle adds over commit–reveal with the same deposit.

How it works

The sender draws n random links and runs n hash chains of m SHA-256 steps, all in parallel, one per link.
The puzzle publishes the first link in the clear and hides each later link under a hash of the end of the chain before it. The key is a hash of every chain's end.
An opener without the key learns each link only by finishing the previous chain, so it must run all n·m steps one after another, however much hardware it has.

What we show

A proved delay

In the random-oracle model, a classical attacker with the hash rate of the whole Bitcoin network derives the key even one oracle round early with probability at most about 2⁻¹¹⁷ for a 30-second lock with 24-byte links.

Sender work done in advance

The sender's work is unavoidable for hash-only time locks, but a puzzle does not depend on the transaction it seals, so a wallet can keep a stock of puzzles and build more while idle.

A clear limit

Delay encryption, where one computation per slot opens every transaction sent to it, is impossible from hashes alone when the setup is cheap. Per-transaction puzzles are what hashes can do.

A specified implementation

A versioned byte format with test vectors, a Rust implementation with SHA-256 hardware backends, an independent Python implementation that agrees on every vector, and a prototype encrypted mempool on an EVM chain.

Limitations

Disclosure, not execution. The puzzle guarantees that a withheld transaction becomes public, not that it executes in its committed position.
Puzzles are not checked. Only a well-formed puzzle opens to its key, and no efficient check is known.
The delay rests on a hardware estimate. The 30 seconds assume one chained SHA-256 every 3.5 ns: 3.7 times faster than the fastest published SHA-256 design, and 6.6 times faster than one Apple M4 core, which needs about 3 min 21 s. A faster attacker shortens the delay; restoring it multiplies every sender's work.
Recovery work is per puzzle. Independent puzzles share no work, so each withheld key costs one full solve.
Excluded transactions become readable too. Expiry prevents execution, not disclosure. The secrecy is temporary: it protects against front-running, not the lasting confidentiality that shielded transfers need.

Status

leanSeal is a research proof of concept. The format is specified and tested. Post-quantum security is proved for the idealized chained puzzle; a bound for leanSeal's exact encoding against quantum attackers is open. Do not protect anything of value with it.

Try it

git clone https://github.com/leanEthereum/leanSeal && cd leanSeal
make && make test
export PATH="$PWD/target/release:$PATH"
leanseal gen -d 30s --step-ns 3.5 -o tx.secret    # build a 30-second puzzle in advance
leanseal encrypt -s tx.secret -i tx.bin -o tx.env # seal the message under it
leanseal key tx.secret | leanseal open tx.env -k - -o out.bin   # fast path: the sender's key
leanseal open tx.env --solve -o out.bin           # fallback: solve the puzzle