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.
November continued the trend set in October, with discussions primarily focused on Cancun/Deneb update. The testnet for basic feature implementation and Blob use cases, Devnet #11, concluded successfully. In addition, Devnet #12, which started on November 30, is also progressing well. However, there have been some challenges with certain clients not smoothly integrating with MEV-Boost, and testing on this front is ongoing. Once this issue is resolved, it's expected that within the next 1-2 weeks, all clients will test Cancun/Deneb upgrade in a Goerli shadow fork environment, and a hard fork to activate it is planned for mid-January.
After Cancun/Deneb update, Prague/Electra update is anticipated to begin. Discussions about what specifications to include in this update have already opened in this thread - topics under discussion include the introduction of Verkle trie for a Stateless Network, pre-compilation for BLS12-381 due to its high demand in rollups and cryptographic use cases, and the introduction of EIP-7002, which is expected to lower barriers for independent validators by allowing them to terminate staking without the need for provider actions.
Thus, in December and January, it is expected that a significant number of Core EIPs related to the next update will be proposed or advanced to the next stage. Following the anticipation surrounding Cancun/Deneb upgrade, it's also expected that more ERCs related to various use cases, new token standards & extensions will be proposed.
Apart from April, November was the month with the fewest EIPs proposed in 2023. Throughout November, a total of 8 new EIPs were drafted, which is 3 less than the previous month - as of November 30th, the total number of proposed EIPs for the year stood at 706. Except for two, all of the proposed EIPs were related to Token Standards/Extensions & Contract Schemes.
Below are more detailed categorizations of the newly drafted EIPs, with some notable ones highlighted.
2.1.1 EIP-7549: Move committee index outside Attestation
Source : ethos.dev/beacon-chain
In Ethereum 2.0's Beacon Chain, there are concepts of a 'slot', which occurs every 12 seconds, and an 'epoch', which is comprised of 32 slots. The Beacon Chain divides validators participating in each epoch evenly across these 32 slots, with one block being produced in each slot. At least 128 validators are required per slot. One of these validators can either become a proposer, who proposes a block, or a member of a committee that attests to the proposed block, determined by a mechanism called RANDAO. Within each slot, a single block proposer is chosen to propose a block to the committee. If this block receives approval from more than two-thirds of the attested votes collected from the rest of the committee members, it can be created.
Source : eth2book
The validators in the committee submit AttestationData, which is structured as above - it includes the slot assigned to the validator, the index of the committee they belong to within the slot, and the votes reflecting the validator's opinions. Therefore, as long as there are more than 2^18 (=262,144) validators, at least 1366(=ceil(3264(2/3))) Attestations are needed for a checkpoint of an epoch to be justified.
However, all committee members in each slot are essentially voting on the same information. Thus, instead of dividing individual AttestationData by committee, aggregating AttestationData that have the same consensus vote to form a single Attestation can significantly reduce the number of Attestations needed for approval by more than two-thirds.
As a methodology for that, EIP-7549 proposes moving the index field of the AttestationData Class out to the Attestation Class. This would make the process of justifying checkpoints more efficient. Therefore, if EIP-7549 is implemented, it is expected that Casper FFG clients within the Ethereum network will operate more efficiently.
2.1.2 EIP-7545: Verkle proof verification precompile
As explained in the previous post, the introduction of the Verkle Trie is a requirement for Ethereum to transition to Statelessness - here, the Verkle Trie, in comparison to the traditional Hexary Patricia Tree, has a structural advantage in that it can maintain the size of proofs consistently (i.e., vector commitment). This feature enables the Ethereum network's communication to be uniformly structured and sustainable.
Source : Vitalik’s Twitter
However, even if the size of the proofs can be kept close to constant thanks to the structure of the Verkle Tree, if the way the proofs are verified itself is not easy, it will be very difficult to verify and utilize the data at the application level - in fact, according to The Verge, Ethereum's roadmap includes to gradually update the various methods of validation that are practically available, with the goal of eventually achieving a "Fully SNARKed Ethereum," which would make block validation extremely easy. This means that even with the introduction of Verkle Trie, data may not be retrieved in a cost-effective manner initially due to the lack of a sufficiently mature proof verification system.
EIP-7545 proposes to introduce contracts that pre-compiles* these methodologies as a way to experiment with different proof verification methodologies for the stateless Ethereum network - the precompiled contracts are added at address 0x21 and contain the following parameters: 1) 'version', which is the version of the proof verification function, 2) 'proof_data_location', which is the memory address to find the beginning of the proof data, 3) 'proof_data_size', which represents length of the proof data, 4) and 'state_root'.
Source : EIP-7545
If this EIP is adopted, existing applications will be able to efficiently verify verkle proofs without having to upgrade their own contracts in response to the newly introduced proof systems.
*Pre-compilation refers to the process of verifying in advance that bytecode for specific user-defined tasks is valid, secure, and meets optimization standards to allow smart contract developers to use the functionalities without putting too much overhead on the Ethereum Virtual Machine's (EVM) core.
2.2.1 ERC-7496: NFT Dynamic Traits / ERC-7498: NFT Redeemables
Dynamic NFTs, also known as Interactive or Programmable NFTs, have been gaining attention for introducing a level of interaction and functionality that surpasses conventional NFTs - the attributes of Dynamic NFTs can change or respond according to pre-programmed methods or specific contexts defined by users. This allows for a wide range of applications, such as representing real-world assets, attributes of game characters, unique access rights to specific events, dynamic content, and etc. thereby offering users enhanced or new experiences.
One of the most intuitive methods to enable Dynamic NFTs involves changing how the metadata defining NFT attributes is stored and queried. Currently, many of the metadata representing NFT attributes are often stored off-chain (i.e., outside the blockchain) due to various reasons like security, cost, and limitations of NFT contract storage. This means that most NFTs are structurally very complex and inefficient to dynamically manage their own properties, making it very difficult for their data to be directly queried on-chain and utilized in conjunction with external contracts - this is why we refer to most existing NFTs as Static NFTs, as opposed to Dynamic NFTs.
“function setTrait(uint256 tokenId, bytes32 traitKey, bytes32 newValue) external;"
To address these limitations, ERC-7496 extends the use of NFTs already represented by ERC-721 or ERC-1155 by giving them dynamic on-chain attributes. A method called 'setTrait' can define metadata by assigning a key-value data pair called 'traitKey' and 'newValue' to a specific NFT. Users are free to define their own trait name (or byte32), and the following four types are supported*.
string - sets a string value for the attribute
decimal - sets a numeric value in decimal format for the attribute
boolean - sets a boolean value for the attribute
epochSeconds - sets a timestamp with the elapsed time in seconds from the Unix epoch to the current time.
*Please refer to the link for detailed schema and parameters for metadata.
Source : ERC-7496
The way ERC-7496 adds flexibility to the storage and representation of metadata through a key-value format is very similar to ERC-725Y, the universal profile standard adopted by the LUKSO Mainnet. There are several other ERCs relevant to Dynamic NFTs, including ERC-4906, which enables third parties to utilize hooks by sending events when metadata is updated; ERC-7160, an extension to the NFT standard that enables a wide and efficient reference to various types of metadata URIs; and ERC-7409, which allows NFTs to build interactive utilities utilizing Unicode-based emoji.
There is also ERC-7508, which is a repository for storing various types of on-chain attributes, but the advantages of ERC-7496 over that standard are: 1) it is an extended standard, which means that it assigns attributes directly to NFTs instead of referencing them; 2) it is simpler to use and adopts a more flexible structure for defining attributes.
Meanwhile, ERC-7498 proposes an extended standard for redeemable NFTs for digital services and experiences and physical goods - redemption events are managed on-chain by a unit called a Campaign, and upon redemption, the on-chain NFTs are burned. However, it is also possible to implement redeemable NFTs by updating the trait that indicates redemption instead of burning the NFT, called 'trait redemption'. In this case, ERC-7498 uses ERC-7496 for this function.
ERC-7496 and ERC-7498, proposed by the Opensea team, are currently being actively utilized in the Seaport Protocol.
2.2.2 ERC-7410: ERC-20 Update Allowance By Spender
One of the most famous token standards, ERC-20's 'Allowance' method, determines how much permission to assets in a user's wallet is granted by the user to a third party, represented by a 'Spender', to mediate a specific interaction - this Spender can be a DApp or DeFi protocol, or it can be an individual EOA that is responsible for signing if using a Multi-Signature Wallet, etc.
However, this structure increases the risk of the user's funds being stolen if the Spender is hacked*, or if the user is a multi-signature wallet, there are structural difficulties in allowing multiple signers to flexibly adjust the amount of assets available for trading - ERC-7410 extends ERC-20's functionality to allow Spenders to revoke or reduce a given Allowanece.
“function decreaseAllowanceBySpender(address owner, uint256 subtractedValue) external;"
The method supported by this ERC is very simple - by increasing the value of subtractedValue, the Spender can subtract that amount from the currently given Allowance. This means that if the Spender sets subtractedValue to a value greater than or equal to the current Allowance, the Spender's Allowance will effectively be zero.
As the need to strengthen the security layer is being emphasized even in applications, and various multi-signature wallet cases are being created to manage treasuries, this standard should be considered by existing wallet/application services.
*The risks of Allownace are well known - if the amount of assets a user authorizes to products and protocols via Allownace is unlimited, the protocol/product is effectively in a position to steal the user's funds at will, and the user has to trust the protocol/product. Therefore, services are emerging that make users fully aware of the value of the allowances they have granted, or allow them to revoke their signature on a project for a specific value of allowances.
2.3.4 Others
In addition to the eight new EIPs adopted as Draft, 19 EIPs changed status during the month of November. Of these, 14 EIPs were advanced to the next stage (i.e., Final, Last Call, Review, Draft, etc.) for eventual adoption. 4 of the remaining 5 EIPs did not advance to the next stage and were changed to Stagnant. One EIP was finally moved to Withdrawn.
Also, unlike last month when progress was made across a range of scopes including Consensus & Execution Layer, URIs & URLs, Modules, Registry, Wallet, and Token Standards, the EIPs that made progress this month were dominated by Token Standards & Extensions, along with a few Core EIPs.
Notable among the Core EIPs regarding the upcoming Dencun update are - EIP-4788, which removes the need for an oracle system by exposing the parent beacon block root at the execution layer, and EIP-7516 (ref - last article), which allows rollup contracts to efficiently/effectively price the use of blob data. Also of note is EIP-3074 (ref - last article), which introduces new OPCODEs (i.e., AUTH, AUTHCALL) to achieve account abstraction in the form of delegating the rights of the existing EOA owner to the caller.
Notable among the ERCs are - ERC-3643, a token standard that emerged to better and more securely manage security tokens as STO guidelines are getting refined by countries; ERC-7160, an extension of the NFT standard that enables a wide and efficient reference to various types of metadata URIs; and ERC-7066, a standard that enables locking for NFTFi while still allowing NFT owners to fully use the functionality of their NFTs.
Source : Beaconcha.in
Since the introduction of Beacon Chain in December 2020, Ethereum's staking volume has been steadily moving upwards, with approximately 24% of the total Ethereum circulating on the Ethereum network now staked - in April 2023, the Shanghai Update made Ethereum withdrawable for depositors. This raised concerns about selling pressure on ETH, which was previously only available for deposits to run validators, but contrary to such concerns, the amount of ETH deposited has actually increased.
Of course, the 24% figure is not very high compared to staking rates on other mainnets (e.g., Solana ~ 70% / Cosmos ~ 65% / Polkadot & Avalanche ~ 50% / Polygon ~ 38%). However, it would be more accurate to say that this is a deliberate adjustment to maintain the decentralized nature of the Ethereum network while preventing network instability caused by excessive proliferation of validators (ref EIP-7514 section of the last article), and the updates currently underway within the Ethereum network are also aimed at gradually increasing the size of staked ETH through the introduction of a series of EIPs, with the priority of not sacrificing the stable operation of the existing network.
Consistent with this, the most discussed issues outside of the Ethereum network are also discussions to support the stable operation of the Ethereum network - keywords include the risks posed by Lido's dominant share of staked Ethereum and DVT* technology to ensure stable node operations and reduce the barrier to entry for non-professional validators.
*DVT stands for Distributed Validator Technology, a technology that allows multiple node operators to share their validator keys to build an active-active architecture. It is expected to significantly improve downtime by allowing a small number of clusters to consensually operate a common node, and lower the barrier to entry for node operation so that non-expert validators (e.g., solo validators) can easily participate.
Anyway, assuming the demand for Ethereum's stable network remains constant, and as these solutions make Ethereum node operations more reliable and the barriers to entry improve, the demand for staking on Ethereum will continue to rise. If so, we should keep an eye out for solutions that make staked Ethereum more versatile - in addition to the competing features of various liquid staking solutions (e.g., Coinbase Prime, Rocket Pool, Frax Ether, Stakewise, Binance, Stader Labs, etc.), the use of the Eigen Layer is particularly noteworthy.
The main idea behind the Eigen Layer is the concept of "Re-Staking". Re-staking enables the already staked ETH to be utilized once again to enhance the security of other protocols (AVS, Actively Validated Services), meaning that for protocols supported by Eigen Layer, Validator can earn not only validation rewards for Ethereum, but also validation rewards for AVS - although there is a double risk of slashing within the Ethereum network, as well as slashing in AVS. The implementation is fairly straightforward, with the withdrawal address of the staked ETH delegated to a smart contract on Eigen Layer.
The process itself is similar to liquid staking protocols that allow staked ETH to become liquid and interact with other protocols. However, Eigen Layer can contribute significantly to the overall ecosystem by not only providing additional benefits to users, but also by adding security to protocols such as bridges and oracles that are essential for the smooth flow of data across blockchain networks - currently, Eigen Layer has 10+ partnerships underway (or in discussion) including Altlayer (RaaS), Blockless (Infrastructure Platform), Celo (L2), Espresso (Shared Sequencer Solution), Hyperlane (Interoperability Layer), Mantle (L2), Near Protocol (L1), and etc.
In short, paying attention to the various discussions and technologies that could improve the staking experience on Ethereum, as well as the new services that are being implemented through the mediation of staked Ethereum itself, will give us great insight into how the staking market will evolve in the future, and what opportunities we can explore within it.
Thanks to Kate for designing the graphics for this article.
We produce in-depth blockchain research articles
The blockchain industry in South Korea is currently abuzz with talks of a never-before-seen event: mainnet merge proposal from Klaytn and Finschia
In October, we saw an even distribution of subcategories across both new EIPs and EIPs that have progressed to the next level, but it's notable that EIPs related to transactions or ERC-4337 are being discussed more and more frequently.
September was a month of adoption for many new Core EIPs, and it was also notable that many EIPs related to contract and token standards moved closer to finalization.