Ethereum's Strawmap: Frankensteinzation, Complexity, and Liveness Galore Part 1

This year, Justin Drake released a strawman proposal roadmap for Ethereum on behalf of the Ethereum Foundation, known as the Strawmap. It is not meant to be a plan carved in stone but a concrete blueprint offered to the community for examination, critique, and potential modification. Thus, I will offer my own critique founded in problems concerning liveness and complexity. Part 1 covers Strawmap preliminary forks, future Strawmap mechanics, and how these two lead to prover liveness concerns. Part 2 will analyze the concept of complexity from an information systems perspective, and how complexity may impact Ethereum’s future. Will it resemble a Frankenstein-like monster or offer a new hope for decentralized finance? 

A Guide, a Platonic Kochab: The Five North Stars 

The Strawmap proposes five North Stars as end-state goals for what Ethereum should look like within the next decade. In this article, I will primarily focus on North Star 2 and 4. 

North Star 1: Finality. Currently, Ethereum produces a block every 12 seconds while finality takes roughly 13 minutes. The first North Star targets a block time of 2 seconds with a finality time of 6-16 seconds. Ideally, Ethereum ecosystem users and institutions will no longer need to use L2S for faster confirmation times, develop complex applications, or pay lower fees; they can obtain these benefits on the L1 instead. 

North Star 2: Gigagas L1. As of today, Ethereum’s L1 throughput is approximately 15-30 transactions per second, with a 60 million gas limit per 12-second block. Gigagas L1, as the name implies, plans to achieve 1 gigagas per second (e.g., 1 billion gas units) with a throughput of 10,000 transactions per second. The Ethereum Foundation and Ethereum community intend to achieve this by implementing ZK proofs via moving zkEVM from the L2 layer to the L1 layer. 

North Star 3: Teragas L2. Given Ethereum’s Gigagas plan, L2s must develop a new selling point, as scaling will no longer be an L2's objective. Vitalik has noted that it no longer makes sense for L2s to function solely as cheaper or faster versions of Ethereum. Instead, the goal is to have L2s serve as a specialized layer for financial customization and compliance environments. Nonetheless, Teragas L2 intends to increase L2 capacity to 1 gigabyte/second of blob data or roughly 10 million transactions per second. 

North Star 4: A Post-Quantum L1. As advances in quantum computing pose a growing threat to existing cryptography, Ethereum aims to prioritize post-quantum security through hash-based cryptography and a broader redesign of its cryptographic infrastructure. Vitalik highlighted this in a recent post, outlining plans for leanSPHINCS post-quantum user signatures, signature aggregation through STARKs, zkzk frames, and other post-quantum improvements. I will discuss this in Part 2 in further detail.

North Star 5: A Private L1. The last North Star envisages an Ethereum infrastructure in which the sender, receiver, and amount of protocol-level transfers will be cryptographically shielded yet verifiable. Thus, privacy will no longer be an opt-in mechanism but the default standard.

Ethereum’s Central Contradiction: Capital at Rest, Activity in Motion

The Strawmap poses a solution to Ethereum’s previous roadmap failures. Initially, Ethereum made a strategic choice after The Merge: Don't try to make Ethereum L1 extraordinarily fast. Push most activity onto L2 rollups and let Ethereum serve primarily as the secure settlement/data layer underneath them. This worked in some ways but mostly caused major problems for both Ethereum’s infrastructure and ETH’s price action. Simply put, offboarding activity to L2s created a strong divide between capital at rest and activity in motion. Ethereum became an asset issuance moat. By moat, I mean a competitive advantage that's difficult for competitors to reproduce. On paper, their competitive advantage looks promising, as Ethereum has held 55–60% of TVL market share since mid-2022. However, TVL can be misleading and doesn’t measure genuine economic activity, as it’s largely based on token price appreciation and recursive leverage (in which the same ETH appears multiple times across staking, lending, and restaking). 

Moreover, this competitive advantage largely stems from institutional, first-serve trust, as Ethereum has existed for many years, contains enormous liquidity, has mature infrastructure, and has survived repeated crises. For example, imagine a company like BlackRock wants to tokenize an investment product. They aren’t going to think about how high the fees are or how fast the chain is; they are primarily concerned with compliance monitoring, custodian integration, regulation, technical integration, legal challenges, and so on. As someone who worked for Binance, I can say that ERC20 tokens were the easiest to list because of this trust premium shared by regulatory institutions. 

While Ethereum has an advantage in the first category, capital at rest, it lost most of its advantage in the second, activity in motion. This happened for two reasons: first, activity shifted elsewhere, and second, Ethereum deliberately reduced its revenue. Activity flowed elsewhere as EVM L2s became parasitic to Ethereum’s L1 economy. So, while activity remained within the ecosystem, it economically harmed the base layer as L2s processed an enormous number of transactions while paying Ethereum relatively little for data/settlement. Moreover, for the first time, Ethereum had major competition. Other chains became faster and cheaper, capturing retail user market share, primarily among those who aren’t concerned with compliance or Ethereum’s trust premium. 

The second reason occurred via EIP-4844, which made posting L2 data to Ethereum roughly 99% cheaper. Ethereum essentially cannibalized its own fee revenue intentionally to pursue scaling. Why does lowering fees hurt ETH? Because of EIP-1559’s burning mechanism. When you pay Ethereum's base transaction fee, that ETH doesn't go to somebody else; it’s burned. For example, imagine Ethereum issues 1,000 new ETH to validators, but 1,500 in transaction fees are burned, resulting in a net deflationary ETH supply of -500. However, suppose only 400 ETH is burned via EIP-4844’s cheap activity. Now we have an issuance of +1000 ETH with only 400 ETH burned, creating a +600 inflationary ETH supply; in turn, ETH's monetary/value-accrual mechanism weakens. Hence, a contradiction occurs: capital at rest while activity remains in motion elsewhere. 

Current Architecture Enforcement for Future Strawmap Goals 

Ethereum could theoretically increase its gas limit enormously tomorrow; however, this wouldn’t be feasible with Ethereum’s current rules. The problem is that Ethereum’s validators currently independently re-execute transactions to verify whether a block’s state transition is correct, a model known as N-of-N verification. 

To put it simply, the N-of-N model means that when someone (the block-proposer) adds a block of transactions, the validating nodes must redo the transactions themselves to ensure the result is correct. It’s like having thousands of accountants independently redo the same calculation instead of trusting one accountant’s answer. 

This redundant computation provides strong trustlessness, but it creates a scaling ceiling. In other words, if Ethereum increased computation by 100x, validators would have to perform 100x as much work within the same protocol's timing constraints. Hardware requirements would rise, ordinary operators would be priced out, and validation would concentrate amongst data-center operators.

The Strawmap vision attempts something much more radical: separate expensive computation from inexpensive verification. Three updates are particularly important for understanding the transition: ePBS (enshrined Proposer-Builder Separation), Block Access Lists (BALs), and, eventually, the L1 zkEVM.

ePBS and Block Access Lists are core features of Ethereum’s upcoming Glamsterdam fork. ePBS changes how blocks are constructed and processed. Currently, validators have little time to deal with a block (roughly 4 seconds to receive it, process transactions, verify rules, and vote within the standard 12-second window). Thus, increasing the gas limit (i.e., increasing the block size) would require validators to process much more in the same amount of time. ePBS solves this problem by separating consensus block verification from execution payload verification. Validators can quickly attest to the block they are agreeing on, while allowing more time to verify more complex transactional data within the entire 12-second window; this gives validators several times longer to process a block, thereby making larger blocks more practical. Moreover, eBPS is important for the future L1 zkEVM, as incorporating ZK technology into the base layer will require more execution time. 

Ethereum currently processes transactions sequentially because it doesn’t know in advance which transactions can be processed simultaneously. For example, a transaction might depend on the previous transaction before it. Let’s say Alice has 100 ETH and sends 70 ETH to Bob in transaction 1 but then attempts to send 50 ETH in transaction 2. You can't blindly process both transactions independently because together Alice is trying to spend $120. Thus, the rule of sequential execution is enforced.

However, not all transactions interact with one another. In fact, most don’t. Galaxy cites historical analysis suggesting roughly 60–80% of transactions in typical blocks don't overlap in state. So sequential execution ordering is largely redundant. BALs resolve this redundancy problem by telling us, ahead of execution, which parts of Ethereum's state each transaction will read or change. So, Ethereum will know ahead of time that transactions 1 and 2 touch Alice’s account and that they shouldn’t be processed simultaneously; the other transactions that do not touch Alice's account, however, can be processed simultaneously, thereby making parallel execution possible. As one can imagine, this greatly increases scalability and, most importantly, provides a proto-framework for L1 zkEVM. 

The Strawmap Begins: Increased Complexity and Liveness Problems 

It’s important to note that Ethereum doesn’t simply limit transactions; it limits gas. With Gigagas, the long-term Strawmap goal is to increase the gas limit to approximately 1 billion gas per second, or 1 gigagas/second. Hence the term Gigagas. The method for implementing Gigagas primarily consists of moving away from the N-of-N model to the 1-of-N model, the L1zkEVM. Within the 1-of-N model, validators will no longer perform transaction execution; instead, sophisticated provers will, essentially separating execution from verification at the L1 level. A prover executes transactions, calculates the resulting Ethereum state, generates a ZK proof showing the execution was correct, and then sends that proof to validators. Validators then verify the proof rather than re-executing the whole block. In this sense, validators thereby become ZkAttesters. Thus, Ethereum’s computational burden is eliminated. It’s been relocated. However, it’s important to note that Ethereum won’t need every prover to be online to do the work; only at least one needs to produce a valid proof successfully, hence the term 1-of-N. 

In other words, instead of having a builder compute 100,000 transactions with 10,000 validators computing the same 100,000 transactions again (the current Ethereum N-of-N model), we now have one prover computing 100,000 transactions, producing a proof, and 10,000 validators verifying the proof (the 1-of-N model). That's an enormous reduction in redundant computation. 

To perform this service, provers will require heavy hardware and power consumption costs. Only large databases and specialized companies will be able to handle the service. This creates something of a paradox, whereby the prover service is largely centralized yet allows for further decentralization of the validator set (i.e., if validators no longer need to perform execution or maintain the entire Ethereum state, they can verify consensus blocks using cheaper hardware and less compute). 

Additionally, BALs opens the door for recursive ZK proofs at the L1 layer, or what Vitalik calls Ethereum ZKZK. As computation increases enormously under the GigaGas vision, producing a single gigantic proof sequentially on a single machine becomes problematic. Therefore, Vitalik eventually wants ZK-prover parallelization, whereby Starks proves the validity of other Starks. So, instead of having the validator set verify two separate proofs, A and B, a prover can generate a proof AB and allow the validator set to verify AB instead. And you can do this again and again, as shown in Figure 1 below.

Prover Liveness Problems

As I explained in a previous article, The Master of Time: How DAGKNIGHT Solves an Impossibility Result Unachievable by Bitcoin, Ethereum and Classical BFT Models, Ethereum suffers from a consensus and bootstrapping-liveness dependency problem. Now, Ethereum’s proposed prover-based scaling architecture introduces a third dependency—prover liveness.

One of the great attractions of zero-knowledge and validity proofs is that the prover does not have to be trusted. If a prover claims that an invalid Ethereum state transition is valid, the cryptographic proof should fail verification. Ethereum validators can therefore reject the result without reproducing all of the original computation. Ethereum does not necessarily need to trust the prover for safety; however, it depends on the prover for liveness. Thus, we have moved from a model of trust to one of dependency, creating a centralized bottleneck. Given the substantial capex and opex required to run future provers, an economic pathway toward concentration is formed. Concentration does not necessarily give these actors the ability to forge Ethereum’s state; however, it matters enormously for availability. 

Ethereum could become dependent on a small number of actors being online. If enough provers are available via the 1-of-N model, we don't have much of a problem. However, suppose only five organizations can reliably prove worst-case Gigagas blocks within Ethereum’s deadline. Then we have a problem, as many things, such as cloud outages, coordinated refusals, common-mode failures, regulatory intervention, software bugs, and so on, can affect these prover organizations, causing an Ethereum-wide concern. This means the number of provers is less important than the number of genuinely independent proving paths. For example, 100 provers all running the same software on the same GPU architecture through the same cloud provider may offer considerably less liveness diversity than the number “100” would suggest. Ethereum therefore needs diversity not merely in prover ownership but potentially across hardware, power sources, network infrastructures, proof systems, zkVM implementations, software, geographic jurisdictions, and the like, as the network needs to ensure that failure of one component does not simultaneously eliminate all credible proving paths. And this problem seems beyond the scope of Ethereum; it would require massive institutional and legal coordination that goes well beyond crypto itself. Instead, it's an industrial organization problem. In other words, Ethereum can try to minimize the technological economies of scale of proving, but it cannot eliminate economic economies of scale. 

Moreover, the Strawmap’s increasing reliance on recursive STARKs (i.e., ZKZK) broadens this problem, as proof generation itself becomes a pipeline. In other words, unlike the previous Ethereum model, where ZK proofs were largely offboarded to the L2 layer, proof verification now becomes part of the protocol’s consensus-critical path at the L1 layer under the Gigagas model. More is therefore at stake in ensuring prover liveness and timely proof availability. Ethereum must now depend on provers for execution, witness generation, individual proof generation, recursive proof generation and aggregation, final proof delivery, and so on, before validators can verify the resulting proof. Each additional dependency introduces another potential bottleneck in the consensus-critical proving pipeline, where delays or failures can threaten timely proof availability. When combined with prover centralization, this creates a deeper problem.