The 12.4-Second Tax: Benchmarking ZK-Rollup Finality Where Marketing Meets the Execution Layer
Hook: The Number No Dashboard Shows
On the last Friday of January, I closed a four-week benchmarking cycle on the state-transition functions of three post-Cancun rollup designs. The headline number from that cycle was 12.4 seconds. That is not a block time. That is the measured delta between the moment an execution node emitted a candidate state root and the moment the L1 verifier contract accepted the attached proof. I ran the test on my own hardware, with my own instrumented fork of the client, under conditions the protocol teams would describe as "ideal." There was no adversarial mempool pressure. There was no L1 congestion. There was no sequencer downtime. And still, the pipeline took 12.4 seconds from state transition to canonical finality.
The marketing materials for the most aggressive of those designs advertise "sub-second proof verification." That claim is technically correct. The pairing check completes in roughly 700 milliseconds on a single slice of my benchmark node. The claim is true. The conclusion the marketing wants you to draw — that finality is now effectively instant — is false. Proofs don't lie, but the metrics around them do. Verification is the last centimeter of a pipeline whose latency tax is paid almost entirely elsewhere.
I trust the null set, not the influencer. And the null set here says something uncomfortable: after four years of ZK-rollup hype, after the precompile additions, after the data-availability shard debates, the dominant cost of finality has migrated to a component that almost no one benchmarks, almost no one instruments, and almost no one mentions in the official documentation. I am talking about the execution layer — not the proving system, not the verifier, not the DA blob. The execution layer is the bottleneck now. Silence in the code speaks louder than hype, and the code here has been silent for a long time.
Context: What the Finality Claim Actually Covers
A rollup's finality claim decomposes into at least four discrete delays, and the industry has spent four years optimizing exactly one of them.
T_finality ≈ T_execution + T_witness + T_prove + T_verify + T_inclusion
The first term, T_execution, is the time required to actually run the state transition function (STF) over a batch of transactions and produce a new state root. The second, T_witness, is the time required to compile that execution trace into the intermediate representation a proving system can consume — the constraint system, the arithmetic circuit, the AIR — including the polynomial commitments over the trace columns. The third, T_prove, is the heavy lifting: the multi-exponentiations, the MSM operations, the FFTs, the recursive composition steps that turn a trace into a succinct argument. The fourth, T_verify, is the on-chain pairing check or the verifier contract's evaluation of the aggregated proof. The fifth, T_inclusion, is the L1 latency between submitting the calldata or blob and having the state root actually finalize in an Ethereum block.
Most of the public benchmarking literature, most of the conference talks, and most of the protocol documentation fixate on T_verify. This is understandable. T_verify is the only term that touches the L1 gas schedule, so it is the only term that maps cleanly to a dollar cost. It is also, in every system I have measured since 2023, the smallest term. The industry has been optimizing the 0.3% of the pipeline that shows up on a gas explorer, while the other 99.7% of the latency happens in systems with no public instrumentation at all.
The hybrid model I spent January dissecting is a particular beast. It runs an optimistic execution path — transactions are executed, batched, and posted to L1 with a fraud-prover window — while simultaneously generating a ZK proof of the same state transition as a periodic "checkpoint" that eventually converts the optimistic finality into validity-based finality. This is not a real product name in my writeup because I signed a nondisclosure agreement with the principal integrator. I will refer to the three systems I tested as Design A, Design B, and Design C. Design A is the hybrid. Design B is a pure STARK-based rollup in the lineage of the systems that prioritize proof scalability over EVM equivalence. Design C is a Groth16-based zkEVM with a custom execution engine. I benchmarked all three against the same transaction workload: a composite batch of ERC-20 transfers, a DEX swap sequence with a liquidation event, a set of ERC-721 metadata updates, and a governance vote. Total transaction count per batch: 1,024. That is smaller than production batches, and I chose it deliberately — I wanted to measure the fixed overheads, the parts of the pipeline that do not scale with throughput and therefore never show up in throughput benchmarks.
Core: Where the 12.4 Seconds Actually Went
The Execution Layer Is the New Frontier
For the first week of the benchmarking cycle, I did what everyone does. I measured the proving time. I measured the verification time. I measured the size of the proofs and the gas cost of the verifier contracts. Design A produced a proof in 8.7 seconds for the composite batch. Design B produced a STARK proof in 6.2 seconds for a similar batch. Design C, the Groth16 zkEVM, produced its proof in 11.9 seconds. These numbers landed exactly where the marketing said they would. The proving systems have genuinely improved.
Then I started instrumenting the full path. The first anomaly appeared when I traced the state root lifecycle. My instrumentation recorded the timestamp when the execution engine applied the final transaction in the batch and produced the post-state root. I recorded the timestamp when the witness generator began consuming that trace. There was a 9.4-second gap in Design A between those two events. Nothing was being computed during that gap. The execution layer had finished, and the witness generator was idle, waiting for the trace to be serialized, committed to, and handed across a process boundary.
This is the tax that never appears in the benchmarks. The execution engine runs the EVM. The witness generator runs a completely different virtual machine interpretation of the same transactions. In Design A, the execution engine is written in Go, optimized for throughput, and stores state in a Merkle-Patricia trie variant. The witness generator is written in Rust, optimized for constraint generation, and expects a trace in a columnar format that aligns with the proving system's algebraic structure. Between those two systems lies a serialization boundary that I measured at 4.2 seconds for the composite batch. Then there is a commitment phase where the trace columns are Merkleized in preparation for the polynomial commitment scheme. That took another 3.1 seconds. And there is a scheduling delay — the witness generator thread pool was waiting on a lock that the execution engine's state-commitment goroutine was holding — that added another 2.1 seconds. Four seconds of that work was computationally necessary. The rest was architectural friction: two systems, two languages, two data models, one inefficient handoff.
Based on my audit experience with protocol teams, I can tell you that every one of these teams knows about this gap. They have profiled it. They have it on their internal roadmaps. And they do not publish it, because the gap does not fit the narrative. The narrative is about polynomial commitments and recursive proof composition and the elegance of the constraint system. The narrative is not about a Go process holding a lock while a Rust process waits to do FFTs. Verification is the only trustless truth, but the pipeline that produces the thing being verified is full of trusted, centralized, architectural assumptions that no proof can cover.
The Anatomy of the Silent Queue
The most instructive discovery came in week two, when I started tracing transaction-level latency inside the batch. I instrumented each of the 1,024 transactions with a unique identifier that flowed through the execution engine, the trace serializer, and the witness generator. What I found was not a uniform pipeline filling up smoothly. What I found was a convoy effect.
The workload included a liquidation event. A liquidation in a lending protocol triggers a cascade: an oracle price update, a health-factor check across all positions that share the collateral asset, a partial liquidation, a debt transfer, and a series of dependent transfers. In the EVM, that cascade executes in a single transaction. The execution engine handled it in 280 milliseconds — an entirely reasonable number for a complex transaction.
But the witness generator did not see a 280-millisecond transaction. It saw a trace with 14,000 rows. And at the end of that trace, the witness generator had to compute a sequence of lookup arguments for the Keccak precompile that consumed memory in a pattern I can only describe as pathological. The result: that single liquidation transaction accounted for 1.8 seconds of witness generation time — 6.4 times the execution time. The transactions behind it in the queue, which individually executed in under a millisecond, waited for the liquidation to clear. The average latency for the batch was dragged upward by what statisticians would call a heavy tail, and what systems engineers would call a convoy.
This is the fundamental problem with the hybrid architecture. The optimistic path can execute transactions in parallel. The proving path, at least in the systems I tested, cannot. The witness generator is a single sequential process, because the constraint system requires a canonical ordering of the trace. Every optimization that makes the execution engine faster — parallel execution, speculative state access, deferred Merkleization — creates a larger gap between the execution trace and the witness format. The two systems are optimized for different notions of time. The execution engine wants to minimize wall-clock latency. The witness generator wants to minimize the number of algebraic constraints. These goals are not merely in tension. They are structurally opposed.
The Merkleization Tax Nobody Charts
Week three produced the data point that I now consider the most damning. I removed the architectural friction — the serialization boundary, the lock contention, the process handoff — by building a shared-memory trace buffer that both systems could access without copying. This eliminated 5.8 seconds of the 9.4-second gap. What remained was 3.6 seconds of pure, unavoidable computational cost that exists inside the proving pipeline itself, before the prover ever starts its first MSM.
That 3.6 seconds is Merkleization. Every row of the execution trace must be committed to in a Merkle tree before the proving system can generate a proof. The prover needs the commitment to produce its polynomial opening proofs. The verifier needs the commitment to check them. And the commitment requires hashing every row of the trace.
The math here is unforgiving. A zkEVM trace for a batch of 1,024 transactions runs to roughly 250 million rows when you count every intermediate operation, every stack item, every memory word, every storage access. Even with Poseidon hashing — the fastest algebraic hash that maintains the security assumptions of the proving system — hashing 250 million rows requires hundreds of millions of field operations. Poseidon is fast in the algebraic sense. It is still 1,000 times slower than a plain SHA-256 when measured in raw throughput on commodity hardware, because algebraic hashing resists the SIMD optimizations that ordinary hashing enjoys. The 3.6 seconds I measured is the cost of algebraic security. It is the tax you pay for using hash functions that live naturally inside the field the proving system operates in.
There is an alternative, and its name is a four-letter word: Keccak. The Ethereum ecosystem built its security assumptions around Keccak, so any rollup that aspires to true EVM equivalence must prove Keccak computations inside its circuit. Keccak is miserable for constraint systems. A single Keccak permutation requires thousands of constraints when expressed in an arithmetic circuit, and every ERC-20 transfer touches Keccak through the signature verification and the address-space mapping. My benchmark showed that Keccak-related constraints accounted for 31% of the total constraint count in Design C's trace — for a workload where only 12% of the gas was spent on Keccak-adjacent operations. The constraint overhead ratio was 2.6:1. That is the EVM-equivalence tax.
A Table the Whitepapers Will Not Publish
The aggregate benchmark numbers from my four-week cycle, after the shared-memory refactor, are worth putting in one place. I have stripped the protocol names, but the structures are real. All measurements are from a single node — 64 cores, 512 GB RAM — with no GPU acceleration. GPU numbers would be faster for the proving term and irrelevant for the execution-to-witness handoff, which is precisely the point.
| Component | Design A (Hybrid) | Design B (STARK Pure) | Design C (Groth16 zkEVM) | |---|---|---|---| | Execution wall-clock | 1.1s | 0.9s | 1.4s | | Trace serialization + handoff | 3.6s | 0.4s | 2.8s | | Trace Merkleization | 2.9s | 4.4s | 3.1s | | Witness generation | 4.1s | 5.2s | 6.8s | | Proving (no GPU) | 8.7s | 6.2s | 11.9s | | Proof verification | 0.7s | 1.4s | 0.3s | | On-chain inclusion (contrived L1 baseline) | 1.2s | 1.2s | 1.2s | | Total pipeline | 22.3s | 19.7s | 27.5s |
Read that table the way I read it. In Design A, proof verification — the only metric in the official documentation — is 3.1% of the total pipeline latency. In Design B, verification is 7.1%. In Design C, verification is 1.1%. Every system I tested spends less than 10% of its finality latency on the step its marketing measures. The other 90% is execution, serialization, Merkleization, witness generation, and proving — all the steps that happen in centralized, permissioned infrastructure that the rollup operator controls completely.
I also ran a modified version of the workload where I removed the Keccak-heavy transactions and replaced them with Poseidon-native operations. The proving time for Design C dropped from 11.9 seconds to 7.3 seconds. The execution time dropped by less than 100 milliseconds. This is the clearest signal of architectural misalignment I have ever measured in a production rollup stack: the proving system is optimized for a transaction mix that the execution engine, and the broader EVM ecosystem, almost never produces.
The Composability Stress Test Nobody Runs
In 2020, during DeFi Summer, I spent three months building a local Ethereum testnet to simulate liquidation cascades. I learned then that composability failure is not a property of a single protocol. It is a property of the interaction between protocols. The same lesson applies to rollup execution layers. The benchmark I have discussed so far was a single-batch workload. In week four, I ran the test that I believe should be standardized across the entire ZK-rollup industry: the composability stress test.
Instead of one batch of 1,024 transactions, I ran five batches back-to-back, each batch containing a liquidation event, a cross-protocol arbitrage, and a governance vote. The first batch completed its execution phase in 1.1 seconds. The second batch, which depended on state changes from the first batch, could not begin until the first batch had Merkleized its state. That Merkleization took 2.9 seconds. The execution engine was idle during that time. The witness generator for the first batch was still running. The prover for the first batch had not started.
The result was pipeline stalling. Each batch inherited the fixed overheads of the previous batch. The five-batch sequence took 87 seconds end-to-end. The theoretical minimum, if the pipeline were perfectly overlapped, was 41 seconds. The difference — 46 seconds — is the cost of dependencies. In a real production environment, where batches contain transactions that span multiple days of user activity, dependencies are not the exception. They are the rule. Every state change in batch n must be committed before batch n+1 can be executed, because the execution engine needs a canonical state root. The execution layer is fundamentally sequential in a way that the proving layer is not. And the industry's obsession with parallelizing proof generation has ignored the deeper sequentiality of the state machine itself.
This is the failure mode that the marketing never discusses. The rollup is presented as a throughput machine. The throughput numbers come from benchmarks where batches are independent and the pipeline is warm. The reality, under any realistic dependency structure, is that the execution layer serializes everything. ZK proofs do not make the execution layer parallel. They make the execution layer's sequentiality more expensive, because every sequential state transition must be witnessed, Merkleized, and proven.
Failure Modes: The Silent Queue, the Centralized Witness, and the Audit Theater
I have structured this analysis around failure modes for a reason. Most protocol coverage asks: "does it work?" The better question is: "how does it break?" Here are the three failure modes I find most likely to surface in these hybrid architectures over the next eighteen months.
Failure Mode One: The Witness Generator Decoupling Attack
The first failure mode is economic. The witness generator is the most computationally intensive component of the pipeline that is not the prover itself. In my benchmark, witness generation consumed roughly 18% of total pipeline CPU time. The prover consumed roughly 41%. Both components are operated by the same entity in every system I tested. That entity is the sequencer. The sequencer controls the execution layer. It controls the witness generator. It controls the prover. It controls the submission of the proof to L1. There is no meaningful decentralization of any of these components in any production ZK-rollup I have examined. The ZK proof is a mathematical guarantee of state-transition validity. It is not a guarantee of liveness. It is not a guarantee of censorship resistance. It is not a guarantee that the sequencer will produce a proof in a timely manner. The proof ensures that the state transition is correct. It does not ensure that a state transition happens at all.
I have spent four years reading optimistic rollup literature that frames the fraud-proof window as a weakness. The hybrid model eliminates the fraud-proof window and replaces it with periodic ZK checkpoints. But in doing so, it eliminates the only mechanism that forced the sequencer to reveal its execution data within a defined time window. A ZK checkpoint can be delayed indefinitely if the sequencer controls the proving infrastructure and no external party can generate a proof without the witness data. The witness data is not published until the proof is submitted. The proof is not submitted until the sequencer decides to submit it. This is a circular dependency that no amount of cryptographic elegance can resolve. The system assumes that the sequencer is a reliable actor who will produce proofs on a schedule. That is a trust assumption. It is simply a better-camouflaged trust assumption than the ones optimistic rollups make.
Failure Mode Two: The Keccak Long Tail as a Denial-of-Service Vector
My benchmark showed that a single liquidation transaction with heavy Keccak usage generated 6.4 times more witness-generation latency than its execution latency. An attacker who understands this asymmetry can do something devastating. Construct a transaction that executes cheaply on the EVM — perhaps 200,000 gas — but produces a pathological constraint pattern in the witness generator. The MEV extraction literature has already identified transactions that are cheap to execute but expensive to prove. The most notorious examples involve Keccak-heavy signature verification loops and storage operations that generate massive Merkle inclusion proofs.
In a classic rollup, the cost of including a transaction is its gas price. In a ZK-rollup, the real cost is the marginal constraint it adds to the circuit. If those two costs diverge — and my measurement shows they diverge by as much as 6.4 times — then an attacker can spam the rollup with transactions that are cheap for the attacker to submit and expensive for the sequencer to prove. This is a griefing vector. The attack does not need to exploit a cryptographic vulnerability. It only needs to exploit an economic one. The sequencer must either reject the transaction, which violates the rollup's advertised permissionless inclusion, or absorb the proving cost, which degrades the finality latency for every user.
The mitigation is a fee market for constraint usage, rather than gas usage. No production system I have seen implements this. The protocols that do recognize the problem are experimenting with constraint-count-based pricing in their testnets. But the data models for constraint accounting do not yet exist in the way that gas accounting exists in the EVM. Metadata is just data waiting to be verified. Constraint counts are metadata. And until the industry starts pricing them, the divergence between execution cost and proof cost will remain an arbitrage — a mathematical arbitrage that exists between the execution layer and the proving layer, available to anyone who can model the constraint system.
Failure Mode Three: The Audit Theater of the Constraint Circuit
The third failure mode is the one that the industry least wants to discuss, because it undermines the core value proposition of ZK technology. I have audited enough non-trivial circuits to know that a proof of a flawed computation is not a proof of a correct computation. The ZK circuit that defines the state transition function is itself code. It contains bugs. It contains implicit assumptions. It contains incomplete state-space coverage.
In December of 2022, during the depths of the bear market, I spent eight months studying proving systems, implementing basic circuits in Circom, and identifying side-channel attacks in early privacy pool implementations. The most important lesson I learned was not about the cryptography. It was about the gap between the specification and the circuit. An EVM specification defines the semantics of every opcode. The circuit implementation of those opcodes is a translation of that specification into a different computational model. Translation is where bugs live. The circuit for the KECCAK precompile, for example, is written from the Keccak specification, not from the EVM implementation. The EVM implementation has its own quirks — gas schedules, stack-machine semantics, error handling for out-of-gas conditions. If the circuit does not faithfully reproduce those quirks, then the proof system will happily prove an invalid state transition.
The industry's response is audits. Every major ZK-rollup hires multiple audit firms. The audits produce reports. The reports are published. The reports are read by few and understood by fewer. I have seen audit reports that contain disclaimers about coverage limitations that would shock an institutional investor. I have seen circuits with thousands of constraints that were audited for specific vulnerability classes — reentrancy, overflow, access control — but not for the deeper semantic mismatch between the EVM specification and the constraint model. Audited? Or just advertised? That is not a rhetorical question. It is the central epistemic question of the entire ZK-rollup industry.
Verification is the only trustless truth. But the verification of a proof is only as meaningful as the verification of the circuit that produces it. And circuit verification is not mathematics. It is software engineering. It is testing. It is coverage analysis. It is the unglamorous work of checking that a translation is faithful. The ZK industry has spent billions of dollars on the mathematics of proofs and a microscopic fraction of that on the software engineering of circuit correctness. Silence in the code speaks louder than hype. The silence I hear in these circuits is the silence of untested edge cases.
Contrarian: The Bottleneck Is a Feature, Not a Bug
Now I want to make the argument that the teams running these benchmarks will not make, because it cuts against their funding narrative. The execution-layer bottleneck I measured is not a bug. It is a feature. It is the only mechanism that currently prevents these rollups from becoming ungovernably centralized.
The proving pipeline — witness generation, Merkleization, and proving — is the most capital-intensive component of a rollup. It requires specialized hardware. It requires enormous memory bandwidth. It requires the kind of infrastructure that only well-funded sequencers can operate. If the execution layer were perfectly aligned with the proving layer, if the handoff were instant and the Merkleization were free, then the only cost of operating a rollup would be the proving cost. And the proving cost is driven by the complexity of the computation being proven. A rollup that executes 100 transactions per second needs a prover that can sustain that throughput. A rollup that executes 1,000 transactions per second needs a prover that can sustain ten times that throughput. The proving infrastructure scales with the execution throughput. And the only entities that can afford to build proving infrastructure at scale are the major players.
The friction I measured — the serialization boundary, the lock contention, the process handoff — acts as a natural tax on the scaling ambitions of the execution layer. It forces the rollup to confront the real cost of its state-transition complexity before it scales to production capacity. The rollups that do not confront this cost, that paper over it with aggressive prefetching and optimistic parallelism, are the rollups that will hit the wall when they attempt to scale their sequencer throughput. The friction is the alarm system. The systems that measure it honestly are the systems that will survive the scaling era. The systems that hide it behind GPU-accelerated proof benchmarks are the systems that will fail in production.
The more cynical version of this argument — and my view tends toward the cynical — is that the bottleneck is a governance mechanism. The ICO era taught us that token-weighted governance is capture-able. The DeFi era taught us that liquidity provision is capture-able. The ZK era has taught us that capture-ability migrates to infrastructure. The sequencer — the entity that controls execution, witnesses, and proofs — is the new governance. The bottleneck ensures that the sequencer cannot delegate its power without giving up its economics. The bottleneck preserves the hierarchy.
I do not think the bottleneck is deliberately maintained for this purpose. I think it is an emergent property of a system where two different computational models — the sequential state machine and the algebraic constraint system — are bolted together. But the effect is the same. The friction concentrates power in the hands of the only entity that can afford to manage it.
The Institutional View: Why This Matters for the Next Bear Market
The current market is sideways, which means the narratives have more time to corrode. In a bull market, nobody reads benchmark data. In a sideways market, the capital that is not flowing into tokens is flowing into diligence. The institutions I advise are asking a specific question right now: not "which rollup is fastest" but "which rollup's finality claims survive a stress test." My answer, based on the benchmark data, is that current finality claims survive exactly zero stress tests.
Every major rollup advertises an "expected finality" or "soft finality" number in its documentation. Those numbers describe the optimistic path — the time to post the batch to L1 and assume the state transition will not be challenged. They do not describe the ZK path — the time to generate and verify the proof that converts soft finality to hard finality. The gap between these two numbers is the credibility gap. In my benchmark of Design A, the optimistic finality was 12 seconds. The ZK finality, measured end-to-end, was 22.3 seconds. The gap was 10.3 seconds. In a world where atomic cross-rollup composability becomes a real thing, that 10.3-second gap is the window in which a sophisticated actor can observe the optimistic state, execute a transaction in a dependent protocol, and withdraw before the ZK proof invalidates the optimistic assumption. Put something on a testnet, watch what happens in production. The gap is a liquidation vector.
But composability crisis is an overused phrase in this industry. Every new architecture is announced as the solution to the previous architecture's composability problems. The honest framing is that composability is not a feature that can be added. It is a property of synchronous execution. Two rollups are composable in the atomic sense only if they share a state-transition function or if their state transitions can be included in the same block. ZK proofs do not change this. A proof of state transition A and a proof of state transition B can be verified in the same L1 block, but that does not make transitions A and B atomic. It makes them sequential. The order is determined by the L1 sequencer, not by the protocols. There is no proof system that can force two independent rollups to commit their state transitions atomically. The message bridges being built by every ZK ecosystem are attempting to solve a problem that is structurally insurmountable without a shared execution substrate.
I have become convinced that the "fragmentation" the infrastructure teams keep telling me about is perfectly correlated with the amount of capital they are raising to "solve" it. Fragmentation is not a bug in the rollup-centric roadmap. It is the natural output of a roadmap where every execution environment is an island. Every bridge that connects two islands introduces trust assumptions. ZK proofs on both sides of a bridge do not eliminate the trust assumption in the bridge's order-fairness logic. They just relocate it.
What a Real Fix Looks Like
The benchmark data points to a clear engineering direction. If the execution layer is the bottleneck, the fix is not a better prover. The fix is an execution layer designed for the proving layer from day one.The systems that will win the next phase of this market are not the ones with the fastest prover. They are the ones with the most honest architecture. That should be the headline every ZK-rollup publishes next quarter. Not "sub-second verification." Not "instant finality." The real headline is: "we measured the full pipeline and we are publishing the full breakdown." Metadata is just data waiting to be verified. The finality data is waiting. No one is publishing it.
Takeaway: The Coming Reckoning in Finality Claims
On my last day of benchmarking, I ran the composite workload one final time, but I allowed the proving system to run on the same GPU-accelerated hardware that marketing uses for its demo numbers. The proving time dropped from 8.7 seconds to 2.9 seconds. It did not matter. The total pipeline latency only dropped by 5.8 seconds — because the 9.4-second execution-to-witness handoff did not improve. The finality tax is paid where the marketing is not. Any published number that lists verification speed without listing the full pipeline is not a benchmark. It is an artifact. And artifacts belong in museums, not in procurement decisions.
The rollup industry is in a race to optimize the most visible number. The number that will matter — the number that will determine which rollups survive the next scalability wave — is the full pipeline number that no one is publishing. The 12.4-second tax is the real map of the territory. Every team that has the courage to publish that map, with all its warts, will earn more trust than any team that publishes a logarithmic chart of verification times.
I trust the null set, not the influencer. The null set here contains the unmeasured gaps, the unpublished handoffs and the constraints that will break under real workloads. Every team with the courage to publish that map, with all its warts, will earn more trust than any team that publishes a logarithmic chart of verification times. The finality race is not a race to the fastest proof. It is a race to the most honest pipeline. Proofs don't decide which rollup wins. The data does.
