EIP Fun Weekly #27: ERC-4337 vs EIP-3074
Get the latest updates on EIP discussions about supply caps, new standards for modular smart contract accounts, upcoming meetings, and more.
Hello everyone! Welcome to read the 27th 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 Call #177
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
Goerli Shadow Fork:The Ethereum Foundation DevOps team launched a second shadow fork of the Goerli testnet, activating it with 290 nodes running 100 validators each in multiple locations, with nearly all clients successfully joining and upgrading, and the network performing well despite bandwidth increases and different block propagation events emitted by different clients, as described in the detailed analysis (GSF #1).
Precompile Address Ranges:During discussions, developers debated the allocation of precompile address ranges for Layer 2 solutions (L2s), considering whether L2s should use separate addresses or share them with Ethereum mainnet. While a disjointed range was favored by some due to uncertainty around the RIP process, the idea of using the same addresses for L1 and L2s was supported by others to avoid potential limitations. Currently, L2s are advised to use a separate precompile address range, with the option to reconsider in the future.
Prague/Electra Proposals:Beiko called for developers to review proposals for the Prague/Electra upgrade and prioritize code changes for the next Ethereum upgrade, suggesting the activation of a small upgrade before the end of 2024. The Verkle Trie upgrade, a major change expected shortly after the Cancun upgrade, was discussed as a potential standalone upgrade due to its complexity. Data availability sampling, aimed at reducing costs on Ethereum, is also making progress without requiring in-protocol changes.
Want to know more details? Check out “Ethereum All Core Developers Execution #177 Writeup” by Christine Kim.
EIP Status Change
Here are the EIPs that have been approved for a status change on this week:
EIP-6780: SELFDESTRUCT only in same transaction
Status: Draft → Review
Abstract: This EIP proposes a modification to the functionality of the SELFDESTRUCT opcode. The proposed change ensures that when SELFDESTRUCT is called, the account's remaining Ether will be transferred to the specified target. However, the current behavior will be maintained if SELFDESTRUCT is called within the same transaction in which the contract was created.
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
Discussion:Prague/Electra Network Upgrade Meta Thread
As the Dencun event concludes, it is now time to shift our focus towards the Prague/Electra upgrade. Following the approach taken for the Cancun 12 upgrade, Tim Beiko suggests utilizing this thread as a platform to discuss the overall process and extent of the upcoming upgrade.
Suggestions
@Tim Beiko
My suggestion for larger process adjustments is to reintroduce Meta EIPs. Currently, there is no centralized platform to track the comprehensive scope of a network upgrade before it is deployed and announced through a blog post. Considering the separation of ERC and EIPs, I propose the use of Meta EIPs again, to track the inclusion of EIPs in network upgrades.
@ralexstokes
I'll initiate the discussion by introducing EIP-2537 90. There may be some minor adjustments to the precompiles and gas schedule, but all of this will be addressed in time for thorough discussions regarding its inclusion in Prague/Electra. There is considerable demand from both rollups and cryptography use cases, making the inclusion of BLS12-381 precompiles a top priority for this hard fork. It seems like the perfect opportunity to incorporate them.
@Wander
I agree that EIP 7002 (EL-induced exits) is worth mentioning. The staking community greatly requires a mechanism to initiate exits through smart contracts, which would effectively and completely enhance trustless staking protocols. Although some ideas for potential enhancements were discussed at DevConnect this year, even if it is included as-is, Ethereum would experience a significant improvement in terms of security.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/prague-electra-network-upgrade-meta-thread/16809/9
ERC-7521: Generalized Intents for Smart Contract Wallets
The proposal,authored by Stephen Monn (@pixelcircuits), Bikem Bengisu (@supiket),suggests the implementation of a generalized intent specification entry point contract to support various intent standards as they evolve.
Rather than requiring constant upgrades to smart contract wallets for new intent standards, a single trusted entry point contract handles signature verification and delegates low-level intent data handling to other contracts specified by users.
These signed messages, known as UserIntents, circulate through different mempool strategies for MEV (Maximal Extractable Value) searchers to analyze and combine with their own UserIntents into an object called an IntentSolution. MEV searchers then package this IntentSolution into a transaction, which undergoes the usual MEV channels to ultimately be included in a block.
What are its potential use cases?
Decentralization
Any MEV searcher is welcome to participate in solving signed intents as part of the process.
Developers have the freedom to include their own intent standard definitions, providing users with the option to opt-in during the sign-up process.
Be forward thinking for future intent standard compatibility: It is important to define an intent standard interface that grants future intent standard defining contracts maximum access to information regarding the current handleIntents execution context.
Keep gas costs down to a minimum:To optimize gas efficiency for common use cases, the entry point contract should incorporate essential intent handling logic, such as the execution order of intent segments.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/erc-7521-generalized-intents-for-smart-contract-wallets/15840
ERC-7208: On-chain Data Container
ERC-7208 introduces the concept of On-Chain Data Containers (ODCs) which are mutable, extensible, and composable on-chain data storage containers. ODCs can possess specific properties, be governed by restrictions, and trigger actions through hooks. The programmability of ODCs is facilitated by Property Manager smart contracts, allowing for the implementation of multiple interfaces to handle the stored values.
What are its potential use cases?
Consider the tokenization of a luxury car rental as an example. This use case would require the interoperability of rentable NFTs (ERC-4907), a security token (ERC-3643), and a compliance system utilizing one or several standards. The challenge is that once this solution is built, the ERCs become fixed and may not be interoperable with other solutions. ERC-7208 addresses this issue by introducing ODCs, which streamline custom interoperable solutions and enable interactions across different standard interfaces. This allows for greater flexibility and ease of integration with other products and services.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/erc-7208-on-chain-data-container/14778
Anecdote of the Week: ERC-4337 vs EIP-3074
What is the concept of Account Abstraction?
Each Ethereum account incorporates five key functionalities:
Authentication: Verifying and confirming one's identity.
Authorization: Determining the accessibility and privileges granted to an account.
Replay protection: Ensuring transaction order is independent of replay protection.
Gas payment: Separating gas payment from the account's balance.
Execution: Implementing various execution logics.
Account abstraction introduces the ability to customize these functionalities beyond the hardcoded implementation.
ERC-4337 vs EIP-3074: False dichotomy
EIP-3074 introduces invokers to enable arbitrary execution logic and enhance an EOA's capabilities without the need to transfer assets to a new account, focusing solely on execution abstraction.
On the other hand, ERC-4337 aims to abstract all five functionalities, posing a more challenging task to maintain decentralization and censorship resistance. It primarily addresses mitigating DoS and griefing attacks that arise from abstracting the first four functionalities, but requires migrating to a smart account instead of extending an EOA's capabilities.
There is minimal overlap between these two methods, limited only to Execution abstraction.
Furthermore, each method addresses unique problems that the other does not: EIP-3074 serves existing EOAs and prioritizes simplicity, while ERC-4337 aims to provide complete Account Abstraction without compromising core Ethereum properties like decentralization.
If a comparison is necessary, ERC-4337 is more comparable to EIP-2938 rather than EIP-3074. EIP-2938 was a significant advancement in account abstraction, specifically addressing the challenges of DoS mitigation in an AA mempool. While ERC-4337 resolves certain issues that EIP-2938 did not, a comprehensive comparison falls outside the scope of this document.
Want to know more about it? Check out:
EIP Events
EIP Editing Office Hour Meeting #30
Date & Time - December 26, 2023, at 15:00 UTC
For more details about the meeting agenda, 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.