(1/21) @ethereum Upgrades: EIP-7742
Today, Ethereum hardcodes blob maximum in both the consensus and execution layer, breaking the separation-of-concerns paradigm that defines Ethereum's two-layer architecture. EIP-7742 fixes this and paves the way for the Danksharding future.
(2/21) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes).
These nodes are real computers in the real world, communicating directly from peer to peer.
x.com/LogarithmicRex/status/1592309373732151296
(3/21) Unfortunately, it's impossible to build a single shared computer that is both decentralized (the foundation of credible neutrality) and performant enough to service the entire world.
And so, the question is how do we upgrade today's Ethereum into the World Computer?
(4/21) But blockchains are not typical computers... the question isn't "how much computation can Ethereum process," it's "how much value can Ethereum settle."
This is the idea behind the scaling roadmap: move execution off-chain while retaining settlement on-chain.
x.com/LogarithmicRex/status/1564316505650524160
(5/21) Rollup-centric roadmap tl;dr: rollups are independent blockchains that execute txns and post the result on Ethereum, which maintains the final record of ownership.
The Danksharding upgrade introduced blobs - abundant, cheap space for rollups to post critical data.
x.com/LogarithmicRex/status/1591614638138875905
(6/21) In March 2024, the Dencun hard fork brought the first major upgrade to Ethereum to natively support rollups: EIP-4844 aka Proto-Danksharding.
Fun fact: Danksharding is named after @dankrad; Proto-Danksharding is named after @protolambda.
eip4844.com/
(7/21) Post-Merge (2022), today's Ethereum is actually made up from the combination of two distinct blockchains: Ethereum's original chain (now called the execution layer, responsible for the EVM) and the newer Beacon Chain (now called the consensus layer, responsible for PoS).
x.com/LogarithmicRex/status/1861070198918545700
(8/21) When Dencun introduced blobs, it had to be built on top of the legacy left by the Merge. In particular, the number of blobs was hardcoded into both the execution and consensus layer.
The problem: changing the number is clunky.
(9/21) Which brings us to EIP-7742, an upgrade that will reduce the number of places the number of blobs is hardcoded into Ethereum.
By clear technical debt, EIP-7742 makes increasing blob count (and therefore Ethereum's bandwidth) easier and safer.
eips.ethereum.org/EIPS/eip-7742
(10/21) According to the specifications of EIP-4844, the maximum allowed blob count is communicated from the consensus to the execution layer during every slot (new block).
And yet, this value is also hardcoded into both layers.
(11/21) Coders will already understand, but for those that don't:
Hardcoding limits flexibility and adaptability. If changes are needed, updates require modifying the system itself, which is costly and error-prone (especially when the same value is hardcoded in multiple places).
(12/21) The major change introduced by EIP-7742 solves this redundancy by eliminating the hardcoded entry in the execution layer.
Because this data is already provided via the consensus layer during block construction, there are no security/operational impacts of this removal.
(13/21) If all you're here for is to understand the technical changes introduced by EIP-7742, at this point we are done.
But for those looking for a more holistic understanding of the "why" of this change, we need to dive a little deeper and talk about the blob target.
(14/21) To understand the system behind blob-counts, we need to take a small detour into EIP-1559.
EIP-1559 dictates block size and gas costs. When demand is high, block size increases to accommodate more transactions while gas cost increases to suppress demand.
x.com/LogarithmicRex/status/1858932051598336322
(15/21) The dynamics introduced in EIP-1559 have been applied to how Ethereum manages blobs: when demand is high, Ethereum allows more blobs while also increasing the cost (blob base fee).
Demand is "high" when the current amount of blobs is greater than the blob target.
(16/21) Today, the blob target is hardcoded into the execution layer as a proportion of the blob maximum (target = maximum/2).
Because of the change introduced by EIP-7742, we need to change this calculation to use the maximum provided by the consensus layer.
(17/21) Once we make this change, we will have decoupled the blob count between the consensus and execution layers.
After EIP-7742, the consensus layer will be the source of the blob max and the execution layer will be the sole arbiter of the blob target and current base fee.
(18/21) At this point you might be asking "why not just push all of this computation onto one layer?"
While it is technically possible to force all of this computation onto the consensus layer, it violates the separations of concerns between the consensus and execution layer.
(19/21) Under the two-layer design, the consensus layer secures Ethereum while the execution layer is operates (and prices) computation.
The blob max is a security concern (too many blobs risks a denial of service attack), the target/base fee is a computational concern.
(20/21) This is the philosophical basis of EIP-7742: removing the technical debt introduced in the original implementation of EIP-4844 to uncouple blob count between the execution and consensus layers.
The why: to make increasing blobs and achieving Danksharding much easier.
(21/21) In summary, EIP-7742 is a change to how the system that controls EIP-4844 that is intended to remove technical debt and make blob increases much easier and more flexible.
This under-the-hood change is a small but important step in the Danksharding roadmap.