EIP Fun Weekly #23: The Art of Pruning
This week, we will be exploring the EIPs that contribute to the pruning of the Ethereum ecosystem, plus updates on key EIP meetings, new ideas, and more!
Hello everyone! Welcome to read the 23rd 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.
AllCoreDevs Execution Layer Meeting #175
Takeaways:
The developers have agreed to launch Devnet 12 next week, even if not all teams are ready.
Additionally, Tim Beiko stressed the importance of shutting down Goerli, reminding validator teams and EF developers that once Dencun goes live on Goerli, they should cease running the Goerli validator within 3 months of the Goerli Dencun upgrade or 1 month after the mainnet Dencun upgrade.
Beiko also mentioned that Dencun will be the final upgrade to be implemented on the test network. As a result, he advised users who are still relying on Goerli as a stable test network to migrate to other networks in order to facilitate a seamless transition.
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
New EIP-6601: EVM Modular Arithmetic Extensions (EVMMAX)
EIP 6601 builds upon EIP 5843, suggesting the inclusion of optimized modular addition, subtraction, and multiplication opcodes into the EVM. These opcodes specifically cater to odd moduli with sizes reaching up to 4096 bits. The author of EIP 6601 is @jwasinger.
Why propose it?
Benefits of the changes proposed in this EIP:
Enables the implementation of elliptic curve arithmetic operations on different curves, such as BLS12-381, through EVM contracts.
The gas cost per operation for values up to 256 bits in size can be reduced by 90-95% compared to the existing MULMOD and ADDMOD opcodes.
It becomes feasible to implement modexp (modular exponentiation) functionality as an EVM contract.
Leads to significant cost reductions for algebraic hash functions like MiMC/Poseidon and zkp verifications within the EVM.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
EIP-6909-multi-token-standard
The proposal, written by authors JT Riley (@jtriley-eth), Dillon (@d1ll0n), Sara (@snreynolds), and Vectorized (@Vectorized), introduces a multi-token contract that serves as a simplified alternative to the ERC-1155 Multi-Token Standard.
It aims to provide a streamlined solution for managing multiple tokens within a single contract, enhancing the efficiency and usability of token-based systems on the Ethereum platform.
Why propose it?
The proposed multi-token contract standard, in contrast to ERC-1155, excludes certain features that are deemed unnecessary. This includes the requirement for recipient accounts to implement callbacks with specific return values and the inclusion of batch-calls in the specification.
Additionally, the single operator permission scheme in ERC-1155, which grants unlimited allowance on every token ID, is not part of the proposed standard. The focus is on maintaining backwards compatibility where necessary while removing unnecessary features. To minimize the required external interface and improve user experience, additional features like batch calls, increase and decrease allowance methods, and other improvements are deliberately omitted from the specification.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-6909-multi-token-standard/13891
EIP-2294: Explicit bound to Chain ID size
Under this EIP, beginning from blocknum = FORK_BLKNUM, there is a size restriction imposed on the EIP-155 Chain ID parameter. This restriction sets a maximum value floor(MAX_UINT64 / 2) - 36 to ensure consistency in the usage of this parameter across different projects. The authors of this EIP are Zainan Victor Zhou (@xinbenlv) and Alex Beregszaszi (@axic).
Why propose it?
EIP-155 plays a crucial role in ensuring domain separation and replay protection for Ethereum protocol signed messages through the Chain ID parameter. However, the EIP does not specify any particular size requirements for this parameter. Allowing it to be 256-bit wide necessitates the usage of arithmetic operations beyond the 256-bit limit when calculating the v field in the RLP encoding of a transaction.
A carefully chosen Chain ID value is imperative in order to maintain uniform implementation of EIP-155 (along with its derivative, EIP-1344) across different client codebases and external tools. By explicitly establishing a maximum size for the Chain ID parameter, Ethereum and projects built on its codebase can mitigate these risks, ensuring the network's security and the integrity of its operations.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090
Anecdote of the Week
As enthusiasts, our primary desire is to witness growth, which is why pruning can seem counterintuitive. We often perceive growth as a symbol of success and vitality, making it difficult to comprehend the need for cutting it off. While some may fear harming plants through pruning, the truth is that pruning actually stimulates further growth and enhances overall plant health.
When a branch is cut, it triggers a chemical response in the plant, leading to the development of new foliage and branching. Pruning not only enhances the overall health of the plant by managing its structure and size but also allows us to guide the plant to fulfill our desired outcomes.
In the realm of Ethereum, a similar scenario arises. To rebuild the deposit Merkle tree, the majority of client implementations necessitate beacon nodes to download and retain each deposit log from the inception of the deposit contract.
Nevertheless, this method compels beacon nodes to store excessive deposits beyond what is essential for consensus participation. Moreover, it results in longer synchronization times for new nodes, especially during weak subjectivity sync. This simplistic approach also hinders the pruning of historical contract logs from full nodes, an aspect frequently debated in relation to controlling state expansion.
The art of pruning in the Ethereum ecosystem can be approached through the proposal of EIP-4881. This proposal introduces a standardized format for transmitting the deposit contract Merkle tree in a compressed form during weak subjectivity sync. By implementing this format, newly synchronizing consensus clients can reconstruct the deposit tree more efficiently, without the need to download all historical deposits. Furthermore, this format enables clients to prune deposits that are no longer necessary for full consensus participation.
During the deposit processing in the beacon chain, each deposit is submitted with a Merkle path to the deposit root, which is a one-time requirement. Once a deposit has been processed and the deposit finalization conditions are met, many of the hashes along the path to the deposit root are no longer necessary for constructing Merkle proofs on the chain. These surplus hashes can be pruned, saving space within the system.
The provided diagram showcases the progression of the deposit Merkle tree during this process, along with the corresponding changes in the DepositTreeSnapshot. As new deposits are added and older ones reach finalization:
Want to know more about it? Check out:
EIP Events
EIP Editing Office Hour Meeting #28
Date & Time - November 28, 2023, at 15:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
EIPIP Meeting #95
Date & Time - November 29, 2023, at 16:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
Tokenbound Weekly Dev Call (ERC-6551)
Date & Time - November 30, 2023, at 15:00 UTC
For meeting message and more detail, you may join the official dev working group here.
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.