The Surge
The Surge
.
specification
implementation
rollup
scaling
(diverse 6-of-8 or stricter)
self-healing
rollup
scaling
wheels
commitments
rollup standards
+ interop
Optimistic Rollups
Live | Stage 0 & 1
Optimistic Rollups process Ethereum transactions off-chain and post results to the mainnet, assuming transactions are valid unless a fraud proof is submitted during a challenge period.
This mechanism contrasts with ZK-EVMs, which ensure the correctness of transactions through cryptographic proofs before posting to the blockchain.
Unique to Optimistic Rollups, the challenge window allows external validators the opportunity to dispute transactions, leveraging Ethereum’s security for data verification without the computational overhead of zero-knowledge proofs inherent to ZK-EVMs.
This design significantly lowers gas costs by deferring validation responsibilities until disputes arise.
Resources
ZK-EVMs
Live | Stage 0
ZK-EVMs streamline Ethereum scaling by executing transactions off-chain while maintaining EVM compatibility.
They use zero-knowledge proofs to validate these transactions before any data is posted to the mainnet, contrasting with Optimistic Rollups that rely on post-transaction fraud proofs.
Specifically, ZK-EVMs produce a cryptographic validity proof for each batch of transactions, confirming correctness upfront and ensuring immediate finality without waiting periods.
This method not only secures transactions but also significantly reduces gas costs by compressing transaction data and posting minimal summary data as calldata, effectively bypassing the gas-heavy demand of traditional transaction processing on Ethereum.
Resources
EIP-4844 Specification
March 13, 2024
Ethereum's sharding roadmap has evolved from an idealistic,
to a pragmatic rollup centric approach. The Ethereum community originally pursued
sharding at the execution layer (Full Sharding).
Gradually, and in conjunction with the rollup centric roadmap,
leading research began to favor sharding only on the consensus layer (Data Sharding).
Again, the community shifted in favor of Danksharding , which is not technically sharding at all,
but rather a probabilistic data sampling approach requiring the introduction of second transaction type, blobs. EIP-4844,
Proto-Danksharding, is the first iteration of this approach.
Resources
EIP-4844 Inclusion
March 13, 2024
EIP-4844 introduced a new transaction type that carries large data "blobs,"
which are cheap to include on the consensus layer but are not processed by Ethereum's execution layer. Each blob is stored on the consensus layer for 4096 epochs, or ~18 days. Extra protocol solutions can, and do
store this blob data indefinitely.
This ephemeral approach limits the computational burden on nodes, as they only store these blobs for a limited time. Under EIP-4844, a max of 6 blobs may be attached to a given block, although the
blob market is designed to target 3 per blob; each blob adds 128kb of temporary storage to each block.
Proto-Danksharding lays the groundwork for future scalability upgrades, particularly full Danksharding,
by setting up the necessary cryptographic and technical infrastructure. In later EIPs, we expect to be able to increase both the size, and the number of blobs that may be attached to a block.
Resources
Basic Rollup Scalling Complete
March 13, 2024
While blobs have drastically reduced the costs L2s must pay Ethereum to inherit its security, we must still address existing caveats.
These caveats are perhaps best described by the L2beat organization, which propose three stages to categorize a rollup's maturity: Stage 0, Stage 1, and Stage 2.
In their current form, all rollups remain either in Stage 0, or Stage 1
Quoting directly from an L2beat blog post:
Stage 0 — Full Training Wheels: At this stage, the rollup is effectively run by the operators.
Still, there is an source-available software that allows for the reconstruction of the state from the data posted on L1,
used to compare state roots with the proposed ones.
Stage 1 — Limited Training Wheels: In this stage, the rollup transitions to being governed by smart contracts. However, a Security Council might remain in place to address potential bugs. This stage is characterized by the implementation of a fully functional proof system, decentralization of fraud proof submission, and provision for user exits without operator coordination. The Security Council, comprised of a diverse set of participants, provides a safety net, but its power also poses a potential risk.
Resources
peerDAS
Ongoing Research
EIP-4844 specified a maximum of six and a target of three blobs that could be included alongside each Ethereum block. These blobs are also a predetermined size of 128KB each. PeerDAS, or Peer Data Availability Sampling, would allow both the number and the size of blobs to be increased. This will become increasingly important as the rollup space matures and begins to consume the available blob space.
peerDAS will enable nodes to verify just a portion of a blob, rather than the entire contents of each. This method allows the amount of blob data that can be attached to a block, which is already ephemeral, to be substantially increased without imposing additional hardware burdens on node operators.
Resources
Efficient DA self-healing
Ongoing Research
With data availability sampling nodes will only hold portions of data, there's therefore a critical need
to restore the complete dataset when some parts are unavailable or deliberately censored.
Data availability self-healing facilitates this by enabling nodes to share their stored data samples across the network.
This process allows for the collective reconstruction of the full dataset on a peer-to-peer basis, enhancing the system's
resistance to censorship and ensuring that no single node or group can withhold crucial data.
Resources
- -
Full Rollup Scaling Complete
TBD
This roadmap item boils down to two items: ship additional optimizations to Ethereum's consensus layer to further reduce blob costs for rollups, and have
the rollups themselves mature to point where they may be considered Stage 2, per L2beat's definitions. In other words, utilize their scalabilty benefits without sacrificing security.
Quoting directly from an L2beat blog post:
"Stage 2 — No Training Wheels: This is the final stage where the rollup becomes fully managed by smart contracts.
At this point, the fraud proof system is permissionless, and users are given ample time to exit in the event of unwanted upgrades.
The Security Council’s role is strictly confined to addressing soundness errors that can be adjudicated on-chain, and users are protected from governance attacks."
Resources
Rollup Interoperability
Extra Protocol
There's some concern about fragmented liquidity in Ethereum rollup-centric roadmap. Assuming Layer 2s reach Stage 2 and
eventually inherit all of Ethereum's security, there are still potential UX problems.
This roadmap item is vague, and is meant to highlight the broad need for Layer 2s, whether optimistic or zkEVM, to play nice together. We want some amount of interoperability.
We want standards for moving assets between them. Ultimately these UX problems will likely be solved extra-protocol amongst the rollups.
Resources
- -
Q-safe, no setup commitments
TBD
As part of Ethereum's long-term roadmap to ensure resilience against quantum computing threats, the "Q-scale, No Setup Commitments" initiative
focuses on transitioning away from polynomial commitments that aren't quantum-safe.
The widely-used KZG commitments, while efficient, require a trusted setup and are vulnerable to quantum attacks. Ongoing research aims to develop and implement a more secure and setup-free alternative, likely leveraging STARKs.
This future-proofing effort will allow Ethereum to "hot swap" KZG with these advanced commitments, maintaining security and efficiency in a post-quantum world.
Resources
- -