EIP Fun Weekly #36: EIP-6110
Embark on an exhilarating journey as we delve into the EIP-6110, and more.
Hello everyone! Welcome to read the 34th 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 #32
EIP Status Change
Here is the EIP that have been approved for a status change on the EIP Editing Office Hour Meeting this week:
EIP-7523: Empty accounts deprecation
Status: Draft → Review
Abstract: This EIP serves as a prohibition against having empty accounts in the state of any post-merge network. As there are currently no empty accounts present outside of the testsuite, and the creation of new empty accounts is not possible, this requirement is already effectively met in practice. By explicitly banning empty accounts, it helps to reduce future technical debt.
EIP-3540: EOF - EVM Object Format v1
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.
EIP-6206: EOF - JUMPF and non-returning functions
Status: Draft → Review
Abstract: This EIP, also known as EIP-4750, introduces tail call optimizations for EOF (End of Function) functions. It achieves this by introducing a new instruction called JUMPF, which allows for jumping to a code section without adding a new return stack frame. Furthermore, the format of the type sections is expanded to enable the declaration of sections as non-returning. This modification simplifies the stack validation process for JUMPF instructions executed within such sections.
EIP-7480: EOF - Data section access instructions
Status: Draft → Review
Abstract: This update introduces four new instructions that enable reading the data section of an EOF (End of Function) container.These new instructions provide enhanced functionality for accessing and manipulating the data within an EOF container.
AllCoreDevs Consensus Layer Call #128
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: Ethereum clients have finalized their software for the Dencun upgrade, except for Lodestar. Testing on a dedicated testnet is in progress, and the mainnet shadow fork is live without any reported issues. The official announcement of the Dencun mainnet date is expected next week, with activation set for March 13, 2024. The Flashbots team is also preparing a Dencun-ready release for their MEV-Boost software.
2.Electra EIP Discussion: Danny Ryan shared an update on the Electra EIP discussions. Development work on PeerDAS and ePBS can be done alongside Electra, but their inclusion is not certain. Inclusion lists are less complex than expected, but unknowns need to be addressed before including them in Electra. The MaxEB change may be put on hold due to complexity. The Electra upgrade will focus on the agreed EIPs from ACDC #126 and investigating inclusion lists' readiness.
3.Issuance Curve Adjustment Proposal: Ansgar Dietrichs presented a proposal to reduce staking rewards for Electra due to the increased demand for staking on Ethereum. The proposal aims to address negative effects such as network load and reliance on third-party protocols. Further research and discussion are needed before deciding on its inclusion in Electra. The technical implementation of the proposal is straightforward but requires careful consideration.
4.Light Client Roadmap for Electra: Etan Kissling, a Nimbus developer, discussed SSZ-related EIPs for Electra and their impact on light client development in Ethereum. These EIPs aim to improve compatibility between CL and EL and support light client nodes that verify the blockchain with minimal resources. Kissling's proposal outlines updates to important data structures using an SSZ wrapper. Danny Ryan encouraged client teams to review and provide feedback on the proposal.
Further Reading
Ethereum All Core Developers Consensus Call #128 Writeup by Christine Kim: https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-128/
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
New ERC-7596: Equity Shares Book-Entry System
The proposed Equity Shares Book-Entry System introduces a protocol and ABI definition that leverages smart contracts to automate equity share management and corporate governance processes. It brings transparency, eliminates defaults, enables direct exercise of rights, and connects equity shares to the crypto markets, potentially benefiting companies and investors alike.
Why proposed it?
The corporate governance challenges in capital markets can be categorized into three main issues: the difficulty for right holders to exercise their rights, occasional intentional violations of obligations by obligors, and untimely or inaccurate information disclosure. By leveraging smart contracts to manage equity shares and corporate governance activities, human influences can be minimized, leading to several significant benefits.
First, direct exercise of rights can be facilitated, allowing right holders to smoothly and seamlessly assert their entitlements. Second, obligors are unable to default on their obligations as all actions are self-executing within the smart contract framework. Lastly, real-time and accurate information disclosure becomes possible, ensuring transparency in the corporate governance process.
Booking equity shares on the blockchain goes beyond a simple transfer of existing shareholder records. The crucial aspect lies in the utilization of smart contracts to address the aforementioned corporate governance challenges. Smart contracts are entrusted with complete control over all legal procedures related to share transactions and corporate governance. This ensures strict adherence to internal governance rules (e.g., Articles of Association, Operation Agreement, Shareholders Agreement) and external governing laws (e.g., Securities Act, Securities Exchange Act).
Consequently, the capital market can rely on the objective logic of smart contracts to automate the creation, modification, execution, and termination of equity share rights. This implementation establishes a genuinely trustworthy "Credit Internet of Web 3.0" by embracing the concept of "Code Is Law." It enables a transparent and reliable governance system that operates within the predefined rules and regulations of the corporate world.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/erc-7596-equity-shares-book-entry-system/18155
EIP-2330: EXTSLOAD opcode
This proposal introduces a new opcode called EXTSLOAD at 0x5c. When executed, it pops two items from the stack: the account address and the storage key. It then pushes the corresponding storage value onto the stack. The gas cost for this operation is determined by the sum of the account access cost and the storage read cost, as specified by EIP-2929 Access Lists.In summary, EXTSLOAD allows for efficient access to storage values based on the account address and storage key, with gas costs calculated according to the rules defined in EIP-2929.
What’s its potential uses?
Batch Operations: By combining multiple function calls into a single transaction, developers can perform multiple operations in a single atomic set of actions. This is particularly useful for executing a series of interdependent or related transactions.
Gas Efficiency: The Multicall standard helps optimize gas costs by reducing the overhead associated with individual transactions. By bundling multiple calls together, gas costs can be significantly reduced compared to executing each call separately.
Contract Aggregators: EIP-2330 enables the creation of contract aggregators or middleware services that can execute multiple contract interactions on behalf of users or other contracts. This can simplify and streamline complex interactions with multiple contracts.
On-Chain Batch Processing: Smart contracts with complex logic that requires the execution of multiple function calls can utilize EIP-2330 to perform batch processing efficiently on-chain. This can improve scalability and reduce transaction costs for such contracts.
Further Reading
FEM forum discussion:
Anecdote of the Week: EIP-6110
During this week, developers unanimously decided to initiate the development process for the Electra upgrade. At present, three Ethereum Improvement Proposals (EIPs) have been selected for inclusion in this upgrade. These EIPs are as follows: EIP 6110, which focuses on providing validator deposits on the blockchain; EIP 7002, which enables the activation of exits within the execution layer; and EIP 7549, which involves relocating the committee index from the attestation. Today, let's explore the details of EIP-6110 and delve into its significance.
Why proposed it?
The EIP-6110 proposal focuses on the processing of validator deposits within the protocol itself, eliminating the current proposer voting mechanism. This change enhances the security and user experience of the deposit flow and simplifies client software design. The advantages of in-protocol deposit processing include significantly increased deposit security, reducing the likelihood of processing fake deposits even with a majority of adversarial stake. It also reduces the delay between submitting a deposit transaction and its processing, improving efficiency compared to the existing mechanism. Additionally, it eliminates the need for beacon block proposals to rely on JSON-RPC API data polling, which can be prone to failures and inconsistencies. It also removes the requirement for maintaining and distributing deposit contract snapshots. Overall, this proposal reduces complexity and improves the robustness of the Consensus Layer client software.
What’s its potential uses?
Enhanced Security: By supplanting the proposer voting mechanism, the in-protocol deposit processing significantly increases the security of deposits. It mitigates the risk of processing fake deposits even when a significant portion of the stake is adversarial.
Improved Efficiency: The proposed in-protocol mechanism reduces the delay between submitting a deposit transaction on the Execution Layer and its processing on the Consensus Layer. This results in a considerable decrease in processing time, with approximately 13 minutes compared to the current mechanism's 12 hours.
Elimination of Dependencies: EIP-6110 eliminates the dependency on JSON-RPC API data polling for beacon block proposals. This eradicates potential failures caused by inconsistencies between different implementations of the API and the reliance on the inner state of client software, such as syncing.
Removal of Deposit Contract Snapshots: With the adoption of EIP-6110, the necessity to maintain and distribute deposit contract snapshots, as specified in EIP-4881, is eliminated. This simplifies the process and reduces overhead in managing deposit-related operations.
Reduction of Complexity: By incorporating in-protocol deposit processing, the design and engineering complexity of Consensus Layer client software is reduced. This addresses previous challenges and makes the software more robust and reliable.
EIP Events
Ethereum Cat Herders Meeting #127
Date & Time - February 27, 16:00 UTC
For details about the meeting, you can visit this GitHub issue.
EIPIP Meeting #101
Date & Time - February 28, 2024, at 17:30 UTC
For details about the meeting, you can visit this GitHub issue.
AllCoreDevs Execution Layer Meeting #182
Date & Time - February 29, 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.