The Good Tech Companies - EIP-7623: The Proposal That Will Re-price Calldata For Ethereum Transactions

Episode Date: January 17, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/eip-7623-the-proposal-that-will-re-price-calldata-for-ethereum-transactions. Learn how EIP-7623 proposes adjustments to Ethereum calldata pricing that aim to make gas costs fairer and better reflect resource consumption by users. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum, #ethereum-transaction-pricing, #ethereum-fee-markets, #ethereum-layer-2-scaling, #ethereum-scalability, #2077-research, #ethereum-blockchain, #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. EIP-7623 proposes changes to Ethereum's calldata pricing structure, aiming to make gas costs more reflective of actual resource usage. This adjustment seeks to improve fairness and efficiency in how Ethereum's resources are allocated. Read the full article to learn more about how these changes could impact Ethereum users and the network in general.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. EIP-7623. The proposal that will reprice call data for Ethereum transactions, by 2077 research. Blockchain transactions consume CPU, memory, storage, and other resources when they are propagated, executed among nodes, and stored. Therefore, proper pricing of transactions is essential to prevent network abuse and achieve efficient resource utilization. However, determining the appropriate pricing for transactions has been a long-standing challenge in blockchain protocol design. Vitalik Buterin, founder of Ethereum, touches on this issue in an old research document.

Greater than one of the most challenging issues in blockchain protocol design is how to greater than limit and price the submission of transactions that get included into the greater than chain. Vitalik Buterin EIP 7623 is an Ethereum improvement proposal, EIP, that aims to change the pricing of call data to limit the maximum block size. Unlike previous proposals that merely increased the cost of call data to limit the maximum block size. Unlike previous proposals that merely increased the cost of call data, EIP-7623 focuses on minimizing its impact on everyday user transactions while achieving efficient resource utilization. In this article, we explain the rationale for repricing call data used by transactions on Ethereum Layer 1, L1, and the impact on block sizes and network performance.

We also establish context for proposed changes to Ethereum's transaction fee mechanism, drawing from years of research into the problem of efficient pricing of blockchain resources. Let's dive in, setting the stage, why is it so difficult to price transactions properly? Pricing blockchain transactions is difficult because estimating the exact amount of each resource that each transaction consumes is inherently complex. Currently, in Ethereum, all resources are represented as unified units called gas and blob gas, introduced with EIP-4844. There are predefined rules that convert transaction resource consumption into GAS, and these rules are periodically updated. Examples of these rules include a transaction incurring a fixed overhead of at least 21,000 gas, primarily for signature verification.

Predefined gas consumption for each EVM opcode. Additionally, gas consumption for call data is an integral part of these rules, which is less commonly known but highly significant. Call data pricing is crucial because it directly influences the maximum block size. Further, it impacts all transactions using smart contracts, particularly affecting the cost of roll-up transactions that depend on call data space, rather than blobs, for data availability. Why does block size matter? Ethereum operates in 12-second slots, during which all validator nodes must propagate blocks and blobs, execute and validate transactions, and attest to the new block. Specifically, the Ethereum client implementation requires honest nodes to receive and validate blocks within the first 4 seconds of the slot. They attest at 4 seconds into the slot,

meaning that blocks arriving after 4 seconds are expected to not get attestations and are susceptible to being roared by the following proposer. To minimize the split views between Ethereum nodes, block execution time and propagation time need to be capped. Ethereum limits block execution time by setting a maximum gas usage, currently capped at 30 million with a target of 15 million. This means Ethereum blocks will use approximately 15M gas on average, with the capacity to expand and consume 30M gas in times of high activity. Also, each EVM opcode has a predetermined gas cost based on its resource consumption. For instance, the SSTORE opcode is more costly than simpler

operations, e.g. arithmetic addition, ad, because it involves accessing and modifying the state tree. This differentiated pricing of EVM opcodes, along with the total gas limit, aim to constrain total execution time. While the gas limit of a block can somewhat constrain block execution time, block propagation time remains unconstrained explicitly. Block size is a major factor affecting propagation time in public blockchains. For instance, larger block sizes increase network load and bandwidth requirements. If the block size greatly exceeds the bandwidth of most nodes, it takes longer for nodes to fully propagate and receive the block, raising the risk of missed or reorg blocks. This is why Bitcoin protocol, pre-segwit,

had a cap of 1MB block size to prevent increased fork rates and ensure the security and low node requirements of the blockchain. Presently Ethereum, there is no explicitly set block size limit. However, the theoretical maximum block size can be estimated by considering gas limit, call data cost, compression rate, etc. Although the current block size of Ethereum is approximately 2.78 MB, excluding blobs, the current call data pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller, around 100KB. If such large payloads were consistently propagated over 10 minutes, it could amount to approximately 42.9MB, which is significantly larger than typical block sizes in other blockchain networks. This could potentially overload the Ethereum network and cause nodes to have different

views for a short period in a DOS attack scenario where 7.15 MB payloads continue for a while. In practice, the average block size in Ethereum today is approximately 125 kilobytes, indicating a significant gap from the maximum block size. This raises another concern regarding inefficiency in resource utilization. For example, if the network can sufficiently handle 1MB blocks in a row, a big discrepancy between the average block size and 1MB suggests that Ethereum has more capacity for data availability, da, functionality but is not utilizing it effectively. By limiting the maximum block size and aligning the average block size closer to this maximum, Ethereum could reduce

consensus risks while achieving more efficient resource utilization. This is why EIP-7623 focuses on the possible maximum block size, which is highly affected by call data pricing. What is call data in Ethereum? Call data is a field in a transaction typically used to convey which functions to call and what parameters to pass. For example, if you want to mint an NFT, you include the mint method and specific traits of the NFT in the call data field. The following example shows the first mint transaction of a CryptoPunk in 2017. The call data, referred to as input data, in the figure, contains the function name, represented by 0xC81D1D5B, and the NFT index, represented by hexadecimal 00001EB0, 7,856 in hexadecimal. If you only transfer ETH and do not interact with any smart contract, the call data field is null.

Besides its primary purpose of passing parameters to smart contracts, call data also used for recording simple memos or by rollups storing their transaction data. In other words, call data doesn't always need to interact with smart contracts or follow strict rules, it can contain arbitrary values. Leveraging this flexibility, optimistic rollups such as optimism and arbitrum, someZK, Validity, Rollups, Post-Compressed Rollup Transaction Data, and Updated States in the Call Data field of their sequencing transactions. Although EIP-4844 has enabled data availability through blobs instead of call data, call data is still preferred by small rollups that do not need the

full 128 kilobytes of a blob for a single batch. Call data is often preferred by small rollups that do not need the full 128 kilobytes of a blob for a single batch. Call data is often used for DA functionality because it is the least gas-consuming way to post large data on the EVM. This is why the maximum block size is constrained by the price of call data. The worst-case scenario occurs when a block is filled with DA-purpose transactions that use small amounts of gas but large data sizes. Currently, the cost of call data is 4 gas per 0 bytes and 16 gas per non-0 byte. Call data can be compressed using snappy compression, EIP-706, and the transaction size cannot exceed 125 kilobytes. Accurate calculation of the maximum block size is

complex due to the varying nature of compression ratios, but it is known that the block can increase up to approximately 2.78 megabytes if 2.78 megabytes blocks continue consecutively due to certain reasons e.g. spamming attacks. The network could be overloaded, and nodes might have split views dueto low propagation speeds. More nodes might att split views due to low propagation speeds. More nodes might attest to different blocks as the canonical chain, increasing the risk of not reaching a consensus. To prevent this, a simple solution could be to increase the cost of call data, for example, doubling the cost of call data to 8 Gbps and 32 Gbps could approximately reduce the maximum

block size in half. However, this approach could harm normal user transactions. Increasing call data costs only to prevent the worst-case scenario might result in a greater loss than gain, given that the average block size is currently only 125 kilobytes and does not pose significant concerns. What is the motivation for EIP-7623? EIP-7623 differs slightly from other proposals that simply increase the call data cost. Instead of a blanket adjustment to the price of call data, EIP-7623 focuses on increasing the gas cost specifically for transactions that appear to serve data availability, DA, purposes. What does this mean? If the gas used in a transaction is insufficient compared to the total data size loaded,

it is considered a DA-purpose transaction and charged significantly more for call data. Conversely, if a transaction consumes enough gas relative to the data size, it is considered a non-DA transaction and is charged the same as it is today. A useful analogy can be drawn between call data in Ethereum and plastic bags in the real world. When we buy products or groceries, we often get plastic bags to carry them, usually at a very low cost or even free. However, if individuals can't purchase an unlimited number of plastic bags, it would be detrimental to the environment. A possible solution is to restrict plastic bags, it would be detrimental to the environment. A possible

solution is to restrict plastic bags to customers who buy enough products or charge a higher price, like $1 per bag. This is analogous to the TEEIP 7623 approach, which functions as a form of Pigouvian tax. It imposes higher costs on transactions that use a large amount of call data but insufficient gas, thereby promoting more efficient resource use. By applying more aggressive costs to those who primarily use call data for data availability rather than a balanced mix of data and execution, the protocol aims to ensure a more efficient and sustainable utilization of network resources. Why target DA transactions on ETHERUM? There is nothing inherently wrong with transactions utilizing Ethereum for data availability. EIP-7623 doesn't discourage Ethereum from

functioning as a data availability layer. Rather, it discourages the use of call data for the purposes of storing transaction data and indirectly encourages the use of blobs for DA instead. This proposal aims to separate the execution layer from the data availability layer, allowing each layer to efficiently manage demand and better predict extreme cases. By doing so, EIP-7623 seeks to enhance the efficiency and predictability of Ethereum's resource management while limiting the DOS surface. This separation ensures that each layer can handle its specific functions more effectively, ultimately contributing to a more robust and scalable Ethereum network.

An overview of EIP-7623 specifications. The current gas calculation of a transaction is as follows. The in the above specification is the minimum gas charged for any transaction. Also, represents the gas used for call data, which EIP7623 mainly tries to fix. Here, is a simple weighted combination of 0 and non-zero bytes, which IS calculated by. Is currently set to 4, so the gas cost of is 4 and is 16. Is the gas used for the execution of a transaction, primarily covering interactions with smart contracts. Non-DA purpose transactions typically have a large component. When a transaction creates a new contract, the term becomes one, meaning incurring additional gas for creating and storing the new contract. Since contract creation is not the focus here,

we will set this term to zero. EIP 7623 proposes the following adjustment to the total gas calculation. In the new calculation, compares the gas calculated by current method, blue box, with call data, red box. The blue box is exactly the same as the current gas calculation method. The red box, which is new in EIP-7623, represents the value that judges if a transaction is for DA purposes. As of January 1, 2025, IS proposed to be 10, which is much higher than the of 4. In other words, if a transaction does not spend enough, the red box will like LIB a higher value than the blue box value, marking it as a DA purpose transaction. Consequently, the transaction will be charged at the rate, effectively paying a little bit less than three times more for call

data. Conversely, most general purpose transactions spend sufficient, so the max blue box, red box, will default to the blue box value, maintaining the current gas cost method. What kind of transactions are affected by EIP 7623? To determine which transactions are affected by EIP 7623, we need to identify the condition where the red box new gas calculation is higher than the blue box current gas calculation. By ignoring the contract creation term and substituting values into the parameters, we derive the following condition. Transactions will incur a higher gas cost if the gas consumed for EVM execution is less than six times the tokens in call data. To make this more intuitive, let's divide both sides by four. Let's remember that six is the gas paid for call data in a transaction. This final equation indicates that if the gas used for EVM execution

is less than twice the gas used for call data, the transaction will incur higher fees for call data. How much will call data costs increase after EIP 7623? Let's assume the minimum gas for a transaction is 21,000, the gas used for EVM execution is K, and the gas used for call data is KX. The total cost of the transaction can then be expressed as, under the current calculation, without EIP 7623, the cost would be 21,000 plus K plus KX. Therefore, the rate of increase with EIP 7623 would be. The increase rate as a function of k is plotted below. To understand the practical impact, let's examine gas usage statistics for common function methods, focusing on those

familiar to most users. Among the various swap functions in decentralized exchanges is the most widely used. In median, it uses 5152 for call data and 175,742 for EVM, and this accounts for 34 times bigger value. Function, used for transferring ERC-20 tokens, consumes around 24,501 gas for EVM execution, about 40 times more than the 620 gas used for call data. Similar to these functions, most daily user transactions have a significant difference between the gas used for call data. Similar to these functions, most daily user transactions have a significant difference between the gas used for call data and EVM execution, meaning they are unlikely to be affected by EIP-7623. Analysis provided by Ethereum researcher Tony Varstater shows that if EIP-7623 is applied, 3.02% of recent Ethereum transactions would be affected. His analysis

also identifies which function methods will be affected and estimates the cost increase for those methods. Further analysis provided by Varstater shows that for recent transactions on Ethereum, 3.02% of transactions get affected if EIP 7623 is applied. His site also shows what function methods will actually be affected and how much the price would increase for those methods. Among the functions impacted by EIP-7623, the most frequently used is commonly employed for sequencing roll-up transactions on Ethereum. Another affected method is commit batches, frequently used in roll-up transactions these two functions are expected to see the most significant cost increases with an estimated 150 increase in total gas costs when using these methods however roll-ups can utilize blobs for

data posting and many roll-ups such as arbitrum one and base are already doing so consequently roll-ups that use blobs for data posting are not likely to be heavily affected by the increased costs imposed by EIP-7623. Analyzing the impact of EIP-7623 on block sizes. EIP-7623 increases the gas cost for transactions that use high amounts of call data. This means that spamming attacks, which rely heavily on call data, would require approximately three times more gas cost, effectively reducing the maximum block size from 2.54 MB to about 0.72 MB. Consequently, the Ethereum network would be better equipped to handle worst-case scenarios where large blocks

are propagated continuously. The reduction in the maximum possible block size creates an opportunity to increase the number of blobs included per block. Currently, the maximum number of blobs is 6, each 128 KB and size. If EIP-7623 is adopted and the same maximum block size is maintained, it could be possible to increase the maximum number of blobs to about 18, which means a 3x increase in the maximum TPS transactions per second of rollups. This calculation involves some oversimplification, as the propagation methods for blobs and blocks differ. However, the primary advantage is the increased separation between the execution and data availability layers. Since blob gas and execution gas have separate fee markets, disturbances in one market will not directly impact the other. This separation simplifies

achieving capital efficiency because it becomes easier to control the target and maximum resources that the Ethereum network can handle within a single block. What are other considerations related to EIP-7623's implementation? While EIP-7623 offers significant benefits, it could potentially impact small roll-ups by necessitating the use of blobs instead of call data. For low-demand roll-ups, the large blob size of 128 Kibbybytes might require them to wait longer until Thet can fill the full blob. This situation increases the need for blob sharing protocols, allowing multiple rollups to share the large blob space for better cost efficiency. Although the blob base fee is currently very low, making blobs an inexpensive DA space,

a sudden rise in demand could place a significant burden on these rollups. Without a concurrent increase in the number of blobs per block, EIP-7623 could make roll-ups submitting DA transactions more competitive, as the total capacity for DA is decreasing overall. It is necessary to assess whether the number of blobs should be increased simultaneously to accommodate this shift. Another consideration is deciding the criteria for the threshold where transactions should be affected by this update. There are trade-offs between block size and user experience. For instance, setting the threshold too aggressively might greatly reduce the maximum block size,

but many transactions might have to pay more gas for call data. While the change in maximum block size is explicit and vivid, it is hard to estimate and quantify how much Ethereum would be impacted by requiring higher gas costs for DA purpose transactions. This threshold can only be set socially. Additionally, the criteria highly depend on other parameters set by EVM operations or the gas limit. For example, if Ethereum were to increase the block gas limit to 300 million in the future, the threshold of EIP-7623 should also be modified to maintain the maximum block size. Conclusion, EIP-7623 is an Ethereum improvement proposal that aims to reduce the maximum block

size by adjusting the call data cost, targeting da purpose transactions this adjustment could potentially increase the cost for non-blob da transactions by up to 300 percent while most everyday user transactions remain unaffected throughout this post we have explored the motivation behind the proposal its implications the types of transactions affected and potential concerns that may arise i hope this writing helps you understand more about this recent proposal and provides detailed insights into its contents. If you are interested and want to know more, you can follow up on Tony Varstatter's analysis and explanation, and participate in the open discussion on the Ethereum Magicians Forum.

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.