However the properties expected for the heartbeat layer are unclear to me and I don’t understand why dynamic availability is the targeted condition for such protocol to be live and safe: if the heartbeat is expected to just produce an ever growing chain (subject to reordering before being finalized by the upper layer), then there are protocols working even in asynchrony and without assumptions on the proportion of faults. A simple example is to apply a function to the currently received blocks to produce a speculative order.

Depending on the function applied, the protocol can even add more guarantee to the speculative order, for instance that a prefix stabilizes over time. I believe this give people as much information about the future state of the chain as possible, even in the worst conditions ever.

We named this problem eventual state machine replication and details can be found in our paper “Kuznetsov, Perion & Tucci-Piergiovanni. (2025). Wait-free Replicated Data Types and Fair Reconciliation”.

Thanks to Alex, Andy, Keewoo, Miha, Moven, Nico, Oskar, Sora, Thore, Vitalik, Yanis, and Zoey for feedback on earlier drafts. This post was researched and written with AI assistance.

TL;DR

For long-lived confidentiality surfaces exposed to harvest-now-decrypt-later, privacy migration is more time-sensitive than authentication migration — nothing can prevent an adversary from decrypting harvested ciphertexts using quantum computers in the future, while signature forgery is at least partially remediable through hard forks and key migration (though with significant ambiguity, attribution, and rollback costs). Industry broadly shipped PQ key exchange first (Chrome, iMessage, AWS, Cloudflare); PQ authentication is still early, especially in default public-web PKI. Ethereum inherits PQ transport encryption for some surfaces (HTTPS/JSON-RPC over TLS via Go 1.24), but application-layer privacy — cryptographic protocols built on top of the EVM rather than natively supported by opcodes or precompiles, such as stealth addresses, zkID, and confidential transactions — requires Ethereum-specific work.

Introduction

The post-quantum threat to blockchain has been broadly recognized and can be categorized into two classes: authenticity and privacy. Authenticity refers to forgery of digital signatures and their broader form — zero-knowledge proofs. Privacy refers to the confidentiality of on-chain and off-chain data, as well as the anonymity and unlinkability of users and their actions.

Significant effort has been spent mitigating authenticity threats. In August 2024, NIST finalized its first three PQC standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). By early 2026, the Ethereum Foundation had elevated PQ security in the protocol roadmap and begun organizing dedicated public PQ workstreams.

By comparison, privacy threats are uniquely urgent because of harvest-now-decrypt-later (HNDL) — the strategy of capturing encrypted data today and stockpiling it until a sufficiently powerful quantum computer can break the encryption. On a conventional network an adversary must actively wiretap traffic to harvest ciphertexts, but blockchains are public, append-only ledgers: application-layer encrypted data — on-chain ciphertexts, stealth address announcements, encrypted notes, viewing keys — is already permanently visible to everyone. There is no interception step; the chain itself is the archive. Any privacy-relevant ciphertext posted today is harvestable by default and will remain exposed for the lifetime of the ledger. Unlike authenticity failures, which are at least partially remediable through emergency coordination (though with significant ambiguity and rollback costs), privacy breaches are irreversible — once a ciphertext is decrypted by a future quantum adversary, no protocol upgrade can re-encrypt it. Industry recognizes this asymmetry: Chrome, Apple iMessage (PQ3), AWS, and Cloudflare already ship PQ key exchange, while PQ authentication in the default public-web PKI remains largely undeployed — because key exchange protects against HNDL but authentication only needs to resist real-time forgery (ethresear.ch PQ tasklist, F5 Labs).

What Ethereum Gets for Free — and What It Doesn’t

Not all PQ privacy migration requires Ethereum-specific research. The broader industry’s encryption migration already covers some transport surfaces: Geth is written in Go, and Go 1.24 ships hybrid PQ TLS (X25519MLKEM768) by default — Kubernetes v1.33 got PQ key exchange automatically just by upgrading Go. HTTPS JSON-RPC endpoints, browser-to-dApp connections, and any libp2p deployments using TLS 1.3 through Go’s TLS stack inherit PQ-encrypted transport with no Ethereum protocol changes. (Ethereum’s native DevP2P/RLPx stack runs over TCP, not TLS, so it does not automatically benefit; and libp2p also supports Noise as a secure channel option, which would need its own PQ upgrade.)

What Ethereum cannot inherit is application-layer privacy — cryptographic protocols built on top of the EVM rather than natively supported by opcodes or precompiles. On-chain ciphertexts, ECDH-based key derivation for note discovery (viewing keys), ECDH-based stealth address generation, ZK-proven encryption (proving inside a ZK circuit that a ciphertext was correctly formed under a given public key, as used in compliant shielded transfers), and access pattern hiding (preventing observers from learning which on-chain records a user reads or writes, e.g., which notes they scan or spend) are all blockchain-specific problems with no industry equivalent. The remainder of this post focuses on these gaps.

Anonymity and Unlinkability

Technologies like Stealth Addresses, zkID, and zkTLS offer good UX for anonymity and unlinkability, sufficient for most use cases today. The question is whether this holds post-quantum.

Stealth Addresses

Stealth Addresses rely on Elliptic Curve Diffie-Hellman Key Exchange (ECDHKE), which is broken by quantum computers. ECDHKE can be replaced with ML-KEM off-chain, but ML-KEM-768 ciphertexts are 1,088 bytes — 33x larger than compressed ECDH points. EIP-4844 blobs are pruned after ~18 days, so using them for stealth address ciphertexts would require recipients to retrieve ciphertexts within that window — adding a liveness requirement that current stealth address designs do not have.

A potential solution without burdening calldata is Oblivious Message Retrieval (OMR) as an off-chain sidecar. This introduces a data availability trust assumption that on-chain stealth addresses do not have: recipients depend on the sidecar operator to store and serve ciphertexts. If the operator goes offline or withholds data, recipients cannot scan for their notes. ML-KEM is structurally more compatible with OMR than ECDH. a stealth address protocol based on Module-LWE outperforms classical ECPDKSAP by ~66.8% in scan time, and the hybrid “Efficient Curvy” protocol achieves ~3x faster scanning. OMR itself has improved from the original construction to PerfOMR (~40 ms/message, 235x smaller keys) and HomeRun (3,830x faster runtime). However, OMR memory costs (~20 GB+) remain impractical for lightweight infrastructure.

zkTLS

As TLS servers migrate to hybrid PQ key exchange (X25519MLKEM768), zkTLS must follow: the MPC/2PC between user and Notary must jointly perform both the X25519 and ML-KEM-768 portions of the handshake without revealing the session key to either party. Current zkTLS protocols like TLSNotary operate over TLS 1.2; TLS 1.3 support (which is where X25519MLKEM768 negotiation occurs) is on their roadmap but not yet shipped. Even for the classical X25519 key exchange inside TLS 1.3 MPC/2PC, no production zkTLS implementation exists — adding ML-KEM-768, whose NTT polynomial arithmetic is expensive in generic MPC frameworks, compounds the challenge further. A concrete demonstration may require co-designing MPC with ML-KEM’s algebraic structure rather than using generic frameworks.

zkID

zkID requires the user to prove inside a ZK circuit on their device that they correctly verified a signature, then submit only the proof — not the credential — to a verifier. Full PQ zkID requires two layers of post-quantum security: (1) the signature scheme itself must be PQ-secure (so a quantum adversary cannot forge credentials), and (2) the proving system that generates the ZK proof must also be PQ-secure (so a quantum adversary cannot forge proofs). The core question for practical deployment is how cheaply PQ signature verification can be arithmetized inside a PQ proving system.

Hash-based schemes (XMSS, Winternitz, SPHINCS+) are built entirely from hash evaluations. Replace the internal hash (SHA-256: ~25,000+ R1CS constraints) with a ZK-native alternative like Poseidon (~240 constraints — see ZKPlus benchmarks, Guo et al.), and the verification circuit shrinks by ~100x. This works because hash-based signatures are generic over the hash function — they need only collision and preimage resistance, not specific algebra. The signature stays PQ-secure and becomes cheap to prove in ZK. Lattice-based signatures (ML-DSA, FN-DSA) lack this property: their NTT polynomial arithmetic is expensive to arithmetize, making them better suited for direct on-chain verification via precompiles (EIP-8051, EIP-8052) rather than being proven correct inside a ZK circuit (i.e., the user proves “I verified this signature” in zero knowledge, without revealing the credential).

Exporting Ethereum ID

This is tractable: the ecosystem can design Ethereum-native hash-based PQ signatures with Poseidon internals, and users prove verification inside a STARK on their device. An important caveat: this is a custom, Ethereum-specific design — not standardized SLH-DSA (FIPS 205 specifies SHAKE/SHA2-based parameter sets only). It would not interoperate with external PKI or satisfy compliance frameworks that mandate NIST-approved algorithms. The approach is compelling precisely because the ecosystem controls both the signer and the verifier, but it should be understood as a native design choice, not a standards-compliant one. **

Importing real-world ID

This is hard: issuers will use standardized ML-DSA or SLH-DSA with SHA-256/SHAKE, not Poseidon. The full verification — including SHA-256/SHAKE and (for ML-DSA) lattice NTT — must be arithmetized as-is. There is a deeper mismatch: real-world signature schemes are typically optimized for fast signing (a server signs many credentials) at the expense of verification cost (a single client verifies), which is the opposite of the blockchain setting where verification happens on-chain or inside a ZK circuit and must be cheap. This design asymmetry is a structural reason why importing real-world credentials is inherently expensive. The lattice-based designated-verifier zkSNARK by Wu et al. achieves ~16 KB proofs (10.3x smaller than Aurora) but remains 131x larger than Groth16; note that the designated-verifier setting means the proof can only be checked by a specific verifier who holds a secret key, not publicly verified on-chain — an additional limitation for blockchain use cases. STARKs are the most practical PQ path (they rely only on collision-resistant hashes, no lattice or pairing assumptions) but produce significantly larger proofs than pre-quantum SNARKs like Groth16. Remaining gaps: closing the 131x PQ/pre-quantum SNARK gap; efficient arithmetization of NIST PQ signature verification; a production-ready PQ SNARK for credential verification.

Confidentiality

Confidentiality — hiding transaction amounts, balances, and contract state — is the regime of privacy-focused Ethereum L2 infrastructure like Aztec (Ignition Chain launched November 2025, though mainnet phase 1 is not yet executing user transactions) and application-layer tools like Railgun and Privacy Pools. State commitments (Merkle trees, note hashes) can use PQ-safe hashes like Poseidon — the vulnerability lies in the encryption layer. Two distinct subproblems arise:

• Note discovery and key exchange: viewing keys in systems like Aztec rely on EC-based key derivation — the sender encrypts to the recipient’s public key so the recipient can identify notes intended for them. ML-KEM can replace ECDHKE here (same 33x ciphertext bloat as stealth addresses, same OMR-based mitigation path), but this key exchange happens outside the ZK circuit and does not require in-circuit proving.
• Proven-correct encryption to a designated auditor / compliance recipient: for selective disclosure in compliant shielded transfers, the sender encrypts directly to the designated recipient’s known public key and proves correctness inside a ZK circuit. The recipient could be a regulatory body, an institutional compliance desk, a DAO treasury auditor, or any party the protocol designates. Pre-quantum, ElGamal did this cheaply (one EC scalar mul, trivially ZK-friendly). Post-quantum, the sender would use lattice-based PKE (e.g., Kyber.CPAPKE or plain-LWE Regev encryption). For most practical designs, the sender can perform lattice PKE outside the circuit, derive a symmetric key, and prove correct symmetric encryption inside the circuit using Poseidon in sponge mode (~240 constraints per permutation, PQ-safe, already used by Aztec for note encryption). If the sender cheats (encrypts to a dummy key), the auditor gets garbage and flags the transaction — a detect-and-flag model. A stronger model — where the protocol guarantees the designated recipient can decrypt — would require proving lattice PKE correct inside a ZK circuit, which remains expensive due to the field mismatch (lattice arithmetic over q = 3,329 vs. proof system fields like BN254), though simpler than full ML-KEM. Whether the weaker detect-and-flag model suffices is an open policy question as much as a cryptographic one.

Client-Side Proving as a Dependency

Both zkID and confidentiality require the user to generate ZK proofs on their own device — delegating to a server leaks the very private inputs the proof is meant to protect. While GPU acceleration benefits all proving backends, PQ proving systems stand to gain disproportionately for two reasons: (1) current CPU performance makes PQ proof generation infeasible for client-side use, creating a harder dependency on GPU acceleration than pre-quantum systems have, and (2) PQ primitives — NTT-based polynomial arithmetic over small fields — are more naturally aligned with GPU architecture than group-based elliptic curve operations, which face a theoretical acceleration upper bound due to their sequential carry-chain dependencies. NTT is the shared primitive across STARK proving and lattice operations, and small-field PQ schemes (M31, q = 3,329) achieve 100+ Gops/s on mobile GPUs vs. < 1 Gops/s for BN254 — so the raw throughput is there.

GPU acceleration applies to both the Ethereum-native ID path (Poseidon-internal hash-based signatures proven in STARKs) and the real-world ID import path (NIST PQ signature verification in SNARKs). But the Ethereum-native path offers a significantly easier route to client-side privacy: by controlling the signature scheme, the ecosystem can choose primitives that are both PQ-safe and GPU-friendly from the start, rather than arithmetizing externally imposed algorithms. Prioritizing the Ethereum ID design space is therefore also a pragmatic client-side proving strategy.

Client-side GPU proving is a broader Ethereum infrastructure challenge (benefiting censorship resistance, validity proofs, and more), not specific to post-quantum privacy. We note it here as a dependency: PQ privacy cannot ship without it, but the GPU ZK ecosystem and its PQ roadmap are best addressed as a general proving infrastructure effort.

Near-Term Roadmap Recommendations

The problems above sit at different levels of maturity. Some have known PQ replacements and can move to implementation; others remain open research. A useful roadmap separates what can ship from what needs breakthroughs — and avoids accumulating new exposure while waiting.

Design principle: no new classical privacy debt. Confidentiality debt is irreversible — unlike authenticity debt, which can be partially remediated through key rotation or emergency forks. Every new privacy protocol that stores long-lived ECDH-derived ciphertext extends the HNDL exposure window permanently. New designs should default to PQ key exchange for any confidentiality surface that persists beyond a single session, with explicit, documented exceptions where PQ alternatives are not yet practical.

1. Quantify the privacy honeypot. A quantum honeypot is the total extractable value a sufficiently powerful quantum computer unlocks on arrival. The authenticity honeypot — aggregate value in accounts with quantum-vulnerable keys — is large but bounded: the community can coordinate an emergency hard fork to freeze exposed accounts and migrate to PQ signatures.

   The privacy honeypot is structurally different and is the focus of this article. It is the cumulative encrypted data on-chain since genesis, growing with every block. No fork can re-encrypt past ciphertexts. Each category of exposure compounds independently:

   • Shielded transactions and encrypted notes: a quantum adversary retroactively decrypts every balance, transfer amount, and contract state ever committed to a shielded pool — full financial histories for every participant.
   • Stealth address linkages: ECDH-derived stealth addresses become traceable back to recipients, collapsing the unlinkability that stealth schemes are designed to provide.
   • Selectively disclosed credentials: compliance-protected disclosures intended for a designated auditor become readable by anyone with a quantum computer — exposing KYC data, institutional positions, and identity linkages to unintended parties.
   • Viewing keys and note discovery: EC-based key derivation for note scanning reveals which notes belong to which recipients, deanonymizing the entire transaction graph even where amounts remain hidden behind symmetric encryption.

   The social implications are distinct from theft: retroactive deanonymization of political donors, dissolution of financial privacy for individuals and institutions, exposure of compliance relationships. The authenticity honeypot can be drained and then stopped. The privacy honeypot can only be prevented from growing further — every block adds irreversible exposure.

   Deliverable: a quantified, regularly updated estimate of the privacy honeypot — data categories at risk, growth rate per category, and remediation timelines — giving governance a concrete basis for migration urgency. An analogous estimate for the authenticity honeypot (value at risk, fork readiness) is useful context but is already better understood.

2. Build a confidentiality surface registry. Enumerate every privacy surface where ciphertext or key material outlives a single session: stealth announcements, viewing keys, encrypted notes, application-layer ciphertext, credential imports, selective-disclosure flows. Tag each with storage lifetime, cryptographic assumptions, and PQ replacement availability. The output is a structured registry teams can query to prioritize migration — not a narrative threat model.

   To keep the registry current, new EIPs and protocol specs that introduce or depend on confidentiality surfaces should include a PQ threat model section — analogous to the existing Security Considerations requirement — identifying quantum-vulnerable assumptions, HNDL-exposed data, and migration paths. This turns PQ readiness from a retroactive audit into a standing design constraint.

3. Ship reference libraries and benchmarks for tractable surfaces. Two surfaces have known PQ primitives and can move to implementation now:

   • ML-KEM note discovery: ciphertext generation and scanning, wallet/indexer interfaces, OMR retrieval sidecars.
   • Ethereum-native zkID: Poseidon-internal hash-based PQ signatures with STARK verification circuits, benchmarked for client-side proving time and proof size.

   The goal is common baselines, not production readiness — ideally validated end-to-end against at least one privacy-oriented L2 or application stack to surface integration issues that benchmarks alone miss.

4. Scope open problems as non-blocking research tracks. Three areas are important but unsolved: PQ-compatible zkTLS (MPC/2PC over ML-KEM handshakes), real-world zkID import (arithmetization of NIST PQ signature verification), and protocol-enforced proven-correct encryption to designated auditors. No concrete protocol exists for any of them within practical constraints. Fund and track these, but do not block progress on the registry, reference libraries, or the design principle above.

Feedback welcome — particularly on the privacy honeypot framing, the tractability assessments, and any PQ privacy surfaces we may have missed.

As you yourself expressed the idea of depositing funds being reasonable, then further consideration should be much warranted. Maybe the fund, albeit a small amount, can be recovered (from the position of purportedly genuine users), a default delay of the recovery (maybe having to wait 24 or 48 hours after withdrawal, much like validators having to wait in recovering their stakes upon deciding to exit) can be considered.

A genuine user, even in times of financial emergency, should not be financially ruined by the small waiting period in recovering a petty amount. But to a spammer-cum-address poisoner, that 24 to 48 hours (or maybe even a week) of waiting period to recover his small deposit from one phishing address to another would be a massive hindrance. Though, he can avoid the wait by funding all his phishing addresses with existing fund but then he would need a very significant amount of ETH in reserve for this, which would be yet another stopping point.

In such a setup, Ethereum would still enjoy cheapass gas fee without much trouble from spammers-cum-address poisoners.

Update:
According to the Culper report, much of the validator participation (post-cheapass gas fee) is artificially boosted by Bitmine alone. Excluding Bitmine, the actual participating validators would be significantly much lower. Essentially, you have one entity that is significantly dominating the board of validators.

I hope the Ethereum development team revolves around doing what is morally right, and not around appealing to the needs of a certain group of people aka the banksters. There is zero validation in the expression “We’re not being controlled nor owned by the banksters. We’re just doing everything they want and need.”

High fees aren’t necessarily bad, but they should only target those who pollute the network, not everyone. Of course, more complex transactions will incur higher costs, but it’s better to ensure low costs for users in most use cases while still severely punishing those who pollute the network. As I mentioned above, EIP-8037 has handled this quite well.

The idea of ​​depositing funds for each new account is reasonable, but it needs further consideration from a technical perspective: Is that money recoverable? How? (Closing the account, or simply transferring it elsewhere?) Otherwise, will the money be permanently burned or distributed to validators?

If paying higher fees can help to significantly reduce fraud (and spam), then why is this now being taken to be a very bad thing? Aren’t users supposed to pay more fees for executing transactions with high economic values and features such as the one you mentioned.

A simpler transaction should use less computation power and the gas fee should be reflected lower. Conversely, a more sophisticated transaction using exponentially higher computation power should be expected to pay far higher gas fee to commensurate for the substantial economic value involved. This should be the economic logic. And if it still fail because the gas fee gets too exorbitantly high because ETH price goes parabolic, then why not just implement a maximum ceiling price by then? Everyone with genuine transactions would win.

Having a minimum bound will resolve address poisoning and spam first for now. This will restore user confidence and grow adoptions. Later, having a maximum bound would resolve exorbitant gas fee later.

Or better still, since every address will assimilate into account abstraction, then making it a default requirement for a newly created address to have a deposit for reserve of say 0.001 ETH to have any functionality and use (similar to some other blockchain that require some deposit upon a new creation) would totally eliminate address poisoning and spam altogether. With such setup, your ideal of having an unbounded cheapass gas fee will stay and the users’ nightmare with address poisoning and spams will be gone.

A large number of transactions that aren’t necessarily spam, such as single transfers from exchanges to wallets, will increase, causing users to pay more fees.

Even small transactions require signatures, and there has been much discussion about post-quantum signature schemes, which generally require significant computational resources (such as zk). Setting a floor as proposed seriously hinders secure transition efforts; otherwise, we would see ecosystem fragmentation as some transactions use older, less secure schemes while others use newer ones.

This proposal primarily reduces spam but hinders access for more users in the future, whereas we have more sustainable, indirect solutions to influence this behavior. Micro-payment models like x402 also cannot operate effectively on the mainnet with the proposed gas fees.

Does ETH inflation affect validator revenue? In my opinion, no, because we need to consider operating costs. Hardware is now cheaper and more efficient, allowing validators to operate effectively at a lower cost. This partially offsets the revenue loss. More importantly, Ethereum is moving closer to stateless clients, enabling more people to operate the network.

Authors
Abel Gutu — Founder & CEO, LedgerWell Inc. Designer and Architect of the CVR Protocol.
Robert Stillwell — Co-founder & CTO, LedgerWell Inc. / CEO, DaedArch Corporation. Builder of the CVR Protocol Engineering Infrastructure.

Date
March 2026

Builds on
ethresear.ch/t/23577 · ethresear.ch/t/23609

Keywords
MCMC · Bayesian fusion · oracle consensus · Basel SCO60 · Group 1a · RWA tokenization · CVR Protocol · Hidden Markov Model

Abstract

This paper introduces Markov Chain Monte Carlo (MCMC) as the computational engine that makes the CVR Protocol’s reputation-weighted Bayesian oracle consensus tractable at institutional scale, and demonstrates that this engine is the precise mathematical mechanism required to produce tokenized physical assets satisfying the Basel Committee on Banking Supervision’s Group 1a classification conditions under SCO60. The CVR Protocol’s oracle network — whose mathematical foundations were established in [1] and [2] — constitutes a Hidden Markov Model (HMM) operating over the continuous physical states of real-world assets. MCMC, specifically the Metropolis-Hastings algorithm applied to the oracle reputation posterior, provides convergence guarantees that are directly mappable to the ‘ongoing basis’ classification requirement of SCO60. We derive a Verification Discount quantification method from the MCMC posterior credible intervals, extend the Basel risk-weight formula introduced in [1] to incorporate full posterior uncertainty, and show that only a continuously monitored, adversarially resistant oracle network satisfying our convergence conditions can produce tokenized physical commodity claims that meet all four SCO60 Group 1a classification conditions simultaneously. The Ethiopian cooperative carbon farming deployment of the CVR Protocol is used as the primary empirical case throughout.

1. Introduction and Motivation

The Basel Committee on Banking Supervision finalized its cryptoasset prudential standard (SCO60) in December 2022 and revised it in July 2024, with full implementation by 1 January 2026. The standard creates a four-tier classification system in which Group 1a tokenized traditional assets — those that confer legally equivalent rights to their physical counterparts — inherit the capital treatment of the underlying asset rather than facing the 1,250% risk weight applied to unclassified cryptoassets. For tokenized physical commodities — carbon credits, agricultural produce, land — Group 1a classification is the difference between a viable institutional asset class and a regulatory dead end.

The critical barrier to Group 1a classification for tokenized physical assets is not legal structure. It is continuous verification. SCO60 requires that banks assess classification conditions on an ‘ongoing basis’, that the tokenized asset ‘confer the same level of legal rights as traditional account-based records of ownership of a physical commodity’, and that the network ‘not pose material risks to transferability, settlement finality, or redeemability’. For physical assets whose value depends on continuously changing real-world conditions — soil carbon sequestration, canopy integrity, supply chain provenance — satisfying these conditions requires a mathematical framework for continuous, adversarially resistant physical state verification. No such framework has been formally specified for blockchain oracle systems until now.

This paper provides that framework. It builds directly on the oracle reputation model and three-layer architecture introduced in [1] and the CVR Protocol’s mathematical specification in [2]. We show that the reputation-weighted Bayesian fusion used in those papers is a specific instance of MCMC applied to the posterior distribution over oracle reliability, and that MCMC’s ergodic theorem provides the convergence guarantee that makes continuous physical asset verification mathematically provable rather than merely asserted.

The core claim: A tokenized physical asset whose underlying state is continuously monitored by an MCMC-convergent CVR Protocol oracle network satisfies all four SCO60 Group 1a classification conditions. Its risk-weighted asset value is calculable from the MCMC posterior credible interval — not from the 1,250% default weight applied to unverified cryptoassets.

2. The CVR Protocol as a Hidden Markov Model

2.1 State Space Definition

Let the true physical state of an asset at time t be the latent variable Sₜ, which is not directly observable. For a carbon farming cooperative site, Sₜ is a vector of physical variables:

Physical State Vector — not directly observable

Sₜ = (Cₜ, Wₜ, Bₜ, Pₜ)

where Cₜ is soil carbon stock (tCO₂e per hectare), Wₜ is water table depth (metres), Bₜ is boundary integrity (binary), and Pₜ is canopy density fraction. The observed variables are oracle sensor submissions at each consensus round:

Observable Oracle Submissions — round t

Oₜ = { o⁽¹⁾ₜ, o⁽²⁾ₜ, …, o⁽ⁿ⁾ₜ }

The emission probability — how likely any given oracle reading is given the true physical state — is modelled as a Gaussian scaled by the oracle’s reputation score R(i,t) from [1]:

Emission Probability — reputation-variance scaled

P(Oₜ | Sₜ) = Π N( o⁽ⁱ⁾ₜ ; Sₜ, σ²ⁱ / R(i,t) )

This is the formal mechanism that converts the reputation formula from [1] into a statistically coherent likelihood weighting scheme. High-reputation oracles have lower emission variance — their readings are trusted to sit closer to the true physical state. Low-reputation oracles have higher emission variance — their readings are discounted proportionally.

2.2 State Transition Dynamics and the Markov Property

The physical asset state evolves according to Markov transition probabilities. The transition from Sₜ to Sₜ₊₁ depends only on the current state — not on the history of how the asset arrived there:

The Markov Property — memory-less state transition

P(Sₜ₊₁ | Sₜ, Sₜ₋₁, …, S₁) = P(Sₜ₊₁ | Sₜ)

This is not an approximation for physical carbon dynamics — it is the correct model. The soil carbon stock next month depends on the stock this month, current management practices, and season. It does not depend on the stock three years ago except through the current state. The Hidden Markov Model is therefore the precisely correct mathematical structure for continuous physical asset monitoring, not a simplification imposed for computational convenience.

2.3 The Filtering Problem — Why MCMC Is Required

The core computational challenge is the filtering problem: given the sequence of oracle observations up to time t, what is the posterior distribution over the true physical state Sₜ?

Bayesian Filter Update Equation

P(Sₜ | O₁,…,Oₜ) = [ P(Oₜ | Sₜ) · P(Sₜ | O₁,…,Oₜ₋₁) ] / P(Oₜ | O₁,…,Oₜ₋₁)

The denominator — the marginal likelihood of the observations — requires integrating over all possible physical states. This integral is analytically intractable when the state space is continuous and the emission probabilities are non-Gaussian, as field IoT sensor data inevitably are. This is precisely the problem MCMC was developed to solve: drawing samples from a distribution that cannot be evaluated analytically, but whose unnormalised density can be computed pointwise.

Why conjugate priors are insufficient: Carbon sequestration dynamics are non-Gaussian, multi-dimensional, and exhibit heavy-tailed outlier behaviour from sensor faults and extreme weather events. Closed-form Bayesian updates using conjugate priors are not applicable. MCMC is not a computational convenience — it is the only mathematically correct approach to this inference problem at scale.

3. MCMC Applied to CVR Protocol Oracle Consensus

3.1 The Metropolis-Hastings Algorithm for Oracle Reputation

The Metropolis-Hastings (MH) algorithm constructs a Markov chain whose stationary distribution equals the target posterior. Applied to the CVR Protocol, the target is the joint posterior over the true physical asset state and all oracle reputation scores, given the current consensus round’s submissions:

Target Posterior Distribution — joint over state and reputations

π(Sₜ, R | Oₜ) ∝ P(Oₜ | Sₜ, R) · P(Sₜ | Sₜ₋₁) · P(R | Rₜ₋₁)

The MH acceptance probability for a proposed move from (S, R) to (S*, R*) is:

Metropolis-Hastings Acceptance Ratio

α = min( 1, [ π(S*, R* | Oₜ) · q(S,R | S*,R*) ] / [ π(S,R | Oₜ) · q(S*,R* | S,R) ] )

The critical property: this ratio does not require computing the intractable normalising constant P(Oₜ | O₁:ₜ₋₁). The MH algorithm works with ratios of unnormalised posteriors only, making the filtering problem computationally tractable for large oracle networks with multiple sensor types. This is the algorithmic bridge that makes the CVR Protocol’s oracle economics deployable at institutional scale.

3.2 The Ergodic Theorem — The Convergence Guarantee

The ergodic theorem is the fundamental convergence result that makes MCMC useful for inference. For an irreducible, aperiodic, positive-recurrent Markov chain, the time-average of any function of the chain converges to its expectation under the stationary distribution, regardless of the starting state:

Ergodic Theorem — the MCMC Law of Large Numbers

(1/N) · Σ (k=1 to N) f(θₖ) → E₍π₎[f(θ)] as N → ∞

Applied to the CVR Protocol: as the number of oracle consensus rounds increases, the sample mean of any function of the oracle state — including the estimated soil carbon stock, the verified deforestation-free probability, or the water table depth — converges to its true posterior expectation under the joint distribution over physical states and oracle reputations. The CVR Protocol does not converge to a point estimate. It converges to the full posterior distribution over the true physical asset state, with quantified uncertainty.

The irreducibility condition is satisfied by the CVR Protocol’s slashing mechanism and reputation floor: any oracle that consistently submits biased readings eventually has its reputation driven to the minimum, but is not permanently excluded — ensuring the chain can reach all plausible physical states. Aperiodicity is guaranteed by the continuous-valued physical state space. Positive recurrence follows from the finite physical bounds of carbon stocks and environmental parameters.

The convergence guarantee in regulatory language: The MCMC ergodic theorem provides the mathematical proof that a CVR Protocol oracle network, operating over a sufficient number of consensus rounds, produces a verified estimate of the physical asset state that converges to the true posterior — with quantified uncertainty bounds expressed as credible intervals. This is the continuous monitoring guarantee that SCO60 Group 1a classification requires.

3.3 The 3-Sigma Threshold as a Bayesian Credible Interval Test

The 3-sigma slashing threshold from [1] and [2] is now formally interpretable within the MCMC framework. After M burn-in iterations are discarded, the MCMC chain produces N posterior samples of the true asset state. The 3-sigma boundary is the rejection region of the Bayesian credible interval:

3-Sigma Threshold — Bayesian Credible Interval Test

Reject oracle i if: | o⁽ⁱ⁾ₜ - E₍π₎[Sₜ | Oₜ] | > 3 · √(Var₍π₎[Sₜ | Oₜ])

Readings outside this boundary have posterior probability less than 0.0027 of occurring if the oracle is reporting truthfully under the current posterior. The 15% stake slash for 3-sigma deviation is therefore an economically calibrated penalty for submitting evidence statistically inconsistent with the posterior consensus. The 20% slash for cryptographically proven false data is the maximum penalty for an event with zero posterior probability under honest reporting. The asymmetry between the two penalties correctly reflects the information content of the evidence: statistical improbability warrants a smaller penalty than cryptographic proof of malice.

4. Connecting MCMC Convergence to Basel SCO60 Group 1a

SCO60 specifies four classification conditions that must be satisfied at all times for a tokenized asset to qualify as Group 1a. We map each condition to a specific, verifiable property of the MCMC-convergent CVR Protocol.

5. Extending the Risk-Weight Formula with MCMC Posterior Uncertainty

5.1 The Original Verification Discount Model

In [1], the Basel risk-weight formula was extended with a static Verification Discount Dᵥₑᵣ:

Original Verification Discount Formula — [1]

RWAᶜᵛᴿ = Exposure · RiskWeight · (1 - Dᵥₑᵣ)

Dᵥₑᵣ was estimated at 20-50% based on continuous commodity monitoring evidence. This paper formalises Dᵥₑᵣ as a function of the MCMC posterior credible interval width — providing a principled, auditable, and dynamically updating verification discount rather than a static estimate.

5.2 The Dynamic Posterior Verification Discount

Let the 95% posterior credible interval for asset state Sₜ, derived from N post-burn-in MCMC samples, be [Lₜ, Uₜ]. Define the Posterior Uncertainty Ratio (PUR) as the ratio of the credible interval width to the asset’s nominal value V:

Posterior Uncertainty Ratio — dynamic, per consensus round

PURₜ = (Uₜ - Lₜ) / V

The Verification Discount is a decreasing function of the PUR — lower uncertainty means higher discount:

Dynamic Verification Discount — MCMC-derived

Dᵥₑᵣ(t) = Dₘₐₓ · ( 1 - PURₜ / PURₘₐₓ )

where Dₘₐₓ is the maximum discount available under the regulatory framework (calibrated at 40-60% from [1]) and PURₘₐₓ is the PUR corresponding to zero discount — the uncertainty level of an unverified, static annual audit. The full dynamic Basel-MCMC risk-weight formula is therefore:

Full Dynamic Basel-MCMC Risk-Weight Formula

RWAᶜᵛᴿ(t) = Exposure · RiskWeight · ( 1 - Dₘₐₓ · ( 1 - PURₜ / PURₘₐₓ ) )

What this formula means for institutional investors: The verification discount is no longer a regulatory negotiation — it is a mathematical output of the MCMC chain. At each consensus round, the posterior credible interval narrows or widens based on sensor agreement, and the capital requirement adjusts accordingly. This is continuous capital optimisation, not periodic re-assessment.

5.3 Numerical Illustration — Ethiopian Carbon Cooperative

The following illustrative example uses projected parameter values for a single Ethiopian coffee cooperative site under Phase 1 CVR Protocol deployment (4 IoT sensor types, n=7 oracle nodes). The PUR values shown are pre-deployment estimates that will be empirically calibrated using Phase 1 sensor data from Q3 2026 onward:

6. Convergence Conditions for Institutional Deployment

The MCMC convergence guarantee requires specific conditions to hold in practice. The following are the minimum deployment requirements for a CVR Protocol oracle network to satisfy the ergodic theorem and therefore produce Group 1a-eligible tokenized assets.

7. The Ethiopian Cooperative Network — Empirical Grounding

The CVR Protocol’s Phase 1 deployment targeting 47 Ethiopian agricultural cooperative sites — beginning with 5 initial cooperative sites in Q2 2026 and scaling to the full 47-site network — provides the empirical grounding for the MCMC framework. Ethiopia published its National Carbon Market Strategy (2025–2035) in June 2025 [11], establishing the policy framework for Article 6.2 bilateral transfers, Article 6.4 mechanism participation, and voluntary carbon market engagement. The CVR Protocol deployment operates within this national strategy framework. Each site instantiates a 7-oracle Metropolis-Hastings chain over a 4-dimensional physical state space, updated at each IoT sensor consensus round.

7.1 The Prior Distribution

The prior over the physical asset state is informed by existing IPCC soil carbon data for Ethiopian Highland and Rift Valley agroecological zones, supplemented by the Ministry of Agriculture’s ground-truth survey data from the Green Legacy Initiative’s 48.8 billion tree planting program. The prior is not flat — it incorporates genuine domain knowledge from the world’s largest afforestation program, making posterior credible intervals tighter from the first consensus round than a naive uninformed prior would produce.

Site Prior — Green Legacy Initiative Calibrated

P(S₀) = N(μ₍GLI₎, Σ₍GLI₎)

where μ₍GLI₎ is the mean carbon stock for the site’s agroecological zone and Σ₍GLI₎ is the within-zone variance from GLI survey data.

7.2 Credit Issuance Conditions

A carbon credit issuance event occurs when the MCMC posterior simultaneously satisfies three conditions:

Credit Issuance Conditions — all three required simultaneously

L⁽⁹⁵⁾ₜ > C₍baseline₎ + δ₍min₎ AND R-hat < 1.05 AND chain_length > N₍min₎

where C₍baseline₎ is the project baseline carbon stock, δ₍min₎ is the minimum verifiable increment, and N₍min₎ is the minimum post-burn-in sample count. All three conditions must hold before a credit issuance event is committed to the blockchain.

7.3 EUDR Supply Chain Application

The same MCMC framework applies to EUDR supply chain verification with a modified state space. The EU Deforestation Regulation, as amended by Regulation (EU) 2025/2650 in December 2025, applies to large operators from 30 December 2026. For Ethiopian coffee — where 92% of landholdings are smaller than 0.5 hectares under largely informal land tenure — the MCMC posterior provides the continuous compliance evidence that the regulation’s Due Diligence Statement requires:

EUDR Physical State Vector

S⁽ᴱᵁᴰᴿ⁾ₜ = (Fₜ, Lₜ, Tₜ, Wₜ)

where Fₜ is deforestation-free status of the cultivation area, Lₜ is GPS-verified land parcel identity, Tₜ is crop type and harvest timestamp, and Wₜ is processing facility compliance status. The MCMC posterior over this state vector, updated continuously from IoT sensor submissions and satellite boundary verification, produces the Due Diligence Statement required by the EU Deforestation Regulation at any point of demand — not as a periodic audit report but as a continuously maintained posterior probability distribution over supply chain compliance.

8. Addressing the SCO60 Permissionless Blockchain Barrier

SCO60 creates a significant barrier for assets on public permissionless blockchains: Classification Conditions 3 and 4 effectively require that node validators be regulated and supervised, which is not practically feasible for Ethereum’s open validator set. The Basel Committee acknowledged this limitation in the original standard and has since moved toward active reconsideration: at its November 2025 meeting in Mexico City, the Committee agreed to expedite a targeted review of specific elements of the cryptoasset standard, and a February 2026 update confirmed ongoing progress on this review.

The MCMC convergence framework provides a path through this barrier because it separates two distinct functions that SCO60 conflates: settlement finality (provided by Ethereum validators) and physical state verification (provided by the CVR Protocol oracle network). The oracle nodes are the entities making physical verification claims. The Ethereum validators are processing the transactions that record those claims. These are separable functions with separable regulatory treatment.

The oracle network — which is the entity making physical asset state claims, which is subject to economic bonding, reputation staking, and quantified slashing enforcement, and which operates under sovereign government oversight in the Ethiopian deployment — constitutes the ‘appropriate risk management standards’ required by SCO60 Condition 4 for the verification layer specifically. The MCMC convergence proof strengthens this argument because it makes oracle network reliability quantifiable: a bank’s compliance officer can be presented with the R-hat diagnostic, the Gelman-Rubin statistic, the burn-in period, and the posterior credible interval — all auditable outputs of the MCMC chain.

The regulatory argument: The Ethereum base layer provides settlement finality for the tokenized asset — it is not the source of physical asset verification risk. The CVR Protocol oracle network — economically bonded, reputation-gated, and MCMC-convergent — constitutes the quantifiable risk management standard required by SCO60 Condition 4 for the physical verification layer.

9. Open Questions and Invitation for Collaboration

This framework opens several research directions that would strengthen both the mathematical foundations and the regulatory argument. I invite collaboration from the Ethereum Research community on each of the following.

1. Hamiltonian Monte Carlo for high-dimensional state spaces. As CVR Protocol deployments scale to multi-sensor, multi-crop cooperative networks, the Metropolis-Hastings sampler may exhibit slow mixing. Hamiltonian Monte Carlo uses gradient information about the posterior geometry to propose moves that traverse the state space more efficiently.
2. Sequential Monte Carlo for real-time filtering. The MH approach is a batch MCMC method requiring multiple iterations per consensus round. Sequential Monte Carlo (particle filter) methods update the posterior recursively as each oracle submission arrives, without requiring multiple iterations.
3. Calibrating the Verification Discount for Basel supervisory acceptance. The dynamic Dᵥₑᵣ(t) formula requires empirical calibration of Dₘₐₓ and PURₘₐₓ with regulatory acceptance by supervisory authorities implementing SCO60.
4. Formal verification of the slashing mechanism via the Transaction Carrying Theorem. The TCT proposal referenced in [1] offers design-level safety verification for smart contract logic. Applying TCT to the CVR Protocol slashing and reputation contracts would provide formal proof that the slashing conditions are correctly computed.

10. Conclusion

This paper has shown that Markov Chain Monte Carlo is not an optional computational enhancement to the CVR Protocol — it is the mathematical engine that makes the protocol’s core claims provable rather than merely asserted. The oracle reputation model introduced in [1] is a Markov chain. The reputation-weighted Bayesian fusion is a posterior inference problem. MCMC is the algorithm that makes this inference tractable at scale and provides the ergodic convergence guarantee that translates continuous physical monitoring into a regulatory-grade evidence standard.

The connection to Basel SCO60 Group 1a is not a marketing claim. It is a structural argument: the four classification conditions for first-class tokenized assets require continuous, adversarially resistant, legally documented verification of physical asset state. The MCMC-convergent CVR Protocol satisfies all four conditions simultaneously with a formal mathematical convergence guarantee rather than a governance checklist. The dynamic verification discount derived from the MCMC posterior credible interval is the principled, auditable mechanism that translates this convergence into quantifiable capital relief for institutional holders.

The thesis in one sentence: The difference between a $3 carbon credit and a $37 carbon credit is mathematical proof of continuous verification — and Markov Chain Monte Carlo is that proof.

References

1. Gutu, A. (2025). Proposal: A Continuous Verifiable Reality (CVR) Framework for Reducing RWA Collateral Risk Weights. Ethereum Research, ethresear.ch/t/23577. December 1, 2025.
2. Gutu, A. (2025). ProofLedger: Core Tenets and Mathematical Framework Based on ProofLedger Documentation. Ethereum Research, ethresear.ch/t/23609. December 4, 2025.
3. Basel Committee on Banking Supervision (2022, rev. 2024). Prudential treatment of cryptoasset exposures — SCO60. BIS. Implementation date: 1 January 2026.
4. Metropolis, N., Rosenbluth, A.W., Rosenbluth, M.N., Teller, A.H., Teller, E. (1953). Equation of State Calculations by Fast Computing Machines. Journal of Chemical Physics, 21(6), 1087–1092.
5. Hastings, W.K. (1970). Monte Carlo sampling methods using Markov chains and their applications. Biometrika, 57(1), 97–109.
6. Gelman, A., Rubin, D.B. (1992). Inference from iterative simulation using multiple sequences. Statistical Science, 7(4), 457–472.
7. European Commission (2026). Draft Delegated Regulation Annex — Carbon Farming Certification Methodologies under CRCF Regulation EU 2024/3012. Ref. Ares(2026)746080, January 22, 2026.
8. Doucet, A., de Freitas, N., Gordon, N. (2001). Sequential Monte Carlo Methods in Practice. Springer.
9. Neal, R.M. (2011). MCMC using Hamiltonian dynamics. In Handbook of Markov Chain Monte Carlo, Chapter 5. CRC Press.
10. Perspectives Climate Group / VCMI / GIZ (2026). Pathways for Strengthening Validation and Verification Body (VVB) Capacity in Africa. February 27, 2026.
11. Federal Democratic Republic of Ethiopia (2025). Ethiopia’s National Carbon Market Strategy (2025–2035). June 2025. Published via UNFCCC Regional Collaboration Centre.
12. Council of the European Union (2025). Regulation (EU) 2025/2650 amending the EU Deforestation Regulation. Adopted December 18, 2025. Application date: 30 December 2026 for large operators.
13. Basel Committee on Banking Supervision (2025). Press release: Basel Committee agrees to expedite targeted review of cryptoasset standard. November 19, 2025. BIS.
14. Basel Committee on Banking Supervision (2026). Press release: Basel Committee discusses targeted review of cryptoasset standard. February 25, 2026. BIS.
15. European Commission Implementing Regulation (EU) 2025/2358 of 20 November 2025, establishing horizontal rules for CRCF certification schemes, certification bodies, and audits under Regulation (EU) 2024/3012.

Abel Gutu · Founder & CEO, LedgerWell Corporation
Robert Stillwell · Co-founder & CTO, LedgerWell Corp. / CEO, DaedArch Corporation

ledgerwell.io

CVR Protocol Mathematical Framework Series — Publication 3 of 4 in the CVR mathematical framework sequence.
Feedback on convergence diagnostics, regulatory mapping, and empirical calibration methodology is actively sought.# Markov Chain Monte Carlo as the Computational Engine for Basel SCO60 Group 1a Tokenized Physical Asset Verification

No 3rd-party wallet should be obligated to share the burden of censoring transactions due to address poisoning. The solution should be at the fundamental level, not at the superficial level.

I just checked with the AI on computation. At current price range, a 1 Gwei fee is just a measly USD 0.04. Give me a break. If 1 Gwei can increase the cost significantly, say USD 40 the likes of international bank wire transfer, then the price of ETH would be around USD 200,000 +. This is not supposed to be anyone’s current worry. The current worry is address poisoning and Ethereum being undesirably inflationary.

Upgrades are not the same as (and should not be viewed as the same with) temporary band aid fixes and patches. They should be meaningful improvements. Not temporary band aid fixes.

Who and what proportion of users may actually need to make computationally expensive transactions that justify unbounded cheapass gas fee both today and in the future? HFT firms doing front-running with sub-penny trades on the blockchain? Poor people just trying to buy a cup of coffee? Have you figured that out? What kind of user would need a computationally expensive transaction that has substantial economic value (it can’t possibly be of low economic substance if it needs high computational power) and yet would be so miserable to complain of higher fee?

And why can’t having both minimum bound floor price + maximum bound ceiling price (on gas) help to reduce exploits right away as well as eliminate exorbitant fees in the future? Why are you so cocksure this will 100% absolutely NEVER work, despite having no supporting evidence?

Update:
I figured your argument for an unbounded cheapass gas fee is valid now and forever ONLY under one very specific situation → the price of ETH being over USD 200,000 AND every transaction is computationally expensive, including making a simple EOA transaction or to one-off buy a cup of coffee. Any situation that fail to satisfy both the conditions stated would invalidate the argument for unbounded cheapass fee completely.

If the development is such that even a simple transaction would need to be computationally expensive, never mind smart contract transactions that involve recurring + differing + multiple transactions, then the development is not smart; it is stupid.

The wallet should address concerns about address poisoning (such as avoiding displaying transactions from spam addresses), that’s all. Fraudulent contracts are similar; wallets should strictly block unknown calls. Generally, this is a problem related to interface adaptation rather than a serious issue stemming from the protocol itself.

It’s true that some blockchains apply different exchange fees to ensure security. For example, Polygon requires a minimum priority fee of 25 gwei, Monad requires a base fee of 100 gwei… But the common point is that their token prices are still very low, while with the current ETH price, it’s difficult to determine precisely.

Ethereum upgrades address various issues within the network, and some of them indirectly resolve the problems currently being raised. There are no new EIPs for the current issue, and everything is still on roadmap. Having an unlimited number of upgrades allows the network to be more adaptable, and this adaptability is distributed across many aspects, not just transaction costs.

As I mentioned above, the amount of gas used per transaction only increases, it doesn’t decrease, and the extremely low floor rate currently in place will compensate for this. Otherwise, both developers and users would lose the economic incentive to switch to safer models (e.g., PQ schemes) because they are very computationally expensive. This is an extremely serious security issue that needs to be considered.

In summary, the current low transaction costs are a stepping stone to greater demand in the future, as we will see more participants and a greater demand for throughput.

Have Ethereum actually ever tried setting a minimum floor price and then observe its impact on various factors as a proof of its feasibility, instead of making theoretical assumptions of what might or might not happen?

Like I said, whatever the upcoming EIPs will just be a temporary and insignificant fix. And the number of EIPs needed to fix all future exploits will be near infinite as the cost of crime is nearing zero.

Ethereum does NOT have poor history due to high gas prices. Otherwise, Bitcoin has worse history. The banking industry, credit card industry, and many other financial services have worst histories. Yet, today these industries remain dominant and in control of everything, including denominating ETH in their dollar term.

If having a minimum floor price will make transaction cost increases significantly, then you only need to set a maximum ceiling price to solve that. That should alleviate your fear and worries.

Controlling the supply is not impossible. It only takes willpower and brains.

If address poisoning is not properly resolved, then there won’t be real sustainable growth, excluding artificial ones. Besides, you are talking of a future that has yet to come, as if such future is 100% certain.

If Ethereum has properly implemented minimum bound floor price in the past and yet it still fail to reduce fraud, then I would give your theoretical argument a big benefit of doubt. But we all know there was no such implementation done before, so whatever the argument against it is purely speculative and invalid. If only Ethereum has done such implementation in the past (minimum bound floor price to gas) and still fail to reduce fraud, then I would say, “Yeah, I was wrong and maybe you are right”. But without such evidence, I know I am very rarely wrong.

The current economic model still revolves around the USD, evident in how people value it. This model is unlikely to change anytime soon, so the prospect of an economy based entirely on ETH is very distant. Until then, transaction costs have always been unpredictable.

Raising the price floor to a certain point essentially flattens the impact across the board, which is not a good approach. We expect the model to minimize the incentive for bad actors while being positive (or at least neutral) for small retail users.

This requires analyses of the behavior between different entities, and we’ve drawn a few conclusions:

1. Attackers tend to create more states : EIP-2780 and the upcoming EIP-8037 will patch this vulnerability.

2. The attackers poisoned the address with small transactions : Wallet interfaces should avoid displaying these transactions (through address reputation assessment, avoiding displaying transactions with duplicate behavior, etc.).

Ethereum has a poor history due to high gas prices, and they have worked hard to reduce it to the current comfortable level. The daily trading volume on the mainnet itself creates a lower limit for gas prices; in my subjective observation, the gas price on the mainnet never reaches 1 wei at any given time.

Having a sufficiently large discount margin keeps transaction fees more stable in the future, as the amount of gas used per transaction will continue to increase rather than decrease (state creation, PQ signature schemes, etc.). If a floor gas price is set as proposed, transaction fees will increase significantly, thus depriving users of the opportunity to utilize more secure transaction mechanisms.

While ETH inflation is unfortunate, EIP-1559 has determined that controlling the supply is impossible. However, it creates sustainable growth in the long term as more users join the network, and the revenue generated will partially offset the emissions.

Regarding concerns about network censorship: Ethereum is moving closer to a stateless client, allowing a large number of ordinary users to participate in the network, thus making the network more decentralized.

Thanks to Julian Ma, Anders Elowsson, Benedikt Wagner and Gottfried Herold for feedback and review.

TL;DR

Encrypted frame transactions hide the execution parameters that matter for MEV extraction until after the block’s contents and ordering are fixed.

The builder commits to the full ordered transaction set before any decryption key is revealed. After reveal, it executes that already-committed ordering in the same slot. This makes same-slot encrypted execution possible without splitting the block into a special encrypted section and a plaintext remainder.

The design reuses LUCID’s encryption scheme: users can release keys themselves, or delegate to a threshold committee, or any other entity. It builds on Frame Transaction (EIP-8141), which replaces hardcoded authorization with programmable VERIFY logic (opening a path toward post-quantum-compatible schemes) and enables field-level selective disclosure through a frame-based transaction structure.

High-level idea

One of the key ideas enabling same-slot encrypted execution is order-execute separation: the builder commits to the full ordered transaction set before any decryption key is revealed, then executes that already-committed ordering in the same slot after reveal.

In ePBS (EIP-7732) block-auctions, the builder bid commits to a precomputed execution result. That doesn’t work here, because the final payload depends on which encrypted transactions are revealed and what they decrypt to. For same-slot encrypted execution, the bid has to commit to transaction contents and ordering first, while execution-dependent outputs such as the final payload and BAL (Block-level Access List, EIP-7928) are bound only after reveal.

This is a key difference from next-slot encrypted designs such as LUCID. In LUCID, encrypted transactions commit in slot N, keys are released during slot N, and execution happens in slot N+1 in a dedicated top-of-block lane. By the time the slot N+1 builder constructs the plaintext part of the block, it already knows the decrypted transactions.

The design also builds on Frame Transaction (EIP-8141), which makes it future-compatible in two ways. VERIFY frames replace hardcoded authorization with programmable public validation, opening a path toward post-quantum-compatible schemes. A frame-based transaction structure avoids hardcoding one permanent public/hidden field split: as new frame types are defined, senders can choose which execution parameters to commit publicly and which to hide, without requiring a new transaction type.

Slot N flow

Each encrypted frame transaction has a public VERIFY frame and a hidden encrypted execution phase. The transaction envelope commits to exec_params_binding = H(exec_params), binding the ciphertext to the plaintext the sender intended.

The slot N flow is:

1. The proposer broadcasts the beacon block containing the winning builder bid. That bid commits to the full ordered transaction list before any key is revealed.
2. Key-releasers observe the beacon block and release k_dem, the per-transaction symmetric key, bound to (slot, beacon_block_root, tx_reveal_id).
3. Attesters cache incoming reveals until T_rev_a, then freeze their local view.
4. The builder freezes its reveal view at T_rev_b, executes the committed ordering, and broadcasts the signed post-reveal payload envelope.
5. The PTC votes on that envelope at the T_PTC deadline.
6. Attesters in slot N+1 verify the slot N payload, including BAL and reveal_root against their cached view, then vote on the block.

Notes:

• Reveal timeliness is enforced through an attester view-merge mechanism similar to FOCIL (EIP-7805). A variant could require a reveal to have quorum support from the PTC before the corresponding decryption key may be included, further constraining builder discretion over reveal inclusion. In either case, the mechanism depends on attesters or PTC members having the underlying transaction bytes in time to validate reveals against exec_params_binding.
• The design also assumes that, for a given (slot, beacon_block_root), there is at most one canonical quorum-supported post-reveal payload envelope. Competing valid envelopes for the same slot should be considered as an equivocation condition.

Roles

Senders

Before submission, the sender runs the key-releaser’s off-protocol KEM to produce (k_dem, kem_ciphertext), encrypts exec_params with k_dem to produce dem_ciphertext, sets exec_params_binding = H(exec_params), signs the envelope, and submits the transaction to the mempool.

For self-decryption, the sender generates a fresh k_dem directly and sets kem_ciphertext to empty.

Includers

During slot N-1, includers build and broadcast inclusion lists. For encrypted transactions, they validate the transaction envelope and VERIFY frame while treating the encrypted execution bytes as opaque bytes subject to size bounds.

A skipped encrypted transaction, where k_dem is not revealed, counts as included for IL satisfaction in the narrow sense that the envelope was included, even though the hidden execution did not run.

Proposer

At slot N, t = 0s, the proposer broadcasts the beacon block containing the builder’s bid. The proposer selects a bid based on bid value and whether the bid’s IL bitlist covers all ILs observed before the proposer’s IL freeze deadline.

The bid commits to:

• tx_ordering_root, a Merkle root over the full ordered list of exact transaction contents
• the IL bitlist
• builder identity and bid value

The transaction set and ordering are locked at bid time, before any key is revealed. The builder commits to all content, but not yet to the final execution result. Execution-dependent outputs such as state_root, receipts_root, block_hash, and BAL remain unknown until after T_rev_b, because they depend on the decrypted contents of encrypted transactions. Since BAL is execution-derived, delaying execution binding also delays BAL binding.

Two commitments need to be distinguished. The ordering commitment must bind the exact transaction bytes, including VERIFY frame data, so that block content is fixed at bid time. Reveal matching, however, should use the stable identifier tx_reveal_id rather than the exact byte commitment, because EIP-8141 deliberately excludes VERIFY.frame.data from the canonical signature hash.

Key-releasers

The role is called key-releaser rather than decryptor because its in-protocol job is to release k_dem, not to perform decryption. Depending on the off-protocol KEM used, a key-releaser may need to decrypt kem_ciphertext internally, but that step is invisible to the protocol.

Key-releasers publish off-protocol instructions describing how senders encapsulate k_dem, the KEM construction, and the associated key-derivation parameters.

The protocol itself places no constraints on the KEM construction, but k_dem must be context-bound to the specific transaction and reveal domain, so that releasing a key for one transaction reveals nothing about others. In practice that means binding it to at least tx_reveal_id, exec_params_binding, and the fork context used at reveal.

The protocol verifies H(exec_params) == exec_params_binding after decryption but cannot verify that the KEM achieves key independence. Users therefore have to trust their chosen key-releaser both for correct construction and not to leak plaintext or keys before the intended reveal point.

Upon seeing the beacon block in slot N, the key-releaser broadcasts k_dem alongside (slot, beacon_block_root, tx_reveal_id), signed by key_releaser_address.

Encrypted transactions condition their validity on valid_block_height, so they cannot be reinserted at a different height after a reorg. Reveals are bound to (slot, beacon_block_root), so a reveal for one fork is invalid on another. Note that this doesn’t prevent reinclusion on a competing fork at the same height, so users should still treat a reorged slot as a privacy breach and avoid resubmitting the same exec_params.

Builder

The builder determines the ordering of all transactions, encrypted and plaintext, subject to IL satisfaction. That ordering is committed in the bid via tx_ordering_root before any key is revealed.

At T_rev_b, the builder freezes its view of reveals. For each revealed entry, it decrypts dem_ciphertext using k_dem to recover exec_params. Unrevealed entries are skipped. It then executes the full block in committed order and broadcasts the signed ExecutionPayloadEnvelope containing the payload, BAL, reveal_root, and the k_dem list.

PTC

At T_PTC in slot N, the PTC votes on payload_envelope_root = hash_tree_root(ExecutionPayloadEnvelope) bound to (slot, beacon_block_root). PTC members verify each revealed k_dem against the corresponding k_dem_commitment in the transaction envelope. This lets the PTC vote on reveal availability without attempting to decrypt dem_ciphertext or re-derive exec_params. PTC members sign at most one payload_envelope_root per (slot, beacon_block_root), namely the first valid envelope they observe.

A stricter variant would also let PTC members attest to reveal availability. Under that variant, a decryption key may be included only if the corresponding reveal has quorum support from the PTC.

Attesters

Before the attestation deadline in slot N, attesters verify the slot N-1 execution payload and BAL as part of determining the chain head. Between the attestation deadline and T_rev_a, they cache incoming key reveals and freeze their local view at T_rev_a.

At t = 3s in slot N+1, attesters decrypt each revealed entry using k_dem from the envelope to recover exec_params, re-execute the slot N block, verify the block validity rules below, validate the slot N BAL, confirm blob data availability, and enforce IL satisfaction on the committed transaction envelopes in the slot N payload.

The intended local rule is: an attester who observed a valid k_dem for entry i before T_rev_a will not attest to a payload where reveal_root marks entry i as unrevealed.

PTC quorum is used to converge on a single payload, and the attester view-merge serves as a CR mechanism to ensure builders don’t exclude reveals without losing attestations.

Transaction format

The transaction layout is conceptually:

[VERIFY frame, plaintext] [ENCRYPTED phase, ciphertext]

A concrete version of this design would require an encrypted execution phase or an additional frame mode on top of FrameTx, since EIP-8141 as written does not itself define an ENCRYPTED frame.

An encrypted frame transaction contains exactly one encrypted execution phase. Transactions execute in committed order. For each encrypted transaction, the VERIFY frame runs first, followed by the encrypted execution phase if revealed. Otherwise the encrypted phase is skipped.

Because this builds on EIP-8141, the VERIFY frame inherits its semantics. It executes like STATICCALL, cannot modify state, and must successfully call APPROVE. If it fails to do so, the transaction is considered invalid. VERIFY frame data is also elided from the canonical signature hash and from other frames’ introspection through TXPARAM*.

That means encrypted frame transactions have to be authored so that all pre-reveal validity checks are decidable from public data alone. In particular, the VERIFY frame’s approval outcome must not depend on hidden execution effects of earlier encrypted transactions in the same block, otherwise a builder could commit an ordering that only becomes invalid after reveal.

The envelope-specific fields are:

The k_dem_commitment field binds the envelope to a specific symmetric key before reveal. At reveal time, the released k_dem is checked against this commitment. This serves two purposes: it lets PTC members vote on reveal availability by checking the commitment alone, and it distinguishes key-releaser misbehavior (releasing a wrong key) from decryption failure (correct key that does not decrypt the ciphertext).

The encrypted execution phase contains:

Clients reject any transaction whose encrypted bytes exceed declared or protocol-wide size limits. A global MAX_TOTAL_ENCRYPTED_BYTES_PER_BLOCK caps aggregate ciphertext size per block. This means the design has one execution fee market, but two constrained block resources: gas and encrypted byte capacity.

Ordering and validity

The builder determines the full ordering of encrypted and plaintext transactions. There is no requirement that encrypted transactions be contiguous or top-of-block.

The bid commits to tx_ordering_root = MerkleRoot(L_order) where each L_order[i] commits to the exact encoded transaction contents.

Separately, reveal_root = MerkleRoot(L_reveal) where L_reveal covers only encrypted entries:

• (tx_reveal_id_i, k_dem_i) if revealed by T_rev_b
• (tx_reveal_id_i, empty) otherwise

Validators enforce three obligations:

• Ordering obligation: transaction contents and ordering match tx_ordering_root
• Public-validity obligation: all pre-reveal validity conditions are satisfied from public data alone
• Encrypt obligation: every entry marked as revealed decrypts correctly and satisfies H(exec_params) == exec_params_binding

Validators derive tx_reveal_id from each encrypted transaction in L_order, in order, and check that L_reveal covers exactly those encrypted entries.

Three cases govern reveal outcomes for each encrypted entry:

• No reveal arrives by T_rev_b. The entry is marked as unrevealed in L_reveal and the encrypted execution phase is skipped. The VERIFY frame still runs and gas costs for the public part are still charged.
• Commitment mismatch: the released k_dem does not match k_dem_commitment. The PTC rejects the reveal as invalid. The entry is treated as unrevealed. This case indicates key-releaser misbehavior: the released key does not correspond to what the sender committed.
• Decryption failure: the released k_dem matches k_dem_commitment but does not produce valid plaintext satisfying H(exec_params) == exec_params_binding. The builder can prove non-decryptability by exhibiting the committed key against the ciphertext. The entry is skipped rather than making the entire payload invalid, since the builder faithfully applied the key the sender bound.

Outside these skip paths, if an entry is marked as revealed in L_reveal but the supplied k_dem does not yield exec_params satisfying the binding and none of the above skip conditions apply, the payload envelope is invalid.

Under the stricter PTC-certified reveal variant, reveal inclusion would satisfy one more condition: a decryption key may be included only if the corresponding reveal has quorum support from the PTC.

Builder constraints

The builder can still include conditional strategies and state-sensitive transactions. What changes is the timing: it has to choose the ordering without seeing the hidden execution parameters of encrypted transactions.

That also means the builder takes execution risk. If an earlier encrypted transaction changes state in a way that causes a later committed plaintext transaction to revert, that later transaction still consumes gas. The sender pays the gas. The builder loses the opportunity value of the wasted block space.

In the base design, the builder still has some discretion over reveals received near the cutoff. It can wait to see which keys propagate and condition inclusion on that. A stricter variant requiring quorum PTC attestations is described in the PTC section; it reduces builder discretion but tightens the timing budget.

Encryption

The construction is a standard KEM-DEM split.

• The KEM lives entirely in kem_ciphertext and can change without consensus changes.
• The DEM is consensus-critical. At reveal time, every node decrypts dem_ciphertext locally using k_dem, reconstructs exec_params, and checks it against exec_params_binding.

A concrete version of the design would also have to fix the hash used in H(exec_params) and the nonce or IV derivation for each dem_id. This post leaves those details abstract, but they cannot be left implicit in a consensus implementation.

The AEAD aad is (chain_id, tx_reveal_id, sender, tx_nonce, exec_params_binding, dem_id) which binds the ciphertext to the intended transaction and prevents transplant attacks.

Encrypted payload

exec_params is RLP(blinding_nonce, target, calldata, priority_fee?, padding?)

The optional tail fields must be encoded canonically, in that order and without gaps.

The blinding nonce ensures that identical targets and calldata still produce unrelated commitments. The target contract lives inside exec_params, so it remains hidden until reveal. The trailing padding field, when present, contains padding_length zero bytes that are stripped before EVM execution. Gas accounting refunds the calldata cost of padding bytes, so the protocol partially subsidizes length hiding. This is well-defined for stream ciphers such as ChaCha20 where one plaintext byte maps to one ciphertext byte; block cipher modes with their own padding semantics would need separate treatment under a different dem_id.

The sender chooses which fields stay public and which are hidden inside exec_params.

Hidden priority fee

The public envelope carries max_fee_per_gas, and APPROVE authorizes gas_limit * max_fee_per_gas, just as in the EIP-1559 fee model adapted to FrameTx. The sender may place the actual priority_fee inside exec_params instead of publishing max_priority_fee_per_gas in the envelope. Before reveal, the builder sees the fee cap but not the exact tip.

After reveal, the protocol checks that priority_fee <= max_fee_per_gas - base_fee and charges gas_used * (base_fee + priority_fee).

The builder receives the realized priority fee. Any unused authorized amount is refunded. If the encrypted frame is skipped because no key arrived by T_rev_b, hidden priority_fee is never charged, since exec_params was never decrypted. A sender that prefers more predictable inclusion can still publish a visible priority fee in the public envelope.

Note that this fee treatment is part of the encrypted transaction design. It is not something current FrameTx semantics already provide automatically.

Fees, skips, and the free option

If k_dem does not arrive before T_rev_b, the transaction is skipped. The VERIFY frame still runs, the nonce is still consumed, and the sender still pays intrinsic costs, calldata costs, and VERIFY gas. The hidden execution phase does not run.

Because APPROVE authorizes the full gas budget up front and refunds unused gas afterward, skip behavior is clean: the sender is charged for the public part that actually ran, and the encrypted execution gas is refunded. Hidden priority_fee is not charged on skip because it is only defined after successful decryption.

The free option remains. A self-decrypting sender can observe the committed ordering and choose whether to reveal. If the ordering is favorable, it reveals and executes. If the ordering is unfavorable, it withholds and gets a skip.

Candidate mitigations include additional fees on encrypted transactions (fixed or dynamic, such as ToB fees in LUCID), or penalties for repeated skips.

Privacy properties

Encrypted frame transactions only provide pre-trade privacy.

Before reveal, the builder sees public envelope data, the VERIFY frame, the gas limit, the fee cap, the key-releaser choice, and dem_ciphertext_len. It does not see the target contract, calldata, amounts, routes, or counterparties. When padding is used, the actual exec_params length is ambiguous within the declared ciphertext bound, further reducing information leakage from message size.

This does not provide sender anonymity at the network layer, and network-level metadata can still reveal information about who is sending the transaction or which system it came from.

After reveal, any node can recover exec_params for revealed entries from the published k_dem values. At that point the transaction has already executed, so the information can no longer be used to frontrun or sandwich it. But it is not permanently hidden.

The privacy guarantees also depend on key-releaser trust. If the key-releaser leaks plaintext or keys to a builder before the public reveal, the key blind-ordering property is lost.

Failure modes

• A non-cooperating key-releaser can cause a skip.
• A colluding key-releaser can privately reveal to the builder after T_rev_a but before T_rev_b, causing execution that attesters did not observe early enough to protect through view-merge.
• A builder can withhold the post-reveal payload envelope after keys have propagated, causing a missed slot that is also a privacy breach.
• A builder can equivocate over reveal_root, sending different reveal sets to different PTC members. The transaction set and ordering remain fixed by tx_ordering_root, but the reveal set still changes execution and can split views. EIP-7732 already notes payload and PTC equivocations as part of the split-view risk surface in enshrined PBS.

zkEVM path

The design extends naturally to a zkEVM setting. The reveal mechanism stays the same; what changes is that DEM decryption becomes a proving obligation rather than a direct execution-layer check. Note that a zkEVM upgrade does not automatically make exec_params permanently hidden: the proving system must be zero knowledge (not just succinct), and k_dem must remain a private witness. It also tightens the timing budget, as the number of encrypted transactions per block becomes jointly constrained by proof generation time and the per-transaction circuit cost of DEM verification.

Relation to LUCID

Encrypted frame transactions and LUCID share the same basic key-releaser model and the same KEM-DEM intuition. The difference is where the builder’s commitment happens and what block structure that implies.

LUCID commits encrypted transactions in slot N, releases keys during slot N, and executes them in a dedicated top-of-block lane in slot N+1. That leaves the next-slot builder with decrypted knowledge before placing the plaintext remainder of the block, and it introduces a separate ToB_fee_per_gas ordering rule for that lane.

Encrypted frame transactions commit transaction contents and order before reveal, execute in the same slot, keep encrypted and plaintext flow in one interleaved ordering, and place encrypted execution on the same substrate as programmable validation and field-level hiding.

Open questions

Reveal timing and attester view-merge. The reveal window needs careful calibration: long enough for keys to propagate broadly, short enough to leave time for execution and payload publication. The attester view-merge rule that enforces this also needs a full specification, covering what counts as a valid observed reveal, what data attesters must already hold, and how to handle clock jitter and uneven propagation.

ePBS commitment variant. This design requires a different bid structure from EIP-7732. The builder commits to transaction contents and ordering before execution, whereas EIP-7732 bids on a precommitted block_hash. The exact changes to the bid object, PTC vote target, fork-choice rules, and post-reveal envelope canonicalization all need separate specification.

Free-option problem. A self-decrypting sender can observe the committed ordering and choose whether to reveal, effectively holding a free option on execution. The design needs a principled mitigation that does not reintroduce significant complexity or a second fee market.

My question from Lattice-based signatures aggregation post had the consensus setting in mind, where we don’t need to keep the public key around (as the validator’s public key can be looked up by its index). In that case, assuming the proof size stays more or less constant at about ~70 KB, the break even point should be around 100 signatures.

For reference, I am adding below a similar comparison you did but with the consensus setting in mind. I forked your code here for the estimation, adapted the formulas and considered the same three cases.

Case 1: Key Recovery, No Aggregation

This case only seems interesting on the EL (where public keys are not stored) as on the CL public keys are already known. Included for comparison:

\text{Total} = N \cdot (\tilde{S} + R)

Case 2: Standard Falcon, No Aggregation

Similar to your case 2, but includes the validator indexes instead of the public key p:

\text{Total} = N \cdot (S + R + \text{idx})

Case 3: Standard Falcon, With Aggregation

Similar to your case 3, but includes the validator indexes instead of the public key p:

\text{Total} = a_N + N \cdot (R + \text{idx})

As expected, the break even shifts to the left now and it is indeed around 100 signatures (instead of 200 as in EL).

Core Properties

1. Greater decentralization than Bitcoin
   In Bitcoin, transactions are not fully autonomous, they require permission from miners to be processed.AOB removes this dependency entirely. Payments are processed without requiring miner cooperation or awareness, achieving a stronger form of decentralization where no privileged party has structural access to transaction content.
2. Cryptographic security against double-spend — no economic assumptions required
   Bitcoin’s double-spend resistance relies on the economic rationality of miners (i.e., that attacking the network is less profitable than honest mining). This is an wishful economic guarantee, not a cryptographic one. AOB’s double-spend protection is enforced at the cryptographic level, holding unconditionally regardless of miner incentives or hash rate distribution.
3. Unbounded performance capacity
   AOB’s architecture does not impose a global throughput ceiling. Capacity scales without sacrificing the security or decentralization properties above.
4. Hash-rate-anchored stablecoin under high decentralization
   AOB enables a stablecoin whose value is anchored to computational work (hash rate), issued and maintained under fully decentralized conditions without relying on collateral, governance tokens, or trusted oracles.

Why Now

We believe AOB addresses fundamental limitations that have constrained blockchain adoption — not at the application layer, but at the protocol layer. We are actively seeking research collaborators and commercial partners to develop and deploy this architecture.
More details and resources below. We welcome questions and critical feedback.

Published paper: Achieving Greater Decentralization with Atomic Ownership Blockchains
Unpublished preprint: Migrating Bitcoin to AOB for Enhanced Security
Grokipedia entry
Wikipedia draft

Two interactive demos:

• Basic blockchain operations
• Banknote definition and simulated network protocol video

Testnet (supports banknote-style payment and speedy-channel payment across devices on real netwrok) video

manel1874:

break-even point in terms of the number of signatures

For that, see our recent post Revisiting Falcon signature aggregation for PQ mempools

tl;dr: This post compares the size of signatures and aggregates for transactions using Falcon signatures (as defined in the Falcon specification), under different assumptions about key recovery and aggregation.

Introduction

Ethereum’s post-quantum (PQ) work has recently shifted from long-term research to more applied research and engineering efforts. As PQ transaction signatures move closer to deployment, one constraint has become evident: post-quantum signatures are large, and their cost is felt most acutely in network bandwidth (e.g., mempool propagation) and node storage requirements.

The Falcon signature scheme remains a compelling reference due to its selection for standardization by NIST and its relatively compact signatures, compared to other post-quantum alternatives.

However, even for Falcon, its signature sizes (666 Byte) impose very different mempool and storage costs than ECDSA (< 100 Byte) when many transactions coexist. This has motivated renewed interest in aggregation, particularly at the mempool or block-construction level, as a hypothesis worth examining under realistic assumptions.

In this post, a quantitative analysis of Falcon signature aggregation is presented using the standard Falcon scheme, comparing the total size of signatures and aggregates under different assumptions about public key recovery and aggregation, with the goal of clarifying the trade-offs relevant to post-quantum Ethereum transactions.

The central question examined here is when, and under which conditions, aggregation of post-quantum signatures in the mempool meaningfully reduces the total size of transaction data.

Prior Work

While pre-quantum signatures often have the algebraic structure to be aggregated natively (e.g., BLS signatures), aggregation for post-quantum schemes is often more complex.

Aggregation of Falcon and related lattice-based signatures has been explored in prior cryptographic and Ethereum-focused work, including a paper that studies aggregation using the LaBRADOR proof system and achieves somewhat compact aggregated signatures at the cost of non-trivial aggregation and verification overheads.

Related discussion in the Ethereum research community examines lattice-based signature aggregation in blockchain settings, highlighting practical trade-offs around proof size, verification time, and implementability in an ethresearch post.

As a disclaimer, we do not consider SPHINCS+ or Dilithium signatures here (which are larger than Falcon signatures). This document focuses exclusively on Falcon and its aggregation properties under Ethereum-relevant assumptions.

For broader context on post-quantum Ethereum transaction signatures, including prior discussion of Falcon and account abstraction, see this earlier three-part series: Part 1, Part 2, and Part 3.

Why Falcon?

Falcon has been selected by NIST for standardization. It has the smallest signatures among those selected schemes, and aggregation has also been studied in the literature.

As the figure above highlights, Falcon is especially attractive in this discussion because, among the selected NIST PQ signature schemes, it combines relatively small signature size with comparatively favorable aggregation properties. In particular, Falcon is one of the few practical candidates for which aggregation has been explored in a way that is plausibly relevant to Ethereum-style transaction pipelines.

We emphasize that this post is not claiming that Ethereum must use Falcon. It just studies what happens if we were to use Falcon.

Quick Recap of Falcon

Roughly, the verification equation for Falcon has the form H(m,r) = s_1 + s_2 h, and additionally a norm constraint on the vector (s_1,s_2) is checked. Here h is the public key, H is a hash function. The signature can have one of two forms:

• Standard Version. It is (s_2,r), where r is a random salt. The value s_1 is recomputed during verification as s_1 = H(m,r) - s_2 h.
• Version for Key Recovery Mode. The signature is (s_1,s_2,r). In this case, one can recompute the public key (and its hash) from the signature and the message, see Section 3.12 of the Falcon specification.

We do not go into detail on how these signatures are generated or in which domains these objects live. Both is not relevant for our discussion.

Throughout, we make the assumption that for aggregation, the hash function is not changed (e.g., we don’t replace it with Poseidon2). Further, we assume that the salts are not aggregated. That is, in the aggregated signature we have an aggregated version of all s_2's (or s_1,s_2's) and all individual salts. This is reasonable to assume (see discussions here) and makes the aggregation using succinct proofs more efficient, as the statement to be proven is purely algebraic, and no hash is involved.

We use the following notation throughout. When the public key is known, a Falcon signature has size S+R, where R denotes the size of the salt component and S denotes the size of s_2 above. When the public key is not known and only its hash is available (i.e., the address), the signature size increases to \tilde{S} + R for \tilde{S} > S, following the key-recovery mechanism described above.

Addresses are represented as a hash of the public key and have size h, while the full public key has size p. We denote by N the number of transactions considered.

We denote by a_N the aggregated signature size, which depends on the number of aggregated signatures N and includes the salts. Concrete values for a_N can be computed using a script provided alongside prior work on Falcon aggregation (paper). For our analysis, we used a forked version of the repository, which also contains the code used to generate the plots in this document.

Variants of how to use Falcon

We now compare the total storage costs, considering different variants of how Falcon could be used. Note while we talk about storage, the same applies to bandwidth.

Case 1: With Key Recovery, No Aggregation

In this case, we use the Falcon version for key recovery mode (see above), meaning that from a signature one can rederive the public key and consequently its hash (the address). Then, for each transaction, we need to store the signature including the nonce and the address of the sender. Namely, each transaction stores:

• Salt: R
• Signature (excluding salt): \tilde{S}
• Total N(\tilde{S}+R)

The sender address is not stored explicitly: it is recovered from the signature during verification, analogously to how Ethereum currently recovers the sender from an ECDSA signature.

Case 2: Without Key Recovery, No Aggregation

If we use the standard Falcon version instead (without key recovery, see above), then we save on signature size, but additionally need to explicitly store the public keys. We do not need to store addresses, as they can be derived from the public keys. Concretely, each transaction stores:

• Public key: p
• Salt: R
• Signature (excluding salt): S
• Total N(p+S+R)

Case 3: Without Key Recovery, With Aggregation

Now, assume we aggregate signatures, and an aggregate for N signatures has size a_N. Then, we no longer need to store the individual signatures. Namely, each transaction stores:

• Public key: p
• Salt: R

In addition, we have one aggregated signature of size a_N.

• Total N(p+R) + a_N

Note 1. When computing a_N in our scripts below, we call the scripts from Falcon signature aggregation with LaBRADOR in a black-box way. Of course, not only LaBRADOR can be used for aggregation, but any SNARK. We note that hash-based SNARKs (which seem to be favored in Ethereum these days) are larger than LaBRADOR, and so using LaBRADOR is a very optimistic estimate for size of aggregated signatures.

Note 2. We do not consider the case of key recovery with aggregation, as this is not covered by the work on Falcon signature aggregation. This is primarly because the statement to be proven here would involve hashes and would have less algebraic structure, which means it is less efficient to prove than the statement that is considered for the standard variant.

Results

We computed (code here) the total size (in KiB) for each of the three cases as a function of the number of transactions N.

Case 2 is the most expensive across the entire range. Each transaction carries a full public key (p) and a standard signature (S + R), so total size grows steeply.

Case 1 is cheaper because key recovery eliminates the need to store either the full public key or the address sunce both are recoverable from the signature itself.

Case 3 replaces N individual signatures with a single aggregated signature of size a_N. But each transaction still needs a full public key and an individual salt, so the fixed proof overhead makes Case 3 more expensive than Case 1 for small N (~50 KiB). As N grows, the lower marginal cost dominates, and Case 3 crosses below Case 1 around N \approx 200 (dashed line in the figure).

Even past this crossover, the savings from aggregation are modest. At today’s typical Ethereum block sizes (~250 transactions), Case 3 saves only slightly over Case 1. The gap widens slowly and aggregation only pays off substantially for signature counts well beyond current per-block levels.

Conclusion

Our results suggest that Case 1 (Key Recovery, No Aggregation) could be a practical sweet spot for Falcon-based PQ transactions on Ethereum. It results in the lowest storage cost at current block sizes without requiring aggregation infrastructure, and its simplicity makes it the most straightforward path to deployment.

Aggregation (Case 3) does eventually win on storage, but only for large N, and the savings remain modest near today’s typical block sizes.

Beyond proof sizes, aggregation introduces substantial system complexity. Someone must perform the aggregation and producing proofs over hundreds of signatures within block times can be computationally expensive. Realizing bandwidth savings at the mempool level also likely requires architectures like recursive STARK-based mempools, where every node acts as a prover and proofs are folded incrementally during gossip.

That said, aggregation techniques are improving. Schemes such as Hatchi may reduce proof sizes in the future, and recent work on faster aggregation verification reduces the computational cost of checking aggregated proofs. If these improvements materialize, the trade-offs may shift.

Finally, we note that this analysis focuses on Falcon as specified today. Future modifications to the scheme itself (e.g., derandomization) could change the per-signature costs and alter the relative comparison. We leave exploration of such modifications to future work.

I want to specifically touch on your point regarding the STARKs / FRI instantiation being the ideal path for a fully transparent, plausibly PQ-secure authorization layer. Historically, the pushback against using STARKs for client-side or decentralized AA proving has been the severe hardware requirements and proving latency at scale.

I recently open-sourced the Qingming ZKP Engine, which directly attacks this FRI proving bottleneck using consumer-grade AMD GPUs (ROCm/HIP), and I believe it could make the STARK instantiation of ZK-ACE highly practical today without needing enterprise clusters.

By taking over the unsafe pointer lifecycle in Rust to bypass standard memory transfers and mapping arrays directly to the AMD 96MB Infinity Cache (Zero-Copy), alongside mathematically reducing the Fermat modular inversions in the fold loop into O(1) scalar multiplications (Zero-Inversions), we achieved the following on a single $999 RX 7900 XTX:

• NTT (2242^{24}224 scale): 18.94 ms

• Merkle Tree (L0): 763.3 ms

• FRI Prove (End-to-End, 16.7M leaves): 2.56 s

If your ZK-ACE identity commitments and authorization bindings were instantiated over a Goldilocks field STARK, the proving time on consumer hardware would be virtually instantaneous with this engine.

Would love for you or anyone in the AA/PQC research space to check out the host-side benchmark logic. This kind of hardware-layer dimensionality reduction might perfectly complement the architectural dimensionality reduction you just presented.

GitHub: qingming-zkp

TL;DR: Current PQC migration plans assume we must verify post-quantum signatures — either on-chain (kilobytes per tx) or inside ZK circuits (millions of constraints). We present an alternative: prove authorization semantics directly in ZK, without any signature object. Result: 4,024 R1CS constraints, 128-byte proofs, 52 ms proving time. The construction is proof-system agnostic (Groth16, PLONK, STARKs all work) and deployable today as an AA validator module — no protocol changes required.

Motivation: The PQC data wall

The community has been actively exploring PQC migration paths (13) and the core tension is well-known:

That’s a 30-60x increase in authorization data per transaction. In rollup architectures where calldata/blob space is explicitly priced, this is a first-order scalability problem.

The “obvious” solution and why it’s expensive

The natural response is: verify PQ signatures inside ZK circuits, post only the succinct proof on-chain.

The problem: lattice-based signature verification requires NTTs over degree-256 polynomial rings in \mathbb{Z}_q (q = 2^{23} - 2^{13} + 1), emulated over a ~254-bit proof-system field. Structural lower bounds:

Even with optimized gadgets, we’re looking at millions of constraints just to prove “this signature is valid.”

Key observation: authorization ≠ signatures

Here’s the thing: at the consensus layer, blockchains don’t actually require verification of a specific signature object. What consensus requires is assurance that a transaction was authorized by the correct entity.

Signatures are an implementation artifact for expressing authorization — not authorization itself. We’ve been conflating the two.

ZK-ACE: identity-centric authorization

We present ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities), which takes this observation to its logical conclusion:

Don’t verify signatures in ZK. Don’t compress signatures. Eliminate signature objects from the authorization path entirely.

Instead, the chain stores a compact identity commitment (32 bytes):

$$ID_{com} = H(REV | salt | domain)$$

where REV is a 256-bit identity root derived from a deterministic identity derivation primitive (DIDP). Each transaction carries a ZK proof attesting:

1. (C1) Commitment consistency: Prover knows a preimage of ID_{com}
2. (C2) Derivation correctness: A target-binding hash is consistent with deterministic key derivation under the identity root
3. (C3) Authorization binding: The identity root has authorized this specific TxHash
4. (C4) Anti-replay: Nonce commitment or nullifier is correctly derived
5. (C5) Domain separation: All bindings use the declared chain/domain tag

The entire circuit is 5 Poseidon hash invocations + equality constraints. No lattice arithmetic. No signature verification logic. No non-native field emulation.

Benchmarks (reference implementation)

Implementation: arkworks + Groth16 over BN254, Poseidon (t=3, \alpha=17, 8 full + 57 partial rounds).

Circuit size:

Both replay modes (nonce-registry and nullifier-set) produce identical constraint counts.

Performance (single-threaded, Apple M3 Pro, Criterion.rs, 100 samples):

Proof size:

Compression vs. PQ signatures:

Constraint comparison (the core result):

That’s a ~500x constraint reduction — not from optimizing signature verification, but from not doing it at all.

Deployment: AA validator module

ZK-ACE is designed as an ERC-4337 validator module. In an AA wallet:

• The account validation logic invokes ZK-ACE verification instead of checking a classical or PQ signature
• Proof generation happens client-side (~52 ms)
• The bundler transports proof + public inputs (untrusted, learns nothing)
• On-chain verification costs ~604 μs per proof

This means no protocol-level changes are required. ZK-ACE can be deployed on existing infrastructure.

Proof-system agnostic by design

An important design property: ZK-ACE is a protocol-level authorization model, not a proof-system-specific construction. The five constraints (C1)–(C5) are stated over abstract hash evaluations and equality checks. They can be instantiated with:

The benchmarks above use Groth16 because it gives the tightest numbers, but the protocol doesn’t depend on it. In particular, a STARK instantiation would make the entire authorization pipeline plausibly post-quantum at the proof layer as well — no trusted setup, no pairing assumptions, hash-based soundness only. The identity commitments are proof-system-agnostic (they’re just hash outputs), so migrating from one proof system to another does not require identity rotation or re-registration.

The security reductions in the paper are stated generically in terms of knowledge-soundness advantage \text{Adv}^{ks} and are compatible with any backend satisfying completeness, knowledge soundness, zero-knowledge, and public-input binding.

Assumed primitive: DIDP

ZK-ACE assumes a Deterministic Identity Derivation Primitive (DIDP) as a black box — any framework providing:

• Deterministic key derivation from a high-entropy root
• Context isolation across derivation paths
• Identity-root recovery hardness

This is not tied to any specific construction. A simple HKDF(root, context) satisfies the interface. We provide ACE-GF as an instantiation; any KDF with domain separation works.

Security

Four game-based security definitions with reduction-based proofs under standard assumptions:

• Authorization soundness → reduces to knowledge soundness + collision resistance + DIDP recovery hardness
• Replay resistance → reduces to authorization soundness + verifier enforcement
• Substitution resistance → reduces to public-input binding of the proof system
• Cross-domain separation → reduces to collision resistance + public-input binding

Full proofs in the paper.

What this is NOT

To be explicit:

• Not ZK-verification of PQ signatures (we don’t verify any signature inside the circuit)
• Not signature compression (we eliminate signatures, not shrink them)
• Not a new signature scheme
• Not dependent on any specific identity framework

It’s a change in what we prove: from “this signature is valid” to “this identity authorized this transaction.”

Relation to existing discussions

This work connects to the ongoing PQC migration discourse:

• So you wanna Post-Quantum Ethereum transaction signature identified the AA path for PQC
• The road to Post-Quantum Ethereum transaction is paved with AA demonstrated Falcon verification via AA
• Poqeth benchmarked PQ signature verification on-chain

These approaches all preserve the signature-centric model. ZK-ACE asks: what if we don’t?

Paper: ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems

Reference implementation: github.com/ya-xyz/zk-ace

Huge thanks to Ben, Francesco, Joachim, Justin, Mikhail, Roberto, Thomas, Vitalik, and Yann for their feedback.

We are working on a proposal for the next consensus protocol for Ethereum. A central piece of the new design is a two-layer architecture: a fast available chain — the heartbeat — produced by a small randomly-sampled committee, and a separate finality mechanism that trails behind, finalizing blocks the heartbeat has already produced — crucially, with the two layers fully decoupled, unlike the current Gasper design where LMD-GHOST and Casper FFG interact in ways that have proven difficult to reason about. Vitalik outlined this direction in a recent post.

This post focuses on the first layer — the heartbeat — and on a property we believe should be a strict requirement for it: dynamic availability.

Why dynamic availability matters

Ethereum has never gone offline^[1]. Through the Merge, through client bugs, through cloud provider outages — the chain has kept producing blocks. This is not an accident. It is a consequence of how the protocol handles fluctuating participation, and it is a property the next consensus design should strengthen, not compromise.

Dynamic availability is the formalization of this property: a protocol is dynamically available if it remains safe and live as long as a majority of the currently awake^[2] stake is honest. Not a majority of all registered validators — a majority of the awake ones. The chain keeps going regardless of how many validators are asleep, as long as the ones that are awake are mostly honest.

Why should this be a strict requirement?

Resilience and self-recovery. When validators go offline — due to a consensus client bug, a cloud provider outage, or a regional network disruption — a dynamically available protocol continues producing blocks. In the common case, recovery is straightforward: the affected operators fix the bug, the data center comes back online, and participation returns to normal. The chain never stopped, so there is nothing to restart. If participation does not recover — if a large fraction of validators remains offline indefinitely — Ethereum has a fallback: the inactivity leak, a mechanism that gradually penalizes inactive validators, reducing their effective stake until the finality gadget can resume operation, without out-of-band coordination. There is a class of chains — typically optimized for throughput — that implicitly rely on a responsive social layer for recovery from extreme events: the chain halts, a small group of stakeholders gets on a call to coordinate, and validators restart in unison. When decentralization is not the primary constraint, this approach is efficient. It is not compatible with Ethereum’s design philosophy.

These are not hypothetical scenarios. In May 2023, bugs in the Prysm and Teku consensus clients (together running over 50% of validators) caused Ethereum’s first mainnet inactivity leak. In November 2020, a consensus bug in Geth caused a small portion of the network to split off, disrupting services that relied on affected nodes, including Infura, MetaMask, MakerDAO, and Uniswap. When a majority client forks, dynamic availability ensures both forks continue to operate. Individual operators can identify and switch to the correct fork well before network-wide convergence.

Censorship resistance. If an adversary with majority stake begins censoring, the honest minority needs to mount a response. A dynamically available chain allows them to begin building an alternative fork, even with a small number of validators, and grow it as others recognize the situation and join.

Application-layer continuity. DeFi protocols, rollups, and bridges all depend on a functioning L1. A halted base layer freezes composable DeFi simultaneously (liquidations cannot execute, oracle prices become stale, positions accumulate unmanageable risk), stalls rollup operations (batch posting, fraud proofs, validity proofs), and forces bridges into ambiguous states. This is not theoretical: during Solana’s February 2024 halt, the chain stopped producing blocks for five hours — DeFi protocols were completely inoperable, positions could not be adjusted, and risk accumulated with no mechanism to manage it. By contrast, during Ethereum’s May 2023 finality disruption, blocks kept being produced and transactions continued to process normally — the application layer was largely unaffected because the available chain never stopped. Final settlement still requires the finality layer, but operational continuity depends on the heartbeat continuing to produce blocks.

There is a unifying principle behind these points:

it’s better to give people as much information about the future state of the chain as possible.

This is the same principle that makes shorter finality times preferable to longer ones, and finality preferable to purely probabilistic confirmation. When finality is interrupted, a dynamically available chain provides partial but useful information about the likely future state. A halted chain provides none.

The world BFT assumes is not the world Ethereum lives in

Most consensus protocols you’ve heard of — PBFT, Tendermint, HotStuff — assume a fixed set of validators that are reliably awake. Under that model, safety is provable, but liveness typically fails if too many validators go offline (often around \ge \frac{1}{3}). That tradeoff is unavoidable.

Ethereum has thousands of independently operated nodes, and even well-incentivized operators go offline: upgrades, cloud and ISP incidents, hardware failures, misconfigurations, ordinary human error. Designing a protocol that needs “near-perfect participation” for liveness is designing for a world that doesn’t exist.

The sleepy model takes (some aspects of) the real world seriously: honest validators can be awake or asleep, and that can change over time. In this setting, a protocol is dynamically available if it remains safe and live as long as a majority of the currently awake stake is honest. Sleeping validators are not counted against any fault budget — neither Byzantine nor crash. This matters in practice: real-world outages have pushed participation down to around 33% (Figure 10), a level that would exceed the fault tolerance of any protocol that accounts for offline validators as faulty.

Put differently:

Ethereum should keep producing a coherent chain as long as most of the stake that is actually awake is honest.

You cannot avoid the two-layer split

One might ask: why not build a single protocol that is both dynamically available and provides finality? Put differently: why do we need a trailing finality mechanism on top? The answer is that this is impossible.

The availability-finality dilemma — a blockchain-specific form of the CAP theorem — proves that no single protocol can guarantee both:

• Liveness under dynamic participation: the chain continues to grow even as the set of awake validators fluctuates.
• Safety under network partitions: once a transaction is confirmed, it cannot be reverted even if the network temporarily splits.

In other terms, dynamically available protocols must assume synchrony.

BFT protocols achieve partition safety but halt when participation drops. Longest-chain protocols, e.g., Bitcoin’s consensus protocol, achieve dynamic availability but offer only probabilistic confirmation — and must assume synchrony to do so. No protocol can do both at once. This is a fundamental limitation.

The architectural implication is direct: any protocol that aims to never halt and to provide irreversible finality must have a dynamically available component. The heartbeat layer is not an optimization — it is a structural necessity imposed by the impossibility result.

From property to protocol

Saying the heartbeat must be dynamically available still leaves open what protocol to use. The requirement rules out off-the-shelf BFT (which halts under dynamic participation), but it also rules out naive adaptations of LMD-GHOST. While Gasper functions well in practice under varying participation levels, LMD-GHOST cannot be proven dynamically available: Neu, Tas, and Tse demonstrated adversarial strategies that violate safety and liveness of LMD-GHOST in the synchronous model, and subsequent patches have not closed the gap. A protocol is dynamically available by definition only if it satisfies both safety and liveness in the sleepy model — the existence of these attacks means LMD-GHOST does not meet this bar.

Goldfish was designed to close this gap. It is a propose-and-vote protocol — structurally closer to BFT than to longest chain — that achieves dynamic availability with:

• Constant expected confirmation latency: the time to confirm does not grow with the target security level. This is the key separation from longest-chain protocols.
• Reorg resilience: blocks proposed by honest proposers are guaranteed to remain in the canonical chain. This property, absent in LMD-GHOST, eliminates a class of attacks that have plagued Ethereum’s current fork-choice rule.
• Subsampling: the protocol can run with a randomly selected committee of ~256 validators per slot, keeping per-slot communication O(1) relative to the total validator set.
• Composability: Goldfish can serve as the available-chain component in an ebb-and-flow protocol, pairing with a finality gadget.

What this buys in practice: slot times

The current Ethereum slot structure requires aggregating ~30,000 attestations per slot. If Ethereum moves to single-slot epochs, this number rises by default to the full active validator set — currently around one million. Any future reduction of the 32 ETH deposit minimum would push it even higher. Because these numbers far exceed what a single subnet can propagate, attestations pass through multiple aggregation rounds before reaching the global network. As Vitalik observes:

\text{aggregation time} \approx \log_C(\text{validator count})

where C is the per-subnet capacity (hundreds to low thousands of signatures), and the aggregation time is measured in network rounds, each taking roughly \Delta^[3]. With the full validator set on the critical path, each slot requires between 3\Delta and 4\Delta.

A dynamically available protocol with ~256 subsampled validators fits within a single subnet broadcast. No aggregation rounds are needed. This removes the aggregation overhead entirely, leaving only the time for block propagation and committee voting on the critical path.^[4]

Finality still involves the full validator set, but it proceeds in parallel with the dynamically available component, off the critical path. The two layers do not compete for the same latency budget.

A near-term benefit: post-quantum readiness and post-quantum heartbeat

The transition to post-quantum cryptography is an ongoing concern for Ethereum. A major obstacle is signature aggregation: Ethereum currently relies on BLS signatures, which can be efficiently and easily aggregated, but no post-quantum signature scheme offers comparable aggregation properties at practical sizes.

A dynamically available heartbeat with a small subsampled committee sidesteps this problem. With ~256 validators per slot, signatures do not need to be aggregated at all — they can be naively concatenated. Post-quantum signature sizes vary by scheme; with a scheme at ~3 KB per signature, 256 signatures amount to ~768 KB. leanMultisig — a minimal zkVM targeting XMSS signature aggregation and recursion — can compress this further: early benchmarks show aggregation of over a thousand signatures with proof sizes in the 300–500 KB range, approaching the cost of naive concatenation. These results currently rely on a conjectured security assumption; provably secure parameters are in progress.

This means a post-quantum heartbeat — a dynamically available protocol running with post-quantum signatures — could be deployed significantly sooner than a full post-quantum decoupled protocol, which would additionally require post-quantum signature aggregation for the finality layer’s full validator set. The heartbeat-finality decoupling makes this incremental deployment path possible: upgrade the heartbeat to post-quantum first, address finality-layer signatures separately as post-quantum aggregation techniques mature.

Without this decoupling, post-quantum migration becomes an all-or-nothing problem: you cannot upgrade Ethereum’s signatures until you have a PQ aggregation scheme that scales to the full validator set — an active area of research. The two-layer architecture turns this into two independent problems, one of which (~256 concatenated signatures) is solvable with existing schemes today.

What we are building

The target architecture:

1. Heartbeat: a dynamically available protocol (Goldfish/RLMD-GHOST family) with ~256 randomly sampled validators per slot — small enough to operate with concatenated post-quantum signatures, enabling a post-quantum heartbeat as an early deployment milestone.
2. Trailing finality gadget: a separate mechanism using the full active validator set, finalizing the heartbeat’s chain head.

The two layers are fully decoupled. This yields fast slots, flexibility in choosing the finality mechanism, a clean separation during inactivity leaks, and reduced complexity relative to Gasper.

A detailed treatment of the finality layer will follow in a subsequent post.

1. We refer to block production, not finality. Finality has been temporarily disrupted — most notably during the May 2023 consensus clients incident — but the chain never stopped producing blocks. The daily block proposal chart shows that even during this incident, over 90% of slots received a proposed block. This was a joint consequence of client diversity (Lighthouse, Nimbus, and Lodestar were unaffected by the Prysm/Teku bug) and dynamic availability (the protocol kept producing blocks with the validators that remained awake, rather than halting because total participation fell below an absolute threshold). ↩︎

2. We use “awake” in the sense of the sleepy model: a validator is awake if it is actively participating in the protocol, and asleep otherwise. This is a protocol-level notion, distinct from network connectivity. ↩︎

3. \Delta denotes the assumed upper bound on network message delivery time between any two honest validators. ↩︎

4. The precise slot structure depends on the protocol. Goldfish, for example, uses 3\Delta slots (proposal, vote buffering, voting) or 4\Delta if fast confirmations are implemented. ↩︎

Some Ethereum-anchored systems (e.g., L2s and cross-chain bridges) act before protocol finality, relying on heuristic signals such as confirmation depth. We describe a rational finality stall, where validators temporarily delay finality without breaking consensus. During this window, Ethereum-anchored systems may act on a non-finalized state that can later be reorganized.

Heuristic Confirmation Rules Used by Representative Cross-Chain Bridges

(i) Most systems trigger settlement after a fixed number of block confirmations rather than waiting for Ethereum finality (two epochs).
(ii) Delay is estimated using an average Ethereum block time of ≈12 s, i.e., Delay ≈ blocks × 12 s.
Confirmation thresholds are taken from official documentation.

Motivation

Many Ethereum-anchored systems do not literally wait for Ethereum protocol finality before acting. Instead, they often rely on heuristic signals such as a fixed number of block confirmations or a fixed time delay. For example, many cross-chain bridges trigger settlement after a fixed number of block confirmations rather than waiting for Ethereum protocol finality (two epochs).

Under normal conditions, these signals tend to correlate with Ethereum finality, and applications may treat them as roughly interchangeable. However, these signals represent different security boundaries.

It is therefore useful to separate two questions:

1. Has the chain continued to grow?
2. Has the corresponding state reached Ethereum protocol finality?

Under ordinary network conditions, these signals may appear closely aligned, but they are not equivalent.

Ethereum protocol finality represents the strongest settlement guarantee available in the protocol. If an Ethereum-anchored system acts earlier, it is implicitly relying on a weaker settlement rule.

Rational Finality Stall

We define a rational finality stall as a scenario in which a coalition of validators intentionally delays Ethereum protocol finality for a limited period due to economic incentives.

In such a scenario:

• validators withhold attestations required for finalization,
• the chain continues to grow normally,
• and finality is temporarily delayed without reverting any finalized blocks.

An attacker does not aim to break Ethereum consensus itself, but rather to create a window during which Ethereum-anchored systems act on non-finalized state.

A simplified sequence could look like this:

1. A coalition with sufficient stake to block finality withholds the votes required for finalization.
2. The chain continues to extend normally.
3. Ethereum-anchored systems relying on confirmation depth or time delay interpret the growing chain as sufficiently stable.
4. These systems perform externally meaningful actions.
5. Later it becomes clear that the action was taken on a prefix that never reached protocol finality.

Importantly, the attacker does not necessarily need to revert finalized history.
It may be sufficient to create a window during which downstream systems are willing to act before finality is reached.

Economic Perspective

This scenario can be viewed through a simple economic lens. Suppose an Ethereum-anchored system triggers action after k confirmations, or t minutes. A rational attacker only needs the finality stall to persist long enough for this trigger to fire.

The relevant comparison therefore, becomes:

Is the value extractable from inducing pre-finality actions larger than the attacker’s cost of sustaining the stall?

The attacker’s cost may include:

1. Foregone validator rewards: Validators withholding attestations lose normal attestation rewards and may incur penalties.

2. Inactivity leak losses: If finality fails for several epochs, the inactivity leak mechanism gradually reduces the stake of validators on the non-finalizing side.

3. Coordination and opportunity costs: A coalition large enough to stall finality must coordinate behavior and accept capital risk.

The attacker’s potential upside may come from actions triggered during that window, such as:

• asset releases
• token mints
• cross-chain message execution
• liquidity advancement
• accounting updates

The attacker does not need to break Ethereum finality itself. It may be sufficient to delay finality long enough for pre-finality triggers in Ethereum-anchored systems to fire.

From this perspective, the issue is best understood as a latency–settlement tradeoff under adversarial economics.

Latest data from Beaconcha.in indicates that Lido currently maintains a staking share of 21.14%. The total network stake is approximately 38,029,806.48 ETH.

To reach the 1/3 threshold necessary to initiate a finality stall, a gap of approximately 12.19% of total stake (4,635,833.41 ETH) must be filled.

Assuming that each validator has a stake of 32 ETH, 14,487 additional validators would be required to participate in the attack.

The attacker would need to provide a minimum bribe equivalent to the lost rewards of these additional validators to incentivize their participation in the stall.

Based on the Ethereum base reward calculation model, in the event of a 94-block reorganization caused by an attack, a rational validator can earn a base reward of approximately 30,846.69 Gwei.

Therefore:

• Total reward for 12.19% validators ≈ 4,468,752,870.41 Gwei
• Equivalent ≈ 4.47 ETH

Using the Ethereum staking annual interest rate of 2.778% (source: Ethereum staking: How does it work?), the total reward earned by these validators is approximately 4.61 ETH.

Therefore, in order to make the finality stall economically feasible (assuming Lido is the attacker), the value extracted from the target system must exceed the bribery cost of approximately 4.61 ETH, excluding additional coordination and capital risks.

Disclaimer. Lido is used here only as an illustrative example due to its large staking share.
This analysis does not imply that Lido would attempt such an attack.

The goal is simply to show that, given the current staking distribution, the economic barrier to coordinating a temporary finality stall may be lower than commonly assumed. The example therefore serves to illustrate the potential feasibility of the scenario under realistic network conditions.

Conclusion

Ethereum protocol finality exists to provide a strong settlement boundary. However, some Ethereum-anchored systems may choose to act earlier for latency or capital efficiency reasons. Doing so introduces additional reorganization risks.

From a protocol design perspective, the safest default is to align application settlement rules with Ethereum protocol finality whenever possible. We therefore strongly encourage Ethereum-anchored systems to explicitly account for these risks when designing settlement mechanisms, particularly when relying on heuristic confirmation rules such as block depth or time delays.

by Manuel B. Santos (@manel1874) and Danno Ferrin (@shemnon) form Tectonic Labs.

This note collects ideas on how to design a signature-free authenticated key exchange (AKE) for the execution-layer P2P stack.

Acknowledgments to Mike Lodder for running benchmarks on the Rebar scheme.

Motivation

As noted in a recent PSE blogpost, Ethereum’s P2P stack relies heavily on elliptic-curve cryptography. The blog post identifies several post-quantum (PQ) migration requirements for Ethereum’s consensus and execution P2P layers and concludes with a call for further exploration. Their initial analysis, based on a drop-in replacement of PQ primitives, highlights some practical constraints. For example, in the UDP-based Discv4/5 protocols, a drop-in replacement exceeds the 1280-byte UDP frame limit.

Here we focus on the execution P2P stack and explore a specific direction: can we remove signatures from the execution P2P layer entirely? Instead of replacing ECDSA with a PQ signature scheme, we bind node identity to KEM keys and use KEMs for both key exchange and authentication. We present a progression of protocols and compare their security features and bandwidth trade-offs. For reference, we also describe the current RLPx handshake protocol.

Note: Two of the proposed protocols use the standard KEM API, providing crypto-agility and modularity for this layer. In practice, we instantiate the KEM with X-Wing (Barbosa et al., (2024)) to provide hybrid security. The final authenticated key exchange uses a specific lattice-based double-KEM construction, which provides less modularity.

Authentication Flavors in Key Exchange

Before diving into protocol designs, it helps to clarify what “authentication” means in a key exchange, since the protocols we present achieve different forms of it. We follow the definitional framework of Guilhem et al., (2019):

• Implicit key authentication: Only the intended peer could compute the session key (because only they hold the private key). However, you have no proof that they actually did.

• Explicit key authentication: You obtain evidence that the peer has computed the same session key. This is typically achieved through key confirmation: one party sends a value (e.g., a MAC) derived from the session key, and the other verifies it. This follows from a composition result by Guilhem et al.: implicit AKE + key confirmation => explicit AKE.

The current RLPx handshake provides explicit authentication for the initiator (via an ECDSA signature) but only implicit authentication for the recipient. The two last DAKE-based protocols achieve explicit authentication for both parties, without using any signatures.

KEM-Based Node Identity

In summary, we propose a system in which node identity depends solely on KEM keys. The 64-byte \texttt{nodeId} (currently defined as \texttt{nodeId} = \mathsf{Keccak512}(\texttt{x} \parallel \texttt{y}) of the ECDSA public key) is replaced with:

where \mathsf{pk}_\text{KEM} is the node’s long-term KEM public key. We hash the KEM key rather than using it directly, keeping \texttt{nodeId} small enough for UDP packets regardless of the KEM type.

Discovery

We focus on Discv4, which in its original design signs every gossip message with ECDSA. Below we show the structure of its packet:

A drop-in replacement with a Falcon-512 signature would look something like this:

Indeed, PQ signatures do not fit within the 1280-byte UDP frame allocated for discovery messages. Instead of fragmenting packets, we take a simpler approach: replace signatures with hash commitments. More specifically, we commit to the \texttt{nodeId} and the standard message payload from the original Discv4 specification using \mathsf{Keccak256}. This leads to the following structure:

With this approach, we loose authentication at discovery time. Anyone can forge a discovery packet claiming any \texttt{nodeId}.

Why it is acceptable: real identity validation happens during the subsequent RLPx handshake phase. In the existing P2P design, an adversary can already locally generate many key pairs, creating a large number of fraudulent neighbor announcements Marcus et al., (2018). The \texttt{peerId} received during discovery serves as input to the handshake phase and allows us to verify that the party performing the handshake is the same one that participated in discovery.

Original RLPx Handshake

The existing RLPx protocol uses ECIES (Elliptic Curve Integrated Encryption Scheme) for the handshake. Each node has a long-term key pair (\mathsf{pk}, \mathsf{sk}) from a signature scheme (secp256k1).

The initiator signs a random nonce with ECDSA, ECIES-encrypts an auth message to the recipient’s static key, and exchanges ephemeral ECDH keys to derive session keys with forward secrecy.

Interestingly, RLPx does not provide recipient implicit key authentication. This occurs because the initiator does not check whether the recipient was able to decrypt the initiator’s ephemeral public key (e_i_pk) in step 4.

A Progression of KEM-Based Protocols

We present three PQ protocol variants and compare them with the original RLPx. The first two variants use X-Wing (a hybrid KEM combining X25519 and ML-KEM-768 (Barbosa et al., (2024)) as the underlying KEM. Long-term keys are now (\mathsf{pk}, \mathsf{sk}) of a KEM scheme rather than a signature scheme.

Protocol 1: Implicit AKE

The first protocol is an implicit authentication key exchange in which both parties encapsulate to each other’s long-term static keys. They then combine the resulting KEM shared secrets (k_i, k_r) to derive a final session key.

This PQ version inevitably requires one more round (the init round) than the original RLPx, because the initiator must first obtain the recipient’s public key. This protocol also provides fewer security features than the original RLPx: it offers no forward secrecy, since the shared secrets are directly encapsulated using long-term static keys, and only implicit authentication, since there is no mechanism ensuring both parties derived the same shared keys.

Let’s address these limitations in the next two protocol versions.

Protocol 2: Explicit AKE

This protocol aims to provide forward secrecy and explicit key authentication for both parties. It follows the spirit of the protocol described in NIST SP 800-227 (Fig. 11, p. 42). However, since we only require key authentication and not entity authentication (which binds a private key to a real-world entity), certificates are not necessary.

Forward secrecy is achieved by using two separate KEMs: long-term KEM keys for authentication and ephemeral KEM keys for forward secrecy. Explicit key authentication is obtained using the result from Guilhem et al.: implicit AKE + key confirmation = explicit AKE. The price of explicit recipient authentication is one additional confirmation message (a MAC derived from the session key) and 256 bytes of additional communication.

Note: NIST SP 800-227 (Fig. 5, p. 23) recommends deriving a key for key confirmation from k_i. However, in Step 7 we follow the construction from Beguinet et al., (2025) and use k_i directly. Using a KDF here would not change any communication metrics.

Protocol 3: Explicit DAKE

The final protocol has essentially the same structure as Protocol 2, but replaces two independent KEM encapsulations with a double-KEM (Maul). This construction encapsulates a single key under two public keys (long-term + ephemeral) in a single compressed ciphertext.

The protocol is heavily inspired by the \mathsf{DAKE}_2 protocol from Beguinet et al., (2025).

For the bandwidth estimation, we consider the \mathsf{DAKE}_2 NIST Category 3 construction with a ciphertext of 1440 bytes and a public key of 1240 bytes (see Table 2 of Beguinet et al., (2025)). This matches the same post-quantum security level as X-Wing.

The ack message shrinks from 2,528 bytes to 1,728 bytes thanks to double-KEM compression. However, this approach only compresses the ack message; the other messages remain mostly unchanged.

Because Maul double-KEM does not yet have an implementation, we benchmarked Rebar, a concurrent construction (reinforcing KEM, RKEM) by Hashimoto et al., (2025), with a similar compression rate. For reproducibility, you can check the code for our benchmarks here.

The reinforcing KEM (RKEM) introduces a computational overhead compared to two independent ML-KEM-512 operations:

Although Rebar introduces a \sim 9\times computational overhead, the impact will likely be diluted during the handshake because communication latency dominates.

Comparison & Final Remarks

The bandwidth increase (800 B vs. 7–8 KB) is significant on paper, but the handshake occurs only once per peer connection and Ethereum nodes maintain long-lived peer connections. Once the session is established, symmetric encryption takes over. So, the additional round-trip (4 messages vs. 2) introduces one extra RTT of latency, which is acceptable for a connection that is expected to persist.

Among the proposed designs, Protocol 2 (Explicit AKE) offers the most balanced trade-off. It achieves all the desired security properties (forward secrecy + explicit key authentication) while relying only on standard, well-understood hybrid KEM constructions.

Although Protocol 3 reduces bandwidth through double-KEM compression, the gains are relatively modest in the context of a one-time handshake. Given the additional complexity, lack of mature implementations, and non-trivial computational overhead, these savings do not justify moving away from a simpler and more robust construction.

Or maybe is it just because you have been valuing or estimating everything based strictly on fiat dollar? Should be some food for thought. Maybe if you value everything ETH based on ETH itself alone (not based on an fiat money value, be it dollar, yen, renminbi, or euro), that the worry about variable fee would not arise regardless of the price of ETH, hmm…

As long as the cost of doing crime is close to nil, the incentive to commit the crime will remain close to infinite. If crime method A no long works, then the criminals will figure out crime method B. Controlling the mass creation of new accounts is not without its limitations and may very likely just be a temporal and insignificant band aid fix. And then the development team will face with another exploit requiring further EIPs. The more EIPs you have in place to fix a problem (that cannot be absolutely fixed with any of the EIPs on its own), the more unnecessarily complicated the development will be. And as the incentive to do crime is near infinite (because the cost of exploit is near zero), I predict the number of EIPs required to fix all possible + potential future exploits to be near infinite too, don’t you think?

Update:
Almost forgot to mention this…As the tx cost (and cost of exploit) gets closer to zero (cheapass price maybe because the banksters-cum-sponsors demand for it for some high frequency trading operations), the “money supply” of ETH is now becoming inflationary → validator reward falling → decreasing incentive to be validator → increasing the risk of validation being dominated only by a few shadow elite group of people → compromised blockchain ultimately devolved to serve only the banksters, it should be clear that the cost of having an undefined floor price of transactions significantly outweighs everything.

Update #2:
In answering your question, if the price of ETH gets to ICO level, i.e. dirt cheap market cap, two scenarios become possible:
Scenario 1: People start to use ETH blockchain for dirt cheap and low-value transactions, thus the 1 Gwei floor price will remain feasible.
Scenario 2: People start to use ETH blockchain for high-value transactions, thus requiring cargo-load of ETHs per transaction. In this case, the price of ETH as denominated in fiat dollar will not remain dirt cheap at ICO level for too long, thus rendering the effort to re-adjust the floor price from 1 Gwei to say, 1000 Gwei, become unnecessary. That floor price can stay at 1 Gwei.

Fortunately, we have EIP-2780 and EIP-8037, which effectively control the mass creation of new accounts, indirectly reducing the attacker’s incentive by decreasing the number of accounts that can be created in a block. This is a fitting punishment for spammers, but it hardly harms ordinary users.

You can even tell it in the prompt exactly what your budget is, and it will stay within that budget.

Computational time is proportional to the square of the sum of the prompt length and the response length. My understanding, though, is that commercial providers charge linearly, not quadratically.

omarespejel:

The protocol gets dramatically simpler. The trade-off is ~20-40% cost overhead due to unused token budget

My experience using LLMs is wildly different from this, I would estimate with no refunds my overhead would be like 100x. eg. when I sent requests to GPT 5.2 etc with OpenRouter, I need to have a >$5 budget to make requests, to cover the max possible size, but on average each request costs like a cent.

The problem is that the resource consumption of requests is extremely variable. “write a 10000 word essay” and “translate ‘你好世界’ to English” go through the same prompt path. Or “prove [ X ] theorem”, “research how to do [Y]”, and many other tasks are tasks of the form “search until you find it”, whose probability distribution if you modeled it out would probably be some infinite-variance Levy-ish distribution. Sometimes it takes 100 thinking tokens, sometimes it takes 5000, occasionally it takes 100000.

This isn’t theoretical. vLLM’s chunk-based prefix caching had a documented timing side channel (CVE-2025-46570, GHSA-4qjh-9fv9-r85r), where cache-hit timing differences achieved an AUC of 0.99 with 8-token prefixes, enough to verify whether two requests share context. Patched in vLLM 0.9.0, but the fundamental issue is architectural: any shared-cache inference server leaks request similarity through timing unless explicitly mitigated.

Are you assuming here that the inference server is a TEE, and describing a TEE leak? I was actually assuming a worse security model than even this: the entity running this is a forwarder to OpenAI/Anthropic/…, and so the ultimate inferring entity is an entity that we cannot trust at all.

So yeah, preserving privacy in such a design would require several things on top of ZK-API: probably (i) mixnets, and (ii) having a small local model sanitize requests. Even that would be far from perfect, but it would be much better data leakage prevention than nothing, and importantly it would not be fragile: the key thing that ZK-API ensures is that even if eg. 80% of your requests get linked together based on content and timing, the remaining 20% (which might be about totally different subject matter) stay anonymized.

Marcolopeez:

• The catch (discussed in the asanso series as well) is that the bundler still posts an ECDSA-signed transaction, so the end-to-end flow is not fully PQ-resistant. It also introduces extra moving parts (mempool-like infrastructure, fees, operational complexity).

Yes the end to end flow is not PQ resistant; but since the bundler does not own anything, it seems not very important that it still uses ECDSA.

Or am I missing something?

The aim is to move emergency response from ideological debate into formal mechanism design that makes intervention cost, containment speed, and centralization cost measurable so governance can reason quantitatively about action vs. inaction under stress.

What LIF contains

• 705 exploit incidents ($78.81B in cumulative losses, 2016–2026)

• 137 documented intervention cases ($2.51B in prevented losses)

• A Scope × Authority taxonomy classifying interventions along two dimensions: the precision of the intervention (Network → Protocol → Asset → Module → Account) and the concentration of trigger authority (Signer Set → Delegated Body → Governance)

• A stochastic cost model that makes explicit the tradeoff between containment speed, collateral disruption, standing centralization cost and the legitimacy of it all:

where standing centralization cost captures the peacetime privilege burden, and activation cost captures containment speed and collateral disruption. The model yields three testable predictions, all confirmed empirically against the 705-incident dataset.

• An open dataset and interactive explorer at lif-research.org

Key empirical findings

1. While 80.6% of at-risk capital saw intervention attempts, only 26.5% was successfully recovered, a $7.7B delta between attempted and successful containment during hack crisis.

2. Speed dominates deliberation for containment. Signer Sets (protocol-team-controlled multisigs) successfully protect 2.5× more capital than Governance processes. Median containment time: ~30 min for Signer Sets vs. days for onchain governance, while the balance hovers around ~90 min for Delegated bodies (i.e Security Councils and Emergency SubDAOs).

3. Losses follow a heavy tail (α ≈ 1.33). The results show that intervention mechanisms should be designed to contain catastrophic super-hacks, not really for the average incidents.

4. The industry is professionalizing fast. Intervention success rate: 10.9% (2024) to 82.5% (2025).

Live governance case study

I have been applying this framework during the GnosisDAO Framework Consultation following the Balancer proxy exploit. My contributions include a Hierarchy of Precision for intervention scope, an Optimistic Freeze model, and a synthesis distinguishing preventative credible layers from bounded institutional recourse.

→ A Framework for the Future - Gnosis Forum

Academic companion

“Legitimate Overrides in Decentralized Protocols” - Elem & Talmon

arXiv:2602.12260: https://arxiv.org/abs/2602.12260

The paper has been accepted for presentation at TERSE 2026 (Token Engineering Research Symposium; EthCC, Cannes).

We formalize intervention as a game-theoretic problem and prove when bounded delegation outperforms both pure immutability and unbounded admin discretion.

Links

• LIF dataset + explorer: lif-research.org

• arXiv paper: arXiv:2602.12260

• Gnosis forum contribution: A Framework for the Future

• Repository: GitHub

I especially welcome critique on:

1. Taxonomy granularity: Is the 5-level Scope hierarchy (Network to Account) the right resolution for the design space?

2. Standing centralization cost: How do we formally quantify the peacetime cost of maintaining intervention capabilities? What discount rate should different mechanisms carry?

3. Evidence standards: What cryptographic or social evidence standards should be required for post-incident replay and ratification of emergency actions?

4. Financial backstops: Could programmable risk pools (parametric insurance primitives) complement intervention frameworks by pricing the residual risk that containment fails?

5. Non-retroactivity: How do we design framework updates that apply forward-only, preserving legitimacy of past decisions made under prior rules?

Contributions, replication, and critique are explicitly encouraged. The dataset and calculator are open-source.

First, in our analysis we assume that all honest validators continue to follow the protocol and the default client behavior throughout the attack. Even under that standard assumption, the attack is already sufficient to impose systematic incentive losses on honest validators. So the core issue exists at the incentive layer itself, without needing to assume that honest participants deviate, stop voting, or exit.

Second, from a verification or monitoring perspective, the attack also shows that locally visible fork-choice state before finalization should be interpreted with caution. During the withholding interval, observers may see a branch that appears stable, while still-valid but not-yet-revealed blocks or votes can later change which branch remains eligible or becomes canonical.

More broadly, if such deviations from expected protocol behavior were to persist, they could weaken validator confidence in the protocol’s normal operation and potentially worsen participation incentives, which would only make these incentive vulnerabilities more concerning.

From an observer’s perspective, that dynamic is particularly interesting because it means the apparent fork-choice state can remain stable for some time while important information (votes or blocks) is still withheld. When that delayed information is eventually revealed, fork choice may resolve in a way that invalidates what previously appeared to be a well-supported branch.

I’m curious how people here think about this from a verification standpoint, especially for observers who are syncing or monitoring the chain. In particular, whether scenarios like this are primarily viewed as validator incentive attacks, or whether they also highlight limits on how confidently observers can interpret locally visible fork-choice state during those intervals.

Would be interested to hear how others working on fork choice and long-range verification think about that boundary.

in our design, most of the things are P2P, but not on any blockchain, peers join a libp2p gossipsub topic, and they use an arbitrary antispam challenge chosen by the community owner as the validation (antispam) function.

some mechanism to deposit funds somewhere and get credits to publish to the libp2p gossipsub topic is one of the most open and obvious way to do it, so it would be really useful for us and other similar projects like waku, farcaster, etc that use a similar antispam/DDOS strategy.

we are still seriously working on this project and have a few users and P2P communities running, but getting the antispam challenge right is the most difficult part at the moment. it’s difficult for users to easily onboard, yet also prevent people from flooding with spam.

In my paper, ZK-ACE (Identity-Centric Zero-Knowledge Authorization), I propose a different approach:

• Shift the Paradigm: Instead of verifying the signature object itself, we prove the semantic authorization of a transaction.
• Minimalist Circuits: By using an identity commitment anchored on-chain , the circuit only needs to perform a few ZK-friendly hashes (like Poseidon).
• Massive Scaling: This reduces the circuit to only ~1,400 R1CS constraints , regardless of the underlying signature scheme’s complexity.

Essentially, we move from O(n) verification (where n is the signature size) to O(1) constant-size proofs. It sidesteps the “massive circuit” problem by treating the signature as a proof-generation artifact that never needs to touch the blockchain.

I’d love to hear your thoughts on whether this identity-centric model could be a more sustainable path for ZK-proving Ethereum transactions. ArXiv: 2603.07974

Thanks,
Jason

Regarding the worry that such proposal may be detrimental, i.e. causing tx fee to rise exponentially as the price of ETH rises exponentially in the future. This is an intellectual fallacy because it relies on the absolute assumption that ETH price will definitively and absolutely rise exponentially in the future, guaranteed (by some magical and yet unknown factor). What I fear most is if the current setting is kept prevalent to the point whereby the network ultimately become so polluted and defiled by address poisoning (and potentially many other threats arising in the future), that the future scenario whereby the price of ETH rises, if any at all, becomes non-existent.

So please don’t bother about the future that nobody even know about or even absolutely assured of, and start solving the most immediate problem that may soon become terminal, irreversible, and end up with pointless regrets about what we should have done differently, instead of keep peddling about “what if the ETH price will rise exponentially in the future”.

I say, what if the price of ETH will NEVER rise if we keep on making wrong decisions today?

We explore a decentralized proving architecture for Curvy, a privacy-preserving protocol based on stealth-address UTXOs and ZK aggregation. We identify a problem arising from concurrent state updates to a shared Sparse Merkle Tree (SMT) root, and propose an on-chain slot-based sequencing mechanism for provers. We analyze denial-of-service risks introduced by this approach and propose collateral-backed participation and request throttling as mitigations.

Background

Curvy protocol allows private transfers using stealth address transfers and ZK proofs. As each received transfer ends on a different stealth address, Curvy enables aggregation of funds using a ZK aggregator without revealing the funds’ origin to the public. However, a single centralized prover would be able to gather information on all transaction graph sections, thus reconstructing the origins of all funds. To prevent this kind of privacy leak, we are investigating decentralized provers that can individually create their own aggregation proofs or submit batch proofs from multiple users.

The funds from stealth transfers are represented in a UTXO manner as notes. Each note is stored in an SMT, and the current SMT root is kept in the aggregator smart contract. Note IDs (tree leaves) are emitted through events. Each client can listen to events and reconstruct the tree. Aggregation is a process in which existing notes are destroyed, and new notes are created, having the balance of the output notes equal to the sum of all input note balances. Each aggregation creates new notes and updates the notes tree, backed by the ZK proof testifying to the correctness of the update.

Problem Statement

Computing the aggregation proof requires providing both the old and new SMT root, computed after all new notes are correctly inserted. Due to the sequential nature of the on-chain root updates, if multiple provers try to modify the SMT based on the same old root, only the first prover would be able to successfully do the operation, while transactions of all other provers would be reverted. Even if a prover is indeed the first to submit the transaction, non-deterministic transaction ordering may cause the prover’s transaction to not be the first in a block, and the transaction may revert. Reverted transaction with only two (old and new) root values and Groth16 proof data in calldata cost ~33000 gas. Even though the cost is not significantly high, repeated transaction does not guarantee success even with the updated roots and corresponding proof.

Slot-Based Prover Sequencing

To mitigate the collisions resulting in multiple provers referring to the same old state, we propose the introduction of an on-chain request queue, where provers would first apply for a time slot in which they can submit their state updates. A time slot refers to an interval [fromBlockNumber, toBlockNumber] associated with a given message sender. Provers can submit their proofs only when the current block number is within the range of their time slot.

This way, the natural sequence of updates is maintained on-chain, and provers can determine their proving slot. Waiting time is also known in advance, meaning that provers can save time on constant state polling and event listening. The “sign-up” operation is a low-cost operation compared to reverting transactions carrying the ZK proof and public data. This solution prevents collisions but allows DOS attacks on the smart contract, having malicious users occupying a large number of slots using relatively small funds.

Skipped time slots are not reusable. If a prover misses the given slot, a new slot needs to be requested. The timeframe of a slot needs to be properly estimated. Slot start time needs to be delayed for at least the time required for generating Groth16 proof, while end time needs to provide a proper buffer, taking into account network latency. Exact values are yet to be determined. Slot overlaps are not allowed.

If a prover, for some reason, submits an invalid proof, the slot is still active until the slot deadline, allowing the prover to submit the corrected proof.

Collateral-backed provers

The source of the DOS attack possibility lies in the low cost of slot requests. Adding an extra cost to all requests may be a theoretical solution, but the user experience and cumulative proving costs undermine the overall benefits of decentralized proving. We consider requiring each prover to provide one-time collateral before requesting a time slot. The collateral would not be lost but locked until the provers decide to stop proving and withdraw their collateral. This way, the entry barrier has higher on-time costs but eliminates a portion of malicious provers that can cross the barrier. Additionally, each honest prover would receive a fee from all aggregated funds in their submitted proofs, making honest behavior additionally incentivized.

Request throttling

The collateral acts as a joining token to the proving service, but once joined, a prover may still spam the request queue. To mitigate this, the requests are throttled so provers may submit only a certain number of requests in a given time frame (i.e., once in 10 minutes). To be able to request slots more frequently, the required collateral would need to be higher. If one request time slot per a given time frame costs X, k slots would have a linearly higher cost of kX. Throttling would be implemented on a smart contract level, tracking the last request submission time from each prover with deposited collateral.

Data visibility

In the described protocol, each prover will require knowledge of private inputs for the construction of ZK proofs. If a prover is providing proving services to other users, it will be able to see certain disclosed information. In general, it will be aware of a segment of the transaction graph. Without knowledge of all transactions in the chain from deposits to withdrawals, the origin and destination of funds will remain untraceable for the prover.

For decades, software development revolved around programming languages such as C++, Python, Java, and many others. Today’s AI systems like ChatGPT or Claude follow the same paradigm: generate code to automate tasks.

This approach resembles putting a steam engine on a horse carriage . The power source has changed, but the architecture is the same.

LLMs can generate programs extremely well, but the fundamental abstraction of computing is still a deterministic program —a rigid sequence of instructions written in a programming language.

We argue that this abstraction will not survive the age of AI.

As we argue below, in the future, programming languages will either disappear entirely or move into a niche layer. Instead of writing programs, humans will interact with agents that have personalities, memory, strategies, and objectives we call TODOs .

2. The Fundamental Problem of Programs

Consider a simple example.

Alice wants to dollar-cost average into Unicorn Corp by buying 1,000 shares over the course of a month. A traditional solution might be a Python script:

• Each day the script executes a trade
• It buys a small portion of the total shares

This works perfectly until reality intervenes.

Suppose halfway through the month, a black swan event occurs: the founder of Unicorn Corp suddenly dies. The the investment thesis collapses.

But Alice’s Python script keeps buying shares every day . It continues executing the loop because it cannot interpret events or reassess objectives.

Now compare this to the case where Alice hires a human broker .

The broker also buys shares daily. But when the founder dies, the broker pauses trading and calls Alice:

“The situation has changed. Should we stop buying?”

This illustrates a key weakness of traditional programs: they are brittle, rigid, and context-blind .

Human agents operate very differently. They constantly integrate new information and adjust behavior accordingly.

We are all used to running programs and dealing with their rigidity and brittleness. We do not have to do it anymore

3. From Programs to Agents

Instead of writing a rigid Python script, Alice could instead define a TODO :

“Accumulate roughly 1,000 shares of Unicorn Corp over a month in a sensible, risk-aware way.”

This description specifies a sane goal , not instructions.

An agent operating under this TODO would:

• observe market conditions
• remember past trades
• update its strategy dynamically
• pause or reassess when major events occur

The agent behaves more like a human professional than a deterministic script.

TODOs therefore represent high-level descriptions of goals , not explicit algorithms.

4. Flexibility Through TODOs

This paradigm also provides a level of flexibility that traditional programs struggle to achieve.

Suppose Alice begins her investment plan but ten days into the month changes her mind :

• She wants to double the number of shares purchased
• She also wants to buy only on days when the price dips

With a Python script, this change becomes very complicated.

Alice would need to:

1. Stop the running program
2. Modify the code
3. Ensure the new logic is compatible with past trades already written to the database
4. Restart the system safely

With TODOs the process is much simpler.

Alice simply updates the TODO :

“Double the total shares and buy only on price dips.”

The agent continues running and internally adapts its strategy while maintaining continuity with previous actions.

This is exactly how one would update instructions given to a human assistant.

5. The New Building Blocks for Computing

In this framework, the core abstractions of computing change.

Instead of programs written in programming languages, systems are built from four components:

5.1 Personalities

Persistent behavioral frameworks that define how agents reason, evaluate risk, and respond to events.

5.2 Memory

Structured records of observations, actions, and learned knowledge.

5.3 Strategies

Dynamic approaches used by the agent to accomplish objectives.

5.4 TODOs

High-level descriptions of goals that guide behavior.

Together these components create systems that are adaptive rather than deterministic .

6. Why Hierarchy Is Essential

These elements must be organized hierarchically .

Lower levels of the hierarchy change rapidly:

• individual actions
• tactical strategies
• short-term observations

Higher levels change much more slowly:

• long-term strategies
• TODO objectives
• core personality traits

This structure mirrors how human organizations and cognition work.

The higher the level in the hierarchy, the more valuable and stable the information becomes .

7. Why Blockchain Matters

7.1 Controlling the highest level of hierarchy

This hierarchical structure naturally introduces a role for blockchain systems .

Humans cannot realistically supervise every decision made by autonomous agents. However, they can control the highest-value layers of the hierarchy .

Blockchain provides the ideal infrastructure for storing:

• high-level TODOs
• personality parameters
• strategic frameworks
• important memory checkpoints

Blockchains offer properties that are particularly valuable in this context:

• immutability
• transparency
• shared access between humans and AI agents

In this architecture, blockchain becomes a communication layer between humans and autonomous agents .

Humans modify high-level objectives and constraints, while agents autonomously execute lower-level actions.

7.2 Enforcing rules.

The second place for blockchain is to enforce rules for agents. Execution must be flexible, but rules need to be rigids.

Ironically, smartcontracts written in Solidity may be one of the few places where programming languages will remain as a way for humans to set rigid rules that agents can obey. Since smartcontracts have tiny amounts of code, they can be reviewed by humans without need for AI. As an example, a human can set spending limit for its AI agents using a smarcontract on blockchain.

8. Conclusion

The transition from programming languages to agents represents a fundamental shift in how software is built.

Just as graphical interfaces replaced command-line computing for most users, agent-based systems may eventually replace traditional programming for many tasks .

And when that happens, the fundamental unit of computing will no longer be a program.

It will be an autonomous agent with a personality and a purpose .

tl;dr: Witness encryption has been theoretically possible since 2013 but remains cryptographically undeployable. I’ve spent several years building a system that approximates its core properties using client-side ZK proofs, homomorphic two-party key generation, and economic slashing — with two working test implementations running today. This post is about the problem, the framing, and an honest account of where the trust boundaries sit.

The Problem

Witness encryption describes a deceptively simple primitive: encrypt a message such that it can only be decrypted by someone who can produce a valid witness for an NP statement. The condition is the key. No trusted party. No custodian. Just proof.

No secure general construction exists today. The original multilinear map construction has been broken. Evasive LWE approaches are promising but not yet deployable. Meanwhile the problems witness encryption would solve — private key recovery, identity-bound data delivery, trustless conditional access — are being patched with custodians and social recovery mechanisms that introduce exactly the failure modes cryptography is supposed to eliminate.

The Substitution

Can you build a system where a secret is cryptographically bound to a condition — where satisfying the condition is necessary and sufficient to recover the secret — without a trusted party, and without the secret ever existing in plaintext? Sealing and unsealing require communication with a processor, but the processor learns nothing about the secret or the conditions.

The answer is yes — with one substitution. Instead of the mathematical guarantee that no party can decrypt without a valid witness, you build an economic guarantee that no party will — because doing so destroys their staked capital irreversibly.

This is a crypto-economic construction, not a purely cryptographic one. The goal is not to raise the ceiling of cryptographic security but to raise the floor high enough that real UX becomes possible without sacrificing self-custody.

Proposed Primitive (informal)

A system providing:

• Confidentiality against all but a publicly slashable operator
• Cryptographic verification of release conditions
• Publicly attributable misbehavior with permissionless enforcement
• Compatible with future cryptographic substitution of the operator role

Design Principles

Before describing the construction, four principles constrain the design:

Primitive composition, not invention. Nihilium introduces no new cryptographic primitives. It composes Shamir Secret Sharing, ECElGamal homomorphic encryption, zero-knowledge proofs, EVM-based staking and slashing, and Merkle trees for timestamping — all using established libraries. The contribution is a novel configuration that achieves the target properties.

Value decomposition. What is sealed is never the asset itself — only a component worthless in isolation. A password without its encrypted file has zero standalone value. An encrypted file without its password has zero standalone value. Their combination has the full asset value. This means processor stake needs only to exceed the value an attacker could extract from the sealed component alone — which is zero under correct usage. The stake-to-asset-value comparison that initially appears problematic is the wrong frame.

Client-side proof burden. Unlike MPC and threshold systems where servers evaluate conditions, Nihilium inverts responsibility: the client proves, the processor validates. Processors remain stateless and lightweight. The condition language is infinitely extensible without processor software updates. Condition contents remain hidden from processors until unsealing.

Enforcement-only blockchain. The EVM provides immutable contracts, censorship-resistant slashing, and permissionless stake registration. In normal operation, only the datastream requires regular on-chain transactions. Clients and processors interact off-chain unless slashing or forced execution is triggered.

System Actors

The protocol has four actor types:

The Client holds secrets and bears full responsibility for cryptographic operations — defining unseal conditions, generating all zero-knowledge proofs, and executing homomorphic encryption operations within ZK circuits.

The Processor is an independent operator that commits to conditional decryption via economic stake. Processors hold an EdDSA signing key and an ECElGamal decryption key (both on Baby Jubjub). They sign sealing commitments, validate chained proof execution at unsealing time, and decrypt homomorphic ciphertexts upon successful validation. They are entirely stateless, scale horizontally without coordination, and operate independently — they are not nodes in a consensus network. Each processor is independently slashable, and processor stake is reputation capital at risk across all commitments: a single provable misbehavior forfeits the entire stake permanently.

The Datastream is a timestamping and data anchoring mechanism backed by stake. It uses a two-tier Merkle tree with a smart contract per operator updated each Ethereum block. Its critical function is anchoring the reveal value that initiates unsealing — creating mandatory public observability of all unsealing attempts. It also produces stake-backed exclusion claims: signed assertions that a value does not exist in the datastream within a specified time window. If disproven, the operator is slashed. A forced inclusion mechanism provides censorship resistance. And a full on-chain version will exist to guarantee liveness

The Blockchain (EVM) serves as the permissionless enforcement layer — processor and datastream stake registration and slashing, public key registration, and unseal condition verification contract registry.

How It Works

The project is called Nihilium. Full architecture is not yet open source, but the conceptual structure is as follows.

Two-party key generation. A processor generates one key component and the client generates a second inside a ZK circuit. The components are combined inside a homomorphic ciphertext — the final key exists only as an encrypted sum, never in plaintext during construction. The processor holds the decryption key for that ciphertext, but decrypting it without a valid proof being presented is a slashable offense. If the decrypted key is ever observed outside a valid unsealing flow, attribution is unambiguous: the processor is the only party capable of producing it. Anyone can initiate a permissionless on-chain slashing challenge; the processor must produce a valid unsealing proof or lose their stake.

Chained proofs. A composable condition pipeline supporting both ZK proof verifiers and conventional on-chain contracts. Steps pass typed signals between each other, support forking for OR-logic, and are committed to in a single hash root at sealing time — binding without revealing. Execution happens off-chain at the processor; on-chain contracts serve as the challenge layer, keeping normal operation nearly gasless. A ZK coprocessor could compact the entire chain to a constant-size proof on-chain — not yet implemented but the architecture supports it.

Conditions are assembled in a visual editor using a library of reusable modules (see example below).

Symmetric enforcement. The same mechanism that slashes early disclosure also enforces censorship resistance in reverse: a processor who refuses a valid unsealing request faces identical slashing. Binary ruin for either violation — not a social guarantee, the same proof operating in both directions.

Public observability. Every unsealing attempt is publicly visible before decryption occurs. To initiate unsealing, the client must insert a reveal value into the datastream — a mandatory step observable by anyone monitoring it. The owner of a sealed secret can watch for unexpected attempts in real time without trusting any party to report them. This structural observability is also what makes time-based conditions meaningful: timelocks and revocation windows only work if the unsealing attempt itself cannot be hidden. The attempt cannot be made without leaving a public, timestamped, on-chain trace — an audit property that witness encryption and MPC constructions do not provide.

Threshold redundancy. Shamir Secret Sharing across multiple independent processors gives social recovery where the guardians are contracts, not contacts. The orchestration burden — unavailable guardians, lost contact — is replaced by a threshold of economically staked actors, any subset of whom can serve the request. Recovery is a proof, not a conversation.

Where It Goes Further Than the Primitive

Timelocks. Witness encryption for timelocks still requires a real-world temporal anchor — in practice, a ZK proof of a block header from a credible, censorship-resistant chain no single party controls. Nihilium’s datastream anchors to Ethereum block height — the same chain on which slashing is enforced. This is not incidental: all temporal claims, condition verification, and economic enforcement share a single source of truth. A purely cryptographic WE timelock would require a cross-chain trust assumption to use the same anchor; here it is native.

Revocations. Witness encryption is append-only — once a condition can be satisfied, it can be satisfied. Nihilium’s datastream operators — multiple, independently staked, with at least one assumed honest and commitments publicly auditable — can produce stake-backed exclusion claims: cryptographically signed assertions that a value does not exist in the datastream between time X and Y. If it does exist and can be proven, the operator is slashed. This enables conditions of the form “valid proof AND no revocation signal in window T to T+N” — dead man’s switches with cancellation windows, fraud delay periods, regulatory intervention windows. None of these are expressible in the witness encryption primitive.

Comparison

The processor is not a trusted party in the traditional sense — it is a publicly slashable operator whose misbehavior is attributable and permissionlessly challengeable.

Scope

The protocol is completely agnostic to the nature of the sealed value. Any secret representable as bytes can be sealed — private keys, passwords, medical records, legal documents, API tokens. The conditions are what matter, and conditions are defined by the application. The EVM provides the load-bearing guarantees — immutable contracts, censorship-resistant slashing, permissionless stake registration — but the applications that matter most may have nothing to do with blockchains at the user level.

Two test implementations are running: identity-verified file delivery using ZKPassport, and a “forgot password” recovery flow using ZKEmail where recovery requires replying to an email — no reset link, no 2FA, no server holding your secret. A reference implementation including the email server will be open sourced.
‘Forgot my password’: recovery.nihilium.io
Identity based file transfer: transfer.nihilium.io

Open Questions

• Can the detectability assumption — that leaked keys surface in publicly verifiable contexts — be strengthened cryptographically?
• Is there a formal security definition for slashable conditional key release as a standalone primitive, distinct from WE and MPC?
• Can the chained proof pipeline be efficiently compiled to a single ZK validity proof via coprocessor without sacrificing the composability properties?

What I Am Looking For

I am sharing this to establish the conceptual territory publicly and invite serious feedback on the framing, the trust boundary analysis, and the open questions above. Open to collaboration with researchers working on WE approximations or related primitives, and to conversations with teams building in adjacent problem spaces.

The project is Nihilium: nihilium.io , x.com/nihiliumio

— Olaf

Special thanks to Gary for feedback and review!

Snap sync (snap/1) dramatically improved node sync when it launched in Geth v1.10.0. But it has a well-known Achilles’ heel: the trie healing phase, an iterative process where syncing nodes discover and fix state inconsistencies one trie node at a time. This phase has caused nodes to get stuck healing for days or weeks and has been identified as something the community wants to eliminate.

With EIP-7928 (Block-Level Access Lists), a new approach becomes possible: replace trie healing entirely with sequential BAL application. This post explains how snap sync works today, what makes trie healing problematic, and how a proposed snap/2 protocol upgrade would fix it.

Part 1: How Snap Sync Works Today

The problem snap sync solves

A new Ethereum node needs the current state: every account balance, storage slot, and contract bytecode. This state lives in a Merkle Patricia Trie with the account trie saturated at a depth of about 7 levels (EF blog: Snapshot Acceleration), containing hundreds of millions of nodes.

The old approach (“fast sync”, eth/63–66) downloaded this trie node by node from the root. At block ~11,177,000, the state contained 617 million trie nodes, and syncing them required downloading 43.8 GB of data distributed over 1,607M packets, resulting in a total of ~10h 50m of sync time.

Snap sync’s key insight: skip the intermediate trie nodes entirely and download the leaves (accounts, storage) as contiguous ranges, then rebuild the trie locally. This requires serving nodes to maintain a dynamic snapshot, a flat key-value store that can iterate accounts in ~7 minutes versus ~9.5 hours for raw trie iteration (see snap.md).

Comparing fast-sync with snap sync, we got the following improvements:

Note: These benchmarks are from block ~11.2M (late 2020). The state has grown since, but the relative improvements remain representative. Modern snap sync typically takes 2–3 hours total on good hardware.

The three phases

Snap sync proceeds in three phases:

Phase 1 - Header Download: Uses the eth protocol to download all block headers, building a verified chain. The CL drives the EL, which means the first HEAD is received from the CL and the EL then downloads all parent headers starting from the latest header and moving backwards.

Phase 2 - State Download: The node picks a pivot block P (typically HEAD−64) and downloads the complete state at P:

• GetAccountRange (0x00): Download accounts in contiguous hash ranges, each response Merkle-proven at the boundaries to prevent gap attacks
• GetStorageRanges (0x02): Download storage slots for contracts, with multiple small contracts batchable into one request
• GetByteCodes (0x04): Download contract code, verified by codehash comparison

Each response is capped by byte size (not count) for predictable bandwidth, and different peers can serve different ranges concurrently. Serving nodes keep snapshots for the most recent 128 blocks (~25.6 minutes at 12 seconds per slot).

The pivot block is a block far enough in the past from the tip of the chain to ensure that we don’t download state that is the result of a block that is later reorged. 64-block deep reorgs are practically impossible. Even if such a reorg occurs, the already downloaded state does not need to be discarded and can be repaired by iteratively fetching the required trie nodes.

Crucially, as each state range is received, the node rebuilds and persists the intermediate trie nodes for that segment locally rather than fetching them over the network. By the end of Phase 2, the bulk of the trie is already correctly constructed, significantly reducing the healing workload to only fixing nodes made inconsistent by state changes that occurred during the download window.

Phase 3 - Healing: While Phase 2 is running, the chain advances from the pivot block P to P+K, turning the downloaded state stale. Healing fixes this, but it’s also where a problem begins.

How trie healing works

The healing phase uses GetTrieNodes (0x06) / TrieNodes (0x07) to iteratively discover and fetch changed trie nodes:

Why trie healing is the bottleneck

1. Iterative discovery. Syncing nodes don’t know what changed until they look. Each round of GetTrieNodes reveals the next set of differences, requiring another round trip. This is fundamentally sequential.
2. Small payloads, many round trips. Individual trie nodes are 100–500 bytes. Even batched, the data per round trip is tiny relative to network latency.
3. Moving target. With 12-second slots, about 1,000 trie nodes are deleted and 2,000 added per block. Healing must outpace this or it will never converge.
4. Random disk access. Serving GetTrieNodes requires random database reads. This is expensive compared to the sequential reads used by GetAccountRange.
5. Progress is unknowable. As Geth documentation notes: “It is not possible to monitor the progress of the state heal because the extent of the errors cannot be known until the current state has already been regenerated.”

The real-world impact can be severe. Examples include nodes being stuck for 2+ weeks while healing (43 million trie nodes, 11.7 GiB downloaded; throughput degraded to ~2 trie nodes/second), being stuck for 4 or 6 days during healing.

The at-launch benchmark showed healing adding ~541,260 trie nodes (~160 MiB) at block ~11.2M, but with today’s larger state and higher block gas limit, the healing burden is already substantially heavier, and will worsen with further gas limit increases.

Part 2: Block-Level Access Lists (BALs)

EIP-7928 introduces Block-Level Access Lists (BALs): data structures recording every account and storage location accessed during block execution, along with post-execution values. Each block header commits to its BAL via a new block_access_list_hash field placed in the block header:

block_access_list_hash = keccak256(rlp.encode(block_access_list))

A BAL contains, for every accessed account:

• Storage changes: per-slot post-values, indexed by which transaction caused the change
• Storage reads: slots read but not modified
• Balance/nonce/code changes: post-transaction values

BALs are RLP-encoded, deterministically ordered (accounts lexicographically by address, changes by transaction index), and complete. State diffs are a subset of the BAL and can therefore be used to assist during sync.

BAL sizes

Empirical analysis of 1,000 mainnet blocks at a 60M block gas limit showed that BALs are ~72.4 KiB on average.

Nodes must retain BALs for at least the weak subjectivity period (up to 3,533 epochs, ~15.7 days at today’s validator set size).

Part 3: snap/2: BAL-Based State Healing

Instead of iteratively discovering and fetching trie nodes, snap/2 inverts the snap/1 pattern. In snap/1, the trie is built incrementally during download and the flat state is derived from it. In snap/2, only the flat state (leaves) is synced, BAL diffs are applied directly to it, and the trie is rebuilt once from the complete state, eliminating incremental trie construction and the complex healing it requires.

Concretely, instead of iteratively discovering and fetching trie nodes, nodes download the BALs for every block that advanced during sync and apply the state diffs sequentially. The set of blocks is known upfront. Each BAL is verified against its header commitment. This eliminates the need for iterative discovery.

snap/2 removes the trie healing messages and replaces them with BALs, reusing the same message IDs:

Note that reusing the message IDs is safe because snap/2 is a new protocol version negotiated during the RLPx handshake. snap/1 peers never see snap/2 messages.

The new messages

GetBlockAccessLists (0x06):

[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]

BlockAccessLists (0x07):

[request-id: P, [block-access-list₁, block-access-list₂, ...]]

• Nodes must always respond
• Empty entries (zero-length bytes) for unavailable BALs
• Responses preserve request order and may be truncated from the tail
• Recommended soft limit set to 2 MiB per response, which is consistent with existing messages, e.g. blocks, headers or receipts.

The new sync algorithm

Notably, since BALs are guaranteed to be correct by consensus (BAL hash check against canonical blocks), the state roots are guaranteed to match; thus, clients could even skip the final state root comparison step.

Why this works

With snap/2, the healing window is bounded and known. For a pivot at HEAD−64:

• 64 blocks × ~72.4 KiB (projected 60M gas) ≈ 4.5 MiB total BAL data
• Fits in 2–3 responses at the 2 MiB soft limit
• Serving BALs requires only a few disk lookups instead of a lookup for every changed trie node
• 1–3 total round trips (including any “tail” blocks that arrive during application)
• Extracting the state diff from the BAL is purely local computation. There’s no need for trie traversal.

Compared to snap/1, snap/2’s healing is more efficient, requiring fewer disk reads and round trips. With snap/2, at least in theory, it should become impossible for the chain to outpace sync.

Relationship with eth/71

EIP-8159 adds BAL exchange to the eth protocol as messages 0x12/0x13. Both exist for different reasons:

Messages are duplicated in eth/71 and snap/2 to ensure snap stays a self-contained satellite protocol and to allow snap to evolve independently, for example, serving only state diffs instead of full BALs in a future version, without requiring changes to eth.

Part 4: Comparison

Healing phase: snap/1 vs snap/2

The complete flow, comparing snap/1 with snap/2, looks like the following:

Failure modes

A concrete example

Consider a pivot at block 22,000,000 with the chain 200 blocks ahead when state download completes:

snap/1: Start trie traversal from block 22,000,200’s state root. Each round discovers more differences, goes deeper. Meanwhile, multiple new blocks arrive during healing. In the best case, this takes minutes; in pathological cases (slow disk, slow network), it has taken days.

snap/2: Request BALs for multiple blocks. At a 60M block gas limit, that’s ~4–5 MiB, which fits in a few responses. Apply the BALs locally, optionally verify the state root matches. A few more blocks arrived during application? Fetch 2–3 more BALs. Total: 2–3 round trips, seconds to complete.

Further Reading

• Ethereum Snapshot Protocol (snap/1) — devp2p spec
• Ethereum Wire Protocol (eth) — devp2p spec
• EIP-7928: Block-Level Access Lists
• EIP-7928 BAL Size Analysis (empirical, 30M gas)
• EIP-8159: eth/71 — Block Access List Exchange
• Geth Sync Modes documentation
• Geth FAQ — state healing
• Ask about Geth: Snapshot Acceleration — EF Blog
• Geth v1.10.0 release — EF Blog
• Weak Subjectivity — Ethereum Consensus Specs
• Block-level Access Lists (BALs) — ethresear.ch
• go-ethereum #23191: State heal phase very slow (2+ weeks)
• go-ethereum #25945: Stuck healing for 4 days
• go-ethereum #25898: State heal since 6 days
• go-ethereum #27692: Get rid of snap sync heal phase
• Nethermind Sync Modes documentation
• Proof-of-stake (12s slots) — ethereum.org

You’re right that I buried the lede. The core problem I’m trying to solve: most trust systems in crypto let you prove who you are once, but not that you’re still the same person acting consistently over time. Keys get stolen, reputations get gamed, founders accumulate power. CCP tries to make authority a continuous, computable function rather than a one-time credential.

On the UX/security tension — I think you’re making a fair point and I may have been too quick to echo Vitalik’s framing. There is a real cost to adding friction (biological sensors, multi-axis verification). I’d argue the tradeoff shifts depending on the stakes of the action being authorized, but you’re correct that it’s a tradeoff, not a free lunch.

On the jargon — noted. I’ll revise the opening to lead with a plain-English problem statement before going into the math.

And yes, fixing the LaTeX now — thanks for the heads up.

There are all these open source self-hostable tools. So, why not extending them?
In comparison to any web 3 twitter clone, those apps are actually used.
For example: Add a marketplace to penpot.

So, how would you go about it? Easy. It’s open source and has SAML or OIDC? Done.
That’s all it take. You relay it to SIWE OIDC and login with your wallet.

I am too sick, in the literal sense and sick of this industry, I won’t draw some fancy diagram here.
Posted a video demonstration on twitter, if anyone cares.

Probably won’t have a look here any more.
This whole industry is just sucked into Greed, Ego and Envy any way.
Nothing interesting in get rich quick schemes everywhere.

Abstract

Encrypted mempools hide transaction contents before inclusion, but they generally do not hide identity-critical admission metadata. In many designs, the admission path still exposes fields such as sender and nonce—or a public envelope signer that serves the same practical role—because these fields are what make dynamic mempool checks possible.

If sender and nonce are hidden without replacement, nodes lose the information needed to evaluate nonce and solvency. Admission becomes blind.

GhostPool replaces public (sender, nonce) admission checks with:

• a root-bound zero-knowledge admission proof for encrypted transactions,
• a ciphertext-to-payload commitment binding,
• and a shared nullifier namespace spanning encrypted and plaintext transactions.

The main construction is stated in the standard account model, where nonce stability gives the clearest correctness argument and the protocol naturally supports the head-of-line nonce. GhostPool leaves network-layer origin and economic metadata such as gas limits and fee parameters unchanged. It is an admission-layer protocol that composes with encrypted-mempool designs such as Shutter-style threshold encryption, multiparty delay encryption, batched threshold encryption for pending-transaction privacy, and recent public-envelope encrypted mempool proposals.

1. Introduction

1.1 Encrypted mempools hide payloads, not admission metadata

Encrypted mempools are now a broad design space rather than a single proposal. Examples include threshold-encrypted mempools, public-envelope encrypted mempools, and academic proposals based on multiparty delay encryption or batched threshold encryption.

Across these approaches, the main objective is usually to hide transaction contents until a protocol-defined decryption point. What generally remains exposed is the admission interface and, with it, identity-critical metadata such as sender and nonce.

That is the layer GhostPool targets.

As long as sender and nonce remain visible, encrypted mempools preserve dynamic admission checks—but also preserve account-level leakage. The current universal enshrined encrypted mempool proposal, for example, keeps a public envelope with its own fee-payment and nonce semantics and does not target user privacy. GhostPool addresses the complementary problem: private admission.

1.2 Validation blindness

A node receiving a transaction must check at least four things:

1. Format: envelope structure, field sizes, valid encoding
2. Authorization: valid signature from the sender
3. Nonce: the transaction targets the sender’s next usable nonce
4. Solvency: the account can cover the transaction’s worst-case cost

The first two are static. The latter two are dynamic: they require an account lookup keyed by the sender.

This creates a direct tradeoff:

• If sender and nonce stay visible, nodes preserve dynamic admission checks, but encrypted submissions still leak account-level activity.
• If sender and nonce are hidden without replacement, nodes can no longer perform nonce or solvency checks at all.

I refer to this failure mode as validation blindness.

This is distinct from the better-known mempool DoS literature, which studies admission, eviction, and locking attacks under already-visible transaction identities and prices. GhostPool’s problem is simpler and more fundamental: under private admission, the dynamic checks themselves disappear unless they are cryptographically replaced.

1.3 Protocol statement

GhostPool resolves validation blindness for private head-of-line admission by replacing public (sender, nonce) checks with:

• a root-bound zero-knowledge admission proof,
• a ciphertext binding through a public payload commitment,
• and a shared nullifier namespace that tracks nonce-slot consumption across both encrypted and plaintext transactions.

The protocol is first stated in the standard account model, where the nonce-stability argument is simplest and the tracked slot is the native account nonce. Within that setting, sender and nonce can be removed from the cleartext encrypted-admission path without reintroducing validation blindness.

The protocol deliberately focuses on:

• the head-of-line nonce,
• encrypted-mempool formats that can authenticate a payload commitment for ciphertexts,
• and public fee/gas metadata.

Section 7 discusses broader account models and the remaining metadata that GhostPool does not hide.

2. GhostPool at a glance

For the standard account model, GhostPool relies on a simple monotonicity fact:

If an account’s nonce has not changed since a proof was generated, then its balance could only have stayed the same or increased.

A solvency proof therefore does not need to be regenerated on every new block. It only needs to remain true that the relevant nonce slot has not been consumed.

GhostPool turns the stale-proof problem into a slot-tracking problem by assigning each (account, nonce) pair a deterministic nullifier without exposing the account in the encrypted admission path.

Figure 1. GhostPool replaces public (sender, nonce) admission checks with a root-bound proof plus a slot nullifier, removing sender/nonce from the encrypted admission path without reintroducing validation blindness.

3. Protocol

3.1 Envelope format

A submitted encrypted transaction takes the form of an envelope:

where:

• ciphertext is the encrypted payload,
• payload_commitment is a public commitment to the hidden payload,
• N is the canonical nullifier,
• \pi_{\text{leaf}} is the leaf proof,
• ref_root is the exact state root the proof was generated against,
• public_meta contains non-private transport and pool-management fields.

In the base construction, public_meta also contains the execution-relevant fields intentionally left in the clear for packing and ordering, such as:

• gas_limit,
• max_fee_per_gas,
• max_priority_fee_per_gas,
• and any expiry or routing hints.

GhostPool does not require the latest state root. It requires an exact root and a bounded freshness rule.

3.2 Leaf proof

The leaf proof \pi_{\text{leaf}} attests to the following without revealing sender or nonce:

1. Authorization: the hidden transaction is signed by a valid key corresponding to the hidden account.
2. Nonce validity: the account’s on-chain nonce equals the hidden nonce used in the transaction.
3. Solvency: the account’s balance covers the transaction’s declared worst-case execution cost, i.e. its value plus a fee bound derived from the public gas and fee fields.
4. Public-field consistency: any execution-relevant fields intentionally kept in the clear match the corresponding fields of the hidden transaction.
5. Nullifier binding: the public nullifier N is correctly derived from the same hidden key and hidden nonce.
6. Payload commitment binding: the hidden transaction commits to the public payload_commitment.
7. Anchor binding: all state witnesses are proven against the exact ref_root.

The proof establishes authorization, nonce validity, solvency, and slot binding against a fixed state root. Freshness and current includability under the latest base fee remain mempool policy decisions evaluated outside the proof.

For Ethereum-style fee semantics, the natural proof statement is a worst-case cost bound using the transaction’s declared fee bound, rather than a claim about current includability at the latest base fee.

3.3 Ciphertext binding

A valid proof is not sufficient by itself. Nodes must also know that the proof refers to the same hidden transaction as the public ciphertext.

GhostPool splits this binding into two parts:

• inside the proof: hidden transaction \rightarrow payload_commitment
• inside the encryption layer: ciphertext \rightarrow payload_commitment

The enclosing encrypted-mempool format must therefore authenticate a payload commitment for ciphertexts—for example through associated data, authenticated wrapping, or an equivalent mechanism. GhostPool does not require one specific encryption scheme. It requires this authenticated commitment hook.

This removes the attack where a user proves validity for one hidden transaction while attaching ciphertext for another.

3.4 Nullifier

Each nonce slot is assigned a canonical nullifier:

where sk is the sender secret key and address = \mathsf{Addr}(pk).

GhostPool does not use a plain hash such as H(address \,\|\, nonce), or any deterministic public artifact that an observer can recompute directly from visible state. The design target is slot uniqueness without public enumerability from visible state alone.

The nullifier serves four purposes:

• slot uniqueness: the same (account, nonce) yields the same N,
• unforgeability: without the sender secret key, third parties cannot produce a valid nullifier for that slot,
• non-enumerability from public state: guessing (address, nonce) is not enough to test a guess against an observed N,
• shared slot semantics: the same slot key is used across encrypted and plaintext flows.

At an intuitive level, an observer can derive B_{\mathrm{slot}} from public data but cannot test whether an observed N belongs to that slot without either the sender secret key or a valid public certificate.

HashToCurve should be instantiated as a constant-time hash-to-curve or encode-to-curve method with proper domain separation; see RFC 9380. The protocol-level nullifier is the canonical encoding of the group element N. Implementations may additionally hash it for local indexing.

This construction is adjacent to deterministic public-artifact designs such as PLUME, but GhostPool uses the nullifier specifically as a nonce-slot key for mempool admission.

3.5 Plaintext path

GhostPool does not force plaintext transactions into the encrypted admission circuit.

A plaintext transaction continues to use the ordinary mempool path with visible sender, nonce, and fee fields. The only additional requirement is that it also carry:

• the canonical nullifier N for its visible nonce slot, and
• a lightweight slot certificate \pi_{\text{slot}} proving:

equivalently,

The verifier recovers pk from the ordinary transaction signature, computes B_{\mathrm{slot}} from (address, nonce), and checks \pi_{\text{slot}} as a DLEQ / Chaum–Pedersen relation. This is much lighter than a full leaf proof and uses standard machinery; see RFC 9497.

This is the public certification path for the same nullifier object that encrypted transactions prove inside the leaf circuit. It also gives plaintext and encrypted transactions one shared slot namespace.

3.6 Admission pipeline

When a node receives an encrypted envelope E, it runs checks from cheapest to most expensive:

1. Envelope sanity: valid structure, required fields present, size caps respected.
2. Nullifier prefilter: check whether N conflicts with an existing pool entry.
3. Anchor freshness: verify ref_root is canonical and recent enough.
4. Ciphertext commitment check: verify that the ciphertext authenticates the declared payload_commitment.
5. Leaf proof verification: verify \pi_{\text{leaf}}.
6. Replacement finalization: if policy allows it, replace the older entry for the same nullifier.

The ordering is chosen to reject malformed or stale objects before proof verification.

4. Shared nullifier namespace

GhostPool’s architectural core is that encrypted and plaintext transactions take different admission paths but converge on one shared slot namespace.

Figure 2. Encrypted and plaintext transactions use different admission checks but converge on one shared nullifier namespace and one spent-nullifier view.

This shared namespace is what makes the nonce-stability argument usable in practice. A pending encrypted proof remains live as long as:

• its reference root is still fresh enough, and
• its nullifier has not entered the spent set.

In deployment, plaintext nullifier artifacts must be available across the reorg horizon so that the spent set remains reconstructible. How those artifacts are persisted is a transport or format choice. The admission logic itself is unchanged.

5. Pool policy

5.1 Requirement

Every transaction that enters the mempool—encrypted or plaintext—must carry a canonical nullifier:

• for encrypted transactions, nullifier correctness is established inside \pi_{\text{leaf}};
• for plaintext transactions, nullifier correctness is established by the ordinary signature path plus \pi_{\text{slot}}.

GhostPool therefore relies on a single slot-tracking invariant:

Any event capable of consuming the tracked nonce slot must be represented in the same slot-consumption view.

In the base construction, this is achieved directly because encrypted and plaintext transactions both participate in the shared nullifier namespace.

5.2 Freshness window

GhostPool accepts an encrypted proof only if its ref_root remains within the last W canonical block roots.

Conceptually, encrypted entries remain pending while:

• ref_root is within the window,
• and N \notin \texttt{spent}.

Expiry applies only to encrypted entries. Plaintext entries do not carry root-bound GhostPool leaf proofs.

5.3 Replacement

Replacement is defined over the shared nullifier slot, not over visible sender fields.

If two pool entries carry the same nullifier, they compete for the same underlying (account, nonce) slot. A new entry may replace an older one if local policy allows it.

GhostPool standardizes slot equality through the nullifier. It does not standardize one universal fee-bump rule across plaintext and encrypted flows.

5.4 Reorgs

When the chain reorgs, included transactions in reverted blocks are no longer final, so their nullifiers must move back out of the spent set.

Nodes maintain a per-block nullifier update log. On reorg:

1. replay reverted blocks in reverse,
2. apply new canonical blocks forward,
3. re-evaluate pending encrypted entries whose freshness or spentness changed.

6. Aggregation and propagation

Recursive STARK aggregation is the natural propagation layer for GhostPool when leaf proofs are large.

If encrypted envelopes were propagated naively together with their leaf proofs, both proof bandwidth and network-wide verification work would grow quickly with throughput. The recursive propagation pattern proposed in Recursive-STARK-based bandwidth-efficient mempool addresses this setting: nodes verify fresh objects once, then periodically publish recursive proofs over the valid objects they currently know about.

GhostPool uses that pattern on the encrypted path.

A node that first receives an encrypted envelope verifies its leaf proof once. Then, at every tick, it generates a recursive STARK covering all still-valid encrypted envelopes in its local view and forwards that recursive proof to peers together with any encrypted envelopes that the peer has not yet seen, but without their original leaf proofs.

The recursive proof’s public input is a set descriptor for the covered encrypted envelopes—for example, a bitfield or a list of envelope hashes. The recursive circuit then takes:

• zero or more encrypted envelopes with their leaf proofs,
• zero or more other recursive STARKs of the same type,
• and a discard set,

and proves the validity of the union of all directly supplied envelopes and all recursively imported sets, minus the envelopes that are discarded.

This “union minus discard” structure matches GhostPool well. It allows the aggregate to evolve with the mempool:

• envelopes whose ref_root has fallen outside the freshness window can be discarded,
• envelopes whose nullifier has entered the spent set can be discarded,
• envelopes replaced by a newer transaction for the same slot can be discarded.

If one node currently has {Tx1, Tx2, Tx3} and another has {Tx2, Tx3, Tx4}, their recursive proofs can be merged into a larger proof covering the union {Tx1, Tx2, Tx3, Tx4}. A builder that receives multiple partially overlapping aggregates can combine them in exactly the same way.

Figure 3. Recursive aggregation merges overlapping encrypted transaction sets into a single proof over their union, with invalidated objects removed through the discard set.

This gives GhostPool two concrete advantages on the encrypted path.

First, it reduces network-wide verification work. A fresh encrypted envelope still needs to be checked once when it first enters the network, but downstream nodes increasingly verify recursive coverage proofs over sets of envelopes rather than re-verifying every leaf proof independently.

Second, it reduces proof propagation overhead. Each encrypted envelope body still needs to propagate through the network, but proof traffic becomes tick-based per peer rather than per envelope. That is the main bandwidth gain of the recursive construction: object data scales with the number of envelopes, while proof overhead scales with the tick rate and peer count.

7. Discussion

7.1 Broader account models

The nonce-stability argument is simplest in the standard account model because outgoing transactions are the mechanism that both consume nonce and reduce balance.

EIP-7702 shows why that simplicity does not survive unchanged once delegated execution paths are introduced. In those settings, native balance can no longer be reasoned about from nonce stability alone, and the tracked slot may be consumed through authorization paths that are not ordinary GhostPool-tracked transactions.

That changes the object that the protocol needs to track. One natural recovery direction is to replace native-balance solvency with an escrow-style solvency object and to broaden slot-consumption tracking accordingly. The admission architecture itself does not change.

7.2 Transaction chains

The base protocol supports only the head-of-line nonce.

If a user wants to queue private transactions for nonces n, n+1, n+2, the later ones are not independently provable against current on-chain state. A naive dependency pointer from n+1 to the nullifier of n would reintroduce linkage.

Private queued transaction chains therefore need another layer, most likely a set-membership or dependency proof over admissible parent nullifiers.

7.3 Economic metadata and fingerprinting

GhostPool hides sender and nonce in the encrypted admission path, but economic metadata remains a meaningful privacy risk. Fee parameters and gas limits can act as strong statistical fingerprints, and they become even more revealing when combined with other observable features such as ciphertext size, timing, and application-specific behavior.

Hiding economic metadata is substantially harder because builders need it for ordering and packing. More importantly, standard cryptographic ideas like ORE or HE do not solve this in a public submission setting. If anyone can produce encryptions or interact with the comparison interface, then small-domain metadata can still be recovered by probing: encrypt guesses, compare outcomes, and infer the underlying value.

Designing fee and gas confidentiality that still works with public submission, builder incentives, and block construction remains an open problem. GhostPool treats it as separate work.

8. Conclusion

Encrypted mempools already have credible designs for hiding transaction contents until inclusion order is fixed. What they generally do not yet provide is a private way to decide whether an encrypted transaction is admissible in the first place, without reintroducing validation blindness.

GhostPool fills that gap.

Within its base scope—head-of-line nonce admission in the standard account model, under encrypted formats that authenticate a payload commitment—GhostPool replaces public (sender, nonce) admission checks with a root-bound ZK proof plus a shared nullifier namespace spanning encrypted and plaintext transactions. This removes identity-critical admission metadata from the cleartext encrypted-admission path while preserving semantic admission checks.

Appendix

Everything below is optional. It makes the proposal easier to implement and review, but can be removed without changing the core narrative.

Appendix A. Notation and parameters

• h: current head block number observed by the node
• W: freshness window (in blocks)
• \mathcal{R}_h: the set of canonical block roots in the window, e.g. \{\texttt{root}[h-W], \dots, \texttt{root}[h]\}
• ref_root: exact root used inside \pi_{\text{leaf}}
• payload_commitment: public commitment to the hidden transaction payload
• sk, pk: signing secret/public key
• address = \mathsf{Addr}(pk): account address
• nonce: account nonce
• \mathsf{HashToCurve}(\cdot): domain-separated hash-to-curve or encode-to-curve function

Recommended domain separation inputs for B_{\mathrm{slot}}:

• protocol domain string, e.g. "ghostpool/nullifier/v1"
• chainid
• address
• nonce

Appendix B. Informal proof statements

B.1 Encrypted leaf proof relation

Public inputs

• payload_commitment
• N
• ref_root
• public fee and packing fields from public_meta

Witness

• sk, pk, address, nonce
• hidden transaction fields (to, value, gas_limit, max_fee_per_gas, max_priority_fee_per_gas, calldata, etc.)
• signature material
• account and state witnesses under ref_root

Statement

The prover shows existence of a witness such that:

1. address = \mathsf{Addr}(pk)
2. the hidden transaction signature verifies under pk
3. \mathsf{nonce}(address;\ ref\_root) = nonce
4. \mathsf{balance}(address;\ ref\_root) \ge \texttt{worst_case_cost(hidden_tx)}
5. the public gas and fee fields equal the corresponding fields of the hidden transaction
6. payload_commitment = Commit(hidden_tx)
7. B_{\mathrm{slot}} = \mathsf{HashToCurve}(\texttt{dst} | \texttt{chainid} | address | nonce)
8. N = sk \cdot B_{\mathrm{slot}}

B.2 Plaintext slot certificate relation

Public inputs

• pk (recovered from the ordinary transaction signature)
• B_{\mathrm{slot}} (computed from visible (address, nonce))
• N

Witness

• sk

Statement

Prove:

This is a standard DLEQ / Chaum–Pedersen statement; see RFC 9497.

Appendix C. Slot certificate details

A standard Chaum–Pedersen proof of equality of discrete logs over a prime-order group works as follows:

• Prover knows sk such that pk = sk \cdot G and N = sk \cdot B.
• Prover samples random r and computes commitments:
  a_1 = r \cdot G,\qquad a_2 = r \cdot B
• Verifier supplies challenge c.
• Prover responds:
  z = r + c \cdot sk
• Verifier checks:
  z \cdot G = a_1 + c \cdot pk
  and
  z \cdot B = a_2 + c \cdot N

A Fiat–Shamir transform makes this non-interactive.

Appendix D. Practical notes

• A natural starting point is W \in [32, 128] blocks.

• Storage overhead is mainly:

  • pending_map, bounded by mempool size
  • spent_set, bounded by the recent chain horizon tracked for recovery and reorg safety

• The most expensive engineering point is likely the encrypted leaf proof, especially if the implementation keeps secp256k1-style authorization relations inside the proof system.

• Wallet support may need to expose either:

  • direct nullifier-generation support,
  • or a generic “prove slot certificate” path compatible with the chosen DLEQ implementation.

Introduction

The SSZ Engine API spec proposes replacing JSON-RPC encoding with binary SSZ (Simple Serialize) for the Ethereum Engine API — the interface between consensus layer (CL) and execution layer (EL) clients.

Today, every message between CL and EL is JSON-encoded: every byte of every transaction, blob, and withdrawal is hex-encoded and wrapped in JSON. For small payloads like forkchoiceUpdated, this is fine. For engine_getPayloadV5 — which returns the full ExecutionPayload plus BlobsBundle — the encoding overhead becomes a meaningful contributor to block propagation latency.

Transport

Both transports coexist on the same Engine API port (default 8551):

With PeerDAS and the Fulu fork pushing blob counts from 6 to 72 (target 48), payload sizes through the Engine API will grow significantly. This post presents encoding benchmarks from a live Kurtosis devnet running three EL implementations with SSZ transport instrumentation.

Methodology

Devnet Setup

A Kurtosis devnet was deployed with 12 EL+CL pairs — every combination of three EL clients (Geth, Erigon, Nethermind) and four CL clients (Prysm, Lighthouse, Teku, Lodestar) — all running custom Docker images with SSZ transport support and encoding instrumentation.

Network parameters: 6-second slots, Fulu fork at genesis, 72 max blobs, 48 target blobs, 32 validators per node. Transaction load generated with spamoor at 200 EOA tx/s plus blob transactions (6 sidecars each).

Measurement

Each EL was instrumented to encode every GetPayloadV5 response in both SSZ and JSON, logging the size and time for each:

GetPayloadV5 encoding: SSZ=9,930,470 bytes in 19,700 us | JSON=19,906,846 bytes in 59,531 us | ratio=2.0x size, 3.0x time blobs=72

Results

getPayload Encoding Time at 72 Blobs (Fulu Max)

Worst observed encoding times per EL+CL pair at 72 blobs (~9.9 MB SSZ / ~19.9 MB JSON) after 17 hours of continuous devnet operation:

These are worst-case measurements (highest observed encoding times) across a 17-hour run — real-world typical times are lower, but worst-case latency is what matters for block propagation deadlines.

Key observations:

• SSZ encoding stays under 36 ms across all 12 pairs in the worst case — consistently fast regardless of implementation.
• JSON worst-case encoding ranges from 63 ms to 446 ms — highly variable across EL implementations.
• Geth has the highest JSON overhead (180–446 ms), making the SSZ speedup most dramatic there (7.5–12.8×).
• Nethermind worst-case JSON encoding ranges from 91–120 ms, with SSZ 8.6–20.6× faster.
• Erigon sits in between (63–101 ms JSON), with 3.3–12.7× SSZ speedup.

Wire Size

Consistently across all blob-carrying payloads:

The 2× ratio is structural: JSON hex-encoding doubles every byte (0xff → "0xff" = 4 chars).

Other Engine API Methods

Not all Engine API calls benefit equally from SSZ. The three methods called every slot are forkchoiceUpdated, newPayload, and getPayload. Here is how they compare in terms of request/response sizes and encoding times (all measurements from the Erigon + Prysm pair):

Message sizes:

Encoding times:

forkchoiceUpdated is tiny in both directions — under 200 bytes. The overhead difference between SSZ and JSON is negligible at this scale.

newPayload carries the ExecutionPayload (transactions, withdrawals) but not blobs — those propagate via the gossip layer. Even on a high-throughput mainnet block (~1,500 transactions), newPayload would be roughly 200–400 KB in SSZ. At these sizes, the encoding overhead is well under 1 ms regardless of format.

getPayload is the outlier. It returns the full ExecutionPayload plus the BlobsBundle (commitments, proofs, and all blob data). At 72 blobs, this single response is 9.9 MB in SSZ (19.9 MB in JSON) — orders of magnitude larger than any other Engine API message. This is where encoding overhead becomes measurable in milliseconds, and why the SSZ transport spec focuses its impact here.

Conclusion

The Engine API’s getPayload response is the largest message exchanged between CL and EL every slot. At 72 blobs, it carries ~9.9 MB of data in SSZ (19.9 MB in JSON) and this single encoding step can take anywhere from 63 ms to 446 ms in JSON depending on the client, eating directly into the block propagation budget.

SSZ encoding of the same payload takes 5–36 ms across all 12 tested EL+CL pairs. The speedup ranges from 3× to 20× depending on the pair, with the worst-case SSZ time still well below the best-case JSON time for most implementations.

The wire size reduction is a consistent 2× across all payload sizes — a structural consequence of eliminating hex encoding. For a 72-blob block, that’s ~10 MB saved per slot on the CL↔EL link.

The cost of adoption is low: both transports coexist on the same port, JSON-RPC remains the default, and SSZ is opt-in via content-type negotiation. Implementations already exist for Geth, Erigon, Nethermind, Prysm, Lighthouse, Teku, and Lodestar.

Reproduction

Kurtosis devnet config

participants:
  # 3 ELs × 4 CLs = 12 pairs
  - el_type: geth
    cl_type: prysm
    supernode: true
    validator_count: 32
  - el_type: geth
    cl_type: lodestar
    supernode: true
    validator_count: 32
  - el_type: geth
    cl_type: teku
    supernode: true
    validator_count: 32
  - el_type: geth
    cl_type: lighthouse
    supernode: true
    validator_count: 32
  - el_type: erigon
    cl_type: prysm
    supernode: true
    validator_count: 32
  - el_type: erigon
    cl_type: lodestar
    supernode: true
    validator_count: 32
  - el_type: erigon
    cl_type: teku
    supernode: true
    validator_count: 32
  - el_type: erigon
    cl_type: lighthouse
    supernode: true
    validator_count: 32
  - el_type: nethermind
    cl_type: prysm
    supernode: true
    validator_count: 32
  - el_type: nethermind
    cl_type: lodestar
    supernode: true
    validator_count: 32
  - el_type: nethermind
    cl_type: teku
    supernode: true
    validator_count: 32
  - el_type: nethermind
    cl_type: lighthouse
    supernode: true
    validator_count: 32
network_params:
  seconds_per_slot: 6
  fulu_fork_epoch: 0
  bpo_1_max_blobs: 72
  bpo_1_target_blobs: 48
additional_services:
  - spamoor
spamoor_params:
  spammers:
    - scenario: eoatx
      config:
        throughput: 200
        max_pending: 400
        max_wallets: 200
    - scenario: blob-combined
      config:
        throughput: 40
        max_pending: 80
        sidecars: 6

kurtosis run github.com/ethpandaops/ethereum-package --args-file ssz_bench_net.yml

Implementations

• Spec: feat: add ssz to engine api by barnabasbusa · Pull Request #764 · ethereum/execution-apis · GitHub
• Geth: eth/catalyst: add SSZ-encoded engine API by Giulio2002 · Pull Request #33926 · ethereum/go-ethereum · GitHub
• Erigon: SSZ-REST Engine API transport (EL server) by Giulio2002 · Pull Request #19670 · erigontech/erigon · GitHub
• Nethermind: feat: SSZ-REST Engine API transport by Giulio2002 · Pull Request #10728 · NethermindEth/nethermind · GitHub
• Prysm: SSZ-REST Engine API Transport for Prysm by Giulio2002 · Pull Request #16447 · OffchainLabs/prysm · GitHub
• Lighthouse: SSZ-REST Engine API transport (CL client) by Giulio2002 · Pull Request #8937 · sigp/lighthouse · GitHub
• Teku: SSZ-REST Engine API transport (CL client) by Giulio2002 · Pull Request #10455 · Consensys/teku · GitHub
• Lodestar: feat: SSZ-REST Engine API transport by Giulio2002 · Pull Request #8994 · ChainSafe/lodestar · GitHub

TL;DR

• A deferred-quotient row of the form L = D + pQ over \mathbb{F}_r is not, by itself, an integer-division statement.

• If Q is left unbounded, that row can be algebraically vacuous in the outer field.

• For one concrete BN254/M31 wrapper family, quotient range binding + canonical residue binding + no-wrap bounds restore exact rowwise \mathbb{Z} semantics.

• In a bounded shared-input Halo2 comparison, the repaired construction remains consistently faster and much smaller in RSS than an explicit bit-decomposition baseline.

The issue

The core surface is the deferred-quotient row equation

By itself, that field equation is not an integer statement. If p is invertible in the outer field and Q is left unbounded, the prover can set

and satisfy the row relation in \mathbb{F}_r without establishing Euclidean division semantics over \mathbb{Z}.

This post is about that exactness gap and a lightweight algebraic repair for one concrete BN254/M31 wrapper family.

Scope

The claim here is:

1. the deferred-quotient equality can be algebraically vacuous at the outer-field level;

2. to read L = D + pQ as an exact integer identity, explicit missing premises are needed;

3. for a concrete BN254/M31 wrapper family, those premises can be enforced with a lightweight algebraic repair.

The benchmark claim follows the same boundary:

• this is a bounded instantiated-family comparison,

• not a claim of full-domain semantic equivalence across every wrapper realization.

The theorem-level statement

For the field equality to lift to an exact identity in \mathbb{Z}, the note requires:

• quotient range binding,

• canonical residue binding,

• no-wrap bounds.

Under those conditions, a satisfied row relation in \mathbb{F}_r lifts to

and on designated residue rows the residue/quotient pair becomes the unique Euclidean remainder/quotient.

So the manuscript proves a restricted-model rowwise exactness theorem for a concrete BN254 family set with one-limb 31/66-bit quotient classes. It is a theorem-level result about algebraic exactness. Backend transcript extraction, PCS-level soundness, Fiat-Shamir closure, and wrapper-level parity are separate questions and not the subject of this note.

What the repair actually adds

At a high level, the repair adds three things to the deferred-quotient rows:

1. Quotient binding. The quotient witness is forced into the intended small canonical class, so the generic outer-field witness Q = p^{-1}(L-D) is no longer admissible.

2. Canonical residue binding. On designated residue rows, the residue is bound to its canonical representative, so the row is no longer compatible with arbitrary field-level aliases of the same congruence class.

3. No-wrap control. Family-wise no-wrap bounds ensure that once both sides are lifted to integers, the satisfied field equality is forced to be the exact integer identity rather than a wrapped congruence.

Concretely, the benchmarked repair construction binds both the quotient cells and the residue-style cells with a lookup-heavy pattern rather than a full explicit bit decomposition. In the current instantiation, the quotient side is split into small lookup-bound chunks instead of a wide boolean decomposition, and the residue side replaces a 31-boolean style binding with a small number of table lookups plus a non-equality style gate such as (x-p)\nu_x = 1; the no-wrap audit then justifies the integer lift. That is the main reason it is interesting to compare against the A_secure baseline in the first place.

Benchmark evidence

After the manuscript draft, I ran a follow-up Halo2 benchmark package comparing:

• A_secure: an explicit bit-decomposition baseline,

• B_note: the algebraic repair construction.

Both arms run through the same Halo2 proof path, the same transcript family, the same fixed-k contract, and the same shared input profiles.

Shared-input repeated reruns at k = 17

For the parity-facing reruns at k_\mathrm{run}=17, I measured:

• \mathrm{scale}=1,4,8,16,32,

• both boundary and standard,

• \mathrm{repeats}=3.

Across those points:

• B_note prove-time ratio stayed in the range 0.821 to 0.884,

• B_note verify-time ratio stayed in the range 0.631 to 0.716,

• B_note RSS stayed at about 0.285 to 0.286 of A_secure.

So within the current fixed-k, shared-input benchmark regime, B_note shows a fairly consistent proving-time and memory advantage.

First k jump and post-jump repeated check

I also checked where the current public harness first stops fitting inside k = 17.

For this benchmark contract:

• \mathrm{scale}=4519 still fits in k_\min=17,

• \mathrm{scale}=4520 is the first point that forces k_\min=18.

This is a property of the current harness.

Then I ran the first post-jump repeated validation at:

• \mathrm{scale}=4520,

• k_\mathrm{run}=18,

• \mathrm{input\_profile}=\mathrm{boundary},

• \mathrm{repeats}=3.

That produced:

• A_secure prove ~32.37 s,

• B_note prove ~26.71 s,

• B/A prove ~0.825,

• A RSS ~6.30 GB,

• B RSS ~1.79 GB,

• B/A RSS ~0.285.

So the advantage persists beyond the first k jump as well, at least for this minimum repeated post-jump check.

Links

• manuscript PDF : https://github.com/junbyjun1238/zk2-bench-b1-lite/releases/download/v0.1.0/deferred-quotient-vacuity-in-bn254-wrappers-a-repair-note-on-algebraic-exactness.pdf
• public benchmark package : https://github.com/junbyjun1238/zk2-bench-b1-lite/tree/v0.1.0/post_manuscript_fullbench
• release snapshot: https://github.com/junbyjun1238/zk2-bench-b1-lite/releases/tag/v0.1.0
• Zenodo archive (DOI) : https://doi.org/10.5281/zenodo.18910795

Is there a way to lift both G_1 and G_2/G_12 to an hyperelliptic curve cover where the final exponentiation isn t required?

Or are there some cases where the right exponentiation inversion is easy as highlighted by some papers that where using faults for performing Miller inversion (which was usefull when a secret was to be hidden).

One additional nuance for the broader Rifle attack family: affecting the eventual fork-choice outcome is not only about weight manipulation. In Rifle executions, the attacker’s block b_j does not need to have higher GHOST weight; instead, the Byzantine strategy uses a delayed-release / justification sequence to make the honest branch fall outside the 2-epoch pruning-protection window (so it is no longer an eligible candidate). Once the honest branch is filtered out by the fork-choice eligibility rule, the attacker branch can become the new canonical branch even without winning a pure weight comparison.

So in this extension, the withheld attestations remain slash-safe and protocol-valid, with the only adversarial capability being control over dissemination timing rather than equivocation. In other words, colluding validators still sign at most one attestation per duty window, but selectively delay publication.

Your point about the [t−32,t−3][t-32, t-3][t−32,t−3] votes is also helpful. Since those votes sit on the shared prefix, they contribute essentially symmetrically to both candidate branches and therefore do not directly shift fork choice. Their primary effect is instead on the justification timeline: by delaying the public visibility of those attestations, the attacker can prevent cpe−1c_{pe-1}cpe−1​ from becoming justifiable on schedule, thereby widening the inactivation window.

So the actual fork-choice asymmetry in this setup seems to arise from the boundary-local behavior near the fork itself (e.g., the sly-* region around slot ttt), where the HLMD-GHOST weight comparison becomes branch-differentiating.

More generally, it seems useful to distinguish two roles delayed publication can play in PoS systems:

1. Justification timing manipulation, where withheld votes primarily affect checkpoint justification and finality timing but do not directly alter fork-choice weights (as in the [t−32,t−3][t-32,t-3][t−32,t−3] batch here), and

2. Fork-choice weight manipulation, where withheld votes point into different descendants across competing branches and therefore directly influence HLMD-GHOST head selection once revealed.

Framing the mechanism this way helped clarify the role the withheld attestations play in the extension. Thanks again for the detailed explanation.

In that extension, the withheld attestations are meant to remain slash-safe and protocol-valid when eventually revealed, i.e., no equivocation, only delayed publication. In other words, colluding validators still produce at most one attestation per assigned duty window, and “withholding” is purely a dissemination choice (private routing + later public release), not signing conflicting attestations.

That said, I would sharpen one point: in this particular extension, the withheld votes from ([t-32,t-3]) are pre-fork in the setup, so they do not materially shift the head among candidate branches by themselves — because they contribute essentially symmetrically to both branches (they sit on the shared prefix). Their primary role here is to strengthen the justification-delay / inactivation effect by keeping cp_{e-1} from becoming justifiable on time in the public view (thus widening the inactivation window), while the actual head shift is driven by the boundary-local asymmetry engineered around the fork window (e.g., the sly-* boundary region around slot (t) and the associated HLMD-GHOST weight comparison).

More generally, delayed publication does become a direct head-shifting lever when the attacker withholds votes whose valid vote points into different descendants on the competing branches (i.e., branch-differentiating weight). The ([t-32,t-3]) batch in this extension is mainly about delaying timely justification, not directly swinging head selection.