Original source: AllCoreDevs Update
Original source: AllCoreDevs Update
Author: Tim Beiko
Original compilation: Ethereum.cn
Welcome to the new AllCoreDevs (Ethereum Core Developers Conference) update - the last one for 2022.
Although these updates started out as a monthly series, the cadence has gradually moved towards a quarterly update. Readers can think of these updates as a summary of the major events surrounding AllCoreDevs. If you want more details, I recommend reading Christine Kim's transcript, Ben Edginton's consensus layer meeting transcript, and my ACD long tweets, which are updated more frequently.
summary
summary
The content of the Shanghai/Capella upgrade has been finalized: withdrawals, EOF, and some minor fixes...provided they don't delay withdrawals
Blob space is coming: EIP-4844 will be the center of Ethereum's next upgrade, and its summoning ceremony will begin soon
On the technical side, efforts are underway to coordinate the upgrade process of the execution layer and the consensus layer. We're also seeing active discussions about better incorporating community input into the process
first level title
Shanghai/Capella upgrade
At a recent AllCoreDevs, the client team came to a consensus on the final scope of the Shanghai/Capella upgrade. While the name of the upgrade may be up for debate, the team is clear on its scope. The main function of the upgrade is to introduce beacon chain withdrawals for stakers. Getting this feature out as soon as possible is something the client team doesn't want to compromise on, so other features in the upgrade need to be ready at the same time, or they might be dropped.
The Shanghai Executive Specification lists all incorporated EIPs:
EIP-3540: EVM Object Format (EOF) v1
EIP-3651: Reduce gas overhead for accessing COINBASE addresses
EIP-3670: EOF - Code Validation
EIP-3855: New opcode PUSH 0
EIP-3860: Limit initcode size and introduce gas metering
EIP-4200: EOF - static relative jump
EIP-4750: EOF - import function
EIP-4895: Beacon Chain push withdrawals as a system operation
EIP-5450: EOF - Stack Validation
secondary title
minor improvement
EIP-3651: Warm COINBASE (reduce the gas overhead of accessing COINBASE addresses)
This EIP fixes an oversight in EIP-2929 where the gas cost modification for certain data field accesses is based on whether the data is already in client memory (WARM) or needs to be retrieved from disk (COLD) .
EIP-2929 sets two pieces of data in client memory to WARM at the start of each transaction: the sending address and the receiving address. EIP-3651 adds a third address to this list, the COINBASE address (i.e. feeRecipient), because it is also the address the client has in memory when processing block transactions.
EIP-3855: PUSH 0 instruction (add opcode `PUSH 0)
As the name suggests, EIP-3855 introduces an opcode that pushes a value of 0 onto the stack. Pushing 0's is often used to fill values in the EVM, this opcode will provide a more efficient and cheaper way to do this.
EIP-3860: Limit and meter initcode (set limits on the size of initcode and introduce gas metering)
This EIP adds a cap on the size of initcode and introduces gas metering based on its length. Its size cap adds an invariant to the EVM, which makes it easier to understand and propose changes.
secondary title
object format
Most of the EIPs included in the Shanghai upgrade are actually part of a single feature: the EVM Object Format (EOF). This work was broken down into 5 different EIPs to help client developers understand each individual modification, but to provide a higher level overview, the developers published a consolidated specification. The EIPs of the five EOFs are:
EIP-3540: EVM Object Format Version 1
EIP-3670: EOF - Code Validation
EIP-4200: EOF - static relative jump
EIP-4750: EOF - import function
EIP-5450: EOF - Stack Validation
It is worth noting that the first step of EOF happened in London upgraded EIP-3541, which reserved the 0xEF 00 prefix for EOF contracts. The EOF range for the Shanghai upgrade has also changed over the past few months.
In February, the client team agreed to consider upgrading in Shanghai to incorporate the two smallest EOF EIPs: EIPs 3540 & 3670. They will all serve as building blocks, but without the introduction of EIP 4200, 4750 and 5450, will not provide full functionality. While it is possible to extend EOF, backwards incompatibility may require a new version. Because contracts prior to EOF or with a specific version of EOF 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 ones.
Before EOF, the client only maintains one set of EVM rules at a time. The code base also supports the 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. After deploying EOF, clients will maintain two parallel sets of EVM rules, so they can execute code in EOF and non-EOF contracts. In other words, version increments of EOF increase the number of parallel rather than sequential EVM rulesets that must be maintained.
For this reason, in the past few months, the client team began to favor the "big EOF"Methods. This way, although they have to implement a larger revision set, the EOF version will last longer and reduce the "parallel EVM" that needs to be maintained"number. Therefore, the developers considered the "big EOF" and finally incorporated it into the Shanghai upgrade.
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 the implementation of EOF has not been completed by January and cannot interoperate quickly with each other, the client team agrees to move EOF out of Shanghai for upgrade.
EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format Version 1)
EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format Version 1)
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 guarantees that any EOF contracts on-chain will follow a valid format, which simplifies interaction with these contracts, as well as static analysis of them.
EIP-3670: EOF - Code Validation (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 be simply changed 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)
EIP-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, as they remove the need for runtime jumpdest analysis, which is required by the existing JUMP & JUMPI opcodes.
EIP-4750: EOF - Functions (EOF-imported functions)
EIP-4750 builds on 4200 a step further: it disallows the JUMP & JUMPI opcodes and adds alternatives for RJUMP, RJUMPI and RJUMPV functions that cannot be duplicated. It does this by introducing a section of specific functions in the EOF bytecode that can be jumped to from, called and returned using, the new JUMPF, CALLF and RETF opcodes, respectively.
EIP-5450: EOF - Stack Validation (EOF-Stack Validation)
Finally, EIP-5450 adds another validation check for EOF contracts, this time around the stack. This EIP prevents EOF contract deployments from potentially causing stack underflow, and code that overflows in some cases. With this EIP, clients can reduce the number of validation checks when executing EOF contracts, as they have better guarantees around stack-related exceptions.
secondary title
Beacon Chain Withdrawal
Last but not least, the main part of "Shapella" (Translator's Note: Shanghai/Capella's collective name) is the beacon chain withdrawal. This part of the change is described in the consensus layer specification and EIP-4895. There is now a slightly outdated meta specification tying these changes together.
At a high level, the mechanics of withdrawals are as follows:
When proposing a block, the validator linearly scans the validator index to find the first 16 validators with 0x01 certificates, 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)
The balance is greater than 32 ETH (that is, the validator reward has been obtained)
is withdrawable (withdrawable, that is, has completely withdrawn from 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:
Validators will create a list of withdrawals from these validators to package into their ExecutionPayload. Each item in the list contains the following:
WithdrawalIndex: An index of all withdrawal transactions that have been made - this helps distinguish withdrawals of the same amount from the same address, same validator
ValidatorIndex: The validator index whose balance was raised
ExecutionAddress: The ETH address of the execution layer, where the withdrawal should be sent
Amount: The amount sent to ExecutionAddress, this amount is measured in gwei (not wei)
When building or processing a block, the execution layer client will perform these withdrawal operations after the transaction is executed. In other words, withdrawals are processed similarly to how proof-of-work rewards are credited, and it does not compete with user transactions for block space.
There are also some notable details:
When processing withdrawals, there is no difference in priority/ranking between submitting "Full Funds" vs. "Partial Funds". The full withdrawal is made when a validator leaves the queue, while partial withdrawals occur periodically, when a linear scan of the validator set is performed and a validator's index number is reached.
In order for withdrawals to be processed, validators must use 0x01 tokens, which are represented by ETH addresses. Only BLS key pair 0x00 credentials are allowed when the beacon chain goes live. In order to initiate a withdrawal, validators with 0x00 credentials will need to sign a BLSToExecutionChange message. These will be activated in the Capella upgrade. There will be various tools used to sign this message, and validators can expect support and tutorials for these tools.
Validators are scanned on a per-block basis. If there are no more than 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 validator index scanned.
As usual, before mainnet goes live, there will be several developer testnets and testnets (maybe even some new testnets!) for validators to run through and iron out any kinks.
first level title
cancun upgrade
Due to the fact that the contents of the upgrade in Shanghai are already full, many EIPs (CFIs) that were considered for upgrade have not been able to enter the upgrade in Shanghai. The client team started discussing which EIPs should be considered for the next upgrade: Cancun upgrade (consensus layer name to be determined)
In terms of the consensus layer, EIP-4844 has become the first EIP to be written into the specification after the Capella upgrade. The executive layer doesn't (yet) have a specification that would implement this layout, but the executive layer team agreed to follow a similar path, with EIP-4844 at the center of the next upgrade.
In accordance with the convention of upgrading to use the name of the city that hosted the Devcon, cancun.md has been created, where EIP-4844 is officially included in the upgrade.
secondary title
KZG ceremony
Another thing that can be expected related to the Cancun upgrade is the KZG ceremony, which is a requirement of EIP-4844.
This ritual will generate the randomness needed to verify the validity of the blob data. For it to be considered secure, only one participant needs to be honest. In other words, if all but one collude, the entire process is cryptographically secure.
first level title
Post-merger upgrade process
As mentioned in a previous update, after the merger, coordinating Ethereum's upgrade process at the execution and consensus layers is an important backlog. At a high level, the execution layer uses the Yellow Paper & EIP to specify modifications, while the consensus layer uses executable Python specifications.
The benefit of the executive-level process is that the EIP is well known by the community and formatted in a way that clearly demonstrates the reasoning behind the proposal. The math-heavy yellow paper paired with the EIPs, and the need to put the specification back into the context of each EIP made the implementation-level specification difficult to understand and extend.
The problem with the consensus layer is the opposite: it has a clear and understandable specification, in a single repository, but changes are not specifically discernible, and proposals are drowned in other public PRs in the repository.
With the introduction of the Ethereum Execution Layer specification, we hope to close this gap from the execution layer perspective. And, with some process wrangling, we might be able to get EIP into the consensus layer process!
That said, as the scope of Shanghai's upgrade was discussed and finalized, it became clear that another part of the process might be lacking: getting the community to express their relative preferences for changes, and to engage in discussions about the overall scope of the upgrade (rather than individual EIPs) Discuss where it is and make it part of the decisions at the AllCoreDevs and Consensus Layer meetings.
It's not clear what it will be like - I'd love to receive suggestions! — but with both the number of stakeholders actively participating in protocol changes and the number of domains affected by layer changes increasing, we clearly need something.
Fortunately, we don't need to start from scratch. Ethereum Magicians has been around for years, and its meetups, dedicated group meetings, or community meetings could be good starting points for scaling.
first level title
Protocol Guild Update
With the Protocol Guild (PG) pilot halfway through, they've released a report looking at how things are going and thinking about what's next for the project.
As a reminder, PG is a permissionless funding mechanism for Ethereum Layer 1 client developers, protocol researchers, and support contributors like you.
This mechanism is centered on individuals, not organizations. In short, each member is entitled to a guild's share of tokens, weighted by how long they have contributed to Ethereum. The addition and deletion of members is carried out in the true way of Ethereum - based on a set of standards, a general consensus is reached within PG. This list is then put on-chain, using the split contract of 0xSplit. Donors can then send funds directly to the recipient's address, or to a vesting contract that issues funds to the recipient's address.
The pilot interim report is summarized in this tweet. Here are some highlights
The pilot raised $9.7M from organizations such as Lido, Uniswap, ENS, NounsDAO, and MolochDAO, as well as some individuals who regularly donate (thanks Tetranode!) - thank you all 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 a low of $13,000 and a high of $79,000
The architecture of PG is changing, will support L2, and remove the need for multi-signatures to update weights
These early results show that PG is working as planned: a mechanism for distributing a basket of tokens to a self-incubating, growing set of protocol contributors. This project would not be where it is today without the generous support of the pilot donors.
Looking ahead, now is the time to expand PG's reach and realize its full potential: Competitive, risk-adjusted compensation for Ethereum maintainers. The easiest thing to do here is to donate to PG from the beginning of the project, as Danny Ryan said in the tweet that started PG.
Most of the donations in the pilot came from larger projects with significant 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 in the maintenance agreement, rather than pulling them away.
To support this, and many other donation types, PG will need a technological overhaul. The next version will support L1 and L2 and further reduce its on-chain governance footprint.
first level title
Follow-up
That concludes 2022... What an extraordinary year! Three months ago, we weren't even merged! Now that Ethereum has Proof of Stake running silently in the background, the focus has shifted to future transactions.
As you return in January, you can expect:
Shanghai/Capella Upgraded Developer Testnet and Shadow Fork
KZG Ceremony Launched
Discussion around Cancun, and how the network upgrade process should evolve to better capture community preferences
The pilot of the protocol guild will end, and we will announce the structure after the pilot
Thanks for reading! And thanks to everyone who took the time to improve Ethereum over the past year - we achieved a lot.
Original link
