A hash-only rollup: OP Stack L2 accounts as Lamport-style hash chains, no ECDSA inside the L2

A Hash‑Only Rollup on OP Stack

TL;DR – The BB84 team runs an OP Stack rollup where L2 transactions carry no signatures. Each account is the tip of a Keccak‑256 hash chain; spending reveals the next pre‑image, and a commit‑reveal protocol binds that pre‑image to a specific transaction. Inside the L2 the only cryptographic assumption is the pre‑image resistance of Keccak‑256 (≈ 2¹²⁸ work under Grover), while ECDSA remains only at the L1 deposit/withdrawal layer.

---

1. How Hash‑Chain Accounts Work

• Account creation – A secret `spendsk` and a random nonce `r` are hashed together with a domain separator to produce the initial chain element `s₀`. Repeated Keccak‑256 applications generate a chain `s₁ … sN` (default `N = 1000`).
• Public commitment – The final element `C = sN` is stored on‑chain, and the address is derived as `trunc20(keccak256("OPHASHADDRv1" ‖ C))`.
• State storage – A pre‑deployed `NullifierTree` contract tracks, per address, the current `lastReveal` (initially `C`), the remaining `chainDepth`, and a set of spent nullifiers.
• Spending – To spend, a user reveals the next pre‑image. The transaction includes a commitment hash, a nullifier, and optionally a new chain commitment for renewal.

The state transition checks:

1. The address is registered and has remaining depth.
2. `keccak256(preImage) == lastReveal`.
3. The nullifier is correctly derived and unused.
4. A matching commitment binds the nullifier, pre‑image, and transaction digest.

If the checks pass, `lastReveal` is updated, `chainDepth` is decremented, and the nullifier is marked spent. The authorization is consumed even if the EVM call reverts.

---

2. Commit‑Reveal Mechanics and Front‑Running Mitigation

A HashCommitTx records a hash that binds a future pre‑image and transaction digest without revealing the pre‑image. A HashRevealTx later supplies the pre‑image, nullifier, and optional new chain data. The commit must be included in a block before the reveal, and the reveal must occur within `expireAfterBlocks` (default 5).

First‑Commit‑Wins Rule

The original design allowed an attacker to overwrite a pending commit after learning the pre‑image from a pending reveal. The protocol was updated (effective 2026‑10‑21) to enforce first‑commit‑wins: each address has a single pending‑commit slot, and a new commit is rejected while the slot is occupied. The slot clears only after a matching reveal or expiry, eliminating the overwrite attack.

Remaining Griefing Vector

An adversary can still submit a junk commit that blocks the address for up to five blocks. This does not enable theft because the attacker lacks the required pre‑image, but it can delay payments. Rate‑limiting (10 tx/min per address) mitigates large‑scale abuse.

---

3. Chain Renewal and Edge Cases

When `chainDepth` reaches 1, the reveal transaction may include `newCommitment` and `newChainLength`. The address continues with a fresh hash chain; failure to provide these values renders the address dead. Wallets must track the chain position and handle renewal automatically.

A malicious sequencer could censor a commit or cause a reorg that invalidates a pending reveal, exposing the pre‑image without a bound transaction. The current design relies on the sequencer’s honesty for this edge case. An alternative append‑only commitment model (the “Guy Fawkes” variant) would store all commits and accept the earliest that matches the pre‑image, removing the need for expiries and reducing griefing.

---

4. Payments‑Specific Features

• One‑time addresses – Payers derive fresh accounts for recipients; an 8‑bit view tag enables cheap scanning of `StealthPool` events.
• Token model – Only bridged stablecoins (e.g., USDC/EURC) are supported via `StealthMintableERC20` contracts; native ETH is not spent directly.
• Gas‑free user txs – Commit and reveal transactions are subsidized, with spam limited by per‑address rate limits.
• Withdrawals – Handled by a custom message passer and modified `OptimismPortal`. Withdrawal proofs are hash‑reveal based, but they trust a permissioned proposer (no fault proofs yet).

---

5. Open Questions for the Community

1. First‑commit‑wins vs. append‑only – Does the short expiry provide sufficient security against a sequencer that can reorder or censor commits?
2. Commit authentication – Are there lightweight alternatives to signatures for authenticating commits, such as a secondary short hash chain?
3. General‑purpose AA – Could hash‑chain accounts be integrated as an EIP‑7702‑style account abstraction on broader L2s rather than a dedicated chain?
4. Fault‑proof integration – How hard would it be to add a Cannon/asterisc‑compatible dispute game to this minimal state transition?

---

Closing Thoughts

The hash‑only rollup demonstrates a pragmatic path toward post‑quantum‑resistant payments on Ethereum L2s by eliminating on‑chain signatures and relying solely on Keccak‑256 pre‑image resistance. While the design introduces new trust assumptions—chiefly at the L1 boundary and in the sequencer—it offers a clear trade‑off: dramatically reduced cryptographic complexity inside the L2 in exchange for careful handling of commit/reveal ordering and chain renewal. Community feedback on the commit model, sequencer incentives, and fault‑proof extensions will be crucial for refining this approach into a robust, production‑grade solution.