EIP Fun Weekly #38: Dencun Upgrade
Dencun Upgrade will be activated on the 269,568th block of the Ethereum mainnet on March 13, 2024, at 13:55 UTC. Come in and see the related EIPs!
Hello everyone! Welcome to read the 38th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community this week.
EIP Updates
First, let's review some of the key meetings this week and the formal changes to EIPs.
EIP Editing Office Hour Meeting #33
EIP Status Change
Here are the EIPs that have been approved for a status change on the EIP Editing Office Hour Meeting this week:
ERC-7590: ERC-20 Holder Extension for NFTs
Status: Draft → Review
Abstract: This proposal presents an expansion of ERC-721 to facilitate the convenient exchange of ERC-20 tokens. By enhancing ERC-721, it enables the management and trading of ERC-20 tokens, which are fungible, within a single NFT. This is achieved by incorporating methods to bring ERC-20 tokens into a specific NFT contract and transferring them out by the NFT owner. To address potential front-running problems, a transfer out nonce is included.
ERC-7007: Verifiable AI-Generated Content Token
Status: Draft → Review
Abstract: We are introducing a flexible and versioned container format for the Ethereum Virtual Machine (EVM) that undergoes validation only once during deployment. The version we are describing here offers the significant advantage of separating code and data, making it easier to implement various changes in the future. This implementation relies on the reserved byte introduced by EIP-3541.
ERC-7092: Financial Bonds
Status: Last Call → Final
Abstract: The proposal aims to introduce fixed-income financial bonds with specific features to support bond issuance in the primary market and facilitate buying or selling bonds in the secondary market. It also includes cross-chain functionalities to enable bond operations and management across multiple blockchains.
AllCoreDevs Consensus Layer Call #129
The AllCoreDevs meetings alternate weekly between ACDC (consensus layer focus) and ACDE (execution layer focus) to guide Ethereum protocol forks. Core EIPs related to protocol changes are typically discussed here more with developers than editors.
Takeaways
1.Dencun Launch Preparations
Some client teams shared their plans to release new recommended versions for the upgrade, including Prysm, Lighthouse, and Teku. The readiness of validators for the upgrade was also a topic of concern, with roughly 50% of Flashbots relay validators and overall Ethereum nodes appearing ready, according to sources like Metrika and Ethernets.
There was a desire expressed for a data tool specifically tracking validator node readiness for upgrades.
2.Electra EIP Discussion
EIP-7549, aimed at improving attestation efficiency, was agreed upon to be included in Pectra. Additional analysis and feedback on EIP-7549's implementation were recommended on GitHub.
The inclusion of EIP-7547, inclusion lists, and EIP-7251, increasing the maximum effective balance (maxEB), were also discussed. Further breakout meetings and specifications refinement were suggested for both EIPs, with client teams expected to make definitive decisions in the next ACDC call.
3.Block Value Beacon API Standardization
During the discussion, a Nimbus developer named "Dustin" raised concerns about the lack of standardization for Beacon API endpoints "produceBlockV3" and "getBlockRewards" across different CL clients. Dustin highlighted underspecified areas and inconsistencies in calculating block values.
Ryan agreed that clarifications should be added to the Beacon API, but other developers, including Radosław Kapka and Potuz from the Prysm team, expressed doubts about the need for standardization since the number of consumers for these endpoints was limited.
Jacek Sieka from Nimbus argued that the "produceBlockV3" endpoint is essential for comparing multiple block sources. Ryan suggested that Dustin create a proposal to standardize the endpoints, and client teams can then discuss whether to continue supporting them.
Further Reading
Ethereum All Core Developers Consensus Call #129 Writeup by Christine Kim: https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-129/
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
EIP-4672: NONCE opcode
It introduces an additional EVM opcode, NONCE (0x47), which could provide novel protection against sybil attacks and expand the design possibilities of smart contracts. This opcode would return specific values: 0 for an unused externally-owned address (EOA), 0 for a smart contract address, and, for example, 2 for an EOA that has sent 3 transactions. The account.nonce opcode would precisely track the nonce of the most recent transaction originating from that address.
What’s its potential uses?
Enhanced Smart Contract Design: The availability of the NONCE opcode expands the design space for smart contracts. Developers can utilize this opcode to create more sophisticated and secure contract functionalities. For example, it can be used to implement access control mechanisms, where certain actions are only allowed based on the specific nonce of the sender's address.
NFT Applications: In the realm of NFTs, the NONCE opcode can be employed to enhance ownership verification and prevent double-spending of unique digital assets. By monitoring the nonce of an address, it becomes easier to validate ownership and ensure that tokens are transferred securely and without duplication.
DeFi and User Management: Decentralized Finance (DeFi) applications can benefit from the NONCE opcode for user management and protocol governance. It can be used to manage user actions, such as voting or participation in staking, based on the nonce of their address, ensuring that only authorized and valid actions are carried out.
Account State Validation: The NONCE opcode can assist in validating the state of user accounts. By comparing the nonce returned by the opcode with the expected nonce, applications can ensure that the account state is consistent and prevent any unauthorized account activity.
Further Reading
FEM forum discussion:
EIP-7069: Revamped CALL instructions
The proposal introduces three new call instructions (CALL2, DELEGATECALL2, and STATICCALL2) with simplified semantics. It also includes a new instruction (RETURNDATALOAD) to load data from return values, and removes outdated functionality. Gas limits are determined by the "63/64th rule," and execution status is returned through a list of codes. These changes aim to improve contract execution efficiency and gas optimization while maintaining compatibility for existing contracts.
Why proposed it?
The observability of gas has been a longstanding issue within the Ethereum ecosystem. The gas system has had to remain flexible to adapt to changes in Ethereum usage and underlying hardware. Unfortunately, compromises and workarounds were often necessary to prevent negative impacts on call instructions due to their complex semantics.
This proposed change aims to remove gas observability from new instructions, enabling the creation of new contracts that are not affected by gas repricings. Additionally, with the introduction of the EVM Object Format (EOF), legacy call instructions can be rejected within EOF contracts, ensuring minimal impact from changes in gas fees. These operations required for removing gas observability will be mandatory in the presence of EOF, replacing existing instructions
It's worth noting that starting from Solidity 0.4.21, the compiler already passes all available gas to calls, unless developers explicitly use overrides to control gas. This suggests that most contracts do not rely on controlling gas.
In addition to the gas-related changes, this proposal introduces the convenience of more detailed status codes, moving away from a simple boolean option to extensible status codes for success (0), revert (1), and failure (2).
Furthermore, the introduction of RETURNDATA* instructions, as outlined in EIP-211, has rendered output parameters of calls largely unused. Use of output buffers in the past has caused issues, such as conflicting implementations in ERC-20 contracts. Relying on RETURNDATA* instructions implicitly clarifies this. The proposal also addresses this by including the "missing" RETURNDATALOAD instruction for comprehensive returndata buffer access instructions.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/eip-7069-revamped-call-instructions/14432/2
Anecdote of the Week: Dencun Upgrade
After successful activation on all test networks, the Dencun network upgrade is now ready to be deployed on the Ethereum mainnet. It will be activated on the 269,568th block of the Ethereum mainnet on March 13, 2024, at 13:55 UTC. This upgrade primarily includes three aspects: optimizations in the execution layer, optimizations in the consensus layer, and protodanksharding.
Execution Layer
EIP-1153: Transient storage opcodes
This proposal introduces temporary storage opcodes, TLOAD and TSTORE, allowing smart contracts to access temporary storage more cost-effectively without accessing disk storage.
EIP-5656: MCOPY - Memory copying instruction
This proposal introduces a new memory copy instruction called MCOPY. The MCOPY instruction allows smart contracts to perform data copying operations in memory, improving execution efficiency and flexibility. By using the MCOPY instruction, smart contracts can efficiently copy data in memory without using traditional loops or other copying methods. This reduces the complexity of contract code and improves execution speed. MCOPY provides smart contract developers with more options and optimization space to meet different memory operation requirements.
EIP-4788: Beacon block root in the EVM
The beacon block root is a crucial concept in Ethereum 2.0 that connects the Ethereum blockchain with the Beacon Chain. The goal of this proposal is to enable the EVM to access and verify the state information of the Beacon Chain, including the validator set and consensus rules. By introducing the beacon block root, smart contracts can have closer interaction with the Ethereum 2.0 network, providing developers with more flexibility and innovation. This opens up more opportunities for smart contract developers to utilize the features and upgrades of Ethereum 2.0, leading to a richer application ecosystem.
EIP-6780: SELFDESTRUCT only in same transaction
In the current Ethereum network, SELFDESTRUCT can be used in any transaction, allowing contracts to self-destruct and release occupied storage space. However, this self-destruction functionality can also be abused. According to EIP-6780, this proposal suggests limiting the usage of SELFDESTRUCT instruction to the same transaction. This means that a contract can only perform self-destruction within the context of the current transaction and is no longer allowed to use SELFDESTRUCT in other transactions. By restricting the usage of SELFDESTRUCT, this proposal aims to enhance the security and predictability of contracts, reducing potential abuse risks.
Consensus Layer
EIP-7044: Perpetually Valid Signed Voluntary Exits
In the Ethereum 2.0 Beacon Chain, validators have the option to voluntarily exit their validator roles. The goal of this proposal is to ensure that exit requests signed by validators remain permanently valid and are not affected by future state changes. By introducing the concept of perpetually valid signed voluntary exits, EIP-7044 aims to provide a robust exit mechanism, ensuring that validators can freely exit and receive their deserved benefits without being impacted by future changes or potential unfairness.
EIP-7045: Increase max attestation inclusion slot
In the current design of the Ethereum network, each validator can only broadcast the attestation of their current slot to the network. By increasing the maximum number of attestation inclusion slots, validators will have more flexibility and be able to broadcast attestations of multiple slots. This proposal aims to improve the performance and scalability of the Beacon Chain, allowing validators to more efficiently broadcast attestations and participate in network activities. Increasing the maximum attestation inclusion slot helps reduce the burden of network communication and supports more validators to participate in the operation of the Beacon Chain.
EIP-7514: Add Max Epoch Churn Limit
This proposal introduces the concept of the maximum epoch churn limit, which sets a maximum number of transitions from pending validators to active validators per epoch. If the number of pending validators exceeds this limit, the excess validators will not be selected as active validators until the next epoch. By adding the maximum epoch churn limit, EIP-7514 aims to control the speed of validator transitions to ensure network stability and security. This limit prevents overly rapid changes in validators, reducing network instability and potential attack risks. Overall, EIP-7514 proposal aims to provide better control over the validator transition process and enhance the performance and robustness of the Beacon Chain.
Protodanksharding
EIP-4844: Shard Blob Transactions
In Ethereum 2.0, sharding is implemented to distribute the blockchain's load across multiple shard regions, improving scalability and throughput. However, the current Ethereum network only supports operations on the entire shard rather than specific data within a shard. By introducing the concept of Blob transactions, EIP-4844 aims to enhance the flexibility and scalability of the Ethereum 2.0 network. This allows for more efficient and feasible processing of specific data within the shard network, providing additional options for data operations while reducing network load and latency. This contributes to further development and widespread adoption of the Ethereum network.
EIP-7516: BLOBBASEFEE instruction
This instruction allows smart contracts to access information about the current base fee. By using the BLOBBASEFEE instruction, smart contracts can retrieve the base fee of the current transaction execution and perform corresponding operations as needed. The purpose of this proposal is to provide increased flexibility and accessibility, enabling smart contracts to manage and adjust fees more effectively.
EIP Events
Ethereum Cat Herders Meeting #127
Date & Time - March 12, 16:00 UTC
For details about the meeting, you can visit this GitHub issue.
EIPIP Meeting #101
Date & Time - March 13, 2024, at 17:30 UTC
For details about the meeting, you can visit this GitHub issue.
AllCoreDevs Execution Layer Meeting #183
Date & Time - March 14, 14:00 UTC
For details about the meeting, you can visit this GitHub issue.
That's all for this week from EIP Fun. EIP Fun is created and supported by LXDAO and PlanckerDAO. We aim to serve as the “layer 2” of the EIP ecosystem, simplifying and accelerating the adoption of EIPs.
Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.
Join the Telegram of EIP Fun: https://t.me/eipfun for more discussions and build connections with EIP buidlers. Follow our Twitter: @EIPFun.