Original title: "Ethereum Core Developers Conference Update 015"
Original source: AllCoreDevs Update
Original compilation: Stephanie, ECN
Shapella upgrade activated! We are in the final stages of planning the next upgrade to Dencun EIPs included are: 4844, 6780, 1153 and 6475, but none of these specs have frozen EIPs 2537, 4788 and 6493 have been shortlisted Many other EIPs are still Discussed on the EthMagicians forum I drafted EIP-6953, which summarizes the trigger mechanism for activating network upgrades for a long time. You will see me talking about Ethereum governance in some places this summer. The full meeting schedule is listed below p>
It's activated! Despite some hiccups with the upgrade activation, less than a month later, we now think it's only natural that withdrawals on Ethereum are processed smoothly
When the last Ethereum core developer meeting update was released, the specifications for the Shapella upgrade were basically confirmed, but there are still many changes . After my release, these specifications were finalized, from progress - update - the final mainnet version was released on the Ethereum Foundation blog, and the protocol announcement now supports email subscriptions!
This update is of a similar nature: we now have a tentative set of EIPs that will be included in the next network upgrade Dencun (Deneb + Cancun). I will give an overview of what they are, why they are important, and the candidate EIPs that are still being considered for inclusion in this upgrade.
Please note that the content of this update is mainly focused on the execution layer of Ethereum - there may be more content on the consensus layer that I missed. If possible, I will post another update when the content of the Dencun upgrade is finalized. But practically speaking, the next article I publish should be the first testnet fork announcement Let's take a look at these EIPs!
This needs no introduction: the 4844 is a core feature of the Dencun network upgrade. In short, this EIP introduces temporary "data blobs" to the Ethereum network that L2 can use to publish transaction/proof data that now resides in CALLDATA .
Because blobs are stored ephemerally, their gas overhead is expected to be much lower than CALLDATA, which is permanently stored on the network. This will significantly reduce L2 transaction fees for users, as more than 90% of the overhead of L2 transactions is now used for L1 data storage. If readers want to know more about 4844, eip4844.com has various levels of interpretation resources, FAQs, etc.
While this upgrade is not such a large merger, EIP-4844 is a major change for Ethereum: it introduces a new data layer to the network, and The current consensus layer and execution layer must interact with it. The size of this EIP means that the bandwidth of other modifications in the Dencun upgrade will be limited.
In other words, in addition to 4844, there are some EIPs that will be included in this upgrade.
EIP-6780, Disable SELFDESTRUCT unless called in the same transaction as the contract was created
< /p>
The second major change introduced in the Dencun upgrade is the disabling of the opcode SELFDESTRUCT in EIP-6780 . This proposal has been discussed for years and has an official retirement notice in the Shapella upgrade.
Some recent analysis has found a common usage pattern for SELFDESTRUCT : contracts are created and destroyed in the same transaction. EIP-6780 allows maintaining this functionality. If SELFDESTRUCT is called in the same transaction as contract creation, it will behave as it does now.
In all other cases, although this opcode will not delete the contract's storage or code, the ETH in the contract will still be transferred to the target address .
While the client team now believes this is the best way to handle SELFDESTRUCT , a more complete impact analysis is still in progress. Once this analysis is complete, the specification may be modified to handle other edge cases. It is also possible to take a completely different approach. For example, EIP-6046 would also be considered.
In other words, removing SELFDESTRUCT for Deneb upgrades is now a question of "how", not "if".
Third to be included in the Dencun upgrade The entry modification is EIP-1153. This proposal has been proposed for almost 5 years, and was re-proposed by the Uniswap team last year. This EIP has received a lot of support from the Ethereum developer community. It introduces two new opcodes - TSTORE and TLOAD, which provide transient storage and are cleared when the transaction is complete. This EIP enables use cases ranging from reentry locks to multiple approvals of ERC20 tokens in a single transaction.
EIP-1153 was also considered for inclusion in the Shapella upgrade, but was ultimately pushed back. This time, the client team agreed to move on with it. It’s worth emphasizing that, aside from the overall soundness and usefulness of this EIP itself, one of the contributing factors to 1153’s inclusion was its excellent technical advocacy work: Uniswap and other teams provided full 1153 reference implementation and comprehensive test cases.
The last modification to be incorporated may Considered as a companion proposal to EIP-4844. Proto-danksharding introduces a new transaction type that uses SSZ encoding instead of the RLP encoding used by other transaction types.
For a long time, there has been discussion of moving Ethereum's execution layer entirely to SSZ encoding, as it is a richer encoding structure and the consensus layer is also used, but implementing it is currently too much work for the Deneb upgrade. EIP-6475 defines one of the elements of SSZ that is part of the 4844 transaction format (Optionals) to ensure it is forward compatible with SSZ objects that we want to introduce to Ethereum in the future.
As discussions continue regarding the best long-term SSZ format for transactions in general and 4844 blob transactions in particular, both EIPs are expected to be revised.
In addition to the EIPs officially included in this upgrade , the client team also has a shortlist that could still be included.
since 2019 This EIP has been considered for upgrades in some form for years. In the past, there has been reluctance to add new cryptographic curves to Ethereum's execution layer. That said, the Beacon Chain relies heavily on BLS12-381, and with our merger completed, it can be said that BLS has become a "core" dependency of Ethereum, with a secure and optimized library.
Introducing this precompilation will allow beacon chain signatures to be verified at the execution layer, as well as new use cases exploiting this curve to be developed.
Similar to 2537, this EIP exposes information from the beacon chain to the execution layer. In this EIP, the root of the beacon chain block is added to the execution payload, which is then stored in a contract in the execution layer. The stored beacon root can then be accessed via a new opcode BEACON_ROOT which takes a slot number as input and returns the associated beacon root.
This EIP will allow more trustless designs for staking pools, bridging, and restaking protocols.
This EIP is for EIP-6475 Added: It defines a signature scheme for SSZ transactions. Although it does not apply to existing RLP transactions, it can be used to ensure that the current 4844 SSZ transaction signature scheme is forward compatible with future implementation layer SSZ overhauls.
Note that EIPs at EOF are not included in the upgrade
Although once selected for Shapella and Dencun Upgrade consideration was included in the list, EOF's entire set of EIPs was officially excluded from this upgrade due to limited bandwidth. Prioritizing them as a "major feature" for future upgrades is being discussed, but the client team has yet to formally agree.
In addition to the above mentioned, the completeness of this upgrade A list of proposed EIPs can be found on the Ethereum Magicians forum. While most of what ended up in the Dencun upgrade has probably already been discussed, there may still be surprises! Notably, when first learning about EIP-5656 opcode MCOPY proposed at the last ACD meeting, the team responded positively.
Network Upgrade Activation EIP
Notice: I have drafted an informative EIP , which lists the various mechanisms that have long been used to trigger network upgrades, from PoW blocks to epochs, TTDs, and now timestamps.
Hope we don't need to change from the current epoch+timestamp combination
Summer (Remote) Talks Summer (Remote) Talks< /p>
Over the next few months, I will have a number of talks sharing my thoughts on how Ethereum's governance process works. Some are offline, some are remote, and some are still to be determined. In chronological order, I will be attending EDCON, ETH Prague, ETHShanghai, EthCC and ETHMontreal.
< /p>
See you then!
Original Source
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
