The Good Tech Companies - EIP-7762 And EIP-7691: Making Ethereum Blobs Great Again

Episode Date: January 10, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/eip-7762-and-eip-7691-making-ethereum-blobs-great-again. Learn how EIP-7762 and EIP-7691 improve Ethereum blobs—boosting scalability and storage efficiency while transforming Ethereum's architecture. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum-scalability, #ethereum-blobs, #ethereum-layer-2-scaling, #2077-research, #ethereum-network, #blockchain, #layer-2-rollups, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. Ethereum Improvement Proposals (EIPs) 7762 and 7691 aim to optimize blob handling in Ethereum, addressing scalability and storage challenges. By enhancing efficiency and reducing resource overhead, these proposals pave the way for a more robust and scalable Ethereum ecosystem

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. EIP-7762 and EIP-7691. Making Ethereum blobs great again, by 2077 research. It has now been 8 months since the Ethereum network introduced blobs through THE-EIP-4844 upgrade. As anticipated, rollups are benefiting from significantly lower batch posting fees, allowing them to submit more transactions to Ethereum via the cost-efficient blob option. However, the blob usage has been low as expected, there are still not enough rollups or decentralized applications, dApps, leveraging blobs. As a result, the blob gas base fee has remained at the minimum price of just one way. Despite four periods of high blob demand, the overall cost remains exceptionally low.

This makes Ethereum an attractive data availability, DA, layer for rollups, but it also raises concerns within the community about whether rollups are contributing enough to the mainnet. Moreover, Ethereum has been experiencing issuance inflation since the adoption of blobs, sparking debates over their impact. Some argue that blobs enable Ethereum to scale and that more rollup services will eventually migrate to the network. Others contend that rollups, as of now, offer little to no contribution to Ethereum. Beyond the price effects, discussions have emerged around the broader implications of blobs. One major topic is whether the minimum blob base fee should be

adjusted, as proposed in EIP-7762. The outcome of this proposal remains uncertain. Another debate, captured in EIP-7691, centers around whether the number of blobs should be increased, with proponents asserting that this would not compromise consensus security. Both proposals are under consideration for the upcoming Pectra hard fork. This article delves into the details of each proposal, exploring the background, the specifics of what has been proposed, and the potential advantages and disadvantages. For those unfamiliar with blobs, we'll first cover the basics. If you're already knowledgeable about EIP-4844 and blobs and are interested

specifically in the proposals, feel free to skip ahead to the discussion on EIP-7762. Let's first dive into the exact concept of data availability and explain HOWEIP4844 enhances Ethereum as a DA layer. What is data availability, DA? Data availability is the property that ensures specific data can be accessed at a given point in time, particularly for the purpose of validating new blocks in blockchain networks. It focuses on the real-time access needed to validate new blocks and ensure consensus is reached. It guarantees that the data necessary for current block validation is available to all the participating nodes, enabling them to verify transactions before adding the block to the chain. DA is often confused with data retrievability, which refers to the ability to access historical

data. Retrievability involves retrieving past data, such as information from old blocks, typically for purposes like syncing new nodes or viewing transaction history. However, retrievability does not impact the real-time validation required for block creation. For example, the Ethereum blockchain ensures DA by making the necessary data for block validation available to nodes at the time a block is proposed. Even IFE Ethereum nodes do not provide all historical data to syncing nodes in certain cases, the consensus mechanism ensures that the required data was available during validation. If the data had been unavailable at that moment, the block would not have been added to the blockchain. It's also important to note that DA is not a binary property. It doesn't simply mean

available or not available. Instead, it exists on a continuous spectrum. Secure and decentralized blockchains like Ethereum provide strong DA, but variations in the degree of availability can occur based on factors such as consensus mechanism and the level of decentralization. Why does DA matter for rollups? Data availability, DA, is vital for rollups because it ensures that transaction data can be accessed to verify state updates and reconstruct the rollup's current state. For optimistic rollups, DA is essential for constructing fraud proofs. If a false state transition is posted, users can rely on the transaction data stored in the DA layer to validate the transition and prove fraud. Without DA, users can rely on the transaction data stored in the DA layer to validate the transition

and prove fraud. Without DA, users would have to trust rollup operators entirely, which could expose them to risks if operators act maliciously or withhold data. For ZK rollups, DA ensures the existence of cryptographic proofs to validate state transitions without needing to post all transaction data. However, in practice, many ZK rollups still post transaction data to the DA layer to enhance transparency and facilitate easier verification by users. Ethereum's strong DA guarantees are why rollups use it as their DA layer. Prior to EIP-4844, rollups leveraged Ethereum's call data field for DA. Now, they can utilize both blobs and call data, improving scalability and efficiency for rollup implementations.

How does EIP4844 enhance Ethereum's DA functionality? EIP4844 introduces a new data structure called a blob, which, unlike call data, is temporarily stored at the consensus layer for approximately 18 days before deletion. Ethereum validators allocate around 50 gigabytes for temporary blob storage. Blobs differ from call data because they are not accessible by the Ethereum Virtual Machine, EVM, only their blob commitments are accessible, reducing the data footprint while still ensuring DA. Blobs offer efficient DA by providing only the essential functions needed for rollups, contributing to significantly reduced transaction fees. Each blob is approximately 128 kibibytes,

and a block can contain up to 6 blobs, totaling around 0.784 mebibytes per block. Blobs are added through a new transaction type called blob transactions, which, like legacy transactions, use at least 21,000 gas and can include 1 to 6 blobs. How are blobs priced currently? Blobs are priced using a new unit called blob gas, where each blob consumes 217 equals 131, 072 blob gas units. Similar to Ethereum's EIP-1559 gas fee mechanism, blob gas prices adjust dynamically based on blob congestion in recent blocks. The blob gas base fee BBLOBGAS, K plus 1 for the next block K plus 1 is calculated as follows. When a block is filled with the maximum of six blobs, the blob gas base fee may increase by approximately 12.5% in the following block. Currently, the minimum blob

base fee is set at one way, establishing the minimum fee per blob at 131,072 way. Each blob transaction also includes the standard execution fee of 21,000 gas multiplied by the gas price. The minimum base fee of one way is under active discussion, with EIP-7762 proposing an increase to better balance costs and data availability needs. EIP-7762. Increase minimum blob base fee. EIP-7762 proposes to increase the blob gas base fee, reserve a hotel much closer to the center, to make price discovery faster. What it attempts to change is only one parameter. It proposes to change it from one-way to 225-way. But what is the reasoning behind this proposal? Is a minimum blob base fee of one-way problematic the issue isn't that rollups contribute minimally to mainnet transactions or pay too little in fees. On the contrary, Ethereum's goal,

especially with EIP-4844, ISTO supports scalable, low-cost rollup transactions. Blob gas base fees have consistently remained at one way since EIP-4844 was activated, with only a few brief surges when blob demand spiked. Ideally, if the base fee could stay at one way indefinitely, this wouldn't be a concern. What matters is that, during sudden demand bursts, the low starting point for blob base fees presents challenges in price discovery. During these surges, the blob gas base fees' gradual adjustment from one way can be slow to align with actual demand. Previously, the blob gas base fee's gradual adjustment from one way can be slow to align with actual demand. Previously, the calculation of could potentially lead to an

undesirable spike in the blob base fee. To prevent this, the EIP introduces a modification that resets the excess blob gas at the fork height. This adjustment ensures smoother transitions around the fork event, analyzing implications of EIP-7762. Since EIP-7762's proposal, it has spurred considerable discussion. While researchers largely agree on the motivation behind this proposal and the need to address issues in price discovery, some concerns remain. One primary issue is the potential impact of frequent protocol adjustments on Ethereum's stability. Regular fine-tuning may introduce unforeseen complexities and risks. Another concern centers on determining an appropriate minimum blob base fee. The arbitrary choice of

225-way lacks a strong empirical basis, prompting calls for further investigation to ensure this value supports the protocol's long-term goals. Establishing a robust rationale for this baseline fee is essential to avoid potential instability or unintended market distortions. EIP-7691 Blob Throughput Increase EIP-7691 proposes a straightforward change, increasing the maximum number of blobs per block. Currently, the cap is 6 blobs per block, with a target of 3. EIP7691 suggests that by raising this limit, no exact number for now, rollups could achieve greater scalability without compromising Ethereum's consensus stability.

What challenges arise from increasing the blob count? Raising the number of blobs per block could increase the total data size transmitted across the Ethereum peer-to-peer P2P network, potentially leading to delays in reaching consensus. Each blob contains 128 kB of data, so 6 blobs add up to 784 kB. With Ethereum's maximum block size around 2 megabytes, the total data transmitted per slot, including blobs, could reach approximately 2.78 megabytes. As the blob count increases, so does the data size, which extends the time required for blocks and blobs to propagate across nodes. This delay can challenge Ethereum's consensus process, especially since validators must submit a stations within a four-second window before each slot ends. Ensuring consensus

stability, therefore, demands careful management of these propagation times. Some may argue that because each blob is propagated via a separate channel, the increased blob count should not significantly affect consensus. However, nodes must still wait for all blobs and block data to arrive, meaning that a higher blob count could potentially result in longer wait times. Empirical analyses following EIP-4844, see post 1, post 2, reveal that the 4 crate has increased post-implementation, and it rises with the blob count per block. The chart below illustrates reorg rates by blob count from April 6 to June 6, 2024. Blocks containing the maximum of six

blobs show a significantly higher reorg rate than blocks with fewer than four blobs, sparking concerns about EIP-4844's impact on Ethereum's consensus security. Is it safe to increase the number of blobs? While reorgs can occur for multiple reasons, higher data loads across the P2P network are just one factor. Suboptimal client implementations may also contribute to reorg rates. My initial analysis suggests that the data availability, DA, time, the duration nodes wait for the final blob to arrive, IS.s. minimal, averaging less than 20 milliseconds, with a difference of less than 5 milliseconds between blocks containing 0 blobs and those with 6 blobs. Given that nodes wait approximately 4000 milliseconds before submitting

attestations, this latency appears negligible and unlikely to critically affect consensus. Below chart shows the DA time estimated with blocks containing different numbers of blobs. Furthermore, Tony's analysis indicates that overall reorg rates have been declining since the implementation of EIP-4844. While earlier data showed a strong correlation between reorg rates and blob counts up until June, more recent data from the last three months reveals minimal differences in reorg rates across blocks with varying blob counts. These findings, attributed to ongoing improvements in Ethereum client performance, suggest that increasing the blob limit would not pose a significant risk to consensus stability. How EIP-7623 supports EIP-7691. Recently, Vitalik suggested, I think we should revisit adding EIP-7623 and

AS Mall Blob Count Increase, EG. Target 3-4, Max 6-8, for Pectra A. To understand how EIP-7623 can facilitate this increase, let's first examine its score proposal. See here for detailed explanation of EIP-7623. What is EIP-7623? EIP-7623 proposes to adjust the gas cost for call data specifically for transactions that primarily serve data availability, DA, purposes. Essentially, transactions with low execution gas relative to their call data size would incur a higher gas cost, potentially up to three times more, for call data usage. Transactions that contain large call data but perform minimal EVM execution would therefore see higher costs, encouraging the use of blobs over call data for DA-related functions.

The rationale behind this adjustment is to minimize the impact on daily, non-DOWSER transactions while optimizing the DA framework. By increasing call data costs for DA-specific transactions, EIP7623 encourages data-heavy operations to transition from call data to blobs, optimizing the network's storage and DA efficiency. Additionally, this proposal aims to reduce the worst-case block size from 2.78 MB to approximately 1.2 MB, addressing the current gap where Ethereum's average block size of around 125 KB could potentially reach a much larger limit. EIP-7623 and EIP-7691 If EIP-7623 effectively reduces the maximum block size, it creates room for a higher blob count, supporting the goals of EIP-7691.

Even with an increased number of blobs, the total data size remains manageable under worst-case conditions due to the reduced reliance on call data for DA. This alignment between EIP-7623 and EIP-7691 allows for a greater blob throughput without increasing the maximum block size beyond sustainable limits. Conclusion This article has introduced recent EIPs focused on enhancing Ethereum's blob functionality. EIP-7762 proposes raising the minimum blob base fee to enable faster price discovery during demand surges while minimizing the impact on overall blob transaction costs. EIP-7691 seeks to increase the blob count per block to further scale Ethereum's data availability

DA layer. With a higher blob count, the blob base fee would experience a more controlled increase during demand peaks, allowing for smoother price adjustments. Detailed discussions are taking place around these proposed changes. For instance, debates include setting the target blob number to 4 and the maximum blob count to 6, as well as determining whether the base fee update rule should be symmetric or asymmetric. Additional considerations involve normalizing excess blob gas and adjusting the blob base fee update fraction. Blobs are a recent addition to Ethereum's ecosystem, and every change-related totem is approached with caution due to their impact on both the application layer and consensus security. Nonetheless,

Ethereum is rapidly advancing, with the research community working diligently to drive development and ensure the network continues to grow and evolve. Tip authors note. A version of this article was originally published here. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.