Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer

conalloreilly · July 6, 2026, 1:15pm

Lean Execution:

a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer

1. Introduction:

Lean Ethereum¹, as proposed by researcher Justin Drake on the 31ˢᵗ of July, 2025, is an ambitious proposal —or family of proposals— that encapsulates a holistic vision for the future world-computer as we begin to consider our own role as developers in the maintenance and governance of the Ethereum protocol into the future. Lean Ethereum isn’t just a far-off solution to Ethereum’s long term problem, but in ways an inwardly-directed question to ourselves:

How can we ensure that the Ethereum protocol remains provably secure, with robust incentives and strong cryptographic security; sufficiently high in throughput; maximally simple; and optimally decentralized, even as we reduce our own influence as developers?

Lean Ethereum is the question, and Justin Drake’s initial answers fell into three categories:

Lean Consensus: fast finality, post-quantum, ultimate decentralization and security.
Lean Execution: minimal SNARK-friendly high-throughput execution capacity.
Lean Data: homogenized data-availability and state storage.

These technical upgrades aim to propel us towards two qualitative goals:

Defense-fort mode: the protocol must be protected against quantum attacks, nation-states, and any other adversaries.
Offense-beast mode: the protocol must be high in throughput and maximally scalable to accommodate the world’s execution and data demands.

Among the tools at hand are post-quantum cryptography, SNARKs/zkEVMs, formal verification, encapsulated complexity and elegant simplicity, and radical decentralization². Physicists uncover the secrets of our reality in pursuit of a single equation to describe the universe, and Lean Ethereum can define one truly elegant equation to describe the world-computer, the singularity of computational coordination.

2. A history of blockchains:

“I’ve been working on an electronic cash system that’s fully peer-to-peer, with no trusted third party.” —Satoshi Nakamoto, October 31st, 2008.

The focus of this article is to outline the Ethereum protocol-research space as it pertains to Lean Execution, the pursuit of the optimal computational engine for the world-computer, and to draw a number of conclusions regarding the nature of blockchains and blockchain-scaling while interpreting their history. As such it’s worth exploring what exactly “execution” even means in the context of blockchains.

2.1 What is a blockchain?:

It’s worthwhile for starters to actually define in sufficiently general terms what a “blockchain” even is. So what is a “block” and what makes a chain of them special? In a simplified context, a blockchain has 6 main components:

Blocks
Ruleset
Procedural memory
Consensus engine
State
Directed linked chain

A block is an operation —or set of operations— on the state under the ruleset, whereby the operations are sourced from some kind of temporary network memory, the state is —really any— field of data, the chain is a cryptographic structure that gives the blocks’ operations on the state a direction (i.e a time-directed ordering), and the consensus engine is what lets willing parties in a distributed network agree on all of these matters. Everything that happens in an entire blockchain’s history begins with an initial state. This initial state is usually defined by a genesis block, which is an operation that creates the initial state (the ruleset doesn’t necessarily apply to the genesis block). Consensus on the initial state is provided by “weak subjectivity,” which is an out-of-protocol way of defining some form of cultural “truth” regarding the blockchain’s initial configuration; for example most genesis blocks are hard-coded into the initial reference software that implements the protocol. Once there’s cultural agreement on the initial state, the consensus engine is used in such a way that new blocks can perform operations on the state under the constraints defined by the ruleset, in such a way that those operations have a defined order-of-operation within the chain’s history.

Now we have a few things:

An initial/current state
A set of rules that define how new operations are performed in blocks and in what order
A network of computers
A consensus engine that provides the network means to agree on 1 and 2.

By definition, since the network of computers agree on initial state N, and they have means to agree on how new block operations can be performed to create state N+1, and they have means to objectively define in what order the operations of a block were performed in the creation of state N+1, they can thus agree on the future states N+2 and N+3, which by induction means they can continue defining new states into perpetuity, but the consensus engine ensures there is not only agreement on the current state, but all past states and potential future states. This gives us a nice way to define a blockchain:

A blockchain is a time-directed record of states shared across a network of computers, with a consensus engine that allows the network to agree on the current state, the historical states, and the rule-set that defines how the future states may be created.

Note that the need for a consensus engine implies a lack of trust, or implicit agreement, which implies that all real blockchains have properties of decentralization, since untrusted parties (by definition anybody from the perspective of anybody) can always participate in consensus. The blockchain creates a root of truth that is a function of the ideological and cultural manifestations of its participants, and consensus allows that root of truth to be created in such a way that the viability of a common state and state transition function can be coordinated within a computational continuum.

The useful part of a blockchain is that the blocks that operate on the state can include operations (usually called transactions) created by individual users in the network and sourced by nodes from memory, but there are operations that exist strictly natively —for example consensus—processes such as subsidies that pay rewards to those who participate in the consensus process.

2.2 A holistic perspective on network capacity:

The defining features of a blockchain can loosely be described as working in tandem to provide three major categories of blockchain capacities:

Consensus capacity
Execution capacity
Memory capacity
Data capacity

The consensus capacity can be defined as having both a breadth and a depth. Consensus breadth refers to the scale at which the consensus engine operates in terms of its number of participants, its level of security, and assumptions of trust; i.e how hard would it be to manipulate the consensus engine. Depth refers to the ‘throughput’ of consensus; i.e how quickly can the chain reach finality, and as such how quickly can users have certainty surrounding the irreversibility of their state changes. Generally speaking both the breadth and the depth of consensus have inverse relationships with one another; growth in one area corresponds to a trade-off in the other, which makes it increasingly challenging to both scale the output of consensus (how “much” consensus is being reached per unit of time, or in other words how much can be agreed upon by the network per unit of time), while keeping the barrier to participation in consensus low and the network decentralized.

Execution capacity refers to the throughput of the actual state-transition function under the ruleset within the chain; i.e how many operations can be performed —and agreed upon by consensus— per unit of time; in the naive blockchain model that Bitcoin and Ethereum presently use, execution capacity is often the limiting factor to consensus depth, since part of the bottleneck is the fact that every block must be re-executed by every consensus participant; statelessness and snarkification more broadly fundamentally disrupt this inherent limitation.

Memory capacity is essentially the capacity of the network to temporarily store data, direct it towards the execution and consensus engines for on-chain computation, and govern its availability and utilization. Examples of memory-layer functionality are inclusion-lists, virtual/sharded mempools, encrypted/private mempools, and based sequencing. By default the memory-layer-data is probably replicated across most nodes, but a sufficiently sharded network would rely on mempool sharding to remove this bottleneck; it’s also worth noting that the lack of strict consensus rules governing this intermediate transactional limbo (neither inside or outside of a block) has led to issues like toxic MEV and censorship resistance.

Data capacity is related to the network’s capacity to reach consensus on the state of the network (and any external relevant information such as rollup states), or in other words, how much information the network can store and use within the execution process —or sometimes outside of it. The naive model of Bitcoin and Ethereum rely on every node replicating this network state, but Ethereum is moving towards more resourceful data bandwidth through blob data availability sampling.

The interactions between the four capacities generally follow the following model: Consensus capacity is the chain’s root of truth, execution capacity is encapsulated within the consensus engine’s truth, memory capacity directs data towards the execution engine for computation, and the data capacity is enforced either implicitly (by execution) or explicitly (by consensus).

Observing how these capacities differ across blockchain models can provide us with a unique perspective on what scaling capacity holistically actually entails.

2.3 Blockchains in practice:

The first blockchain was deployed by Satoshi Nakamoto, inventor of the electronic cash system Bitcoin³; one of the earliest Bitcoin-like time-stamping/state-consensus systems was proposed by Scott Stornetta and Stuart Haber in 1991⁴. The Bitcoin blockchain was structured as follows:

The genesis block was hard-coded into the reference implementation.
The state was structured as a list of spendable outputs of previous transactions.
A replicated mempool was used to temporarily store transactions and direct them into blocks.
The ruleset defined desirable properties of an electronic cash system based on public-key cryptography that only allowed outputs to be spent under strict spending conditions.
Spendable outputs were initially created by inflation that rewards participants in the consensus engine (known as miners in Bitcoin).

Each block of operations (transactions) had these strict requirements:

For each transaction, the output the transaction spends exists.
Each transaction satisfies the spending conditions of the output it is spending.
The total size of all of the transactions in the block is less than 1 megabyte.

Since the consensus engine used proof-of-work, the blockchain executed the transactions in blocks through the following mechanism:

On average every 10 minutes a random miner is elected to propose a block.
The mempool is itself computed over by miners in an attempt to find the highest fee-paying block, with some minor policies like dust limits set on transaction outputs.
If the block is valid it is included and the resultant state is used as a basis for the next block.

Bitcoin follows a naive blockchain model for this reason. The bottleneck of proof-of-work means three things:

For the sake of decentralization the percentage of the proof-of-work block-time-period (10 mins in Bitcoin) spent computing the transactions (and their actual aggregate data footprint) to be included in a block must be very small, as otherwise more powerful miners would have non-linear advantages —i.e economies of scale.
The vast majority of computational resources are used for the consensus process and not for throughput.
Only one block of execution can happen within one block time-period; i.e there is no parallelism.

A restatement of 1. is that the vast majority of the time to append a new block to the chain is spent on useless consensus work, not execution work. All three of these factors make Bitcoin extremely wasteful.

Originally Ethereum⁵ innovated mostly in execution and state, but only minimally in consensus, since —a slightly improved— proof-of-work was still utilized. The innovation of Ethereum was the generalization of the state-transition ruleset; in other words, Ethereum made the execution operations of a block general-purpose (satisfying properties of Turing-completeness), unlike Bitcoin which only had limited stateless spending conditions for transactions. Therefore the computational potential of Ethereum transactions was made vastly (infinitely) superior by the Ethereum Virtual Machine (EVM), but the computational capacity of Ethereum was still relatively slow.

A major innovation that changed this fact was the introduction of proof-of-stake consensus, which uses in-protocol currency units as the controlling factor in consensus as opposed to wasteful energy consumption. This eliminates the three limiting factors of proof-of-work consensus regarding the execution of a block:

Since there’s no ongoing cost to consensus that can increase a participants statistical control, more of the block time-period (4/12 seconds in modern Ethereum) can be used to compute the transactions to be executed.
The majority of network computational resources can be directed towards execution throughput since proof-of-stake consensus is far more efficient than proof-of-work.
The deterministic proposer election in proof-of-stake can be used to delegate execution throughput to a number of participants at once, which makes sharding-like schemes much more viable.

Since the block-time-period is deterministic in proof-of-stake, there’s a conceptual disconnect between the proof-of-stake “slot” of the block-time-period and the actual “block” of transactions executed. Comparing proof-of-work to proof-of-stake reveals three important questions when defining the execution mechanism of a blockchain:

How much time can we spend executing transactions within a slot (block-time-period)?
What percentage of active block proposer resource-use can be directed to executing transactions in a slot?
How many active network participants can direct their resources to execution throughput at once?

Increasing the execution throughput of the blockchain involves maximizing all three of these values. The current Ethereum protocol is sub-optimal at all three; enshrined proposer-builder separation and statelessness will optimize 1 by increasing the amount of time spent “building” —or computing transactions for— a block in a single slot, and factor 2 can be further optimized in ways such as validator signature aggregation and consolidation, but the protocol offloads the optimization of the third capacity-utilization factor horizontally across “Layer 2s.”

In this document I will refer to the first factor as time-optimization, the second as resource-optimization, and the third as capacity-utilization. Together these are the three execution optimization factors of blockchains.

3. Homogeneous vs heterogeneous capacity:

The Bitcoin blockchain is interesting as from the very beginning it’s been inherently monolithic: in any given slot, every single miner works to find the same single proof-of-work (consensus), all nodes approach a replicated mempool (memory), a single winning miner proposes a single state-transition (execution), and they all share the same single replicated state of unspent outputs (data). Ethereum was implemented similarly in the very beginning, and on the surface, even with proof-of-stake, it would appear to follow the same monolithic structure: every validator signs the same block (consensus), a single random proposer is elected to propose a single state-transition (execution) with transactions from a similarly replicated mempool (memory), and they all replicate the exact same world-state (data).

In section 2.2 I outlined the four capacities of a blockchain as provided by its defining structure described in section 2.1, and in section 2.3 I outlined how these capacities are implemented in practice and what the three optimizations of execution throughput are. Resource-optimization and time-optimization are relatively basic architectural optimizations, and proof-of-stake is excellent at optimizing them, but I claim that the limiting factor of throughput is almost always the capacity-utilization; capacity-utilization is a bottleneck to all four of the capacities defined in section 2.2, not just execution; execution —and also memory— just happen to be the most important places where capacity utilization must be optimized —particularly for scaling.

Monolithic blockchains (Bitcoin being the best example) can be said to be heterogeneous: they do not scale with breadth; i.e increasing the number of consensus participants does not increase the throughput, as the entire state-transition function is always limited to one consensus thread. A consensus engine, despite its provenance ideally being homogenized mechanistically, is inherently heterogeneous in agreement, as by definition to reach consensus you need some kind of singularity of agreement —every Bitcoin block has a header whose hash is below the target difficulty, and every Ethereum consensus block has a set of attestations.

Ethereum is only starting to improve on this limiting factor, and the best examples are within the consensus and data engines. The consensus engine is a useful example due to the very nature of proof-of-stake: proof-of-work implies consensus in the chain, while proof-of-stake needs explicit attestation of consensus to function; in other words, an extremely difficult proof-of-work in Bitcoin implies enormous consensus participation (and by proxy a sizable number of participants), but proof-of-stake requires explicit definition of those validators who contributed to consensus.

3.1 Consensus homogeneity

Even though consensus is inherently heterogeneous in the context of coordinating its root of truth, this additional computational bottleneck was minimized by the Ethereum beacon-chain in a way that follows the paradigm of homogenization of capacity in the context of execution. Specifically, proof-of-stake validation capacity-utilization is optimized by using signature aggregation⁶ across sub-committees to homogenize the validator duties inwards, instead of requiring heterogeneous validation outwards:

In this case, consensus capacity is optimized by using a homogeneous consensus model where proof-of-stake validator signing is folded inwards and then propagated upwards in a way that increasingly optimizes the capacity-utilization of the validator resources. In other words, no single validator has to compute every signature (such as in the heterogeneous model); instead, sub-committees are used to homogenize the overhead of the consensus engine across the validator set to maximize resource efficiency, yet still still every validator can easily verify the aggregated signatures are valid.

The basic principle of heterogeneous vs homogeneous architecture here follows the structure of the three capacities: in the optimal homogeneous architecture, there is a consensus root that is attested to by validators in such a way that local committees can sign in parallel, and these committees’ signatures are aggregated before inclusion in the consensus root; this is analogous to consensus parallelism, in that the consensus engine is running on multiple threads at once, and the results are propagated upwards in such a way that proves validity across all threads’ validators while the bottleneck of verification is only equal to the number of separate threads, and not the total number of validators.

The intuition regarding consensus here is quite powerful: it’s relatively easy to achieve this homogenization/parallelism as validator attestations are relatively stateless, i.e. all signatures have the same dependency (the previous slot) and only read to it, never write. The same is true for proof-of-work through its implicit consensus throughput: all of the miners are working in parallel to achieve consensus on a new probabilistic block, without any need for resolving “dependencies” between miners’ respective work; this makes proof-of-work consensus naturally homogeneous. The remarkable thing about this paradigm is that it resembles a cryptographic defender advantage: an enormous amount of resources are used to secure consensus, but verifying its validity is extremely simple and takes minimal resources; the goal of execution and data homogeneity is to replicate this natural imbalance between the time to compute the aggregate throughput and the time to verify it, which is why zkEVMs and data availability sampling⁷ (zk-tech in general) are such powerful tools on the execution layer. One way of looking at it is that both cryptographic constructs bring the defender advantage of the consensus layer to the execution layer of the chain.

3.2 Data homogeneity

A homogenization of data capacity in theory would leverage this consensus root of truth to enable the network to distribute the storage burden of the execution state of the chain while having the data readily available for use in execution. Data availability sampling enables the network as an aggregate to distribute the burden of storage across the validator set without every individual validator having to store the entirety of the data themselves. Current implementations use KZG commitments to ensure provenance of the data and erasure coding to create redundancy. Optimally the data distribution would be managed in such a way that it can easily be retrieved across the network for execution. Although implementing data availability sampling is far more difficult for executable state data than it is for static blob and history data, it seems intuitively necessary to homogenize the state burden.

Data availability as a mechanism is actually not a strictly necessary component of blockchains, however, but current architectures just deploy it both for the convenience of the user and to better utilize computational resources. To see this fact, one only has to observe that actually, storage costs are merely execution costs shifted to the disk. Take for example a radically stateless model of a blockchain: in this model, nobody permanently stores any data at all except the root of a vector-commitment tree; when a user wishes to perform some kind of operation on the state trie, they must include in their transaction a vector commitment that proves the existence of the state they wish to compute on. Here, the storage overhead of the full-nodes storing the full world-state is offloaded to validating (or building) nodes as execution costs, which are arguably much easier to scale.

Apart from just better utilization of available storage resources, spreading the burden of storage across the validators even minimally off-loads the cost of storing one’s state from the users of the state to the network itself, which makes the user experience much simpler; still though, the cryptoeconomics of permanent storage are actually quite undesirable. If we are to scale the world-computer, and homogenize the data capacity of the network, naively replicated perpetual storage must be replaced by a more economically healthy data availability mechanism that distributes the burden of storage across the network as an aggregate. Incorporating state expiry along with sophisticated data availability sampling mechanisms seems optimal to maximize data capacity utilization in the network.

3.3 Sub-rooted execution and attestor-proposer separation

An optimally homogeneous consensus engine allows for a singularity —or perhaps a beacon— of truth to be provided that encapsulates the network’s execution, memory, and data capacities. Though the root of consensus can subsist independently of any execution, the consensus engine wouldn’t have anything to reach consensus on in that case (other than itself), so as part of the holistic operation of the chain, the consensus engine regulates the execution of new state-changes, and by implication the existence of the current state. The current execution model within Ethereum uses single-threaded naive heterogeneous re-execution that is only weakly time and resource optimized, but not capacity-utilization optimized. Both time and resource optimization come from the combination of the separation between the role of validating execution (validators) and actually enabling throughput (builders) in proposer-builder separation or attestor-proposer separation, along with the natural time and resource optimization of proof-of-stake consensus, but also more advanced constructs like statelessness.

Since execution is defined within the constraints of a ruleset, the provision of execution within the root of consensus has strict constraints enforced as part of the consensus engine that ensures the rules of the EVM are followed. The bottleneck here of verifying these rules for an execution block is currently equal to the cost of re-execution of the entire state-transition of the block. The result of this is that every validator has to execute all of the throughput of the chain, which means the consensus depth —and execution throughput— is actually limited by the maximum amount of computation available of the lowest-powered validator (by computational resources) participate for decentralization’s sake.

One solution to the above limitation where the maximum throughput is equal to the maximum available computational capacity of the lowest-capacity supported validator is the use of SNARKs (succinct non-interactive arguments of knowledge) to prove the validity of execution without naive re-execution. This means that limiting factor on consensus depth actually becomes the time to verify a succinct SNARK proof of valid execution, instead of the time to re-execute the state-transition function. This creates a fundamental disconnect between the time to execute throughput and the time to verify its validity, or in other words, whereas previously the time required to reach consensus on an amount of throughput was bound by the time it took to replicate the execution of that same throughput, now consensus can be reached on throughput in constant execution time, regardless of the scale of that execution.

The disconnecting of the resources required to verify from the resources required to produce throughput means that we can make separate assumptions regarding the role of those who validate execution in the consensus engine, and those who produce the execution itself. One proposal that follows this paradigm is attester-proposer separation, which separates the provision of proof-of-stake validation security from that of proposing new execution blocks. This has enormous benefits as now the consensus engine can be secured by a wide network of extremely low-powered computers, while throughput is provided by higher-powered nodes, and since the requirement to participate in consensus is already Ξ32, the cost of running a specialized throughput-providing node can reach close to that cost without making trade-offs in decentralization. The reason why APS⁸ might be favored over ePBS⁹ is that the role of proposing the block still exists in ePBS, which makes the bandwidth speed of a validator still an economy of scale, which is undesirable for decentralization; ePBS may additionally be undesirable due to the lack of an effective enforcement mechanism for its enshrined builder pipeline.

The problem still remains, however, that even though both resources and time are increasingly optimized by both the homogenization of consensus and the disconnecting of execution resource requirements from validation resource requirements, the sub-rooted execution would still be running on a single thread. Execution capacity utilization is one the hardest parts of Ethereum to optimize, and for the last ten years sharding and sharding-like proposals have been trying to solve this seemingly-impossible problem.

4. A history of sharding:

“Divide each difficulty into as many parts as is feasible and necessary to resolve it.” —René Descartes

4.1 Prehistory

Sharding itself is actually a term borrowed from classical distributed systems design, and most commonly refers to the idea of horizontally partitioning a database into a set of “data shards.”¹⁰ The term, when applied to blockchains, essentially means partitioning the burden of —ideally all— of the 4 capacities across separate committees. This poses a few major questions:

How are the committees selected in a provably unbiased way?
How are cross-process dependencies resolved between committees?
How is security maintained if the number of nodes validating a committee sub-process is by definition lower than in one monolithic network?

The problem of sharding blockchains has been thoroughly investigated for almost a decade¹¹. For the longest time this has essentially appeared to be an impossible problem to solve, mostly due to the inherent link between verifying the throughput of the execution capacity and actually computing (providing) that throughput —as described by the blockchain trilemma. In other words, if the reason why the blockchain is difficult to scale is because the cost of verification is always equal to the cost of execution for every node, than partitioning the network will only ever decrease the amount of verification happening for the same amount of execution, which is an unsustainable model.

One of the earliest blockchain sharding proposals came from Satoshi Nakamoto in December of 2010. Their proposal¹² entailed embedding the Bitcoin blockchain and other chains into a merkle tree, where each chain represents a separate branch. Mining here means solving the PoW for the root of the tree, whereby respective branches can then be pruned off and sent to the chains’ respective networks; since the difficulty may differ across sub-chains, a solution may appear for some branches more often than others, and some solutions may be valid for multiple chains.

The major innovations that have reignited the possibility of native sharding in blockchains are the cryptographic techniques behind zero-knowledge proving, commonly SNARKs —succinct non-interactive arguments of knowledge. Since SNARKs allow an arbitrary amount of computation to be verified in constant time, they have remarkable implications for sharding: instead of partitioning both consensus and execution at the same time, and thus limiting the security of the same amount of execution, we can instead partition (shard) the execution of the throughput, while keeping the consensus engine holistically able to verify all of the arbitrary amount of throughput in constant time —with the same level of security.

Sharding research itself has now become a matter of improving the underlying cryptography behind zero-knowledge proving, and determining the most effective implementation of this sharding paradigm.

4.2 Early Ethereum sharding concepts

Sharding research during the early-stages of the Ethereum 2.0 roadmap¹³ had a number of difficult problems to solve; the problem of scaling by sharding, in fact, could be argued to be the very essence of the blockchain trilemma. The problem with partitioning the network into separate sub-shards in order to increase throughput is that each partition exactly (under certain security models) minimizes the level of security of that shard in direct proportion to the increase in scalability acquired. One way to dampen the negative effects of security being minimized in proportion to throughput is by using random committee selection to maintain heterogeneous-level security in an uncoordinated majority attack model; however the inherent limits may still apply under other attack models, which means it’s not a totally bullet-proof solution. If it’s assumed that malicious but uncoordinated validators probabilistically located in the same shard may be capable of coordinating an attack over a long enough timeframe, it then becomes crucial to ensure that random committee shuffling is occurring at a rate faster than the rate at which these adversaries can coordinate, which is an additional bottleneck.

For example, given N validators, and k (probably a power of 2) potential shards (including the root chain), we can randomly assign N/k validators to each shard in every proof-of-stake slot; each shard has its own proposers that create blocks for their respective shards, and at the end of each slot a “collation header” signed by the supermajority of the shards’ validators is included in the root chain’s block. A big problem here is that there’s no way for the validators of other shards to know if some form of malicious committee creates a malicious incorrect block in their shard, since the execution itself is not replicated; another issue is that, since every validator is delegated into separate blocks they execute upon, there is no way for validators in other shards to know whether or not the actual block data for the collated header is available. Even worse, we never defined who actually stores the state for each respective shard, which is an even harder problem to solve.

One could argue that a sufficiently secure network may very well have marginal potential throughput that can be acquired by marginally decreasing security across partitioned sub-shards in order to extract the maximum throughput available within common security assumptions. Doing this in a way that ensured adequate security network-wide remained an open problem for many years. An even harder problem is arguably determining the way in which cross-shard transactions can be resolved, as otherwise the blockchain effectively makes no tangible gains through sharding, and merely resembles a set of separate chains. One solution involved the idea of a “debit” and “credit” transaction pipeline: an A→B cross-shard transaction can occur by a debit transaction being made on shard A, with a log of the transaction’s inclusion being created in a receipt trie; then, on shard B, a merkle proof can be provided that proves the debit on shard A, and credits the transaction (executes it) on shard B. Making these kinds of interactions atomic, however, was another open problem.

4.3 State channels

State channels¹⁴ were an early off-chain scaling model that was largely dropped in favor of plasmas —and now modern rollup systems. They worked by allowing two parties to initiate a ‘channel’ by signing an initial state; new states can then be computed and signed by both parties, which changes the general-purpose state of the channel. Each new state revokes the previous in some way, which ensures that the latest update to the channel is the one that would be validated on-chain in the event of a dispute. This means that intermediate state-changes can be computed off-chain, with the assurance that the latest state could always be published on-chain. Eventually the channel is closed and the latest state is finalized on the L1.

Different implementations use different revoking mechanisms, but one of the simplest techniques used for Ethereum¹⁵ in the past was for both parties to include a nonce in each new state update, with the on-chain initialization contract always favoring the published state with the highest nonce as the latest. In the case that both parties are honest, a special closure transaction can be mutually signed that finalizes the state; in the event that one party is byzantine (either purposefully malicious or perhaps just offline), a single party can publish the latest state, but there is a delay to ensure any potentially later state can be published. The fraud-proving challenge-window period is what provides final settlement in the case of disputes, but it can often be inconvenient depending on the length of time —and level of security— needed when resolving disputes.

State channels had a few major problems. For starters, since changing the state of the channel is an interactive process, both parties needed to be online to make updates —for example to receive a payment. Another issue is that to secure one’s funds, there’s a requirement to be actively checking the on-chain contract for potential malicious transactions, which again means that the security model assumes liveness of both parties, which becomes a problem in the case of technical failure or censorship of either member of the channel. The bicameral nature of channels also meant that more complexity was necessary to compose state-transitions between multiple parties.

A large part of why state-channels aren’t that powerful as a scaling solution (ignoring the security trade-offs mentioned above) is that actually state-channels are effectively just temporary interactive plasmas between a small number of parties; the fraud-proving and on-chain resolution of plasmas actually are effectively identical when it comes to security tradeoffs (except in data availability) while being far more versatile; plasmas are just arguably superior as they actually allow users to coordinate asynchronously —that is, without both parties being required to be online.

4.4 Plasmas and validiums

Plasmas were a historical scaling solution that combined an on-chain contract to ‘enter’ the plasma, and an off-chain plasma operator that would compute transactions within the plasma itself, periodically posting a commitment to batches of transactions on-chain. They offload the burden of coordination from the users themselves to a plasma operator, which means that users can coordinate asynchronously, unlike state-channels, which require realtime interaction between users; however, this improved user experience comes with a number of trade-offs mostly stemming from the trust placed in the hands of the central operator.

Plasmas used merkle trees to track rudimentary units of cryptocurrency, where each coin was represented by an index in the tree. When funds were deposited into the plasma through the on-chain contract, the operator would send the holder a merkle branch proving the existence of their coins within the tree. The plasma operator would then periodically batch transactions together and post a merkle tree of them onto the chain; withdrawing funds meant publishing a merkle proof of ownership from one of these batches on-chain, but since mainnet itself had no way of verifying the validity of the exit-statement (for example that they hadn’t potentially spent the funds at a later date), a dispute-resolution window was used to ensure that anybody could publish a fraud-proof proving the incorrectness of the withdrawal.

The problem is that to ensure fraud-proofs can be computed and published on-chain, a sufficient number of nodes are required to both actively watch the chain itself, but also have the plasma data available in order to create the proofs. This is a major security issue as it relies on the operator of the plasma being willing to make this data available at all times, which makes them a central point of failure and trusted entity in the system. Another issue was that plasmas only supported basic use-cases like simple asset transfers, which meant they were never a holistic solution to the scaling problem.

Validiums¹⁶ were effectively extensions of the plasma concept that utilized validity proofs (SNARKS) to actually prove the validity of the transaction root published on-chain, which makes it cryptographically impossible for the operator to cheat the users by committing to invalid transactions. This means that in the case where the operator is honest (in terms of data availability) users can have instant withdrawals of funds, since the transactions inside of the published root of the tree are explicitly proven to be valid. The problem of data availability still remains however, so validiums have mostly been replaced by zk-rollups (who use robust data availability) as a spiritual successor.

4.5 Data sharding

Data homogeneity can be described loosely as a mechanism to distribute the burden of data (state or static blob data) storage across the set of validating consensus nodes, rather than redundantly replicating the entire data capacity of the network on every single validator’s hardware. When you approach it from the perspective of the question of what a blockchain is and what it should look like in principle, this seems like an intuitively effective way to run a decentralized world-computer, but from the perspective of early-stage sharding proposals, data availability was more of a problem than a solution.

The issue with sharding is that, even if you assume an arbitrary amount of computation can be verified in a constant amount of time with SNARKs, which means consensus overhead can remain constant even under sharded partitions, you still encounter the fact that sharding has two separate problems to solve: partitioning data and partitioning execution. In the early sharding models, since partitions were achieved by delegating validators into committees and using collation headers to coordinate consensus on the state of shards (assuming each intra-shard committee was byzantine fault-tolerant), it was necessary that not every validator would store every shard’s state and block data; the problem then becomes that the implicit availability of this information disappears, and there’s no way to guarantee that the data necessary to actually follow the state of the shard has actually been made available without some explicit additional mechanism for doing so.

The problem reappears in the case of plasma-based scaling: the security of user funds is relying on the notion that the operator will actually make the correct data available for users to create fraud-proofs; the data unavailability problem made plasmas and validiums a sub-optimal scaling solution for this reason.

Data availability sampling is a mechanism by which the existence and availablity of network state data can be proven without it being necessary for nodes to download the entire data blob. A simple practical example of this is to assemble committees of validators that each store a random sub-portion of all of the data; this can be combined with erasure coding so as to make it possible to extrapolate an entire blob of data given only 50% of the encoded information. This effectively means that an attacker can only get a shard-block included if its respective data has been made available, which means even a malicious majority cannot open the system up to arbitrary changes —i.e invalid blocks.

The current state of data availability sampling has moved away from being a solution to problems in classical sharding and instead towards a model that positions Ethereum as a kind of lender of last resort for rollup security, acting as a base-layer for rollup data availability. EIP-4844¹⁷, for example, uses blobs to store rollup block-data cheaply —although blobs were still replicated across all nodes; PeerDAS¹⁸ was later implemented to fix this problem, where now the burden of blob storage is distributed across the validator set (with redundancy and erasure coding) to make better use of available resources.

4.6 L2s and the rollup-centric roadmap

The problem of data availability and the limited (payments-only for the most part) use-cases of plasma and validium systems paved the way for a more robust scaling construct to take form: the rollup¹⁹. The rollup-centric-roadmap²⁰ is —as of June 2026— Ethereum’s preferred means of scaling. Rollups are very similar to plasmas with a few key exceptions:

Data availability of transaction data is enforced and secured by the L1.
The root committed to the L1 is the root of a rollup state generally, which means general-purpose EVM computation is supported.
The definition of ‘the operator’ is loosened and made more flexible.

Rollup constructions generally fall into two categories: optimistic rollups and zk-rollups. Both rollup types originally used calldata to store transaction data, but today they use blob-data for cheap storage. Blobs²¹ originally were replicated across all nodes, but today use PeerDAS to distribute the burden across the set of validators; the end goal for data availability sampling is a more advanced form of FullDAS.

The data itself (unlike simple plasma transaction trees that track object ownership) is a batch of —usually compressed— transactions that act on the rollup state, along with an updated state root published on-chain in a special rollup contract. The security in optimistic rollups comes from the fact that if the transactions being executed on the previous state result in a different state root than the one provided, or are otherwise invalid, a fraud proof can be published by any node to punish the rollup operator. Optimistic rollups have a challenge window where these fraud proofs can be published that prove the operator computed the rollup state incorrectly, which means finalizing transactions —and thus withdrawing funds securely— can take up to a week. Zk-rollups are more powerful (but more expensive), as they use SNARKs to prove the validity of the rollup state-transition in (hopefully) the very same block the data was published, which means (assuming the cryptography is sound), instant withdrawals can be enabled.

Widespread accessible data availability for rollups means that in theory anybody could act as an operator and post new batches of transactions to arbitrate a state-change. In practice, a centralized operator is usually the one who takes on this role, which is sometimes combined with mult-signature security councils to handle rollup upgrades or more catastrophic scenarios such as rollup failure.

So even though L2s (usually) inherit verification security from the L1, they do not inherit throughput security. What that means is that the actual role of computing the state of the rollup, deciding which transactions to include in batches, and executing those transactions is delegated to a central operator. This leads to a number of issues regarding properties like censorship resistance, privacy, rollup liveness, operator leverage, and centralization broadly. The existence of a centralized operator also adds a point of leverage that can be used by both the organizational structure that coordinated the creation of the rollup (often venture capital funds for example) and regulatory/nation-state bodies.

The fact that Ethereum mainnet does not hold rollups ideologically accountable means that the user experience becomes the highest value proposition for rollups, as it’s easy to see that a large portion of users are ambivalent to Ethereum’s principles when using the rollup software. This makes the utilization of rollups a race to the ideological bottom, where the higher quality user experience of a centralized base is prioritized over a highly-principled more inconvenient mainnet.

Another way of thinking about how rollups work is that they take full advantage of any consensus and data homogeneity (borrowed from mainnet) with increasingly optimal capacity-utilization, but (usually) make no attempts to improve the capacity-utilization of memory (sequencing transactions) and execution (providing throughput) resources across the wider Ethereum ecosystem, delegating these layers to a centralized operator in a way that is not only inefficient but ideologically perverse.

Truly solving the scaling problem, then, can be said to entail decentralizing —and homogenizing— the provenance of memory and execution, i.e sequencing and computation. Notice that doing so actually inherently means implementing native execution-sharding. As the underlying technology behind rollups improves, the pathway towards a scaling solution that optimizes the capacity-utilization of data, execution and memory, within the ideological purview is becoming clearer.

4.7 Based sequencing and native rollups

Rollups arguably do not achieve execution homogeneity and capacity utilization in the strict sense that would be desired in a pure sharding model. Rollups, in fact, only offload the problem to a higher layer, which introduces a number of efficiency and security trade-offs in the process. Since the data and consensus capacities of rollups are essentially inherited directly from mainnet, it’s easy to see why they effectively use and take advantage of the available resources in these domain, but the throughput domains (memory and then execution) are independent of the L1.

This makes the provenance of rollups and their liveness a social coordination problem: the very existence of any information making changes to the rollup state is provided by an exogenous —often centralized— entity maninnet remains agnostic to. This has an efficiency problem and a security problem:

The efficiency problem comes from the fact that it’s unrealistic that a set of uncoordinated rollup operators could ever optimally coordinate the organization of potential messages in their regions of state relative to the actual needs of users. For example, let’s assume some set of users are making transactions on rollup X for some subjective social reason such as, for example, the applications implemented therein; if rollup X had a user that desired to coordinate with a user of rollup Y, however, there is no way to resolve this in real time without additional synchronous composability mechanisms, since the coordination bubbles are already effectively set in a very rigid form.
The security problem comes from the fact that the rollup ‘liveness engine’ needs to be governed to match the changing L1, but since the L2 state transition function and memory (sequencing) model is agnostic to the state of the L1, this must be done manually by means such as security councils, which introduce a number of uncomfortable trust assumptions into the rollup that users of the L1 never have to make.

Native rollups²² are a proposed solution to the latter security problem that use a native EXECUTE precompile on Ethereum mainnet as a way to provide an in-protocol way to verify rollup state transitions such that rollups fully inherit the L1 EVM state transition function. The execute precompile takes inputs pre_state_root , post_state_root , gas_used , and trace . Calling the precompile essentially verifies that the trace input (a set of transactions) results in the post state root when executed on the previous state root —and uses as gas the provided gas used input. An early set of proposals²³ involved using a single-slot execution delay to allow the validity proof of the rollup computation more time to be computed before being disseminated off-chain in the P2P network; this meant both more time to prove the rollup state transition function, but also, potentially using off-chain proof propagation meant that it would not be necessary to enshrine any single proof-system into all Ethereum clients. Note that in the case of a practical liveness failure of the de-facto rollup prover, it’s still possible for an altruistic prover to provide the proof of validity; originally a native rollup gas limit was proposed to make this assumption more viable —that is, make the native-rollup-proving more accessible. Additionally, advances in realtime proving mean that the single-slot proving delay may not actually be necessary. EIP-8079²⁴ is the latest advance in the native rollup research space.

Based rollups²⁵ are a simple rollup construct whereby the rollup memory layer (the sequencing of transactions into rollup blocks) is re-delegated back onto the ‘base’ L1. This is paradigmatically the same as simply letting any user publish a rollup block, but is unique in the sense that practically we can open up the based sequencing design-space to actually allow for more programmable decentralized rollup sequencing; for example, one model might be designed such that L1-sequenced rollup transactions are directly included into the L1 mempool, and then can be included in a native rollup’s trace input in some programmable way —such as forced ordering by fee. The research space behind based sequencing and what it may entail in the future is still under active research, but when combined with native rollups, they can create a rollup ecosystem that comes as close to trustless mainnet-level security as seems intuitively possible. Designing a system that optimizes the aforementioned efficiency factor of the memory and execution capacities, may have to be approached from a different perspective.

5. Memory homogeneity:

5.1 A brief explanation of the memory layer

The Ethereum protocol in recent years has been regarded as having three layers: consensus, execution, and data. The consensus layer provides the root of truth that allows for agreement on the state of the network, the execution layer enables the computation of changes to the state, and the data layer enables the network to efficiently make use of aggregate validator resources to make available both the state of the network and the blocks computed upon the state. The problem with this limited model is that it makes no attempt to regard how exactly the transactions within blocks come to be executed, that these transactions merely came to exist somehow within execution blocks.

This way of thinking makes the protocol agnostic to how exactly transactions are included in blocks to be computed on the execution layer, which has a number of negative effects in the default setting:

Block proposers extract maximal-extractable value (MEV) from users’ transactions, severely degrading the user experience and going against Ethereum’s core principles.
Block proposers can censor user transactions.
Block proposers have strong awareness of users and their behaviour, degrading user privacy.

This layer can be denoted as the “memory layer” due to the ephemeral nature by which the information is stored and directed towards permanent execution and storage; if Ethereum is a world computer, then the consensus layer is the motherboard, the execution layer the CPU, the memory layer the RAM, and the data layer the disk. The goal of memory-layer-optimizations and architectural changes therein can be said to entail designing a system that provides a fairer and more mainnet-values-aligned block execution pipeline that doesn’t face centralization impending risks, along with scaling and efficiency of block creation and execution.

5.2 Problems to solve on the memory layer

A few open challenges currently exist with regards to making the Ethereum memory layer more aligned with mainnet principles —and scaling-related goals more generally:

Ensuring valid transactions resist censorship from block producers; for example using inclusion list specifications such as FOCIL²⁶ (EIP-7805).
Ensuring MEV is holistically made impossible through constructs such as encrypted mempools.
Generalizing EVM computation by both removing the concept of transactions in favor of general-purpose messages, and by using account abstraction constructs that effectively remove the concept of hard-coded externally owned accounts.
Sequencing transactions directly into execution sub-processes in either execution sharding or based rollup sequencing.

Generally these issues can be said to fall into three categories of memory layer optimizations: decentralizing the process of transaction inclusion to be ‘fairer’ in many senses of the word and to similarly eliminate MEV-related threats to the protocol, to accommodate a more abstract model of EVM message-passing in account abstraction, and to coordinate the inclusion of transactions (sequencing) in a more efficient manner —whether within a sharding-based or rollup-based scaling model.

5.3 Sharded/virtual mempools

A holistic solution to the centralization problem of the memory layer involves implementing a transaction inclusion/sequencing (mempool) scheme that not only decentralizes the process to be fairer but in the process conceptually homogenizing it to optimize capacity utilization in the case of scaling through execution-sharding or rollups. A general paradigm for doing this might be to create a kind of decentralized and sharded virtual mempool whereby the transactions being sequenced into blocks are coming directly from some kind of weak consensus within the memory layer. Inclusion lists already do exactly this by implementing mempool-level ephemeral statistical consensus, but a more holistic virtual mempool model is powerful for both the purpose of censorship resistance and of scaling the capacity utilization of network memory in order to accommodate increasing execution capacity. A basic virtual mempool implementation may have the following properties:

Censorship resistance is enforced through forced inclusion.
MEV is eliminated through forced ordering.
Based sequencing is used to direct transactions into execution shards and/or rollups.

Optimally a considerable portion of aggregate validator resources may be deployed to synthesize this virtual mempool in order to ensure high capacity utilization and decentralization of the memory layer.

An optimally homogenized memory layer would resemble the virtual mempool construct, whereby validators coordinate to sequence transactions into execution shards in a way where no single validator has full autonomy over all of the sequencing. Notice that it isn’t inherently true that a homogenized execution layer would entail a homogenized memory layer: execution of blocks may be optimally homogenized, but every homogeneous batch of execution might just be sequenced by a monolithic builder/proposer-like role. Memory sharding through virtual mempools can lead to extremely high throughput when combined with execution sharding, however, and can (depending on the implementation) bring all of the benefits of forced-inclusion and forced-ordering along with it.

6. Execution homogeneity:

“You cannot do anything on the Ethereum Blockchain you couldn’t do on a smartphone in 1999.” —Vitalik Buterin

6.1 General principles

All paradigms of blockchain scaling often exhibit common properties exemplary of the nature of the problem itself: trying to achieve high levels of throughput, which can loosely be defined as the amount of coordination (in an abstract sense) happening per unit of time; simplistically, a blockchain is an infrastructural layer for enabling this coordination. Unfortunately this coordination has an opportunity cost: that is, the mere ability to coordinate with other users on a blockchain creates a margin of additional overhead relative to how many other users one can potentially coordinate with over some period of time. The naive blockchain model where all computation happens sequentially and all state and execution is replicated represents the purest form of this dilemma: every single user has the ability to coordinate with any other user at any time in the blockchain’s history, which makes it necessary to compute the aggregate of the throughput on a single execution thread.

The scaling solutions mentioned in section 5 can be described in terms of potential coordination over some period of time:

State channels allow any N users (in practice usually two) to coordinate instantaneously, in that all N users must be online and interactive for the coordination to occur.
Plasmas and validiums allow some static K users to coordinate, where K < N (the total set of users of the main chain) at any time —assuming the honesty of a trusted operator; users who want to coordinate with the larger set of N must incur some delay (challenge window) or additional overhead (validity proof) and can only do so with rigid separation between K and N.
Rollups, like plasmas and validiums, allow static K < N rollup users to coordinate, not necessarily trusting an operator, with the same rigid separation and overhead for coordination with non-rollup users as plasmas and validiums.

In theory you’d imagine that state channels would be the optimal form of scaling: they use an extremely minimal amount of data and computation on mainnet, only using it as a lender of last resort for security and a consensus root of truth, and theoretically allow the set of coordinating users to be unbounded. The problem is that although technically all state channel users can coordinate, coordinating users must be online and active for the coordination to occur, which makes the entire league of applications that require asynchronous interaction impossible. State channels are truly the strictest form of off-chain computation: they strip down the overhead on mainnet to the bare minimum (finality) and offload everything else (liveness, data, execution, settlement) to the users.

Plasmas are a step up in terms of asynchronous coordination, as they essentially implement a similar mechanism to state-channels, just where the execution and data is offloaded to a trusted operator. Ignoring the problems associated with trusting the operator, plasmas also introduce the additional bottleneck of much longer (or more expensive) exit windows and an inability to easily coordinate interactions with users of other plasmas or the main network (this is because, due to asynchronous coordination, proof-systems must be used for exiting, rather than just having the entire set of users agree to exit like in state channels), which constrains the set of possible coordinated interactions to interactions with users of the plasma itself.

Rollups effectively come close to eliminating the trusted operator problem, but keep the constraints related to the strict separation of internal and external users in place, which limits the coordination space in an extremely rigid way.

The naive all-encompassing coordination space of L1 is intuitively flawed: every user pays an enormous opportunity cost in terms of transaction speed and network throughput for the ability to coordinate with every other user, which is totally redundant for the vast majority of use cases. The goal then is to create a mechanism that allows users to coordinate with as many other users as possible, with as much flexibility over when that coordination can occur as possible, without exposing the users to any additional overhead due to marginal potential coordination that they will never take advantage of.

6.2 Depth-first vrs breadth-first scaling

The intuition that actually the set of users that any other user may seek the opportunity to coordinate with —hopefully asynchronously at any time— leads to the natural conclusion that actually the ideal form of scaling is a mechanism that allows for the network’s execution, data, and memory space to be ‘sharded’ or partitioned in some way to optimize for the most effective permutation of sub-rooted coordination spaces (shards, rollups, plasmas, etc…) relative to the set of potentially coordinating users.

Since any partitioning of the execution and memory space inherently creates friction between spaces, solving the problem of modulating the spaces to encapsulate a set of users in such a way that optimally represents their pursued set of users to coordinate with is a challenging problem, and the historical solutions usually have ended up being highly rigid anyway, where filling the gaps with cross-region messages/transactions is an even harder problem to solve. One of sharding’s largest historical challenges was actually managing the ‘shape’ (the enclosed sub-region of the network) of these shards in a way that accurately reflects the coordination needs of the users.

Rollups are a quasi-effective solution to half of this problem, as they effectively delegate the role of coordinating the creation of the execution and memory region to the rollup social and governance structure; there’s a well-defined understanding of what exists inside and outside of the rollup, where users have full autonomy to decide which rollup contains a set of users that accurately reflects their needs. The intuition, however, is that the problem still exists: rollups do not solve the problem of modulating the permutation of sub-regions to optimize for the set of coordinating users, it just offloads the problem to the social layer; rollups arguably are the closest we have come to sharding-level capacity-utilization, but the coordination problem of delegating the execution and memory processes optimally still exists.

An argument can be made that any scaling solution that offloads the delegation of resources to the social layer is a scaling solution that works by scaling in depth, i.e in new protocol ‘layers’ through depth-first scaling. On the other hand, native-sharding solutions resemble breadth-first scaling, in that the burden of execution and memory resources is delegated across the breadth of the network, i.e the existing set of validators/builders; the actual distribution of resources is far more optimized for capacity utilization in breadth-first scaling, since the delegation of execution and memory is more homogenized across the set of all validators/builders (potential sources of throughput), not just offloaded to a separate social layer entirely. The nature of the network remains exactly the same though: some set of transactions will enter network memory; if rollups are based, rollup transactions themselves are sequenced in L1 memory, otherwise they are sequenced through some other external socially coordinated mechanism; and then they are executed within sub-regions of execution based on the users’ own autonomy to choose a region they believe allows them access to a set of users they desire to coordinate with. Regardless of the system of scaling, all transactions across rollups, plasmas, and mainnet are ‘Ethereum’ transactions from first-principles, it’s just a question of what route they take into the world-computer.

The realization is that actually execution sharding and rollup-based scaling are practically identical when taken to their logical conclusion: rollups only work due to the fact that they make inherent tradeoffs (long/expensive exit windows, centralized execution and memory); if those tradeoffs didn’t exist, such as by using instant exit with zk-rollups, synchronous composability based on realtime proving, based sequencing, and execution being delegated to mainnet validators, rollups would effectively have implemented execution sharding in a sort of roundabout way. The end-goal of execution then can be said to be homogenizing the delegation of the execution of throughput across the set of as many validators as possible in a way that resembles execution sharding, in such a way that allows users to coordinate in a maximally effective way, across any period of time asynchronously, without baring costs for potential coordination they may never utilize.

Solving this problem within the previous definition means that it is inherently the optimal form of scaling: any increased overhead or bottleneck in actually managing the delegation of throughput and coordination is required to be lower than the decrease in costs for the coordinating users, while maintaining the desired level of decentralization of builders and validators. Solving this scaling equation entails solving the blockchain trilemma in its purest form. Using the naive replicated blockchain model is a non-solution, as it necessarily decreases the set of potentially coordinating users due the high costs of coordination for everybody, which actually makes the cost of coordination per-user more expensive than it could very well be in a seemingly-more-costly execution sharding system.

6.3 Dynamically optimized realtime execution sharding

A large part of the problem with sharding was the difficulty in managing the permutation of shards —essentially execution sub-regions— in a way that can not only accurately reflect the number of coordinating users, but the precise permutations of users who actually want to coordinate with one another. The problem with both rollups and historical sharding proposals is that they look at homogenization from the wrong perspective: they first create the coordination space, and they assume that the users can organize themselves in a way that works around these execution sub-spaces; really, the goal should be to first determine the coordinated needs of the users, and let the organization and delegation of execution resources adapt to these signals. This is in fact easier said than done, but a potential solution lies in particular in the memory layer.

In itself the idea of a virtual mempool, which can loosely be defined as a sequencing mechanism (a mechanism that organizes how and when transactions are included in execution blocks), is beginning to exist in some rudimentary form in Ethereum today: the Glamsterdam hardfork, for example, will use inclusion lists (forced inclusion of transactions) to solve censorship resistance problems), but there are a number of unique ways that the memory layer’s mechanisms can be improved through the utilization of this idea of a sharded (virtual) mempool that is more organized and coordinated than the existing local one.

A theoretically optimal implementation of execution sharding might use a virtual mempool construct to effectively coordinate the sequencing of mempool transactions into specific execution shards in a way that is determined by the sequencing itself; what that means is that the set of transactions that can be included as valid functions on the state are aggregated in a homogeneous memory layer model so as to compute the optimal permutation of execution shards to maximize the most efficient use of resources relative to what transactions access what areas of the state —which tells you what transactions can be executed in separate shards and what transactions need to be synchronously composed between those temporary execution shards. These execution shards more resemble ephemeral zk-rollups created in real time to match the coordinated actions of the set of live transactions than traditional shard-chains. Not only does such a system allow Ethereum to optimally change the ‘shape’ of the execution layer to match the transactions users are initiating, but it also eliminates the tight coupling problem of older sharding proposals: the system is always adapting to take advantage of the mid-to-best-case of parallelism, but the only negative effect on the system in the worst case is that it degrades down back to the level of throughput of the (current) monolithic model; the whole chain doesn’t break down if one temporary execution shard fails in some sense of liveness, as those broken shards are just pruned out of the chain’s root of truth.

In a sense this kind of adaptive realtime execution sharding is theoretically optimal, as it uses the breadth of the network to accommodate the maximum amount of throughput instantaneously needed (and possible to accommodate), but in the worst-case-scenario it simply falls back to the current naive model.

7. Execution sharding:

“Give me a large enough SNARK, and a chain upon which to place it, and I shall prove the world-computer.” —Aristotle

7.1 Consensus root of truth

All blockchain models conceptually are consensus mechanisms that encapsulate some kind of state transition function; or in other words, a consensus chain that encapsulates an execution chain. The blockchain trilemma stems from the tight coupling of the consensus throughput from the execution throughput: in the naive model, the consensus chain essentially replicates the throughput of the execution chain in order to validate it. The current model in Ethreum is to use the consensus chain to elect a single validating node to transition the execution chain, whereupon the execution can then be wholly replicated by every other validator of the consensus chain. This effectively collapses the entire network —and the aggregate of validator resources— down to one ‘virtual validator’ that incorporates all of the decentralization of the aggregate for security’s sake, while collapsing the virtual validator’s throughput down to the singular. Execution capacity-utilization is essentially leveraging the aggregate of the validator resources for throughput’s sake. These two roles, providing security and providing throughput, are fundamentally separate, but it takes three separate protocol-level changes to realize the benefits of this:

The role of proposing/building an execution block is separated from the role of attesting to that block, which means validator security (consensus throughput/breadth) is provided by potentially low-resource network nodes, while the throughput comes from high-resource network nodes.
The verification mechanism for attesting validators is based on validity proofs instead of naive replication, which means the consensus depth can expand arbitrarily while attestor hardware requirements remain constant.
Since the only negative effect of increasing proposer/builder requirements then becomes a relative constraining of who can participate in proposing execution blocks, we can expand the hardware requirements of doing so to be closer to that which is already required to stake (Ξ32), which means much more scale can be accommodated without sacrificing on decentralization.

The question then becomes how the throughput of the execution chain can be maximized, without the consensus-level bottlenecks that might’ve previously appeared from this increase in throughput needing to be considered. The current model of relying on a single builder/proposer entity is inherently limiting for this reason, as it still constrains the execution throughput to that of any one proposer/builder. The goal is to take the set of potential transactions to be included, and, instead of executing them on a single thread (within a certain gas limit), we can execute them in parallel across a larger set of proposer/builder validators, within whatever limit to parallelism that exists due to Amdhel’s law. In other words, the question is essentially how we can leverage an arbitrary amount of proposer/builder validator computation to execute an arbitrary number of transactions across separate threads while ensuring all computation can be propagated upwards in such a way that it is succinctly provable and contained within the consensus layer’s root of truth.

7.2 Virtual mempools

Many of the statements made in this document regarding approaching sharding from the perspective of optimizing the delegation of execution throughput relative to the actual coordination requirements of transactions, as opposed to approaching it from the perspective that rollups and and historical sharding proposals do (create the execution sub-regions first and let the users come to them), are assuming some notion of realtime knowledge of the transactions that will be potentially included in an execution block before the state transition is even computed. This is a very different way of thinking about mempools in blockchains than the current model does where builders/proposers have full autonomy to decide upon a set of protocol-agnostic local mempool transactions to include in blocks. We thus require some kind of in-protocol mechanism to coordinate a shared temporary memory between builder/proposers.

A simple solution to the problem of synthesizing this virtual mempool is to leverage the existing signature aggregation mechanism that exists on the consensus layer. Instead of just aggregating XMSS signatures (slot attestations) with post-quantum SNARKs, attesting validators could also sign a local view of their mempool (within a certain bound such as the block gas limit) ordered by priority fee; the structure of the local view could be simplified to a list of transaction hashes paired with access lists; transactions broadcasted by users can potentially be SNARK-proven to be valid operations to make inclusion in the virtual mempool much easier. The aggregation committee could then enforce some kind of ruleset upon the aggregated mempool-views such as that any transaction not seen by a super-majority of the committee’s validators must be dropped. Any committee member can then creates a SNARK proof that essentially takes all of the transactions seen by a super-majority of validators and aggregates them into a separate higher-layered virtual mempool view; this then continues recursively. The result is that once the aggregated local mempool views reach the root of the tree, a block gas limit’s worth of ordered transactions seen by a super-majority of validators is assembled into a lightweight list replicated by every validator; the transactions and corresponding access lists can then be directly delegated into the next single-block, or, more desirably, delegate the execution of the transactions across execution committees in parallel. Not only does this implementation bring efficiency gains due to optimization of capacity utilization drawn from increased parallelism, but the virtual mempool itself can bring structural benefits such as increased censorship resistance and MEV-resistant sequencing.

In the simplified model where every validator replicates the same state, having every attestor commit to a block gas limit’s worth of mempool transaction hashes and access lists would likely be tenable in terms of bandwidth. For the purposes of execution sharding, though, we’re assuming we can handle more throughput than any one validator could on their own, which means it would be unsustainable to propagate the entire multi-shard gas limit’s worth of transactions upwards recursively, since the gas limit here is assumed to be many times higher than the limits of an individual validator (the bandwidth requirements could end up being far too high).

Assuming the state data is homogenized in an execution sharding model, it makes sense then to stop working the virtual mempool around the signature aggregation tree and instead structure mempool committees at the bottom of the tree based on specific portions of the state. Validators could be chosen in advance to commit to a local mempool that contains transactions that touch certain random combinations of areas of the state (potentially regardless of what they store themselves), which means the validator can then search for these transactions on the networking layer in advance and commit to transactions that touch those state objects as their local mempool view. Then, rather than propagating the hashes and state accesses upwards, the aggregating committees drop the hashes and only track the state accesses in aggregate, which means the root of the tree will essentially contain a record of state accesses measured by the amount of gas consumed by the aggregate of accesses for each portion of state. Not that the transactions propagated upwards from the root of the tree are based on which portion of the state the transactions enter into, and that any additional state accesses the transactions make will be dealt with when computing the execution committee structure.

In this case rather than the upward propagation of transactions being limited by a single-block gas limit, they can be limited by a sub-block gas limit that is effectively that of an entire single-block in a heterogeneous model; this means multiple full blocks can be executed in parallel based on the state accesses aggregated from the virtual mempool. Note that the virtual mempool in this case is used only as a relative optimization of the execution committee structure based on the memory layer’s probabilistic view on upcoming state accesses; the actual execution is happening within those committees with autonomy on the transactions included (within the limits of the region of state that committee is delegated to execute upon), since forcing the entire network to agree on exactly which transactions will be executed by which committees comes with far too much overhead. The assumption is that the networking layer can be used to coordinate the distribution of the transactions used to synthesize the virtual mempool to the correct committees in time, and then committees can make a best-effort to include as many of those transactions as possible in their sub-blocks; incentives (such as a committee’s aggregated state accesses during mempool synthesis being included rewarding them) can be deployed to incentivize this kind of well-coordinated behavior rather than relying on altruism.

It’s worth noting that this isn’t a holistic optimization of capacity utilization, since, taking this virtual mempool mechanism to its logical conclusion, it’s clear that eventually the sheer bandwidth of data required to aggregate the state accesses will eventually make scaling any further impossible; this also means we not only must limit the gas limit of a sub-block, but somehow set bandwidth-limited constraints on the number of sub-blocks (and thus execution committees) that can be included. While it’s true that even this bottleneck is potentially preceded by a large margin of scaling from increased capacity utilization, a solution that is not bound by bandwidth limits would bring far more scaling gains.

7.3 Execution shard permutations

Once a mechanism is in place to —at least probabilistically— determine the state of an aggregated mempool view, the information can be used to determine the optimal way to shard/partition the execution of the next block across execution committees who compute throughput across sub-blocks. This means there must be some deterministic algorithm replicated across all validators that allows consensus to be reached on the state of the next permutation of committees. A simple algorithm for doing so looks like this:

Separate every transaction (or state-access batch as described in the previous section) into separate execution columns based on their state accesses.
For every transaction that has N > 1 accesses, if the sum of the gas used by all N execution columns of state accesses is less than the sub-block gas limit, combine them into one column that includes the intersecting transaction; otherwise delegate it to an execution column at a higher layer.
Aggregate all other execution columns below the sub-block gas limit into singular columns below the sub-block gas limit.

This algorithm will coordinated the distribution of disjointed execution, which can be used to inform the creation of the execution committees themselves that will execute these execution columns/sub-blocks in parallel.

In practice the structure of the columns would likely contain a number of sub-blocks with increasingly specific portions of the state accesses (such as transactions from a single application or ecosystem), but also a number of sub-blocks that contain the leftover transactions that essentially touch no central piece of state (such as EOAs and smart contract accounts or basic programs). It’s worth noting that step two in the delegation process can sometimes devolve higher-layered intersections to one aggregated sub-block, but in the case where they can’t due to the gas limit (for example the grey columns in the figure above), they must be executed by separate committees at higher layers.

7.4 Execution committees

The execution committees are the actual entities that execute the disjointed throughput in parallel, and whose computation is recursively aggregated and propagated upwards into the consensus chain’s root of truth. The members of the committees themselves are essentially just builder/proposer entities in attestor-proposer separation. The initialization of their role can either come from an execution-tickets-style auction market, or through simple random selection where proposers are selected in proportion to their stake registered into a distinct proposer registry.

There are major benefits to separating the role of the attestors and the proposers for many reasons. To see this, it’s worth understanding the current heterogeneous model: today, the Ethereum consensus chain does not separate the role of an attestor and that of a proposer of execution payloads. Execution blocks are proposed by randomly selecting a proposer to execute the state transition function, and having every attestor validate the payload by replicating the same execution; this means that not only is the network’s throughput limited by the maximum computational capability of the lowest powered attestor (since they must have the time to validate through re-execution), but as a result, every attestor by definition must meet the same hardware requirements as the proposers of execution blocks. The result of this is that the amount of verification happening is bound by the amount of computation. Even naive statelessness does not solve this problem: if every attestor can potentially be a proposer, every attestor must still meet the hardware requirements to propose execution blocks; a better system than is one where these roles of attesting and proposing are strictly segregated, which allows the amount of verification (attesting) and thus security of the chain be unbounded, where participation is possible on minimally-powered hardware, while the computational throughput is virtually unbounded and managed by specialized higher-powered proposing nodes.

This means that, since the staking requirements of a validator in Ethereum include posting Ξ4 as collateral in Lean consensus, the hardware costs of proposing execution blocks can be equivalent to roughly that exact amount without any loss in decentralization. The problem still remains, however, that the limit of the network’s throughput being equal to the (in this case a much higher) maximum computational capability of the lowest powered proposers. The goal of execution sharding is to attempt to utilize close to the entire set of proposer resources to maximize capacity utilization on the execution layer. It’s almost absurd the idea that there are 100s of thousands of potential proposers every slot, but at any one moment, only one of them is contributing to execution throughput, while the rest lie idle. A very positive side-effect of forcing every additional validator (in terms of marginal staked ether) to contribute equivalent execution resources on a per ether basis is that actually it makes economies of scale not just not non-linearly profitable, but actually directly less profitable than solo-staking; this is because an initial home-staker holding Ξ4 is naturally more likely to have a single personal computer capable of running a proposing validator node, whereas an Ξ8 holder will likely have to bare additional costs of acquiring a marginal computer, not to mention that as this equation scales, more centralization means more non-computational infrastructure like warehousing and equipment, whereas home-stakers can simply, well, use their homes.

The committees themselves are structured as follows: X committees of Y > 1 (for redundancy) proposers are delegated across X execution columns to compute the corresponding sub-blocks in parallel; then, an N-ary tree system is used to delegate a number of proposers to super-committees that aggregate N sub-blocks. Increasing N means more bandwidth and verification time is required for each aggregating committee, but that more work can be done in parallel. This process is simple for the naive case where state is replicated across all validators, but in the case where state is sharded, the process is much more difficult, as execution committees cannot simply be selected at random —they must be selected to compute columns based on what state they store; this becomes an increasingly harder problem as we begin to incorporate execution columns that are intersecting and need to be resolved at higher layers of the tree, as it effectively means we must find a committee of nodes who just so happen to store the exact areas of state in question. A potential solution to this is to structure the state trie as a vector commitment (verkle-like) tree in such a way that it means that committees at higher layers can simply receive efficient state proofs from the lower-layered committees in order to resolve intersecting columns, but this still assumes that the committees at the bottom of the tree have access to the correct state to compute the initial transactions of execution columns. This system can even be integrated holistically, where every transaction must by include a state-proof (potentially from the user), which means that the protocol can be agnostic to which validators store which state when selecting committees; this is also a major benefit for security as it makes the committee-structure much more unpredictable. Managing state distribution efficiently in this kind of system is a challenging problem.

7.5 State and data availability

As execution sharding begins to accommodate more throughput and scale, managing the data and state overhead starts to become a major burden on validating nodes; sharding the state then seems like a necessary component of any effective execution sharding model. A simple model using data availability sampling might function as follows:

All of the state data is segmented into a large number X of data blobs. A larger number means more precise and unique combinations of state storage exist for nodes (which is good for execution sharding) but more overhead in verifying commitments.
These blobs are 2-dimensionally erasure coded in proportion Y; this means only 1/Y of the entire state is needed to rebuild everything, ensuring redundancy.
Each blob is distributed to Z random proposing validators every epoch. To avoid the problem of every validator’s stored state being refreshed every epoch, only K% of the data stored is refreshed for each validator; they must then acquire this data on the networking layer.

It’s also worth reconsidering the economics of state-storage in the current model. Currently, not only do all nodes replicate the world-state, but this state is stored for eternity. This is fundamentally an economically erroneous state management model, as it inherently makes validators pay an infinite cost in storage overhead while only receiving fixed fees from the transacting users.

A far better model would use state expiry²⁷ to ensure that users of the state have to pay fair fees that actually pay for storage in proportion to how long the state is being stored for; to avoid inconvenient user experience problems stemming from state expiration, a vector commitment tree can be used to ensure that users have the ability to recover state objects using cryptographic proofs in the case where expiration does occur. Optimally though, even the commitment to a state object must expire eventually on a long enough time-frame. This commitment system can also be used during sub-block execution; to ensure that committees at higher layers have access to the necessary state objects, the lower committees can propagate state proofs upwards. Potentially new forms of state can also be supported, whereby users can opt in to only ever using proofs to initiate transactions. State storage costs can also use an EIP-1559²⁸-like mechanism to price storage costs based on a target total state size. A similar mechanism can be incorporated into smart contracts themselves, where to avoid tragedy-of-the-commons problems where no individual user will pay the state cost for a public contract, potentially every transaction to the contract is forced to pay a state storage fee that delays expiration, but that this fee becomes exponentially smaller and delays the expiration exponentially less relative to the length of the expiration time; this effectively forces all users of a contract to support its availability into the future.

The actual data availability proving can occur in the same recursive tree that XMSS aggregation and virtual mempool synthesis is occurring; nodes potentially can then incur penalties for not proving data availability, and subsidies otherwise. Validators storing specific portions of the state also helps the game-theory behind execution sharding: validator rewards can be engineered such that the priority fees for transactions in sub-blocks are distributed across the set of validators that store the state the transactions access, which means there’s an incentive for them to make sure that those transactions are propagated effectively to the right mempool attestors and execution committees.

7.6 Execution trees

This kind of recursive homogenized throughput from parallel execution columns would be impossible without some form of succinct verification for the actual throughput being recursively aggregated. The aggregation itself uses recursive SNARK proving to succinctly prove all execution columns with one SNARK at the root. This recursive SNARK aggregation of execution columns is called an execution tree. It essentially works as follows:

Any member in a committee at the base of the tree computes a sub-block (preferably without constraints like forced inclusion and ordering) that executes transactions on the subset of state they are delegated to execute upon. They then create a SNARK proof of their block based on the transactions they executed and the post-state, also providing any state proofs necessary both for proving and for the successive layer’s own computation.
Any member in a committee at the successive layer aggregates a number of these proofs and verifies them, taking the highest-capacity sub-block they have found for each aggregated column. They then execute any transactions that intersect any of the states of these sub-blocks (higher-layer columns), creating a new aggregated proof that they propagate upwards to the next layer.
This process continues recursively until a root proposer committee is reached who propagate the full execution block.

Recursive aggregation means that not only are transactions being parallelized, but the resolution of dependencies between execution shards are also being executed in parallel where they can. This has some interesting implications for the user experience: the cheapest transactions will be the ones where execution can happen at the base of the tree (for example all transactions that only touch one state object), and transactions that need to be executed at higher layers will be exponentially more expensive. The nice thing about this system, though, is that because there are sub-blocks being executed at every layer of the tree, you’d expect that the cost of being included in the root sub-block would essentially be as expensive as it would be in the current system where only one block is executed. To be exact, because the actual bottleneck of throughput in the execution tree is logarithmic, the cost of an extremely inefficient multi-state transaction that must be executed at the root of the tree will essentially be the cost in the current system + a small additional cost that is logarithmic to the total throughput.

Another great property of execution trees is that even if the level of redundancy in execution committees’ members is not enough, and there ends up being some kind of asynchronous network failure at any point in the tree, the result will be that the committees at higher layers interpret it the same way they interpret empty slots today. This removes the issues related to tight coupling that existed in previous sharding architectures, where one failure in any shard would compromise the entire network. The nice thing about execution trees is they essentially optimize for the mid-to-best case scenario at all times, but in the worst case the network falls back to the current system. Note that constructs like multi-threaded gas are not necessary since there’s already an implied cost that transactions bare relative to the complexity of their state accesses, which effectively already incentivizes transaction-level parallelism.

7.7 Universal coordination tree

“You cannot grow an infinite-garden without planting some damn trees.” —Unknown

I mentioned when describing the virtual mempool system that actually the process of constructing the virtual mempool can happen within the existing signature aggregation tree, which removes the technical and coordination overhead of managing a separate recursive tree mechanism in parallel. I separately described how the state-availability-proving can co-occur within this same tree. Taking this a step further, it’s worth considering whether or not it may be possible to actually run the execution tree within the same tree as this signature aggregation, virtual mempool synthesis, and data availability proving. Doing this means we can potentially run the entire Ethereum consensus, memory, data, and execution layers within a single recursively aggregated structure, which has a number of benefits:

The entire protocol is overall more efficient due to lower technical overhead.
We’re not splitting validator resources and duties across separate processes, which makes the entire network easier to synchronize.
The separation of validator duties between attestors and proposers is far more clear cut, and easier to modularize: they are effectively the same role, but attestors simply leave the execution and data fields empty when propagating their data upwards in the tree, and they are not included in data and execution-related validator duties.

Since the structure of the execution tree is actually not random, and rather determined by the virtual mempool, it must be created first, and then essentially enclosed within the wider aggregation-memory-data tree. The somewhat-predictable nature of execution committee-structure stemming from delegation based on stored state is one of the reasons why relying on state-proofs for transactions (which means any validator can execute it correctly regardless of their own state storage) is beneficial for security.

Initially this seems like a meaningful improvement over the alternative of running two separate trees in parallel. It’s worth considering, however, whether the lack of randomness —and relative predictability— of the execution tree’s structure can become a security risk: in the case where the majority of staked validators are —potentially executing— proposers, and where the majority of these proposers are being delegated into relatively predictable execution committees, it may be easier to execute network attacks such as coordinating malicious signing among a sub-rooted committee of attesting validators, or just simply DOS attacking specific validator committees in order to achieve economic majority and finalize a malicious chain. It would be worth considering these caveats before deciding upon what kind of mechanism to use for the aggregation of execution, data availability proving, virtual mempool synthesis, and validator attestations.

7.8 Limitations and comparison to existing systems

Paradigmatically this manner of execution sharding is very similar to plasma/rollup-based scaling; it’s just a matter of how capacity utilization itself is achieved, and what trade-offs are made along the way. Interpreting the history of sharding and Ethereum scaling provides many valuable insights into the nature of the problem of achieving capacity utilization: state channels delegate social coordination to the users explicitly in quite a dynamic way, but removes the asynchronous infrastructural layer that is necessary for many use-cases; plasmas and validiums bring asynchronous coordination back to the users, but shifts the problem of data availability and execution to a trusted operator in the process, while also placing the coordination-space into rigid bounds within the plasma itself; rollups largely remove the trusted operator problem, but the social-coordination problem and rigid execution-space remains; based-native rollups go even further in the way of removing trust, but don’t attempt to solve the coordination problem in any way.

In a way execution sharding is an attempt to take full advantage of the trustless data availability, succinctly verifiable execution, and based sequencing of based-native rollups, but while using native state availability, virtual mempool sequencing, and execution committees to make these scaling advantages not only truly trustless and seamless, but also implemented in such a way that can be deployed in realtime to create what could be said to resemble a kind of adaptive temporary initialization of rollups in order to maximally utilize the capacity of the network and optimize the execution of operations on the world-computer based on the realtime coordinated actions of the full set of users. The intuition here is that any transaction broadcasted to either the Ethereum mainnet or a satellite rollup is an “Ethereum” transaction in an abstract sense, and that the goal of scaling should be to scale the number of these transactions that can be accommodated while both keeping them within the ideological purview of mainnet and delegating their execution as efficiently as possible in a way that is seamless to the user.

This kind of native execution sharding, however, does come with innate challenges and additional complexities that are often very easy to simply delegate to rollups without any tight coupling between the security of mainnet and these satellite networks. Issues like the overhead of managing the virtual mempool, the difficulty in synchronizing an execution tree, and the complexities involved with sharded state may prove too risky or too technically challenging to justify implementation.

8. Conclusion

This document was intended to serve as a holistic account of Ethereum’s execution layer in the context of Lean Ethereum: the very nature of blockchain execution, execution scalability, the powerful paradigm of resource homogenization, what it means to achieve capacity utilization, and how a potentially ideal form of scaling can be found by interpreting the history of Ethereum sharding/scaling —leading to why conceptually execution sharding demonstrates what this optimal form of scaling might look like. We introduced Lean Ethereum as not only a technical roadmap, but also a frame of thinking; the history of blockchains, and some fundamental intuitions that can be gained from this history; the paradigm of homogeneity and capacity utilization, and why it represents the ideal form of scaling; a comparative history of sharding, and the important conclusions drawn therein; perspectives on the nature of the protocol’s memory layer; and finally we discussed execution homogeneity, and a conceptual framework for achieving it through execution sharding. Whatever the path to optimal scaling looks like in the world of Lean Ethereum is yet to be determined, but either way, the world-computer will keep computing, and its shining light will remain a beacon of hope for future generations to come; we have a responsibility to accommodate their coordinated actions. Regardless of the way constructs like rollups, validiums, and based sequencing may play a role in the future of Lean Ethereum, we strongly believe the path towards a unification of Ethereum’s four protocol layers on the L1 is on the horizon, and that reaching this destination will represent the zenith of Ethereum’s climb towards self-sovereign computation for the world-computer and all that she beholds.

All roads, one might find, lead to the infinite garden.

References:

[1] Justin Drake, “lean Ethereum”:
https://blog.ethereum.org/2025/07/31/lean-ethereum

[2] Lean Ethereum Roadmap:
https://leanroadmap.org/

[3] Satoshi Nakamoto, “Bitcoin: a Peer-to-Peer Electronic Cash System”:
https://bitcoin.org/bitcoin.pdf

[4] Scott Stornetta, Stuart Haber, “How to time-stamp a digital document”:
https://link.springer.com/article/10.1007/BF00196791

[5] Vitalik Buterin, “Ethereum: a Next-Generation Smart Contract and Decentralized Application Platform”:
https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf

[6] Justin Drake, "Pragmatic Signature Aggregation with BLS”:
https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105

[7] Vitalik Buterin, "An Explanation of the Sharding + DAS Proposal”:
https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS

[8] epf.wiki, “Attestor-Proposer Separation”:
https://epf.wiki/#/wiki/research/PBS/ET

[9] epf.wiki, “Enshrined Proposer-Builder-Separation”:
https://epf.wiki/#/wiki/research/PBS/ePBS

[10] wikipedia.org, “Shard (database architecture)”:
https://en.wikipedia.org/wiki/Shard_(database_architecture)

[11] Gang Wang, Zhijie Jerry Shi, Mark Nixon, Song Han, “SoK sharding on blockchain”:
https://dl.acm.org/doi/abs/10.1145/3318041.3355457

[12] Satoshi Nakamoto, “BitDNS and generalizing Bitcoin”:
https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

[13] Vitalik Buterin, “Sharding FAQ”:
https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html

[14] Jeff Coleman, “State channels”:
https://www.jeffcoleman.ca/state-channels/

[15] ethereum.org, “State channels”:
https://ethereum.org/developers/docs/scaling/state-channels/

[16] Vitalik Buterin, “Exit games for EVM validiums: the return of plasma”:
[https://vitalik.eth.limo/general/2023/11/14/neoplasma.html(https://vitalik.eth.limo/general/2023/11/14/neoplasma.html)

[17] Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo, Ansgar Dietrichs, “EIP-4844: Shard Blob Transactions”:
https://eips.ethereum.org/EIPS/eip-4844

[18] Danny Ryan, Dankrad Feist, Francesco D’Amato, Hsiao-Wei Wang , Alex Stokes, “EIP-7594: PeerDAS - Peer Data Availability Sampling”:
https://eips.ethereum.org/EIPS/eip-7594

[19] Vitalik Buterin, “An Incomplete Guide to Rollups”:
[https://vitalik.eth.limo/general/2021/01/05/rollup.html(https://vitalik.eth.limo/general/2021/01/05/rollup.html)

[20] Vitalik Buterin, “A rollup-centric ethereum roadmap”:
https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698

[21] Vitalik Buterin, “Ethereum has blobs. Where do we go from here?”":
https://vitalik.eth.limo/general/2024/03/28/blobs.html

[22] Justin Drake, “Native rollups —superpowers from L1 execution”:
https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517

[23] Luca Donno, Connor McMenamin, “Native Rollups: Where they are, and where they are going”:
https://medium.com/l2beat/native-rollups-where-they-are-and-where-they-are-going-cb21eb103d46

[24] Luca Donno, Justin Drake, “EIP-8079: Native rollups”:
https://eips.ethereum.org/EIPS/eip-8079

[25] Justin Drake, “Based rollups —superpowers from L1 sequencing”:
https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

[26] Thomas Thiery, Francesco D’Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann, Jihoon Song, “EIP-7805: Fork-choice enforced Inclusion Lists”:
https://eips.ethereum.org/EIPS/eip-7805

[27] Guillaume Ballet, Wei Han Ng, “EIP-7736: Leaf-level state expiry in verkle tree”:
https://eips.ethereum.org/EIPS/eip-7736

[28] Vitalik Buterin , Eric Conner, Rick Dudley Matthew Slipper, Ian Norden , Abdelhamid Bakhta, “EIP-1559: Fee market change for ETH 1.0 chain”:
https://eips.ethereum.org/EIPS/eip-1559