Evolution of Ethereum
Right from its beginning, the Ethereum community is trying to improve the ecosystem constantly. Ethereum gets frequent upgrades to improve its scalability, security, or sustainability. The main focus of the upgrades are:
- Improved scalability
- Cheaper transactions
- Extra security
- Better user experience
- Future Proofing
Ethereum undergoes periodic upgrades to address various challenges and to adapt to improved technology and user requirements.
The Ethereum roadmap is a depiction of a current and long-term plan of Ethereum upgrades. The roadmap reflects the outcome of years of collective effort from both researchers and developers within the academic sphere. Just like the unpredictable progressions happening in the blockchain domain, so are the changes to the roadmap. The Ethereum roadmap is not a constant plan, even the upgrade plans are getting upgraded as per the feedback from implementation and the changing demand of the community.
The community is working on all the upgrades in parallel. Some upgrades are lower priority and are not expected to be implemented anytime soon. Assigning an actual time limit for each upgrade is difficult as the developments in each phase are happening at varying paces. The necessity for an upgrade can also vary over time based on various external factors.
Vitalik Buterin, co-founder of Ethereum, proposed a vision for the Ethereum roadmap that was organized into several categories related to their effects on Ethereum's architecture. It included:
- The Merge: switch of consensus from PoW to PoS
- The Surge: improving scalability by data sharding
- The Scourge: censorship resistance, decentralization and protocol risks from MEV
- The Verge: easy verification of blocks
- The Purge: reducing the computational costs of running nodes and simplifying the protocol
- The Splurge: miscellaneous upgrades that don't fit well into the previous categories.
However, Ethereum is not formally using this terminology, though the vision remains the same as the one proposed by Vitalik.
Roadmap of future upgrades
Each of these phases includes several individual upgrade proposals.
Ethereum welcomes motivated people to participate in research activities.
Upgrade ideas commonly originate from conversations held on platforms such as ethresear.ch, Ethereum Magicians or the Eth R&D discord server.
They may be fixes to newly discovered susceptibilities, recommendations from application developers or even from end users. As these ideas mature they can be formalised as Ethereum Improvement Proposals. This entire process occurs in a transparent manner (visible to public), allowing members of the community to contribute their insights at any stage.
EIPs are proposals for enhancements to the Ethereum.
Ethereum Improvement Proposals (EIPs) outline standards for the Ethereum platform, encompassing core protocol specifications, client APIs, and contract standards. Ethereum Improvement Proposals are a representation of collaborative improvement within the Ethereum blockchain. They are technical write-ups or proposals that describe suggested changes or enhancements to Ethereum. They pave the way for individuals or entities within the Ethereum community to express clever ideas, thereby following a democratic approach. These documents present new features, processes, or environments that require community scrutiny before implementation.
Stages of an EIP
Initially, a proposal enters as a draft, it is subjected to intense scrutiny, and revisions within the community. EIP moves through several stages like idea, draft, review, last call, final, stagnant, withdrawn, and living. Positive response from the community promotes the EIP to the 'Last Call' status, indicating community consensus. After a final review period, the successful EIP gets sealed for implementation and is marked as 'Final.' An EIP which remains inactive for a long period (currently set as 6 months) is said to be of stagnant status. The EIP authors may also withdraw a proposal. There are EIPs which are continuously active and never reach a final state- these are termed as living.
EIPs are sorted into several types.
- The Standard Track include changes that affect the majority of Ethereum implementations. They may be a change to network protocol, validation rules etc. They are further categorized into the following types.
- Core: These upgrades require a consensus fork like changes to consensus algorithms.
- Networking: This category includes improvements to network protocol specifications
- Interface: These upgrades are related to client API/RPC specifications and standards, language-level standards like method names and contract ABIs etc.
- ERC- Ethereum Request for Comments: These include the application-level standards, which consist of contract Application-level standards and conventions, including token standards, name registries, URI schemes, library/package formats and account abstraction. The "request for comments" reflects the community-driven nature of these standards, inviting developers and stakeholders to engage in vigorous discussions before any standardization.
- The Meta EIPs include changes to surrounding processes like procedures, guidelines, changes to the decision-making process, and changes to the environment or tools used in Ethereum development.
- Informational EIPs identify Ethereum design issues and impart general guidelines or information to the community without propounding new features.
The Ethereum protocol is not run by any individual or any organisation. Ethereum is an entirely open-source project, the entire source code of the Ethereum protocol is available on GitHub. Ethereum Foundation operates as a non-profit entity envisioned to foster the development of Ethereum and its associated technologies. The “protocol developers” or “core developers” are the main developers of the Ethereum protocol which refers to people who provide significant contributions to the protocol. The Ethereum Foundation conducts weekly meetings for protocol developers.
The protocol developers are at the heart of Ethereum’s governance mechanisms. To propose a change to the Ethereum protocol, one must submit an Ethereum Improvement Proposal (EIP). Anyone can create an EIP. Once someone submits a proposal, the EIP editors review it. EIP editors are in charge of reviewing EIPs for technical soundness, formatting issues, and correcting spelling, grammar, and code style. Martin Becze, Vitalik Buterin, Gavin Wood, and a few others were the original EIP editors from 2015 to late 2016. Check here for the current EIP editors. EIP-5069 has the details on the process of becoming an EIP editor. People with experience in the EIP process and development on the Ethereum blockchain may apply to become an EIP editor, but the current editors must approve the application.
Once the editors decide that the EIP should proceed, the proposer presents it to the protocol developers in one of their meetings. After several rounds of updates to the proposal, the protocol developers may agree to implement the EIP in the upcoming network upgrades.
Whenever an EIP is submitted for review, it will be assigned a three-digit or four-digit number. All submissions are open-sourced. The number will be usually the first Pull Request or issue for that proposal on EIP GitHub 5 and in some cases it can be allocated by the editors.
The full list of EIPs is available here.
This is the first EIP that was published a month after the repository appeared. It belongs to the Standards Track category. It included multiple changes including increasing the gas cost for creating contracts via transactions from 21,000 to 53,000.
Before the implementation of EIP-1559, the transaction fee mechanism was a first-price auction. Users submit a gas price bid, which is selected in such a way that they outbid their competitors. Miners will be tempted to prioritize transactions with the highest gas prices in a block. The unpredictability of gas prices required the users to make assumptions about other users’ bids to optimize their bid strategy. This was not user-friendly, and led to high fluctuations in transaction fees. EIP-1559 was proposed to resolve these issues.
EIP-1559 introduced some changes to the transaction fee mechanism on Ethereum.
EIP-1559 doubles the block gas limit from 15 million to 30 million while still retaining the target at 15 million. The actual GasPrices of the transactions are calculated by:
GasPrice = min{BaseFee+MaxPriorityFee,MaxFee}
The base fee represents the minimum gas price required for every transaction to be included in a block. The base fee parameter is adjusted dynamically according to the block gas used in the previous block and is determined by network conditions. When the block gas exceeds the target, the base fee for the subsequent block rises, and conversely decreases if the block gas falls below the target. Users can opt for two parameters in their transactions: the maximum priority fee per gas and the maximum fee per gas. Priority fees per gas are the tips which users give to validators to prioritize their transactions. Max fees set the upper limit on the total fees users will pay, encompassing both base fees and priority fees. Any surplus amount beyond the sum of the base fee and priority fee, if applicable, will be reimbursed to the user. This helped in reducing congestion and simplifying fee management for users. The base fee is burned, managing Ether’s inflation.
It defines a common set of rules and functions for creating fungible tokens on the Ethereum blockchain. Proposed by Vitalik and Fabian Vogelsteller, EIP-20 provided the basic functionality needed to “transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.” ERC-20 tokens enable developers to create digital assets with standard features, increasing their interoperability with other applications like exchanges and wallets.
Even though several alternative token standards emerged in the interim years, the ERC-20 defines the template of the majority of tokens.
It defines a non-fungible token (NFT) standard. ERC-721 tokens are unique and indivisible, representing distinct digital or physical assets. This standard provides a set of rules and functions for creating NFTs, enabling developers to create and manage unique digital collectables, assets, and ownership records on the Ethereum blockchain.
The standard offers the basic functionality to track and transfer NFTs. EIP-721 introduced a method to enable multiple applications to work with NFTs on the Ethereum network.
This proposal resulted in Ethereum switching from its original computationally complex and expensive Proof of Work consensus mechanism to the less energy-intensive Proof of Stake system.
This upgrade was authored by Vitalik, Danny Ryan and Mikhail Kalinin. This upgarde includes changes to the block structure, block processing, fork choice rule and network interface inorder to transition Ethereum from Proof of Work (PoW) consensus to the more sustainable Proof of Stake (PoS).
This was successfully executed in 2022 and resulted in a 99.95% decrease in energy consumption.
ERC-4337 is an Ethereum standard that enables smart contract wallets to act as primary accounts. Account abstraction moves crypto from the current way of a simple EOA account, where even small mistakes can make one lose everything, to a future where an account can be customized as per the needs of a user using smart contracts.
This introduces a series of improvements to wallet designs and makes them more user-friendly. As per this proposal, to create a smart account, a user will require both the private key and smart contract. Therefore, the smart contract would establish the guidelines for account usage, including who has access to the account, the types of transactions the account can initiate, and the allocation of gas expenditure. The exciting fact about ERC-4337 is that it doesn’t require any updates to the Ethereum core protocol.
Do you wish to contribute to Ethereum EIPs? If so, first check EIP-1. The guidelines for writing EIPs are included in EIP-1. Next, clone the repository and integrate your EIP into it. A template for EIP is available here. Once it is ready, you can submit a pull request to Ethereum's EIPs repository.
Upgrades are essential for Ethereum's evolution and continued existence in the rapidly evolving blockchain space. They aim to address existing challenges while also incorporating new improvements for decentralized applications (DApps) and the wider ecosystem.Ethereum upgrades are coordinated efforts involving Ethereum developers, validators, node operators, and the community as a whole. The process involves reaching a consensus on proposed changes, testing the upgrades in a testnet, and then implementing them on the mainnet. These upgrades, which usually involve significant changes to the Ethereum blockchain are typically implemented through a hard fork.
A hard fork represents a permanent, backwards-incompatible change to the Ethereum network's protocol. During a hard fork, the existing Ethereum mainnet blockchain divides into two separate chains: the original chain (also called the legacy chain) and the new chain, which incorporates the upgrades. Users and developers must then choose which chain to follow. In essence, it mandates that nodes operating on the old software version become incompatible with the new version, necessitating an upgrade for continued participation. Analogous to a major software update, a hard fork demands universal adoption of the new version to ensure compatibility.
During a hard fork, the network undergoes a split, with one chain adhering to the updated rules and another adhering to the previous rules. However, the execution of hard forks has several challenges, often leading to divisions within the Ethereum community. A famous instance is the creation of Ethereum Classic in 2016, where community members disagreed with the decision to reverse the consequences of a major hack.
It's important to note that Ethereum upgrades can sometimes lead to community debates and even multiple hard forks, since different stakeholders may have varying opinions on the network. Thus, effective communication and governance within the Ethereum community are critical for successful upgrades.
Let us check the summary of some major upgrades in Ethereum history in the order of their occurrence. Each upgrade is assigned a title. The upgrades after the launch of the beacon chain include updates for the execution layer as well as the consensus layer. Execution layer updates are named after cities that hosted the Ethereum developer conference (DevCon), and the consensus layer updates are named after stars and are assigned in alphabetical order, the first update was named after a star beginning with A, the second after a star beginning with B, and so on.
Some major upgrades
Frontier represents the first official release of Ethereum based on Proof of Work. This is essentially a beta release that allows developers to learn, experiment, and begin building on Ethereum. The genesis block was mined which included 8893 transactions of users who bought Ether during the official presale. Around 72 million ETH was pre-mined, of which about 12 million was allocated for the Ethereum development fund. As per the initial settings, the gas limit per block was hard-coded as 5,000 gas. Since transactions have a base cost of 21,000 gas, thus the initial blocks did not have any transactions, only the mining rewards were getting credited. This period was meant to help the miners to start their operations and adapt to the ecosystem. The frontier thawing fork was the one which enabled transaction processing.
This fork was initiated on Sep 7, 2015. This included a software update for the clients, which raised the gas limit to 3 million. This allowed the inclusion of transactions in the block. Block 46,147 contained Ethereum’s first transaction, an ether transfer operation. Developers started coding smart contracts and decentralized applications to be deployed on the Ethereum Blockchain.
This version also had “Canary contracts”, which were controlled by development team members. In fact, throughout the life of Frontier, developers have been able to undo several users’ actions on the network.
To help the future upgradation to Proof of Stake, the difficulty bomb was introduced. Difficulty implies the effort required to mine the next block. The difficulty is adjusted automatically in order to maintain specific block times. Difficulty bombing is the act of exponentially increasing the difficulty, making it difficult for miners to keep up with the increased difficulty, eventually leading to a scenario such that no one can mine a block. This will lead to an ice age situation where no blocks are mined and the blockchain is freezed- a situation suitable for introducing the next proposed hard-fork for switching the consensus to Proof of Stake.
The Homestead fork on March 14, 2016, is the first production release of Ethereum. The Homestead upgrade was significant as it was the first implementation of EIPs or Ethereum Improvement Proposals. EIP-2, EIP-7 and EIP-8 were included in his upgrade. This upgrade introduced new Solidity codes to enhance smart contract functionality and eliminated centralization by removing canary contracts. Users were enabled to hold and transact with ETH and write and deploy smart contracts.
The Ethereum development team, together with a group from a startup, developed “The DAO,” a decentralized autonomous organization built on the Ethereum blockchain. It was a new type of organization based on a smart contract that governs the decision-making of an organization. The DAO tokens provide voting and control rights to their owners. The members could track invested funds in real time. During the crowd sale in April 2016, the DAO raised about $150 million from around 20,000 investors.
But on June 17, the project faced an attack and 3.5 million ETH was stolen. This was worth $50 million (approximately 15% of all ETH in circulation) and ultimately led to the collapse of DAO.
The attackers used a recursive call vulnerability, which allowed a user to withdraw twice as much ether as was invested and transfer funds to the child DAO. The stolen funds could not be withdrawn and the solution proposed by the developers was a hard fork to undo this transfer-to return the invested ETH to the users. This decision was put to vote and most of the miners agreed. The fork transferred the funds from the faulty contract to a new contract.
It was a controversial decision. A part of the community disagreed with the decision, citing it is a violation of the decentralization principle and the blockchain must be immutable. Finally this hard fork paved the way for the creation of two independent blockchains called Ethereum, which returned the funds to investors, and Ethereum Classic preserved the original blockchain.
After the DAO hack, the network witnessed several Denial of Service (DoS) attacks- where the chain was flooded with empty transactions, causing problems for real ones and their inclusion in blocks. Tangerine Whistle was a small unplanned fork that included just one EIP, EIP-150. The proposal increased the cost of executing some opcodes, making an attack extremely expensive for attackers.
The empty transactions by attackers were followed by empty accounts. Attackers created empty accounts, and they transferred zero balances. Though the accounts contained no data, the transactions were processed and included in the blocks, which delayed normal transactions. It affected the block creation time also.
To counter this attack, another fork was implemented to change the cost of some transaction codes, to remove a large number of empty accounts that were a result of earlier DoS attacks. It also added replay attack protection, which prevented copying of transactions from one Ethereum chain and circulating it in another chain.
Metropolis is a planned Ethereum development phase that includes two hard forks: Byzantium and Constantinople.
It included several changes like increasing the transaction confirmation rate, reducing mining reward, delaying the earlier proposed difficulty bomb, introducing return data (embedding transaction return data in receipts) and static call operations.
This marks the second phase of the Metropolis update, which happened two years after the Metropolis update. Here, the miner reward is reduced even more. It optimized the gas costs of certain solidity functions to make smart contract execution less complex and less expensive. Smart contracts became easier to develop, and certain operations in Ethereum were simplified. This fork also sets some requirements for switching to PoS.
A total of 6 EIPs are included in this update. The update was aimed to increase resistance to DDoS attacks, changes in gas calculations, make layer 2 solutions cheaper, allowing contracts to introduce more creative functions and enabling interoperability between Ethereum and Zcash.
The purpose of the Muir Glacier fork was to delay the difficulty bomb. As the proposed difficulty bomb was approaching, block creation times were getting extended and consequently the transaction fee was also increasing. Since the work related to Proof of Stake was delayed, the difficulty bomb was also delayed. This further improved the waiting time of transactions.
This fork introduced 4 main EIPs in Ethereum.
-
EIP-2565: ModExp Gas Cost: Reducing the cost of a built-in function ModExp, which is extensively used in many cryptographic operations. The high cost was preventing its usage. This update reduces gas costs for a specific transaction type that uses modular exponentiation. The reduced cost makes these cryptographic functions more practical, thereby enabling improved security.
-
EIP-2718: Typed Transaction Envelope. This update makes the addition of new transaction types in a backwards compatible manner.
-
EIP-2929: Increasing the gas cost for state access opcodes which are used for many attacks. This was adopted as a measure to make attacks expensive.
-
EIP-2930: Optional access lists. This added a transaction type that comprises an access list (list of addresses and storage keys) that the transaction plans to access. This makes transaction processing easier for clients and lowers gas costs.
This upgrade implemented 5 EIPs -EIP-1559, EIP 3198, EIP 3541, EIP 3554 and EIP 3529. We have already discussed EIP-1559; the other upgrades are:
-
EIP-3198- added a new BASEFEE opcode that returns the value of the base fee of the current block, which will be useful for smart contracts, based on the fee changes as per the 1559 proposal. This can help to reduce the cost of executing smart contracts by providing more accurate information about the minimum required fees for transactions. It can also reduce the number of failed transactions due to insufficient fees.
-
EIP-3541- Every time the EVM processes an instruction, it should do a series of checks regarding the existence of that instruction, compatibility with the environment, gas availability etc. EVM Object Format (EOF) brings a structure to smart contracts so that the EVM can analyze a smart contract before it is deployed on-chain and if it fails, it can be rejected outright. This EIP specified a byte sequence that doesn’t exist in any of the already deployed contracts. Starting from a specific block number, any new code deployment is restricted if it commences with that specific sequence. The proposal prohibits the starting byte of the format from narrowing down the analysis to the contracts which were deployed before this fork.
-
EIP-3554: This update was launched to delay the difficulty bomb further so that it will not happen before the Merge.
-
EIP-3529: This removed gas refunds for SELFDESTRUCT and reduced refunds for SSTORE. Gas refunds allow users to acquire a refund of unused gas following the execution of a transaction or contract. This was introduced to incentivize users to write efficient code and only use the gas they need, thereby preventing network spamming. But this factor serves as a motivation for many exploits. The removal of refunds from the code won't affect its ability to run, but it might turn certain applications economically unviable.
The Altair upgrade was the first scheduled upgrade for the Beacon Chain. It introduced "sync committees"— which makes it possible for light clients, like mobile phones, to act as validators, proposing and voting for blocks on the Beacon Chain. It also updated the beacon chain reward and penalty accounting. Unlike miners, validators are penalized if they disconnect from the network for long periods of time or if they attempt any malicious activity, like proposing two blocks at the same height. This upgrade increased these penalties, motivating validators to stay connected and behave genuinely.
This upgrade is similar to Muir Glacier. This has only one EIP to push the difficulty bomb until the summer of the following year, to prevent the chain from freezing.
The Gray Glacier network upgrade further delayed the difficulty bomb by three months.
This was the second upgrade to the beacon chain. This upgrade aimed to prepare the beacon chain validators for the merge by adding a transaction execution facility to the beacon chain. Validators could verify the transactions and create blocks in the updated format. The beacon chain blocks had a facility for embedding the PoW block information also in a field called execution payload.
Now the beacon chain was set to accept blocks from the Ethereum mainnet. This is considered the last major upgrade before the merge.
The Paris upgrade triggers the execution layer’s transition from Proof of Work to Proof of Stake. The changes came into effect once the total difficulty hit a preset TERMINAL_TOTAL_DIFFICULTY (TTD) of 58750000000000000000000 on September 15, 2022. The client software was also updated so that once they receive a block exceeding the difficulty limit on the Proof of Work chain, they will enter a transition mode and start listening to the Proof of Stake layer for consensus. As soon as the consensus layer has finalized a block whose difficulty exceeds the TERMINAL_TOTAL_DIFFICULTY, the execution layer will start ignoring the PoW blocks completely. Thus signalling a complete switch to Proof of Stake.
Merging Proof of Work Ethereum with Beacon chain
The Beacon chain validators produce the blocks after the TTD, officially confirming the successful transition from Proof of Work to Proof of Stake. Since the merge happened, many fields related to Proof of Work consensus have retired. Some of the changes were:
- Difficulty, nonce, mixHash, ommersHash and ommers fields are no longer valid.
- Block and ommer rewards are deprecated. Rewards will be given to validators based on their stake.
- The heaviest chain rule for fork resolution is replaced with the LMD-GHOST rule, followed by Proof of Stake.
This was the first update since Ethereum switched to Proof of Stake. This has changes to the execution layer (Shanghai) as well as the consensus layer (Capella).
From the launch of the Beacon chain, users may stake ETH to become a validator, perform block creation/proposal, and earn rewards in their wallets. But they were unable to withdraw their staked ether or rewards earned. This upgrade enabled staking withdrawals- validators can withdraw their rewards alone or staked ether and rewards. It also has this EIP that proposes access to Coinbase at lower gas costs, which will be helpful for smart contract users. EIP-3651 proposes to keep the Coinbase software warm. Some users, like builders ( entities which order transactions in the block before sending it to validators), need access to the software called a Coinbase, which is used to receive new tokens on the network. Usually, the transactions require multiple interactions with Coinbase. When the coinbase is accessed initially, there is a warm-up cost and once warmed, the cost of accessing the Coinbase will be lower. The EIP-3651 keeps the Coinbase in a warm state, decreasing the total gas requirement. This is expected to reduce network fees for builders and traders who use builders to execute their trades. The EIP-3855 introduces a new opcode PUSH0 to push the constant value 0 onto the stack. The EIP-6049 deprecated the self-destruct opcode. EIP-3860 introduces a gas cost limit and metering for contract initialization code in order to reduce gas costs.
The Capella upgrade was the third major upgrade to the consensus layer and enabled staking withdrawals. Capella occurred synchronously with the execution layer upgrade, Shanghai, and enabled staking withdrawal functionality. This upgrade provided a way for stakers to update their withdrawal credentials, thereby enabling withdrawals. The upgrade also changed the way historical roots are stored in the beacon state.
The consensus layer updates are called Deneb, and the execution layer updates are called Cancun. The inclusion of a new type of transaction allowing blob spaces has introduced some changes in the basic block structure, as shown below.
Updated block structure after Dencun upgrade
Dencun upgrade introduced the below changes:
-
EIP-1153 — Transient storage opcodes: transient storage is a new mechanism introducing private storage associated with a smart contract. The transient storage can be used similarly to the storage except for the fact that transient storage is automatically cleared at the end of a transaction. It is helpful to temporarily hold data during a transaction, which decreases gas expenses. This will benefit L2 solutions like rollups and contract deployment operations where temporary data management is required.
-
EIP-4788 — Beacon block root in the EVM: Adding an additional field in the header of block: parent_beacon_block_root. This field is 32 bytes, and it stores the hash of the parent beacon block for the given execution block. This allows Beacon Chain’s roots to be accessible to the Ethereum Virtual Machine (EVM), thereby allowing smart contracts direct access to the consensus state. This bridges the communication gap between the execution and consensus layers by allowing access to the Ethereum consensus layer with minimised trust.
-
EIP-4844 — Shard Blob Transactions: Introduces a new type of “blob-carrying transactions” that contain a large amount of data that EVM cannot directly access. The blob transaction processing relies on a cryptographic commitment technique known as KZG scheme which serves as an alternative to Merkle proofs. The commitment will be accessible to EVM and persist, while the transaction data in the blobs will be periodically pruned. The blobs will be stored in the consensus client.
The blob storage will be measured in terms of blob gas, which is cheaper than gas. The blob gas has a different set of rules for fee calculation. The block header has two new fields:
- blob_gas_used denotes the total amount of blob gas consumed by the transactions within the block.
- excess_blob_gas is a running total of blob gas consumed in excess of the target prior to the block. This is needed to compute the blob gas base fee.
For blob-carrying transactions, the TransactionType is BLOB_TX_TYPE. It has new fields max_fee_per_blob_gas for calculating blob gas fees and blob_versioned_hashes, representing a list of hash outputs from kzg_to_versioned_hash.
Example of blob-carrying transaction
-
EIP-5656- MCOPY — A new Memory copying instruction. Currently copying data from one location to another in memory is done by MSTORE and MLOAD opcodes. MCOPY combines both functionalities, and it can efficiently handle copying between non-overlapping areas of memory and overlapping areas, as well as move memory backwards. It helps reduce the number of instructions for memory copy operations, thereby saving gas.
-
EIP-6780: SELFDESTRUCT updations. SELFDESTRUCT was an opcode used to clear unwanted data from the Ethereum state. On invoking the selfdestruct function, the contract balance will be transferred to a target address, associated storage and code will be erased, and nonce will be reset to 0. However, it was moved to a deprecated status later, owing to some attacks that misused the selfdestruct functionalities. There are still contracts which use selfdestruct. As per this upgrade, if the contract does not use SELFDESTRUCT in the same transaction as creation, only the funds are sent to the target, while the code, storage, and nonce are not altered.
-
EIP-7044 -Perpetually Valid Signed Voluntary Exits: If a validator wishes to exit, it is done by sending a “voluntary exit message” (VEM) signed with the validator’s signing key to the consensus client. In the case of delegated staking, the signing keys (used while performing validator tasks) will be with a validator operator (the entity which manages the validators), and the withdrawal keys (required to claim the staked deposit) will be with the Staker who is funding a specific validator. The validator operator normally provides pre-signed voluntary exits for the validators they operate, and these will be sent to the stakers corresponding to each validator. These signed voluntary exits were valid up to only two upgrades. EIP-7044 makes voluntary exits valid forever. This helps simplify the staking operations and opens design options for handling validator exits via smart contracts.
-
EIP-7045- Increase Max Attestation Inclusion Slot: The attestations (votes) of validators are used to decide the fork-choice rule LMD GHOST used in Ethereum. Attestations for a specific slot must be included in a block within a specific time period, after which it is considered invalid. This time period is extended by this upgrade so that more validator attestations will be considered before deciding on a fork choice. The more the attestations, the more will be the efficiency of LMD-GHOST.
-
EIP-7514 -Add Max Epoch Churn Limit: The churn limit restricts the number of validators that can enter or exit the Ethereum network during an epoch. This is adjusted in such a way that the Proof of Stake consensus works in a stable manner. The churn limit was a variable which is adjusted based on the number of active validators. This EIP sets Ethereum’s churn limit as 8, thereby decreasing the growth of the validator set.
-
EIP-7516- BLOBBASEFEE opcode: Add a BLOBBASEFEE (0x4a) instruction that returns the value of the blob base-fee of the current block it is executing in.
Overall the updates are aimed at helping L2, reducing the transaction fee, make Ethereum more affordable, support validator operations in a user-friendly way.
