A quick look at the key points of the Ethereum core developer meeting update
Author: Tim Beiko
Original source: AllCoreDevs Updates
Author: Tim Beiko
Original source: AllCoreDevs Updates
first level title
Summary
So much has happened since January that I've been struggling to find the time to write it all down. Here are the highlights of this update:
The executable specification of the Ethereum execution layer is well underway. Next step: Coordinate the upgrade process for EL+CL.
testnet
The Protocol Guild, a token-based compensation initiative for client developers and researchers, now has over 100 members and is launching a pilot soon.
first level title
testnet
Following Kintsugi, the Kiln testnet was also launched recently. Kiln added some changes and renames to the merge spec based on criticality found on the Kintsugi testnet. Although the merged specification now looks almost final, the transition to running on Kiln has raised implementation issues in various clients. The team is now doubling down on testing to ensure all implementations are safe and stable. Danny talked about this in the latest Finalized update.
As with every upgrade, we will be monitoring the testnets post-upgrade to make sure they are stable. Once we are confident that the testnet is working as intended, we will plan the transition for the Ethereum mainnet!
While we're very close to the merge, and it's a very exciting time for the community as a whole, the fact that the transition happens safely is more important than any target date and is the top priority of the merge. This is by far the most complex upgrade Ethereum has undertaken. We don't want to make mistakes.
Once decided, the testnet and mainnet upgrade timelines will be announced on various community channels, such as This Week in Ethereum, What's New in Eth2, and the Ethereum Foundation Blog (the EF blog) etc. Any claim of a target date at the moment is wrong because we haven't set that date yet. Be extra vigilant for potential scams/false announcements in the coming months!
secondary title
About the difficulty bomb
1. The impact of the bomb on the block time is gradual. This means that once it starts to be felt, there will be a 4-8 week period where block production will slow down, but not drastically (perhaps 14-17 seconds).
Shanghai upgrade
3. Likewise, safe merges >>> fast merges. We hope the transition will go smoothly, and the stability and security of Ethereum is our top concern.
Shanghai upgrade
As mentioned in the last update, with the merged specs pretty much frozen, we've started planning for the Shanghai upgrade. Here are the specs for the upgrade. There are tentatively three major changes in this upgrade, as well as some minor ones. The following in-depth explanations one by one!
secondary title
EVM object format
In the London upgrade, we preserve this part of the identifier by rejecting the deployment of new contracts that start with 0xEF bytes. Before the London upgrade was activated, some contracts that started with this byte were deployed, but this is no longer possible, we can add a second byte (called Magic Byte) to the prefix 0xEF, to get a we can A sequence guaranteed not to be used by any contract.
EIP-3540 describes this in detail and highlights the first practical benefit of this approach: the separation of code and data, which facilitates on-chain code verification. It also paves the way for the introduction of new contract code part types, which help implement now-seemingly complex features, such as account abstraction, control flow in the EVM, and EIP-3074.
EIP-3670 is a companion EIP for 3540 that introduces code verification of EOF contracts at deployment time.
secondary title
Another major feature of the Shanghai upgrade is the activation of beacon chain withdrawals. After several proposals, we came up with a design that the client team was satisfied with: EIP-4895: Beacon chain push withdrawals as operations (beacon chain push withdrawals as system operations).
This meta specification outlines the entire operational process. At a high level, within each slot, the beacon chain processes a certain number of full or partial withdrawals. These withdrawals are tracked in receipts that contain the amount, destination address, and unique index for each withdrawal. These withdrawals are then distributed on the execution layer as part of the block creation and validation process, the same way Proof of Work is distributed to miners today.
There is a tracking issue for multiple changes that need to be made on the consensus layer, which is now in the consensus-specs repository. The partial withdrawal option will allow validators to withdraw their earned rewards while keeping the 32 ETH required to be a validator on-chain and continue to earn rewards.
L2 fee reduction
The last big thing we want to include in the Shanghai upgrade is reducing the cost on the second floor. Because Layer 2 publishes transaction data (and/or proofs) on Layer 1, a large portion of end-user transaction fees comes from data storage in Layer 1. Sharding provides a cheaper alternative to publishing data at the second layer, however although this proposal seems to be settled, a full sharding implementation is not ready yet.
In the meantime, there are now two options available to reduce these overheads: reducing the CALLDATA overhead on mainnet, or a "proto-sharding" implementation, which introduces a new type of transaction on Ethereum called a sharded blob Transactions (Shard Blob Transactions).
secondary title
The easiest way to reduce transaction fees on L2 is to reduce the overhead of storing data on L1. EIP-4488 proposes to do so, lowering the overhead of CALLDATA from 16 gas per byte to 3 gas. The reduction in storage overhead translates into lower Layer 2 fees [1].
While reducing gas overhead is a simple change in itself, it has some secondary effects. First, increasing the CALLDATA in a block will result in a larger block size. In order to balance this, this EIP proposes that there needs to be an upper limit on the maximum number of CALLDATA in a block. Second, even with this upper limit, this EIP will speed up the growth rate of historical chain data on the execution layer. To solve this problem, we need to develop out-of-band data retrieval, and as proposed by EIP-4444, the guarantee of historical data storage in the Ethereum P2P network needs to be changed [1].
While the addition of history chain data would have happened gradually, the inclusion of this EIP means that we need to deal with this issue more urgently after it is deployed. In addition, there is basically nothing in this EIP that can be reused in a complete shard. It's mostly a temporary solution. That said, this EIP is a relatively simple implementation change that does significantly reduce L2 costs.
secondary title
Shard blob transactions
Another proposal is EIP-4844 [2], which brings us closer to a full sharding deployment. Like the Beacon Chain Withdrawal, this proposal also has a meta specification linking to the consensus layer specification and other resources.
At a high level, this new transaction type would contain a commitment to a data blob, which would be broadcast on the beacon chain. This proposal can be thought of as a proposal for "mini-sharding", which does not depend on data availability, and each node of the network needs to verify the data in the blob. Like in full sharding, these data blobs are only guaranteed to be available for a certain amount of time on the network, not stored forever. To keep node requirements manageable, blob data is limited to 1MB/slot instead of 16mb/slot in full shards.
The Optimism team that has been working on this EIP has launched a website that provides an overview of this EIP, aggregates various canonical links, and puts the community's positive reactions to this EIP.
[1] Due to other components involved in L2 transaction pricing, this reduction will not be a full 5x. This Optimisim article has a good explanation of what constitutes an L2 fee. Moreover, ZK rollup will not benefit from this EIP like Optimistic rollup.
[2] EIP-4488 (reduce CALLDATA overhead) and EIP-4844 (shard blob transactions) are competing proposals, and their EIP numbers are too similar.
secondary title
minor improvements
In addition to these three major changes, Shanghai Upgrade is also considering some small improvements, namely
EIP-3651 proposes to reduce the gas overhead for accessing COINBASE addresses, and corrects the negligence of EIP-2929
EIP-3855 proposes a new opcode PUSH0 to push 0 onto the EVM stack.
Additionally, there are several other EIPs proposed for upgrade (see this rough list). EOF, withdrawals, and lower tier 2 fees have made Shanghai one of the biggest upgrades to date, so we need to prioritize what we include very carefully.
Once we start implementing and testing the various EIPs, it will become clearer whether we have additional capabilities to implement other proposals. Of course, we still need to complete the merge first!
first level title
Ethereum Execution Layer Specification (EELS)
As you may have noticed, several Shanghai proposals now span both the executive and consensus layers. In the past, we used different procedures on different layers to introduce changes.
At the executive level, the core EIP contains the changed specification. The "Ethereum Yellow Paper" is the reference specification for the network, but the Yellow Paper is often updated after the upgrade is deployed, sometimes with a greater delay. This means that the effective specification of the execution layer is often "yellow book + EIP X, Y, Z".
So while the community has a good understanding of the flow at the execution level (and provides an easy-to-reference change description), it's not ideal from a technical standpoint. Conversely, while the process of the consensus layer is technically more concise, it is harder for the wider community to understand. Fortunately, work has already started on EELS: An Executable Specification for the Ethereum Execution Layer!
Having enforceable specifications on both the execution layer and the consensus layer will allow us to coordinate the change process between the two layers. There are still many questions to be ironed out, but conversations about how best to migrate have begun. The discussion here on the Ethereum Magicians forum is dedicated to this topic. Although EELS is still under development, we may be able to use it in the Shanghai upgrade, parallel to the current process.
Hopefully the merging of the execution and consensus processes will be simpler than the actual execution and consensus merging.
first level title
Protocol Guild
Last but not least, I want to talk about the Protocol Guild (PG), which now has a fully explained website. Compensation for protocol maintainers has been a hot topic lately, and PG wants to get involved in addressing this issue. Full disclosure: I am a PG member and will receive funding from it.
You can think of compensation as having three categories: base salary, incentives, and potential upside. Currently, the base salaries of client developers and researchers are settled by their respective employers. Although some of them offer incentives in the form of equity, the Ethereum Foundation announced its 39,000 ETH client incentive plan last year to ensure that all client teams have a significant stake in Ethereum.
In simple terms, guilds allow sponsors to donate tokens, which are then given to recipients over time. The receiver set is updatable, allowing new contributors to be added periodically and those who get bored to be removed periodically.
The guild is an early experiment, but if successful, it could be complementary to underlying-focused initiatives like Gitcoin and retroactive public goods funding.
After the success of the Gitcoin grant, the next step for PG is to test the smart contract architecture. At the same time, the search for initial donors will begin. Our plan is to run PG for a year with limited donations to ensure that both the technical and governance parts are running smoothly. Hopefully this pilot proves that we can create new mechanisms on Ethereum to coordinate public goods and money!
Follow-up
