Table of Contents
- 1. Author’s Note
- 2. Newly Drafted EIPs
- 2.1 Execution & Consensus Layer
- 2.2 URI / URL
- 2.3 Library / Packaging / Module
- 2.4 Storage / Registry
- 2.5 Token Standards / Extensions
- 3. Progression of Existing EIPs
- 3.1 Transaction
- 3.2 On-Chain & Off-Chain Data Retrieval / Indexing
- 3.3 Contract - Execution / Scheme
- 3.4 Storage / Repository
- 3.5 Account / Meta Transaction / Wallet
- 3.6 Token Standards & Extensions
- 4. “Food for Thoughts” - Is ERC-4337 an Optimal Solution for AA?
Researcher
Related Projects
Ethereum broke new ground by bringing the concept of smart contracts to the existing blockchain scene, and with the EIP, its potential is getting realized. Thanks to this, we can now dream of many different businesses and use cases through the blockchain. However, if more opinion leaders with diverse perspectives emerge and shape the trend of EIP together, the future we dream of will be even more enriched.
This article is a high-level trend review of which EIPs are newly adopted as drafts each month. Hopefully, this article will help various builder/business stakeholders understand the history of EIPs, and serve as a catalyst for further value propositions in the industry.
1. Author’s Note
As we saw in the last article, September was a month where a lot of Core EIPs were proposed, especially around the Dencun update. As such, October was more about testing and validating existing EIPs rather than proposing additional EIPs for the Dencun update - in particular, the Epoch Churn Limit adjustment was successfully tested, and other minor bugs were fixed. However, it was discussed that the development schedule will require multiple testnets, so the actual integration of the Dencun update into the mainnet will take longer than expected and will likely be pushed back to early next year.
In addition to this, a major discussion point was that ERC and EIP will finally be separated within the EIP Repository. Actually, this had been discussed in the past when EIPs started to grow in size, but the discussion often stalled when it came to concrete implementation. With the vision of Ethereum network achieving minimalism and robustness, EIPs primarily related to Core are being discussed by a small group of people, while ERCs for more diverse use cases are being proposed by an increasingly diverse group of people, so the separation of the repository is expected to allow EIPs and ERCs to be discussed in a more productive and efficient manner.
Meanwhile, at October's EIP, a number of standards were proposed or advanced to the next stage in a variety of areas, but it was particularly notable that standards related to Transactions or ERC-4337 were frequently discussed.
2. Newly Drafted EIPs
A total of 11 new EIPs were adopted as Drafts in October, down 12 from the previous month - bringing the total number of proposed EIPs to 698 through October 31. Unlike September, which saw an unusually high number of Core EIPs proposed, October's EIPs were dominated by ERCs, as in other months.
Below are more detailed categorizations of the newly adopted EIPs in Draft, with some notable ones highlighted.
2.1 Execution & Consensus Layer
2.1.1 EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
Until now, Ethereum has fixed the amount of ETH deposited per validator at 32 ETH. There are two main problems with this: 1) Entities that want to deposit large amounts of ETH have to run multiple validators, which leads to an excessive number of validators on the network. 2) When each validator earns a reward, any amount over 32 ETH is not re-staked, so there is no compounding effect.
Source : https://beaconscan.com/stat/validator
In fact, the number of validators on Ethereum has been growing rapidly and is now close to 1 million (as of October 31st). If this trend continues, the number of p2p messages that validators need to communicate, the number of BLS signatures that need to be aggregated for each epoch, and the BeaconState memory footprint will increase dramatically, putting a computational strain on nodes - of course, this can be accomplished by setting a conservative Epoch Churn Limit as mentioned in the last post, but this is a band-aid solution, so a more fundamental solution would be to reduce the number of validators in the network.
“MIN_ACTIVATION_BALANCE → 32 ETH” & ”MAX_EFFECTIVE_BALANCE → 2048 ETH”
The main idea behind EIP-7251 is to leave the minimum amount of Ethereum required for validators unchanged (i.e. 32 ETH), but increase the upper limit to 2048 ETH to reduce the number of validators for large depositors, thereby alleviating the communication overhead described above. This will also allow validators to deposit flexible amounts of Ethereum, allowing them to benefit from the compounding effects of staking.
As you can see, this EIP clearly brings a lot of benefits, so many developers are pretty optimistic about its adoption. However, it will need to be carefully debated before it is actually finalized, as its impact could be significant enough to require modifications to a number of key issues, including the dynamics of the committees required for Ethereum nodes to reach consensus and the redefinition of the Epoch Churn Limit.
2.1.2 EIP-7542: eth/69 - available-blocks-extended protocol
In Ethereum, when a new node enters the network, it follows a protocol called DevP2P to build a peer-to-peer network and interact with other nodes. This DevP2P protocol has several subprotocols that cover the entire communication process, including connecting nodes through handshaking, exchanging transactions, etc.
EIP-7542 aims to extend the existing subprotocol (i.e., wire protocol) to allow an Ethereum node to handshake with a peer node, including information about the scope it can serve, so that nodes can connect with their preferred peers based on the data they need and achieve efficient synchronization.
However, the problem with this approach is that nodes prioritize communication with peer nodes that have the block range they need, and may drop communication with non-prioritized peer nodes, resulting in an imbalance in the dynamics of inter-node communication across the network - especially, since Ethereum network is not a network that seeks efficiency enough to tolerate an asymmetric communication structure, but rather seeks to operate a stable network, so it is expected that a lengthy discussion will be required before the proposal is actually finalized.
2.1.3 Others
2.2 URI / URL
2.2.1 ERC-6860: Web3 URL to EVM Call Message Translation
To access a DApp like uniswap, we type 'https://app.uniswap.org/' into our browser URL. But what if we go to 'web3://uniswap.eth’ instead? Currently, most of the data we receive from web3 services is read by their own websites or by node provider services like etherscan. In other words, no matter how decentralized your application is, users still have to go through a centralized server or http://-like protocol (which can be censored) to access it.
As such, ERC-6860 proposes the idea of allowing users to directly execute queries against EVMs, giving them direct access to Web3 services without going through a centralized server, and ensuring that all services are censorship-resistant up to the way they are displayed. So, OSI layer 7 perspective, ERC-6860 is the presentation layer - the standard allows users to render any web content (including HTML/CSS/JPG/PNG/SVG, etc.) on-chain using human-readable URLs.
Source : Twitter
The standard is also compatible with existing Web2 methods (i.e., HTTP-URL), so if existing browser services such as Chrome Browser adopt the standard, users who are not familiar with Web3 will be able to use the Internet in a decentralized way by simply changing their URLs.
2.3 Library / Packaging / Module
2.3.1 ERC-7521: General Intents for Smart Contract Wallets
With growing public interest and accelerating adoption discussions, the practical use cases, or UX, of blockchain have begun to emerge within the industry and beyond. As a result, there is considerable interest in standards that can significantly improve the user experience by removing the need for users to understand the details of the protocol infrastructure or go through the extra steps involved in using an application - the now-familiar account abstraction (based on ERC-4337) is a prime example of this.
By the way, in addition to the account abstraction, there is another concept that has recently begun to receive a lot of attention for its potential to create unique interaction experiences for users: ‘Intent'. When a user submits an Intent, which expresses a desired outcome (or end state), an entity called a Solver ‘somehow' weaves together a series of transactions to bring the desired outcome to each user.
“I want to swap USDC to ETH on Uniswap when the gas fee required by the network is below a certain threshold.”
However, as much as these intents seem like a magic spell, their implementation remains largely unspecified, so there has been a need for a minimum framework that can be shared by users and services that potentially want to utilize them, or by entities that actually ‘solve' them (i.e., solvers) - which is why ERC-7521 was proposed by Essential.
Source : xpara’s Twitter
Basically, the workflow of ERC-7521 is very similar to that of ERC-4337. Intents are pooled together in a separate mempool called the UserIntents Mempool, and solvers weave together various transactions to solve each intent - these transactions can be autonomously generated by the solver, leverage existing transactions, utilize off-chain sources, or even be composed of parts of other users' intents. Users sign which IntentStandard they want their Intent to be executed through, and the signed IntentStandard is validated in a EntryPoint contract and its embedded logic is executed.
The concept of intent, which further abstracts the process by focusing on the outcome, holds the promise of revolutionizing blockchain UX in that the basic unit of interaction on a blockchain (i.e., a transaction), which we have come to feel is raw, can be expressed in an elegant way that is easily understood by humans. And ERC-7521 provides a minimal framework for this possibility to become more and more concrete. Based on this framework, it is hoped that the standards that need to be further refined (e.g., technical implementation, solving proprietary problems by a small number of solvers) will be actively discussed so that Intent use cases can be observed in the near future.
2.4 Storage / Registry
2.4.1 ERC-7484: Registries and Adapters for Smart Accounts
The ERC-4337-based account abstraction redefines the concept of a smart contract account by allowing various modules with specific functionalities to be utilized in the account. As interest in the concept grew, various services began to develop their own modules.
However, the proliferation of different modules has made it difficult for applications or users who want to utilize them to understand which modules they should use and whether they are truly secure. To address these issues, ERC-7484 proposes an interface for a "(Singleton) Module Registry" that collects modules with their attestations of security suitability for use and makes them easily browsable.
The EIP proposes only its interface, so the implementation part is not yet very well specified - the registry MUST implement verification mechanism that the producer of the attestation matches the attester along with the storage of the attestation, functionality to allow the attester to revoke the attestation, and a method called 'check' or ‘checkN'. Here, the check (checkN) method is a simple method that contains the logic to revert if the required number of attestations for a particular module do not exist. Each module registered in the registry is queried by the Adapter to install and run.
Source : Rhinestone’s Blog
It is expected that this ERC will allow the modules needed to define the functionality of smart accounts to be distributed in a more secure and efficient manner, making a significant contribution to the adoption and development of smart contract accounts.
2.5 Token Standards / Extensions
2.5.1 ERC-7417: Token Converter
When an ERC-20-based token is transferred to a smart contract via the 'transfer' method, the corresponding token on the smart contract is locked forever and cannot be retrieved. To overcome this limitation, ERC-223 has been proposed - the main idea of ERC-223 is to add a new method called 'tokenReceived' along with most of the features of ERC-20 and force contracts to implement it. If a token is transferred to a smart contract and 'tokenReceived' is implemented in that contract, the sender will be recognized as depositing the token into the contract, and 'transfer' alone will process the 'approve + transferFrom' logic of ERC-20. In other words, ERC-223 is a more gas-efficient solution than ERC-20 and a standard that prevents cases of misdirected transfers.
However, ERC-20 tokens that already have a unique address will have a new address if they upgrade to ERC-223, and there are potentially many risks associated with this change. The purpose of ERC-7417 is to propose a "Token Converter Contract" to allow existing ERC-20-based tokens to freely upgrade to the ERC-223-based tokens (and vice versa).
ERC-7417 has two main contracts - 'Converter Contract' and 'ERC-223 Wrapper Contract'.
The 'createERC223Wrapper' method of the Converter Contract creates an ERC-223 Wrapper by matching the address of each ERC-20 token with an ERC-223 Wrapper 1:1, and the 'converERC20toERC223' method locks a certain amount of ERC-20 tokens sent by the sender into the contract and sends the corresponding ERC223Wrapper tokens back to the sender. If the sender wants to convert those Wrapper tokens back to ERC-20 tokens, they can send them to the Converter Contract via ERC-223's transfer method - ERC-223's transfer method can handle ERC-20's 'approve + transferFrom' logic.
With services adopting ERC-7417, users will be able to handle existing ERC-20-based assets more reliably and efficiently.
2.5.2 Others
3. Progression of Existing EIPs
By the way, in addition to the 11 new EIPs adopted as Draft, 19 EIPs changed their status during the month of October. Of these, 14 were advanced to the next stage (i.e., Final, Last call, Review, Draft, etc.) for final adoption. The remaining 5 did not advance to the next stage and were moved to the Stagnant stage. No EIPs were finally changed to Withdrawn.
Also, unlike last month, when ERCs were the primary focus of progress, the EIPs that made progress this month all span a wide range of scopes, including Consensus & Execution Layers, URIs & URLs, Modules, Registries, Wallets, and Token Standards.
Some of the most notable ones are - ERC-5164, a standard for unifying the cross-chain interfaces for different EVM-based blockchains, ERC-5564, which will significantly improve privacy features by creating stealth addresses, allowing recipients to receive certain assets privately, EIP-6963, which enables coexistence and level playing field between wallet services by allowing DApps or users to choose their preferences from a variety of browser extension wallets (Refer to - Twitter Thread), and EIP-7503, which takes a novel approach to enabling private transfers within Ethereum network by utilizing the "Burn and Re-mint" mechanism with ZK Proof (Refer to - Twitter Thread).
3.1 Transaction
3.2 On-Chain & Off-Chain Data Retrieval / Indexing
3.3 Contract - Execution / Scheme
3.4 Storage / Repository
3.5 Account / Meta Transaction / Wallet
3.6 Token Standards & Extensions
4. “Food for Thoughts” - Is ERC-4337 an Optimal Solution for AA?
As we briefly discussed earlier, the ERC-4337-based Smart Contract Address (SCA) has been a game changer for the account abstraction narrative. Furthermore, because it's a standard that can be rapidly deployed at the application level without requiring core changes to Ethereum network, a significant number of ERC-4337-related projects have emerged in recent months, including wallets (e.g., Ambire, CyberConnect, Rhinestone, Safe, etc.), bundlers/SDKs (e.g., AA-Bundler, Alchemy, Biconomy, Gelato, Stackup Builder, etc.), etc.
EIP is no exception. As we saw in last month's content, from ERC-7522, which integrates OIDC IDs into SCA, to ERC-6900, the module interface for defining specific features of SCA, and ERC-7484, the Module Registry interface, the impact of ERC-4337 is growing every day. In fact, AA has been around for a while on other mainnets, so maybe this is an example of how blockchain trends are highly dependent on changes in Ethereum ecosystem.
However, we need to ask ourselves whether ERC-4337's influence continues to grow. There have been many different methodologies for implementing AA within Ethereum network over the years, and ERC-4337 has been widely adopted largely due to the fact that it doesn't require any modifications to the current core logic of the network. The flip side of this is that implementing AA with core modifications (i.e., implementing native AA) might be more beneficial to the network in the long run.
ERC-4337 may have the following limitations.
EntryPoint is also a smart contract, which makes it very difficult to modify and could be very dangerous if a security vulnerability is found.
It is also unclear whether Alt Mempool will be sustainable or secure.
It is not as versatile or operational as native AA, as various applications need to conform to the ERC-4337 standard.
Compared to normal transaction processing, gas fees can be significantly more inefficient due to the additional verification process required on-chain.
etc.
Of course, this doesn't mean that we shouldn't reconsider ERC-2938 or ERC-3074 as alternatives to adopting ERC-4337, which modify the consensus layer - they're not perfect solutions, and it's not clear that they're as flexible as ERC-4337 when considered in line with Ethereum's roadmap. In a similar vein, Vitalik recently wrote a post on his blog explaining why the AA-related EIPs that had been discussed before are inadequate in terms of protocol minimalism.
Moreover, as a result, the current ERC-4337-based AA is a great tool to observe real-world use cases as blockchain technology evolves, and even if a native AA were to emerge, the use cases would not change dramatically compared to today. That said, I would like to emphasize that, like ERC-20, which has numerous limitations despite being the most widely adopted, ERC will always be an experimental standard and we should recognize that it is not perfect, and we should always keep the discussion open for better solutions.
Thanks to Kate for designing the graphics for this article.
