Partnered With:

Ethereum Core Developer Conference updates: Shanghai upgrade, withdrawal mechanism, Cancun upgrade......

Read this article in 29 Minutes

This article reviews the latest updates of the Ethereum Core developer conference, including the Shanghai upgrade, which specific EIP is included? What is the exact mechanism of withdrawal?

原文标题：《以太坊核心开发者会议更新 014 》

Original source: AllCoreDevs Update

Original article by Tim Beiko

原文编译： Ethereum.cn

Welcome to the new AllCoreDevs (Ethereum Core Developer Conference) update -- the last one for 2022.

Although these updates were initially a monthly series, the pace gradually shifted to quarterly. Readers can think of these updates as summaries of the major events surrounding AllCoreDevs. If you want more details, I recommend reading Christine Kim Ben Edginton Minutes of consensus level meetings and my long ACD tweets, which are updated more frequently.

Without further ado, let's get started!

summary

The content of the Shanghai /Capella upgrade has been finalized: withdrawals, EOF, and some minor modifications...... That is, if they don't delay withdrawals

Blob space is coming: IP-4844 will be at the center of Ethereum's next upgrade, and its summoning ceremony will begin soon

Efforts are underway to harmonize the executive and consensus level upgrade processes on the technical side. We are also seeing active discussions about better inclusion of community views in the process

The Protocol Guild has released an interim pilot report, along with a broad plan to expand and better support a layer of maintainers by 2023

Shanghai /Capella Upgrade

In a recent case AllCoreDevs The client team reached a consensus on the final scope of the Shanghai/Capella upgrade. While the name of the upgrade may still be up for debate, the team is clear on its scope. The main function of the upgrade is to introduce beacon chain withdrawal for the pledge. Getting this feature out as soon as possible is something the client team doesn't want to compromise on, so the other features in the upgrade need to be ready at the same time or they may be abandoned.

The Shanghai Executive specification lists all the included EIP:

Ip-3540: EVM object format (EOF) v1

Ip-3651: Reduces the gas overhead for accessing the COINBASE address

Ip-3670: EOF - Code verification

Ip-3855: New operation code PUSH0

Ip-3860: Limits the size of initcode and introduces gas metering

Ip-4200: EOF - Static relative jump

Ip-4750: EOF - Import function

Ip-4895: Beacon chain push withdrawal as system operation

Ip-5450: EOF - Stack authentication

Although the list is long, it can be broken down into three distinct sections: small improvements, EVM object formats, and withdrawals. Here are some of them:

Small improvement

Ip-3651: Warm COINBASE (reduces the gas overhead for accessing a COINBASE address)

This EIP was fixed in IP-2929. An oversight in, for example, is that the gas overhead for accessing certain data fields is modified based on whether the data is already in client memory (WARM) or needs to be retrieved from disk (COLD).

Ip-2929 sets two data in the client memory to at the beginning of each transaction; WARM : indicates the sending and receiving addresses. Ip-3651 adds a third address to the list, COINBASE Address (i.e. feeRecipient), because it is also the address in memory when the client processes a block transaction.

Ip-3855: PUSH0 instruction (Added operation code 'PUSH0)

As the name implies, IP-3855 introduces an opcode that pushes a value of 0 onto the stack. Pressing 0 is typically used to populate values in an EVM, and this opcode will provide a more efficient and cheaper way to do so.

Ip-3860: Limit and meter initcode (limit initcode size and introduce gas metering)

This EIP adds initcode The upper limit of the size and the introduction of gas metering based on its length. Its upper size cap adds an invariant to the EVM, which makes it easier to understand and propose changes.

Is initcode The overhead of 2 gas per 32 bytes is introduced, which is used to pay for the jumpdest analysis that the client must perform before execution, which was not previously included in the gas tariff table.

Object format

Most of the EIP included in the Shanghai upgrade is actually part of a single feature: EVM Object Format (EOF). This work was broken down into five different Eips to help client developers understand each individual change, but to provide a higher-level overview, the developers published a consolidated specification. The EIP of the five EOF's are:

EIP-3540: EVM object format version 1

Ip-3670: EOF - Code verification

Ip-4200: EOF - Static relative jump

Ip-4750: EOF - Import function

Ip-5450: EOF - Stack authentication

Notably, the first step of the EOF took place in the London upgrade of IP-3541, which was reserved for the EOF contract. 0xEF00 "Prefix. The range of EOF upgrades in Shanghai has also changed over the past few months.

In February, the client team agreed to consider the Shanghai upgrade to incorporate the two smallest EOF EIP: EIPs 3540 & 3670. They will all serve as building blocks, but will not provide full functionality without introducing EIP 4200, 4750, and 5450. Although it is possible to extend EOF, backward incompatibility may require a new version. Because EOF contracts prior to or with a specific version of EOF must always be executable, each new version of EOF means that the client developer must maintain a new set of EVM execution rules in parallel with the old rules.

Prior to EOF, clients maintained only one set of EVM rules at a time. The code base also supports previous EVM rules, which are modified in each network upgrade, but once they reach the head of the blockchain, only the latest rules must be applied. With EOF deployed, clients maintain two parallel sets of EVM rules, so they can execute code in both EOF and non-EOF contracts. In other words, the increase in EOF versions increases the number of parallel rather than continuous EVM rule sets that must be maintained.

To this end, in the last few months, the client team has started to favor a "big EOF" approach, so that although they have to implement a larger set of changes, the EOF version will last longer and reduce the number of" parallel EVMs "that need to be maintained. Therefore, the developers are thinking about the" big EOF" and eventually incorporate the Shanghai update.

That said, larger features are obviously more difficult to implement and test, and the team doesn't want to see EOF significantly delay beacon chain withdrawals. Therefore, if by January the implementation of EOF was not complete and not interoperable quickly with each other, the client team agreed to move EOF out of Shanghai for the upgrade.

With these threads in mind, let's now briefly look at each EOF EIP:

EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format Version 1)

This EIP introduces "container" to the EOF contract. It adds markup to distinguish between the code and data parts of the contract and prevents deployment of EOF contracts that do not conform to the format. This ensures that EOF contracts on any chain follow a valid format, which simplifies interaction with these contracts and static analysis of them.

EIP-3670: EOF-Code Validation

On top of the container introduced by 3540, IP-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, you can simply change the validation rules to enable it and ensure that no deployed EOF contract references it in its code section.

EIP-4200: EOF - Static relative jumps (EOF - static relative jumps)

Ip-4200 introduced the first EOF-specific opcodes: RJUMP, RJUMPI And RJUMPV, which encode destinations as signed immediate values. These new JUMP opcodes can be used by compilers to optimize gas overhead because they do away with the need for run-time jumpdest analysis, whereas the existing JUMP & JUMPI opcodes are all needed.

Ip-4750: EOF- Functions (EOF- incoming functions)

The IP-4750 goes one step further than the 4200: it is not allowed to be used. JUMP & JUMPI Operation code, and cannot be copied RJUMP, RJUMPI And The RJUMPV function adds an alternative. It does this by introducing specific functions in the EOF bytecode, which can be separated from the new JUMPF, CALLF And RETF Opcodes jump to, and use them to call and return.

EIP-5450: EOF-Stack Validation

Finally, IP-5450 adds another validation check to the EOF contract, this time around the stack. This EIP prevents the deployment of EOF contracts from causing stack underflows and, in some cases, overflows of code. With this EIP, clients can reduce the number of validation checks when executing EOF contracts because they have better assurance around stack-related exceptions.

As a non-EVM expert who pays close attention to the EIP itself, that's all I can say! If you want to take a deeper look at EOF, I recommend lightclients from the Geth team; And the Solidity team's Leo I tweeted about it.

Beacon chain withdrawal

And last but not least, "Shapella." (Shanghai/Capella) The main part is the beacon chain withdrawal. This part of the change is in the consensus layer specification and IP-4895. All have instructions. There is now a slightly outdated meta-specification that ties these changes together.

At the top level, the withdrawal mechanism is as follows:

When proposing a block, the verifier linearly scans the verifier index to find the first 16 verifiers with 0x01 credentials, which need to 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 greater than 32 ETH (i.e., have received the verifier award)

nbsp; withdrawable (withdrawable, i.e. has completely exited the verifier 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:

Validators will create a withdraw list from these validators and package it into their ExecutionPayload. Each item in the list contains the following:

WithdrawalIndex: Index of all withdrawals made -- this helps to distinguish withdrawals of the same amount from the same address, from the same verifier

ValidatorIndex: The validator index of the proposed balance

ExecutionAddress: The ETH address of the execution layer, where withdrawals should be sent

Amount: is sent to ExecutionAddress This quantity is taken by gwei (not wei) metering

When building or processing blocks, the execution client makes these withdrawals after the transaction is executed. In other words, withdrawals are processed in a similar way to proof-of-work rewards, which do not compete with user transactions for block space.

A few more notable details:

When dealing with withdrawals, there is no difference in the priority/sequencing of presenting "full funds" versus "partial funds". Full payment is made when the verifier leaves the exit queue, while partial withdrawals occur periodically when a linear scan of the verifier set is made to a verifier's index number.

In order for the withdrawal to be processed, the verifier must use. 0x01 Credentials, which are represented by ETH addresses. Only the BLS key pair is allowed when the beacon chain is online. 0x00 Vouchers. In order to initiate a withdrawal, there is 0x00 The authenticator of the credential will need to validate a BLSToExecutionChange Message signature. These will be activated in the Capella upgrade. There are several tools available to sign this message, and validators can expect support and tutorials for these tools.

The scan of the verifier is bounded by each block. If there are no 16 withdrawals to be processed after scanning a subset of a verifier set, the verifier stops the scan and the next verifier starts with the last verifier index to be scanned.

As always, there will be several developer beta nets and beta nets (and maybe even some new beta nets!) before the main net goes live. Run the whole process for the verifier and resolve all issues.

Shanghai /Capella isn't the only upgrade making progress! The dev team is also looking ahead to the next upgrade.

Cancun upgrade

Because the content of Shanghai upgrade is full, but many of the EIP (CFI) that were considered for upgrade failed to enter Shanghai upgrade. The client team begins to discuss which EIP should be considered for the next upgrade: the Cancun Upgrade (consensus layer name to be determined)

In terms of the consensus layer, IP-4844 has become the first EIP written into the specification since the Capella upgrade. The executive level does not (yet) have a specification that can implement this layout, but the executive level team has agreed to follow a similar path and focus on IP-4844 for the next upgrade.

In keeping with the usual practice of upgrading the names of cities that have hosted Devcon, cancun. Has been created, and IP-4844 is officially included in the upgrade.

The decision happened at the last minute of the last AllCoreDevs meeting in 2022, so there was no time to deal with other proposals. EIP that went to Shanghai to upgrade the CFI but didn't make the cut were moved to Cancun to upgrade the CFI list in Ethereum Magicians The forum also opened a thread to discuss the candidate EIP for Cancun. Discussions on the scope of the Cancun upgrade should begin in earnest early next year.

The KZG ceremony

Another thing related to the Cancun upgrade that can be expected is the KZG ceremony, which is a requirement of EIP-4844.

This ritual generates the randomness needed to verify the validity of the blob data. For it to be considered safe, only one participant needs to be honest. In other words, if all but one actor conspires, then the whole process is cryptographically secure.

The ceremony starts in January, and it will be open to everyone for a few months. Our goal is to have 10,000 participants, which would be the largest ceremony of its kind to date! If you want to make sure you don't miss out, follow Trent Van Epps on Twitter!

Upgrade process after merging

As mentioned in the previous update, after the merge, coordinating the Ethereum upgrade process at the executive and consensus levels is an important to-do list. At the top level, the executive level uses the Yellow Book & EIP to account for changes, while the consensus layer uses the executable Python specification.

The benefit of the executive-level process is that the EIP is well known to the community and formatted in a way that clearly shows the reasoning behind the proposal. The Yellow Book with a lot of math paired with the EIP and the need to put the specification back into the context of each EIP made the executive specification difficult to understand and extend.

The problem with the consensus layer is the opposite: it has a clear, easy-to-understand specification in a single repository, but the changes are not specific, and the proposal is buried in other public PR in the repository.

With the introduction of the Ethereum executive level specification, we can hopefully close this gap from the executive level. And, with some process debate, we might be able to get EIP introduced into the consensus layer process!

That said, as the scope of the Shanghai upgrade was discussed and finalized, it became clear that another part of the process might be missing: a place for the community to express their relative preference for the change and participate in the discussion about the entire upgrade scope (rather than individual EIP) as part of the decisions made at AllCoreDevs and consensus level meetings.

It's not clear what it will look like - I'd love to receive suggestions! But as the number of stakeholders actively involved in the protocol changes and the number of areas affected by the layer of changes increases, it is clear that something is needed.

Fortunately, we don't have to start from scratch. Ethereum Magicians It's been around for years, and its offline meetups, dedicated group meetings, or community meetings might be a good starting point for expansion.

Expect more progress on this front in early 2023!

Convention renewal

With the Protocol Guild (PG) pilot now halfway through, they've released a report to look at how things are going and think about what's next for the project.

As a reminder, PG is a license-free funding mechanism for Ethereum Layer1 client developers, protocol researchers, and support contributors (like you).

This mechanism is centered on the individual, not the organization. In short, each member is entitled to a share of the guild's tokens, weighted according to how long they contribute to Ethereum. Members are added and removed in the same way as true Ethereum -- based on a set of standards that are generally agreed upon within PG. The list is then placed on the chain, using 0xSplit The split contract. The donor can then send the money directly to the recipient's address, or to a vesting contract that releases the money to the recipient's address.

The interim report on the pilot is summarized in this tweet. Here are some highlights

The pilot raised $9.7 million, which came from organizations such as Lido, Uniswap, ENS, NounsDAO and MolochDAO, as well as individuals who donate regularly (thank you Tetranode!). -- Thank you for making this project possible. ‍!

PG had 90 members at launch and now has 128, among whom $5 million has been distributed

On average, each member received $39,000, with the lowest being $13,000 and the highest being $79,000

The PG architecture is changing to support L2 and remove the need for multiple tabs to update weights

这些早期的结果显示 PG 正在按计划运作：一个将一篮子 Token 分配给一组自我孵化、不断增长的协议贡献者的机制。如果没有试点捐赠者的慷慨支持，这个项目不会有今天的成果。

Looking ahead, now is the time to expand PG's reach to its full potential: offering competitive, risk-moderating compensation to Ethereum maintainers. The easiest thing to do here is to donate to PG from the start, as Danny Ryan said in his tweet launching PG.

试点里的捐款大多来自拥有大量资金的大型项目。如果协议公会可以说服这些项目从第一天就给 PG 捐款，即他们的 Token 仍然是真正「不值钱」的时候，之后，以太坊的维护者就可以从这些成功项目的整个上升轨迹中获益。

When enough projects are involved, incentives can keep the best people in maintenance agreements rather than pulling them away.

To support this, and many other types of giving, PG will need a technological overhaul. The next release will support L1 and L2 and further reduce its on-chain governance footprint.

If you wish to donate to the Agreement Guild project, please contact me - my DM is open!

Follow-up work

That's it for 2022...... What an extraordinary year! Three months ago, we weren't even merging! Now that Ethereum has quietly run its proof of interest in the background, the focus has shifted to future affairs.

As you return in January, you can expect:

Shanghai /Capella upgrade developer test Net and Shadow fork

KZG ceremony online

The discussion around Cancun, and the network upgrade process should be developed to better capture the preferences of the community

The pilot of the protocol Association will be completed and we will announce the post-pilot structure

Thanks for reading! And thank you to everyone who took the time to improve Ethereum over the past year -- we achieved a lot.

See you in 2023!