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.
The scope of the EIP can be broadly categorized into three (i.e., Standard Track, Meta, and Informational) or more specifically into six (i.e., ERC, Networking, Interface, ERC, Meta, and Informational). Among them, ERC standards that support widespread use at the application level, and Core standards that are necessary for Ethereum network to operate as originally designed, have been the main subject of discussion.
https://fourpillars-public.s3.ap-northeast-2.amazonaws.com/articles/95/sept_eip_author_note.png
In 2018, 2022, and 2023, when blockchain received a lot of attention from the public, the proportion of ERC standards proposed was the highest. However, as we will soon see, in September, the discussion on Core began to become more active than ERC, contrary to this trend.
This does not mean that the discussion of ERCs has suddenly decreased - on the contrary, the number of proposed ERCs exceeds the average for 2023. Furthermore, we are seeing many standards related to contracts and interactions are moving toward further adoption, with middleware-like standards such as account abstraction and token-bound accounts starting to emerge that can actually ease the usability of Web3 applications for end-users.
The adoption of Core standards in particular may be due to the fact that there has been a lot of discussion among developers ahead of the upcoming Dencun update to the Ethereum network. As such, it is not expected October's EIP trends to be much different from September's, as the Dencun update is just around the corner. So while it's great to watch ERCs for new business opportunities, it's also great to pay a little more attention to the Core standards and see how the Ethereum network is evolving.
A total of 23 new EIPs were adopted as Drafts in September, an increase of 14 (155%p) over the previous month. This is the highest number of EIPs adopted as Drafts for all of 2023 - bringing the total number of proposed EIPs through the end of September to 687. It is also notable that since January, new EIP Drafts have been dominated by those related to the ERC, while September has been dominated by EIPs related to the Core (i.e., execution & consensus layer).
Below is a more detailed categorization of the newly adopted EIPs in Draft, with some notable ones highlighted.
2.1.1 EIP-6800: Ethereum state using a unified verkle tree
EIP-6800 proposes the introduction of a new Verkle State Tree to achieve ‘Statelessness', which is necessary for the future scalability and sustainability of the Ethereum network - to achieve Statelessness, there are two main approaches: 1) ‘Weak Statelessness’, which requires only block proposers to store states, and allow all other nodes to verify blocks statelessly, and 2) ‘State Expiry’, which involves the idea of clearing the state trie maintained by the Ethereum full node at regular intervals.
Here, the key element that removes the need for validating nodes to have state tries is a proof called a 'Witness', which indicates whether a particular value is contained in a particular location. Block proposers submit this witness whenever they create blocks. However, in the current Hexary Patricia Tree structure, the size of the witnesses generated is proportional to the depth and width of the tree. Therefore, it has been discussed that there is a structural need to bring the size of witness proofs closer to a constant level in order for communication on the Ethereum network to be fully consistent and sustainable - the adoption of Verkle Tree using 'Vector Commitment' instead of hash functions has been discussed positively in this context.
Source : Verkle Tree
The existing Hexary Patricia Tree will exist but be in a frozen state, while the newly introduced Verkle Tree will start empty and a copy of the accessed state will be stored in the tree.
2.1.2 EIP-7514 Add Max Epoch Churn Limit
Currently, Ethereum maintains the stability of the network by dynamically controlling the activation and exit of validators by setting a parameter within the queuing system called the ‘Epoch Churn Limit’ - for example, if the Epoch Churn Limit is set to 8, a maximum of 8 validators can be newly activated or completely exit per epoch every 6.4 minutes (i.e., approximately 1800 per day). Therefore, the more conservatively this parameter is set, the less dynamic the network stability will be.
“Epoch Churn Limit = max(n, Active_Validators/65536)"
EIP-7514 is proposed to linearly mitigate scenarios where an excessive amount of ETH is rapidly staked in Ethereum (i.e., excessive validator activation) by placing an upper bound on this parameter. If an excessive amount of ETH is staked, the consensus layer may experience issues such as an increase in gossip messages & beacon state size, and security issues due to an imbalance in the incentive structure.
This standard is intended as a temporary solution to 1) stabilize the network in the current situation where the queue for validator activation is saturated, and 2) prepare enough time to precede discussions to comprehensively elaborate ETH's tokenomics, including MEV, block rewards, and fee burning mechanisms.
EIP-7514 will be also included in the next Dencun upgrade, along with the following EIPs.
Execution Layer (i.e., EIP-1153, EIP-4788, EIP-5656, EIP-6780, EIP-7516)
Consensus Layer (i.e., EIP-7044, EIP-7045, EIP-7514)
Common (i.e., EIP-4844)
2.1.3 EIP-7516: BLOBBASEFEE opcode
While EIP-3198 is the standard that proposes the OPCODE for the current Ethereum network's base fee (i.e. BASEFEE, 0x48), EIP-7516 is the standard that proposes the OPCODE for the base fee for Blobs (i.e. BLOBBASEFEE, 0x4a), a new data type for Ethereum's rollups.
Source : notes.ethereum.org/@vbuterin
Blob is a data type that aims to provide sufficient data storage for rollups, Ethereum's scalability solution - see EIP-4844 for a detailed description of Blob. While the existing data type, Calldata, requires access to the EVM for computation, making it relatively expensive to publish data on Ethereum, Blobs can be validated more cheaply by simply sampling some data, a practice known as Data Availability Sampling (DAS).
Similar to the motivation behind EIP-3198, EIP-7516 allows roll-up contracts to efficiently and effectively price the use of Blob data. The price of the Blob will be determined by a separate fee market, and in effect, end users will be able to determine when Blob data can be most effectively utilized.
EIP-7516 will be also included in the next Dencun upgrade, along with the following EIPs.
Execution Layer (i.e., EIP-1153, EIP-4788, EIP-5656, EIP-6780, EIP-7516)
Consensus Layer (i.e., EIP-7044, EIP-7045, EIP-7514)
Common (i.e., EIP-4844)
2.1.4 Others
2.2.1 ERC-7522: OIDC ZK Verifier for AA Account
Source : EIP-7522
OpenID Connect (OIDC) is one of the most widely used authentication protocols for Web2 online services. OIDC allows service providers (i.e., Relaying Parties, RPs) to delegate the authentication of users and manage their data to a trusted Identity Provider (IDP), such as Google, and allows users to easily authenticate to multiple services with a single credential (i.e., OIDC ID) for that IDP.
The main idea behind ERC-7522 is to wrap an access token containing a user's identity information from OIDC with a zero-knowledge proof through an off-chain service called ZK Aggregator and link it to an ERC-4337-based smart account.
This will allow users with smart accounts to perform a variety of on-chain activities using familiar OIDC IDs such as Google or Facebook accounts. However, the cost of on-chain verification of zero-knowledge proofs is still very high, so it may be premature to expect a wide range of uses at this stage - for now, it is expected to be used to recover an account holder's keys.
2.2.2 Others
2.3.1 ERC-7512: Onchain Representation for Audits
ERC-7512 provides a standardized format for audit reports of smart contracts that can be published on-chain for the purpose of ensuring security.
Audits of smart contracts typically involve a wide range of investigations to ensure that the functionality of the contract is implemented as intended, that the internal logic is not vulnerable to malicious attacks, and that interactions with other contracts, such as events invoked or triggered by other contracts, do not leave room for secondary damage. However, not only are these audits rarely performed due to their high cost, but the format of the audit itself varies from auditor to auditor, making it difficult to provide a consistent assessment of each audit report.
Source : EIPs Github
Therefore, this ERC introduces a standardized form for audit reports so that individual smart contracts can represent on-chain that they have been audited. This may have the added benefit of enabling the widespread utilization of audited or equivalent security certified smart contracts across the ecosystem.
However, if this ERC becomes widespread, it could also have the side effect of setting the atmospheres that costly audits should be mandatory for smart contracts to be utilized. Furthermore, the on-chain representation of an audit does not in itself guarantee the security of the contract, and its implementation can be complex - especially for upgradable contracts. There are alternatives to representing audits in registry contracts or as metadata, so the practicality of this ERC-7512 is worth reconsidering.
2.3.2 ERC-7406: Multi-Namespace Onchain Registry
ERC-7406 proposes a universally applicable multi-namespace registry standard utilizing a flexible and extensible key-value mapping structure.
On-chain registries play an important role in not only storing data securely, but also interacting with various applications. However, if the registry does not adopt a flexible structure, the format of the stored data values is very limited, making it difficult to interact with a wide range of applications.
The ERC-7406 registry allows developers to flexibly manage different kinds of data by defining multi-namespaces, so that data can be managed/utilized in a wide range of areas such as domain management and data cataloging.
2.3.3 ERC-7508: Dynamic On-Chain Token Attributes Repository
ERC-7508 is a repository standard for storing the attributes of NFTs represented by ERC-721 or ERC-1155 on-chain.
In many cases, the attributes of NFTs have been implemented by referencing URIs in centralized off-chain repositories instead of on-chain repositories - significantly reducing the semantics of the asset itself and its utility potential. With ERC-7508, NFTs can be fully and persistently stored on a trusted on-chain, allowing them to be interacted with across services by simply referencing the on-chain. Additional major benefit may be the flexibility to reflect changes in attribute values based on specific on-chain activity (e.g., a game player leveling up).
A variable called AccessType allows you to define which entities can manage attribute values, which can be defined as String, Uint, Bool, Address, or Bytes for tokenIDs in a particular collection.
2.3.4 Others
2.4.1 ERC-7507: Multi-User NFT Extension
ERC-7507 is an extension of ERC-721, a standard that allows multiple people ("users") to temporarily use an NFT for a period of time ("expires") in addition to the original owner of the NFT.
ERC-7507, proposed for use cases such as renting assets represented by NFTs, is actually a slightly improved version of ERC-4907 among existing EIPs - unlike ERC-7507, ERC-4907 does not allow more than one 'user' to rent individual NFTs, limiting its utility. ERC-7507 is proposed to support a wider range of use cases, such as IP services that can be shared by multiple users(e.g., subscription services) - 'expires' is represented as mapping(uint256 => mapping(address => uint64)), and the ‘setUser' method can be used to set the expiration date of an NFT for specific users.
2.4.2 Others
In addition to the 23 new EIPs adopted as Draft, 81 EIPs changed their status during the month of September. Of these, 22 EIPs were promoted to the next stage (i.e., Final, Last call, Review, Draft, etc.) for eventual adoption. The remaining 59 EIPs did not advance to the next stage and were changed to Stagnant. No EIPs were finally moved to Withdrawn.
While the aforementioned 23 new EIPs include many core EIPs related to the Consensus & Execution Layer, a number of existing EIPs saw significant progress, especially ERC-affiliated EIPs related to contract and token standards - progress was mainly in standards for how contracts interact with each other and for utilizing/extending NFTs. Other notable developments include EIP-2539 to validate BLS signatures and SNARKs, and EIP-6963 to prevent conflicts when installing multiple Ethereum wallet browser extensions.
Cosmos
