Ethereum Core Developers Meeting Notes: Latest Updates on Shanghai Upgrade
Original title: "Original title: "》
#152 Ethereum Core Developers Meeting Notes
Original editor: Stephanie, ECN
edited words
Friends who have watched the "Ethereum 7-day talk" updated weekly by ECN may find that the "7-day talk" has been suspended for nearly a month. In addition to being unable to keep updated due to the editor's infection with Covid some time ago, ECN is also thinking about whether it should continue the editing of the "Seven Day Talk". In the new year, ECN plans to make some content operation adjustments, including the "Seven Day Talk".
The compilation of notes from the Ethereum core developer meeting has always been an important part of the "Seven Day Talk", and we have now decided to update it independently.
If you want us to keep updating the content of the previous "Seven-Day Talks", please feel free to private message us on various social media. We are very willing to hear your feedback in order to improve the quality of our content.
The following are detailed notes 👇
first level title
Progress in Shanghai's upgrade
(https://t.co/HBkcidHvMq)
Additionally, Marius@vdWijden of the Geth team proposed a minor design modification to EIP 3860 (limiting initcode size and introducing gas metering) - correcting a confusing bug pattern in that EIP where violations of initcode limits resulted in Zero address errors instead of OOG (out of gas) errors. The proposal, agreed by the developers, to change the error mode to OOG errors and then terminate or abort execution instead of returning a zero address would reduce confusion and bugs in client implementations. The above is the opinion of the client team. If the smart contract developer strongly opposes this modification, it may not be modified.
first level title
EOF-related EIPs were removed and upgraded in Shanghai
Next, the meeting mainly discussed EOF related topics.
Developer @lightclients on the Geth team gave you an update on the EOF group meeting in December. (EOF is EVM Object Format, which will introduce some changes to the code environment of Ethereum. The EIP related to it will more clearly distinguish the code and data of smart contracts, and make the EVM easier to upgrade in the future.) In short, The spec was finalized with two minor changes: removing JUMPF and making data EOF contracts mandatory to include a data section.
On the testing side, @mhswende from the Geth team has started fuzzing the implementation, finding bugs and fixing them on all clients. The current fuzz testing is mainly aimed at the implementation of EOF container/structure on the client, but does not include the deployed EOF code. Mario Vega@elbuenmayini of the Ethereum Foundation's testing team added that due to the complexity of EOF, it may be difficult to write static test cases for error cases, since the implementation may encounter another error before encountering the exact test case.
On the client side, Geth and Besu have a complete implementation and passed most of the tests. Nethermind also has an implementation, but not sure which test suite is best to use. And Erigon will use Geth's EOF implementation.
Based on the implementation and testing of EOF, Vitalik also expressed concerns about the hasty implementation of EOF, and published an EOF proposal: disable code introspection for EOF accounts: https://ethereum-magicians.org/t/eof- proposal-ban-code-introspection-of-eof-accounts/12113
Vitalik explained the thinking behind this proposal at the meeting, and explained why modifying the EVM is generally more difficult than other protocol modifications. He noted that removing proof-of-work from ethereum is easier than deprecating opcodes. This is because Ethereum applications/contracts rely on specific behavior of the EVM, so modifications must be backwards compatible, or they will break deployed contracts. Changes to other aspects of the protocol would only require everyone to update at a certain time, and otherwise would not break anything on the network.
This means that when we improve the EVM, or introduce new versions, such as EOF, we will most likely need to live with them forever because we cannot deprecate previous versions. Ideally we'd like the EVM to be cleaner/simple, but that's going to be hard if we can only add stuff to it and never remove stuff. One of the biggest challenges of deleting things is code introspection in the EVM.
Therefore, Vitalik's proposal is to add more content in EOF v1, which will greatly limit the code introspection in the EOF contract, thus potentially making it easier to upgrade in the future. @alexberegszaszi of the Ipsilon team mentioned that the authors of the EOF proposal had actually considered similar features before, and decided to give up because they wanted to keep EOF v1 simple. He also proposes an alternative to incorporate Vitalik's proposal into EOF v2: https://ethereum-magicians.org/t/eof v2-aka-what-evm-2-0-could-look-like/12442
However, with this proposal to add content to EOF v1, the client team was concerned that the overall revision would be too large. @lightclients also said that based on the current progress of the EOF test, it may be delayed by about a month to include it in the Shanghai upgrade. If you want to launch the mainnet testnet upgrade in early February, the EOF part should not be ready. Also, this is an important decision because changes to the EVM cannot be modified once deployed.
Does the Shanghai upgrade need to supplement other EIPs? After discussion, the developers decided not to add other EIPs, so as not to delay the Shanghai upgrade.
first level title
Discussion of other EIPs
Subsequently, the developers also discussed the proposal of Etan Kissling of the Nimbus team: adding a hexadecimal root to the transaction list of ExecutionPayloadHeader. https://github.com/ethereum/consensus-specs/pull/3078
To put it simply, the fields encoded in different serialization formats are used between the block header of the execution layer and the execution payload header (ExecutionPayloadHeader) of the consensus layer. The different encoding formats of these two fields bring additional overhead and complexity to the construction of wallets and Ethereum light clients. Kissling proposes to add CL's SSZ serialization format to the execution layer, or consensus layer clients to support the execution layer's RLP serialization format in various ways. This proposal is related to the withdrawal in the Shanghai upgrade, so it is relatively urgent. This issue will be discussed again at the Consensus Layer Conference (ACDC) this week, January 12th.
compile source as@TimBeikoand@christine_dkimand
