Original title: "Ethereum Core Developer Meeting Update 014"
Original source: AllCoreDevs Update
Original author: Tim Beiko
Original translation: Ethereum.cn
Welcome to another AllCoreDevs (Ethereum Core Developers Meeting) update - the last one of 2022.
overview
The Shanghai/Capella upgrades are finalized: withdrawals, EOF, and some minor modifications… provided they don’t delay withdrawals.
Blob space is coming: EIP-4844 will be at the center of Ethereum’s next upgrade, and its summoning ceremony will begin soon.
Efforts are underway to coordinate the upgrade processes of the execution and consensus layers on the technical side, and we are also seeing active discussions on better incorporating community input into this process.
The Protocol Guild published a mid-term pilot report and a rough plan to scale up and better support Layer 1 maintainers in 2023.
Shanghai/Capella Upgrade
At a recent AllCoreDevs, the client teams reached consensus on the final scope of the Shanghai/Capella upgrade. While the name of the upgrade may still be up for debate, the teams are clear on its scope. The main feature of the upgrade is the introduction of beacon chain withdrawals for stakers. Getting this out as soon as possible is something the client teams don’t want to compromise on, so other features in the upgrade need to be ready at the same time or risk being abandoned.
The Shanghai Implementation Specification lists all included EIPs:
EIP-3540: EVM Object Format (EOF) v1
EIP-3651: Reduce gas costs for accessing COINBASE addresses
EIP-3670: EOF - Code Verification
EIP-3855: Added opcode PUSH 0
EIP-3860: Limit the size of initcode and introduce gas metering
EIP-4200: EOF - static relative jumps
EIP-4750: EOF - Introducing functions
EIP-4895: Beacon Chain Push Withdrawals as a System Operation
EIP-5450: EOF - Stack Validation
Although the list is long, it can be divided into three different parts: small improvements, EVM object format, and withdrawals. Let’s go through them one by one:
Minor improvements
EIP-3651: Warm COINBASE (Reduce gas cost for accessing COINBASE addresses)
This EIP fixes an oversight in EIP-2929, which modified the gas cost of accessing certain data fields based on whether the data was already in the client's memory (WARM) or needed to be retrieved from disk (COLD).
EIP-2929 sets two pieces of data in client memory to WARM at the beginning of each transaction: the sending address and the receiving address. EIP-3651 adds a third address to this list, the COINBASE address (ie feeRecipient), because it is also the address in the client's memory when processing block transactions.
EIP-3855: PUSH 0 instruction (new opcode `PUSH 0)
As the name suggests, EIP-3855 introduces an opcode that pushes a value of 0 onto the stack. Pushing 0 is commonly used to fill values in the EVM, and this opcode will provide a more efficient and cheaper way to do this.
EIP-3860: Limit and meter initcode (Limit the size of initcode and introduce gas metering)
This EIP adds an upper limit on the size of initcode and introduces gas metering based on its length. The size limit adds an invariant to the EVM, which makes it easier to understand and propose changes.
Introduced a 2 gas per 32 bytes overhead for initcode, this is to pay for jumpdest analysis that the client must do before execution, which was not previously included in the gas fee table.
Object Format
Most of the EIPs included in the Shanghai upgrade are actually part of this single feature: EVM Object Format (EOF). This work was broken down into 5 different EIPs to help client developers understand each individual modification, but in order to provide a higher-level overview, the developers released a unified specification. The 5 EOF EIPs are:
EIP-3540: EVM Object Format Version 1
EIP-3670: EOF - Code Verification
EIP-4200: EOF - static relative jump
EIP-4750: EOF - Introducing functions
EIP-5450: EOF - Stack Validation
It’s worth noting that the first step towards EOF occurred with the London upgrade, EIP-3541, which reserved the 0xEF00 prefix for EOF contracts. The EOF range has also changed with the Shanghai upgrade over the past few months.
In February, client teams agreed to consider two minimal EOF EIPs for inclusion in the Shanghai upgrade: EIPs 3540 & 3670. They will serve as building blocks, but will not provide full functionality without the introduction of EIPs 4200, 4750, and 5450. While it may be possible to extend EOF, backwards incompatibility may require a new version. Because pre-EOF or version-specific EOF contracts must always be executable, each new EOF version means that client developers must maintain a new set of EVM execution rules in parallel with the old rules.
Before EOF, clients maintain only one set of EVM rules at a time. The codebase also supports previous EVM rules, which are modified with each network upgrade, but once they reach the head of the blockchain, only the latest rules must be applied. After EOF is deployed, clients will maintain two parallel sets of EVM rules, so they can execute code in both EOF and non-EOF contracts. In other words, increasing the version of EOF increases the number of parallel, rather than sequential, sets of EVM rules that must be maintained.
To this end, over the past few months, client teams have begun to favor a "big EOF" approach. This way, although they have to implement a larger set of changes, the EOF version will be maintained for longer and reduce the number of "parallel EVMs" that need to be maintained. Therefore, the developers considered "big EOF" and eventually included it in the Shanghai upgrade.
That is to say, larger functions are obviously more difficult to implement and test, and the team does not want to see EOF seriously delay beacon chain withdrawals. Therefore, if the implementation of EOF is not completed by January and cannot quickly interoperate with each other, the client team agreed to remove EOF from the Shanghai upgrade.
With this in mind, let’s now briefly introduce each EOF EIP:
EIP-3540: EVM Object Format (EOF) v1
This EIP introduces a "container" for EOF contracts. It adds markers to distinguish the code and data parts of the contract and prevents EOF contracts that do not conform to the format from being deployed. This ensures that any EOF contract on the chain will follow a valid format, which simplifies interaction with these contracts and static analysis of them.
EIP-3670: EOF - Code Validation
Building on the container introduced by 3540, EIP-3670 ensures that the code in the EOF contract is valid, or prevents it from being deployed.
This means that undefined opcodes cannot be deployed in EOF contracts, which has the added benefit of reducing the number of EOF versions that need to be added. If a new opcode is added, the validation rules can simply be changed to enable it and guarantee that no deployed EOF contract references it in its code.
EIP-4200: EOF - Static relative jumps
EIP-4200 introduces the first EOF-specific opcodes: RJUMP, RJUMPI, and RJUMPV, which encode the destination as a signed immediate value. These new JUMP opcodes can be used by compilers to optimize gas costs, as they remove the need for runtime jumpdest analysis, which is required for the existing JUMP & JUMPI opcodes.
EIP-4750: EOF - Functions
EIP-4750 goes one step further than 4200: it disallows the use of JUMP & JUMPI opcodes and adds alternatives for RJUMP, RJUMPI and RJUMPV functionality that cannot be replicated. It does this by introducing a special function section in the EOF bytecode that can be jumped to and called and returned from using the new JUMPF, CALLF and RETF opcodes, respectively.
EIP-5450: EOF - Stack Validation
Finally, EIP-5450 adds another validation check to the EOF contract, this time around the stack. This EIP prevents the EOF contract from deploying code that could cause a stack underflow, and in some cases an overflow. With this EIP, clients can reduce the number of validation checks when executing EOF contracts, as they have better guarantees around stack-related exceptions.
As a non-EVM expert who is very focused on the EIP itself, that’s all I can say! If you want to learn more about EOF, I recommend the relevant tweets from lightclients from the Geth team and Leo from the Solidity team.
Beacon Chain Withdrawals
Last but not least, the main part of “Shapella” is beacon chain withdrawals. This part of the change is described in the consensus layer specification and EIP-4895. There is now a slightly outdated meta specification that ties these changes together.
At a high level, withdrawals work like this:
When proposing a block, the validator linearly scans the validator index to find the first 16 validators with 0 x 01 credentials that meet one of the following conditions:
Have a balance above 32 ETH (i.e. have accrued validator rewards)
Are withdrawable (i.e. have fully exited the validator set)
Balance is greater than 32 ETH (i.e. validator rewards have been obtained)
Is withdrawable (i.e. has completely exited the validator set)
From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:
The validator will create a list of withdrawals from these validators and package them into their ExecutionPayload. Each item in the list contains the following:
WithdrawalIndex: Index of all withdrawal transactions that have been made - this helps distinguish withdrawals of the same amount from the same address and the same validator
ValidatorIndex: The index of the validator whose balance is being proposed
ExecutionAddress: The ETH address of the execution layer, where withdrawals should be sent
Amount: The amount sent to the ExecutionAddress. This amount is measured in gwei (not wei).
When a block is constructed or processed, the execution layer client will make these withdrawals after the transaction is executed. In other words, withdrawals are processed similarly to how proof-of-work rewards are credited, and they do not compete with user transactions for block space.
There are some other details worth noting:
When processing withdrawals, there is no difference in priority/ranking between "full funds" and "partial funds". Full funds are withdrawn when a validator leaves the withdrawal queue, while partial withdrawals occur periodically, when a linear scan of the validator set reaches a validator's index.
In order for withdrawals to be processed, validators must use a 0x01 credential, which is represented by an ETH address. Only BLS keypair 0x00 credentials will be allowed at launch. In order to initiate withdrawals, validators with 0x00 credentials will need to sign a BLSToExecutionChange message. These will be activated in the Capella upgrade. There will be multiple tools for signing this message, and validators can expect support and tutorials for these tools.
The scanning of validators is done on a per-block basis. If there are no 16 withdrawals to process after scanning a subset of the validator set, the validator will stop scanning and the next validator will start from the last scanned validator index.
As usual, there will be several developer testnets and testnets (and maybe even some new testnets!) before mainnet launch to give validators a chance to run through the process and iron out any issues.
Shanghai/Capella isn’t the only upgrade making progress! The developer team is also looking ahead to the next upgrade.
Cancun Upgrade
Since the content of the Shanghai upgrade is full, many EIPs (CFI) that were considered for the upgrade did not make it into the Shanghai upgrade. The client team began to discuss which EIPs should be considered for the next upgrade: Cancun upgrade (the name of the consensus layer is yet to be determined)
On the consensus layer side, EIP-4844 has become the first EIP to be written into the specification after the Capella upgrade. The execution layer does not (yet) have a specification that can implement this layout, but the execution layer team agreed to follow a similar path and focus on EIP-4844 in the next upgrade.
Following the convention of upgrades using the name of the city that hosted Devcon, cancun.md has been created where EIP-4844 is formally incorporated into the upgrade.
This decision happened at the last minute of the last AllCoreDevs meeting of 2022, so there was no time to work on other proposals. EIPs that entered the Shanghai upgrade CFI but were ultimately not included were moved to the Cancun upgrade CFI list, and a thread was opened on the Ethereum Magicians forum to discuss candidate EIPs for Cancun. Discussions on the scope of the Cancun upgrade should begin in earnest early next year.
KZG Ceremony
Another thing to look forward to related to the Cancun upgrade is the KZG ceremony, which is a requirement of EIP-4844.
This ceremony will generate the randomness needed to verify the validity of the blob data. For it to be considered secure, only one of the participants needs to be honest. In other words, if all but one participant colludes, the entire process is cryptographically secure.
The ceremony begins in January and will be open to everyone for a few months. Our goal is to have 10, 000 participants, making it the largest ceremony of its kind yet! If you want to make sure you don't miss it, follow Trent Van Epps on Twitter!
Post-merger upgrade process
As mentioned in the previous update, after the merger, coordinating the upgrade process of Ethereum at the execution layer and consensus layer is an important to-do. At a high level, the execution layer uses the yellow paper & EIP to describe the changes, while the consensus layer uses executable Python specifications.
The benefit of the execution layer process is that EIPs are well known to the community and are formatted in a way that clearly shows the reasoning behind the proposal. The math-heavy yellow paper paired with the EIPs and the need to put the specs back into the context of the individual EIPs makes the execution layer specs difficult to understand and extend.
The problem with the consensus layer is the opposite: it has a clear and understandable spec in a single repository, but changes are not concretely identifiable, and proposals are buried in other public PRs in the repository.
With the introduction of the Ethereum Execution Layer Spec, we can hopefully close this gap from the execution layer side, and with some process wrangling, we might be able to get EIPs introduced to the consensus layer process!
That said, as the scope of the Shanghai upgrade was discussed and finalized, it became clear that there might be another part missing from the process: a place for the community to express their relative preferences for the changes and to participate in discussions about the scope of the upgrade as a whole (rather than individual EIPs) as part of the decision-making at the AllCoreDevs and Consensus meetings.
It’s unclear what that will look like yet—I’d love suggestions!—but as the number of stakeholders actively involved in protocol changes grows, as does the number of areas impacted by a layer 1 change, it’s clear that we need something.
Fortunately, we don’t need to start from scratch. Ethereum Magicians has been around for years, and its meetups, dedicated groups, or community conferences could be a good starting point for expansion.
Expect more progress on this front in early 2023!
Protocol Guild Updates
With the Protocol Guild (PG) pilot now halfway complete, they have released a report to take stock of how things are going and what the next steps for the project are.
As a reminder, PG is a permissionless funding mechanism for Ethereum Layer 1 client developers, protocol researchers, and supporting contributors (like you).
This mechanism is centered around individuals, not organizations. In short, each member is eligible for a share of the guild's tokens, weighted by how long they have contributed to Ethereum. Members are added and removed in true Ethereum fashion - based on a set of standards, with a rough consensus reached within PG. This list is then put on-chain, using the 0xSplit split contract. Donors can then send funds directly to the recipient's address, or to a vesting contract that releases funds to the recipient's address.
The pilot interim report is summarized in this tweet. Here are some key points
The pilot raised $9.7M from organizations like Lido, Uniswap, ENS, NounsDAO, and MolochDAO, as well as regular individual donors (thank you Tetranode!) - thank you to everyone for making this possible!
PG had 90 members at launch and now has 128, with $5 million distributed between them
On average, each member received $39, 000, with the lowest amount being $13,000 and the highest being $79,000.
PG’s architecture is changing to support L2 and remove the need for multi-signatures to update weights
These early results show that PG is working as planned: a mechanism to distribute a basket of tokens to a self-incubating, growing group of protocol contributors. Without the generous support of pilot donors, this project would not be what it is today.
Looking ahead, now is the time to expand PG’s reach and realize its full potential: providing competitive, risk-adjusted compensation to Ethereum maintainers. The simplest approach here is for projects to donate to PG from the beginning, as Danny Ryan said in his tweet when launching PG.
Most of the donations in the pilot came from large projects with a lot of funding. If the protocol guild can convince these projects to donate to PG from day one, when their tokens are still truly “worthless”, then Ethereum maintainers can benefit from the entire upward trajectory of these successful projects.
When enough projects are involved, incentives can keep the best talent on maintenance agreements rather than pulling them away.
To support this, and many other types of contributions, PG will need a technical overhaul. The next version will support both L1 and L2 and further reduce its on-chain governance footprint.
If you're a project that would like to donate to the Protocol Guild, please contact me - my DMs are open!
Follow-up
That’s it for 2022… What a year! Three months ago, we weren’t even merged yet! Now that Ethereum is quietly running Proof of Stake in the background, the focus has shifted to what’s next.
As we return in January, you can expect:
Shanghai/Capella Upgrade Developer Testnet and Shadow Fork
KZG ceremony online
Discussions around Cancun and how the network upgrade process should evolve to better capture the community’s preferences
The protocol guild pilot will end and we will announce the post-pilot structure.