Original title: "Ethereum Core Developers Meeting Update 015"

Original source: AllCoreDevs Update

first level title

summary

first level title

Shapella Upgrade

secondary title

Dencun upgrade

When the last Ethereum core developer meeting update was released, the specifications for the Shapella upgrade were basically confirmed, but there were still many changes. After my release, these specifications were finalized, from progress - update - 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.

first level title

secondary title

EIP-4844, Proto-Danksharding

This needs no introduction: the 4844 is a core feature of the Dencun network upgrade. In short, this EIP introduces a temporary "data blob" to the Ethereum network.", L2 can use them to publish the transaction/proof data now stored in CALLDATA.

Since 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, eip 4844.com has various levels of interpretation resources, FAQs, etc.

While this upgrade was not merged on such a large scale, EIP-4844 is a major change for Ethereum: it introduces an entirely new data layer to the network, with which the current consensus and execution layers must interact. The size of this EIP means that the bandwidth of other modifications in the Dencun upgrade will be limited.

That said, in addition to 4844, there are a few EIPs that will be included in this upgrade.

EIP-6780, disable SELFDESTRUCT unless called in the same transaction as contract creation

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 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 the contract creation, then its behavior remains the same as now.

In all other cases, although this opcode will not delete the contract's storage or code, the contract's ETH will still be transferred to the destination address.

Although 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 is also considered.

secondary title

EIP-1153, Transient Storage

The third change incorporated in the Dencun upgrade 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 ERC 20 tokens in a single transaction.

secondary title

EIP-6475: SSZ optional value

The last modification to be incorporated may be seen 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 talk 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 big. 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.

first level title

EIPs considered for inclusion

secondary title

EIP-2537: Precompile for BLS 12-381 curve operations

Since 2019, this EIP has beensome kindForm is considered for upgrades. 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 BLS 12-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.

secondary title

EIP-4788: Beacon block root in EVM

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.

secondary title

EIP-6493: SSZ Transaction Signature Scheme

This EIP is a complement to EIP-6475: 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 upgrades

first level title

Other Proposed EIPs

secondary title

Network upgrade activates EIP

Announcement: I have drafted an informative EIP outlining 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

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 present at EDCON, ETHPrague, ETHShanghai, EthCC, and ETHMontreal.

See you then!

original source