EIP Fun Weekly #39: EIP 7547 Inclusion lists
Explore the EIP-7547,which may strengthen the network's ability to resist any attempts to censor or manipulate transactions, thereby upholding the core value proposition of censorship resistance.
Hello everyone! Welcome to read the 39th 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 #183
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 Retrospective
Developers of Ethereum discussed the positive impact of the Dencun upgrade on the network, as a majority of validator node operators upgraded their software, resulting in no significant disruptions or delays. The network is processing new transactions and blobs more quickly than expected, potentially due to optimizations by "private source" relays for earning additional MEV rewards.
However, there is an increase in reorganizations, with roughly three to four more per day after the upgrade. Following the completion of the upgrade, developers will update the status of the included Ethereum Improvement Proposals to "Final," and the Goerli testnet is experiencing disruptions as users and node operators transition off it.
2.EIPs for Pectra:
During the discussion, developers considered several Ethereum Improvement Proposals (EIPs) for the upcoming Pectra upgrade.
EIP 2537 introduces new cryptographic primitives to enable developers to build more secure and efficient decentralized applications (DApps). EIP 3074 proposes a new opcode, "DELEGATECALL with revert," to enhance composability and enable contracts to delegate calls with the ability to revert state changes in case of exceptions.
EIP 7547, EIP 7623, and EIP 7645 respectively suggest standardized blockchain event reporting, recoverable transfers for ERC-20 tokens, and a bytecode format to optimize gas costs and improve compatibility on the Ethereum blockchain.
Further Reading
Ethereum All Core Developers Execution Call #183 Writeup by Christine Kim: https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-183/
EIPIP Meeting #101
EIPIP stands for “Ethereum Improvement Proposal improvement process”, which intends to bring together experienced developers and experts to facilitate the Ethereum Improvement Proposal improvement process.
EIP Status Change
Here are EIPs that has been approved for a status change:
EIP-7377: Migration Transaction
Status: Undefined → Draft
Abstract: A new transaction type, EIP-2718, is proposed to be introduced with the format 0x04 || rlp([chainId, nonce, maxFeePerGas, maxPriorityFeePerGas, gasLimit, codeAddr, storage, data, value, accessList, yParity, r, s]). This transaction type sets the code field of the sending account in the state trie to the code value at codeAddr and applies the storage tuples to the sender's storage trie.
EIP-4788: Beacon block root in the EVM
Status: Review→ Final
Abstract：Incorporate the hash tree root of every block in the beacon chain into the execution payload header. Save these roots in a smart contract.The cryptographic accumulators, or roots, of the beacon chain blocks enable the creation of proofs for arbitrary consensus states. By making these roots accessible within the Ethereum Virtual Machine (EVM), it enables trust-minimized access to the consensus layer. This functionality has the potential to enhance trust assumptions in various use cases, such as staking pools, restaking constructions, smart contract bridges, mitigating Miner Extractable Value (MEV), and more.
EIP-4200: EOF - Static relative jumps
Status: Draft → Review
Abstract: To optimize and reduce costs in the Ethereum Virtual Machine (EVM), three new jump instructions have been introduced: RJUMP, RJUMPI, and RJUMPV. These instructions encode destinations as signed immediate values, providing efficiency in the majority of use cases. While they offer cost reduction, it's important to note that they may not be applicable in all scenarios.
EIP-7620: EOF Contract Creation
Status: Draft → Review
Abstract：In the EVM Object Format (EOF), the ability to create contracts using creation transactions, CREATE, or CREATE2 instructions is eliminated. Instead, the EOF introduces three new instructions: EOFCREATE, TXCREATE, and RETURNCONTRACT. Additionally, a new transaction type called InitcodeTransaction is introduced to facilitate the creation of contracts using EOF containers. These changes provide an alternative method for contract creation within the EOF framework.
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
New Idea: Towards More Conversational Wallet Connections-A Proposal for the redeemDelegation Interface
The essence of this idea is centered around envisioning a new paradigm for wallet connections in the Ethereum space, focusing on making them more user-centric and conversational.
Why proposed it?
The current method of initiating connections by exposing a user's public address has various drawbacks, including susceptibility to phishing attacks and the burden on application developers to maintain complex indexing infrastructures. This approach tends to favor more established assets and creates barriers for newer entries. Additionally, it leads to wallets relying on centralized infrastructure to combat scams and enhance readability, which undermines the decentralized nature of blockchain interactions.
A potential solution to improve user control and reduce reliance on centralized infrastructure is to give users the ability to initiate site connections and issue "session keys" for dapp connections. This approach empowers users by putting them in charge of granting permissions for their sessions. To achieve this, a standard method for contract accounts to issue arbitrary session permissions is needed, allowing for flexibility and evolution within the ecosystem.
One approach to issuing session permissions is by enabling sites to request specific types of assets needed for the interaction. Users can then have the ability to select the set of assets and permissions they are willing to share. By introducing additional deliberative steps for the user, this approach reduces the risk of confirmation fatigue while giving users greater control over their interactions.
Introduce redeemDelegation
To address these concerns and facilitate a more user-centric approach, the author proposes an abstract Solidity interface called redeemDelegation. Here's an initial draft to initiate discussions:
The purpose of the redeemDelegation interface is to allow contract accounts to adopt customizable authorization logics, enabling tailor-made and user-directed authorization when connecting to websites. This approach deviates from the current practice of websites dictating transactions and relying on obscure allowance methods. By using redeemDelegation, we aim to reduce dependence on centralized infrastructures and provide users with more control over their transactions.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/towards-more-conversational-wallet-connections-a-proposal-for-the-redeemdelegation-interface/16690/1
ERC-7631: Dual Nature Token Pair
In order to establish a linkage between a fungible ERC-20 token contract and a non-fungible ERC-721 token contract, this proposal outlines a mechanism to query the relationship between the two contracts. It also introduces the capability for accounts to configure whether ERC-721 mints and transfers should be skipped during the synchronization process from ERC-20 to ERC-721.
Why proposed it?
The ERC-20 fungible token standard and the ERC-721 non-fungible token standard offer sufficient flexibility to create a unified token pair with dual characteristics. This means that transfers made on the ERC-20 token can automatically trigger transfers on the linked ERC-721 token, and vice versa. This introduces new possibilities, such as native fractionalization of ERC-721 tokens, where the purchase of ERC-20 tokens results in the automatic issuance of ERC-721 tokens proportional to the ERC-20 holdings.
Dual nature token pairs remain fully compliant with both the ERC-20 and ERC-721 token standards. The aim of this proposal is to enhance the functionality of dual nature token pairs by providing extension interfaces for querying the relationship between the tokens. These extension interfaces enable various improvements, such as allowing decentralized exchanges and NFT marketplaces to display the connection between the tokens.
Moreover, users have the option to configure whether they want to skip ERC-721 mints and transfers during the synchronization process from ERC-20 to ERC-721. This gives users control over the synchronization mechanism and allows for customization to suit their specific needs and preferences.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/erc-7631-dual-nature-token-pair/18796
Anecdote of the Week: EIP-7547 Inclusion lists
At the recent ACDE 183 conference, developers explored various Ethereum Improvement Proposals (EIPs) for the upcoming Pectra upgrade. Among these proposals, EIP-7547, also known as Inclusion lists, received attention and consideration.
Brief Introduction
The resistance to censorship is a fundamental and important feature of blockchain technology. In the context of Ethereum, inclusion lists are introduced as a means to enhance the censorship resistance of the network.
By utilizing inclusion lists, those proposing transactions can specify a predetermined set of transactions that must be promptly included in subsequent blocks for those blocks to be considered valid.
The purpose of implementing inclusion lists is to ensure that specific transactions, as defined by the proposer, are prioritized and included in the blockchain without delay or censorship. This mechanism strengthens the network's ability to resist any attempts to censor or manipulate transactions, thereby upholding the core value proposition of censorship resistance in the Ethereum ecosystem.
Why proposed it ?
Since the merge to Ethereum 2.0, validators have increasingly relied on specialized builders to produce blocks in order to maximize their ability to extract Maximum Extractable Value (MEV). This trend, known as Proposer-Builder Separation, has resulted in builders being responsible for the majority of block production (approximately 95% of blocks as of October 2023).
While this allows proposers to access competitive blocks through the mev-boost ecosystem, it has a significant drawback: builders have full control over which transactions are included or excluded from blocks. As a result, proposers face a dilemma: either relinquish control over transaction inclusion or build the block locally, sacrificing potential MEV rewards.
The objective of inclusion lists is to empower proposers by providing a mechanism to forcefully include transactions. The simplest approach involves the proposer for a given slot specifying a list of transactions that must be included in the block produced for that slot. However, this design is not incentive-compatible, as builders may refuse to build blocks if constraints are placed on their behavior. To address this issue, "forward" inclusion lists are proposed, wherein the slot N proposer's specified transactions are enforced in the subsequent slot N+1 block.
However, a straightforward implementation of forward inclusion lists introduces the risk of free data availability, which could be exploited to unnecessarily enlarge the chain without paying the corresponding gas costs. This problem is mitigated by considering nonce reuse and allowing multiple inclusion lists to be specified for each slot. By addressing the incentive compatibility and free data availability issues, the implementation of inclusion lists can proceed more securely.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474
EIP Events
EIP Editing Office Hour Meeting #34
Date & Time - March 19, 2024, at 16:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
AllWalletDevs #22
Date & Time - March 20, 2024, at 13:00 UTC
For more details about the meeting agenda, you can join this Discord Channel.
AllCoreDevs Consensus Layer Meeting #130
Date & Time - March 21, 2024, at 14:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
AllERCDevs #2024 1st
Date & Time - March 21, 17:00 UTC
You may join their discord server here.
For more detail, you may open this thread 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.