Welcome to another AllCoreDevs update 👋🏻
Arrow Glacier is happening next week - upgrade your nodes 🏔
Kintsugi Merge devnets are being stood up - expect a long-lived one for the holidays 🍵
A new proposal, EIP-4488, could make rollup transactions cheaper, but there are tradeoffs. A deep dive on this below 👇🏻
As mentioned in the last update, the Arrow Glacier upgrade is scheduled for block 13,773,000, which is expected on December 8, 2021. If you run an Ethereum node, you should upgrade it now. The list of client versions which support the upgrade is as follows:
For a complete overview of the upgrade, see the full announcement. Hopefully, this is the last time the difficulty bomb is delayed before Ethereum's transition to proof of stake 💣!
After the Amphora interop event, client teams have been hard at work on another sprint of merge devnets: Kintsugi 🍵
The goal of this effort is to incorporate the learnings from Amphora into the specification, test them on a devnet, find what breaks, add fixes to the spec, and do it all again the week after. This rapid pace of iteration allows us to see the latest spec in production weekly, and to gradually gain confidence in the client implementations.
A tracker is available with the various milestones. So far, three devnets have been launched. We are expecting to launch one more ephemeral devnet next week, and then to have a longer-lived one over the holidays. This last Kintsugi devnet will allow application developers, infrastructure and tool providers, and curious users to experiment with the (nearly!) final post-merge Ethereum spec.
For those most eager to try things, basic instructions to connect to the current devnets are available here. The full specifications for The Merge are split across the consensus specs, execution specs and Engine API specs.
CALLDATA Cost Reduction 📉Rollups are expected to be the primary method by which computation on Ethereum is scaled. They allow users to execute their transactions on a separate sub-chain (the L2/rollup) that commits TX data to Ethereum. This removes the need for these transactions to be executed on mainnet but maintains the security and network effects of Ethereum, while allowing far more scalability. The main cost of rollup transactions is then the cost of storing their data on the L1 chain, which is currently done using a transaction's CALLDATA.
The cost of CALLDATA therefore dictates, to a large extent, the cost of transactions on rollups. [0] As of this writing, a simple ETH transfer costs a few dollars on optimistic rollups (ORs) and ~0.25$ on zero-knowledge rollups (ZKRs). While this might not seem particularly high, more complex transactions require higher fees and most of Ethereum's usage is still happening on L1. As users transition to L2, these costs will keep increasing.
To preempt this, EIP-4488 was introduced. It proposes to reduce the CALLDATA cost from 16 gas/byte to 3 gas/byte, a >5x reduction. Because CALLDATA directly increases the block size, the EIP also adds a cap on the maximum CALLDATA in a block. To accommodate non-rollup transactions, this cap can be extended by transactions who only use a small amount (<300 bytes) of CALLDATA. This helps mitigate fee market issues that come up with any scheme that adds two separate limits, in this case gas and CALLDATA.
The benefits of this EIP are clear: posting rollup data to L1 would become 5x cheaper than today relative to other EVM operations. These cost savings would continue until L1 blocks continuously hit the CALLDATA cap, which would require several times Ethereum's current usage to happen on rollups. By then, sharding may be live, which will provide another reduction in rollup transaction costs. In other words, transaction fees are the biggest pain point for users using Ethereum right now, and this EIP would provide another incentive for migration towards rollups.
There are drawbacks, though. First, the EIP would increase the rate at which the Ethereum blockchain's storage requirements grows. In the worst case, assuming all blocks hit the maximum amount of CALLDATA, the increase would be of ~3.0 TB per year. That said, while we are still far from there, Ethereum's rate of growth is already hard to manage. Ever increasing chaindata will long term be unsustainable. Proposals to cap it, such as history expiry (e.g. EIP-4444) and state expiry, are already on the roadmap. Agreeing to EIP-4488 would increase the urgency with which these changes need to be deployed to mainnet.
Second, several months ago, client teams agreed to prioritize Ethereum's transition to proof of stake above everything else. If we waited until after The Merge, it is likely this would not happen before Q4 2022, one year from now. Combining it with The Merge adds too much complexity. Hence, we are left with the option of potentially doing it before The Merge.
While any delays would likely be minimal, due to the simplicity of the change and ability of most client teams to parallelize its implementation, it does go against "The Process" and the prior decisions client teams had committed to. Also, EIPs are often discussed for months prior to being accepted in network upgrades. In this case, a decision would have to be made in the next few weeks if we plan to deploy it prior to The Merge. While this is highly unusual, rollups' importance within the Ethereum roadmap and the prevalence of high L1 fees may justify deviations from the usual processes.
If you have strong opinions about this, I encourage you to share them on the EIP's Ethereum Magicians thread. Regardless of whether EIP-4488 goes live before The Merge, the process by which we make the decision will be an important precedent in Ethereum governance.
Thank you to Ansgar Dietrichs, Vitalik Buterin, Danny Ryan and Dankrad Feist for reviewing drafts of this update.
[0] These are other factors which determine the total cost of a rollup transaction. For an example, see Optimism's documentation.