41 mins ago
746
The history of the hard fork of Ethereum 2.0 "Proof of Stake" is complex. It starts with adding a beacon layer to the existing execution layer, which maintains the proof of work (Phase0 and Altair hard forks) while the beacon layer initiates the proof of stake consensus. Subsequently, PoS is fully activated in the Bellatrix hard fork (although withdrawal is not enabled). Then, Capella hard fork allows withdrawals, completing the validator life cycle. Recent hard forks Deneb (part of the Dencun (Deneb/Cancun) upgrade) have made minor revisions to beacon chain parameters, such as time windows containing proofs, handling of voluntary exits and validator replacement restrictions. The main changes in Dencun occur at the execution layer, launching blob transactions, blob gas, KZG promises for blobs, and abandoning SELFDESTRUCT operations.
Now, the Prague/Electra (i.e., Pectra) hard fork introduces important upgrades to the execution and consensus layers. As auditors for the Lido project, we focus primarily on consensus and staking-related changes in this hard fork. However, we cannot ignore the execution layer changes in Prague, because they include important features that affect the Ethereum network and validators. Let's dig into the details of these changes.
Pectra's higher level overviewElectra introduces numerous features to the beacon layer. Major updates include:
allows the valid balance of the verifier to vary between 32 and 2048 ETH (rather than a fixed 32 ETH).
Allows the verifier to initiate an exit through a secondary "withdrawal" voucher (the active verifier key is no longer required).
Change the way the beacon layer handles Eth1 deposits (the event is no longer resolved from the deposit contract).
To handle regular Eth1 contracts on beacon layerAdd a new common framework for requests (similar to how pre-Electra deposits are managed).
At the same time, Prague introduced the following changes to the execution layer:
A new Precompiled contracts, support the BLS12-381 curve to verify zkSNARK evidence (except the popular BN254 curve).
A new system contract for storing and accessing up to 8192 historical block hashes (very useful for stateless clients).
Increase calldata gas costs to reduce block size and encourage projects to migrate calldata-intensive operations such as rollup to blobs introduced in Dencun.
Supports a larger number of blobs per Eth1 block and provides an API to read these numbers.
Allows EOA (external owned account) to have its own account code, greatly extending the operations EOA can perform, such as multicalles or delegating execution to other addresses .
Let's refer to the relevant Ethereum Improvement Proposal (EIP) for further discussion:
EIP-7251: Add MAX_EFFECTIVE_BALANCE
EIP-7002: Execution layer triggerable exit
EIP-6110: Provide verifier deposit on the chain
EIP-7549: Remove committee index from proof
EIP-7685: General Execution Layer Request
EIP-2537: Precompilation of BLS12-381 Curve Operation
EIP-2935: Save historical block hash in state
EIP-7623: Increase calldata cost
EIP-7691: Increased blob throughput
EIP-7691: Increased blob throughput p>
EIP-7840: Add blob scheduling to the EL configuration file
EIP-7702: Set up an EOA account Code
Some of these EIPs mainly involve the consensus (beacon) layer, while others are related to the execution layer. Some span two layers, because certain operations (such as deposits and withdrawals) require synchronous changes between the consensus and execution layers. Due to this interdependence, it is impractical to separate Electra and Prague, so we will review each EIP in turn and specify the Ethereum components affected in each case.
EIP-7251: Added MAX_EFFECTIVE_BALANCEReference: EIP-7251
From the first Phase0 Since the hard fork, in order to prepare Ethereum's proof of stake, until Electra, the maximum valid balance of the verifier was fixed at 32 ETH. Activate Verifier Requirements at least spec.min_activation_balance (32 ETH). After activation, the validator starts with this maximum valid balance, but can reduce its valid balance to spec.ejection_balance (16 ETH) and be evict when this threshold is reached. This "minimum" logic remains unchanged in Electra, but now spec.max_effective_balance has been increased to 2048 ETH. Therefore, the validator can deposit between 32 and 2048 ETH to activate, all of which will contribute their valid balance. This shift marks the shift from "32ETH-Proof of Stake" to "Proof of Stake" :)
This variable valid balance will now be used for: p>
Increase the probability of becoming a block proposer, proportional to the effective balance
Increase the probability of becoming a synchronization committeeThe probability of a member is proportional to the effective balance
as the basis for calculating the amount of relative reduction and inactive penalties
The first two activities are the most rewarding operations for validators. Therefore, after Electra, validators of large staking will participate more frequently in the block proposal and synchronization committees, with frequency proportional to their effective balance.
Another impact is related to cuts. All fine cuts are proportional to the valid balance of the verifier:
The "immediate" and "delay" fine cuts are greater for verifiers with high pledges .
The "delay" reduction penalty is also greater with the cut-off validators with high stakes, as the "cut-off" part of the total stake becomes Bigger.
Whistleblowers who report validators with higher valid balances receive a larger proportion of reduced stakes.
Electra also proposed changes to the reduction ratio, defining a portion of the reduced validator balance and receiving it by the whistleblower.
The next is the effect of invalidity. When the validator is offline when active (prove or propose), the invalidity score accumulates, resulting in the imposition of invalidity penalty for each cycle. These penalties are also proportional to the validator's valid balance.
As a result of the increase in valid balance, the "replacement limit" of the verifier has also changed. In Ethereum "before Electra", validators usually have the same valid balance, and the exit replacement limit is defined as "In a cycle, there cannot be a maximum of 1/65536 (spec.churn_limit_quotient) total stake to be exited." This creates A "fixed" number of verifier exits with the same stake. However, after Electra, there may be only a few "whales" exit because they represent an important part of the total pledge.
Another consideration is the rotation of many validator keys on a single validator instance. Large validators are currently forced to run thousands of validator keys on one instance to accommodate large staking, splitting them into 32 ETH sections. With Electra, this behavior does notThen it is mandatory. From a financial perspective, this change has little impact because the rewards and probability are linearly scaled with the amount of pledge. Therefore, 100 validators per 32 ETH are equivalent to one 3200 ETH. Additionally, multiple active verifier keys can have the same Eth1 withdrawal credential, allowing all rewards to be withdrawn to a single ETH address, avoiding the gas costs associated with reward mergers. However, managing large amounts of keys incurs additional administrative costs.
The ability to aggregate validator's balances adds a new execution layer request type. Before, we had deposits and withdrawals. Now, there will be another type: aggregate request. It combines two validators into one. This operation request will include the source verifier's public key and the target public key and will be processed similarly to deposits and withdrawals. Aggregations will also have pending requests and balance replacement restrictions, just like deposits and withdrawals.
Summary as follows:
For small independent validators, Electra introduces automatic addition to its Ability to valid balances (and rewards). Previously, any surplus exceeding 32 ETH could only be withdrawn, but after Electra, this surplus will eventually contribute to its effective balance. However, the effective balance can only increase in multiples of spec.effective_balance_increment (1 ETH), which means that the increase only occurs after the next "1 ETH limit".
For large independent validators, Electra provides significant management simplification by allowing multiple active validator keys to be consolidated into one. While this won't change the game, operating a 1x2048 stake is undoubtedly much easier than managing 64x32 stakes.
For mobile staking providers, who collect small staking from users and allocate between validators, Electra adds more flexibility in the staking allocation scheme but also requires serious refactoring of validator accounting based on fixed 32 ETH valid balances.
Another important topic is the historical data and profit estimation of validators, especially relevant to new participants, who try to assess risks and rewards. Prior to Electra (as of this writing), the 32 ETH cap (both smallest or largest, actually) created uniformity in historical data. Valid balances, rewards, individual reduction penalties for all validators, block proposal frequency and other indicators are the same. This uniformity allows Ethereum to test its consensus mechanism without statistical outliers, thereby collecting valuable network behavior data.
After Electra, the distribution of pledges will undergo significant changes. Large validators will be involved in block proposals and synchronization committees more frequently, with greater penalties in cuts and greater impact on delayed cuts, activation queues and exit queues. While this may create challenges in data aggregation, Ethereum’s consensus ensures that nonlinear computing is minimal. The only nonlinear component uses sqrt(total_effective_balance) to calculate the base reward, which applies to all validators. This means that validator rewards and cuts can still be estimated on a "per-1 ETH" basis (or more precisely, based on spec.effective_balance_increment, which may change in the future).
For more details, see our previous article on validator behavior.
EIP-7002: Triggerable execution layer exitReference: EIP-7002
Ether Each verifier in the shop has two key pairs: an active key and an withdrawal key. An active public BLS key serves as the primary identity of the verifier in the beacon chain, which is used to sign blocks, proofs, cuts, synchronize committee aggregations, and (before this EIP) voluntary exit (to follow a delay Initiate the verifier's consensus exit). The second key pair ("withdrawal voucher") can be another BLS key pair or a regular Eth1 account (private key and address). Now, withdrawal messages that are signed by the active BLS private key are required to be extracted to the ETH address. This EIP has been changed.
In fact, the owners of these two (active and withdrawal) key pairs can be different. The verifier's active key is responsible for verification responsibilities: running the server, keeping it running normally, etc., and withdrawal vouchers are usually controlled by the stake owner, who receives rewards and is responsible for funds. At present, only the pledge owner who controls the withdrawal voucher cannot initiate the verifier's exit, and can only withdraw the reward. This situation allows the verifier's active key owner to effectively hold the verifier's balance as a "hostage" in his hand. The verifier can "pre-sign" the exit message and hand it over to the stakeholder, but this workaround is not ideal. In addition, both extraction and exit currently need to be performed through a dedicated API with beacon layer validatorInteraction.
The best solution is to allow the stakeholder to perform both exit and withdrawal operations through regular smart contract calls. This involves standard Eth1 signature checking, which greatly simplifies operations.
This EIP allows stakeholders to trigger withdrawals and exits by sending standard transactions from their ETH address to a dedicated smart contract (similar to existing use of " deposit process of the contract). The process of withdrawing (or exit when sufficient stake is removed) is as follows:
The staker sends a withdrawal request ("in" request to the system's "withdrawal" contract ).
Contracts charge specific fees (in ETH) to mitigate potential malicious attacks, and similar to EIP-1559, the fees increase when request queues are busy.
The contract saves the "in" withdrawal/exit request to its storage.
When a block is proposed to the beacon layer, the "in" withdrawal/exit request in the queue is retrieved from the storage.
The beacon layer processes the "in" request, interacts with the balance of the active verifier, arranges the verifier to exit, and forms a "out" withdrawal request.
"out" withdrawal request is processed at the execution layer, and the stakeholder receives their ETH.
While the deposit is an operation triggered in the Eth1 block and then "moved" to the beacon layer through the "pending" deposit queue, withdrawals follow Different solutions. They are triggered on the beacon layer (via the CLI) and then "moved" to the Eth1 block. Both schemes will now operate through the same common framework (as described below): create a request at the Eth1 layer, process the "pending" deposit/withdrawal/merge queues, and process it at the beacon layer. For "output" operations like withdrawal, the output queue will also be processed, and the result will be "settled" in the Eth1 block.
With this EIP, stakers can use regular ETH transactions to extract and exit their validator without directly interacting with the validator CLI or accessing the validator's basics facility. This greatly simplifies staking operations, especially for large staking providers. Verifier infrastructure can now be almost completely isolated because only the key of the active verifier is maintained, while all staking operations can be handled elsewhere. It eliminates the need for independent stakers to wait for active validator actions and significantly simplifies the off-chain portion of Lido services like Community Staking Module.
So, this EIP "completes" the staking operation, completely migrating it to Eth1 layer, significantly reducing infrastructure security risks and enhancing independent staking initiatives decentralization.
EIP-6110: Supply verifier deposits on the chainReference: EIP-6110
Currently, deposits are achieved through events in the system's "deposit" contract (as discussed in detail in previous articles). The contract accepts ETH and verifier credentials and issues "Deposit()" events, which are then parsed and converted into deposit requests on the beacon layer. The system has many disadvantages: it requires voting on the eth1data of the beacon chain layer, which adds significant delays. In addition, the beacon layer needs to query the execution layer, which further increases complexity. These issues are discussed in detail in the EIP. An easier way to do without dealing with many of these issues is to include deposit requests directly in the Eth1 block at the specified location. This mechanism is similar to the withdrawal processing process described in the previous EIP.
The changes proposed in this EIP are promising. The eth1data processing can now be completely removed, no longer having to vote or prolonged delays between events on the Eth1 side and deposit inclusions on the beacon layer (currently approximately 12 hours). It also removes the logic of deposit contract snapshots. This EIP simplifies deposit processing and aligns it with the withdrawal processing scheme described above.
For stakers and validators, these changes significantly reduce the delay between deposit and validator activation. When validators are cut, the necessary supplements will also be faster.
Nothing more to say about this EIP, except that it removes outdated logic, simplifies the process and creates better ones for all involved result.
EIP-7685: General Execution Layer RequestReference: EIP-7685
This EIP should have been proposed before the first three EIPs related to deposit/withdrawal/merger because it lays the foundation for these EIPs. However, the introduction here is to highlight the growing demand for consistent mobile dedicated data between Eth1 (execution) and beacon (consensus) chain blocks (layers). This EIP affects two layers, making request processing triggered by conventional ETH transactions more efficient. Currently, we observe that the deposit event in the Eth1 block is "moved" to the beacon block for processing.
The withdrawal request (using the CLI) in the beacon block is "moved" to the Eth1 block for processing.
Verifier merge is required, which is also an Eth1->beacon request.
These three operations indicate the necessity of consistent processing of various types of requests when the conversion between the execution layer and the beacon layer. Additionally, we need the ability to trigger these operations using only the Eth1 layer, as this will allow us to isolate the validator's infrastructure from the staking management infrastructure, thus improving security. Therefore, a general solution to manage such requests is both practical and necessary.
This EIP establishes a framework for at least three main situations: deposits, withdrawals, and mergers. This is why early EIP introduced fields like WITHDRAWAL_REQUEST_TYPE and DEPOSIT_REQUEST_TYPE, and now the merge will add another field, CONSOLIDATION_REQUEST_TYPE. In addition, this EIP may include a common mechanism for handling restrictions on such requests (reference constants: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
While the detailed implementation details of this framework are still unavailable, it will certainly include critical request types, integrity mechanisms (e.g., hashing and Merkelization request) and pending queue processing and rate limiting.
This EIP has architectural significance, enabling Eth1 to trigger critical operations in the beacon layer through a unified framework. For end users and projects, this means all requests triggered at Eth1 layerWill be delivered and processed more efficiently on the beacon layer.
EIP-2537: Precompilation of BLS12-381 Curve OperationReference: EIP-2537
If you don't want to get a deeper look, you can think of the precompilation of BLS12-381 as a complex encryption "hash" operation that can now be used in smart contracts. For those interested, let us explore further.
Mathematical operations on elliptic curves such as BLS12-381 (and their corresponding BN-254) are currently mainly used for two purposes:
< p style="text-align: left;">BLS signatures, where a special operation is used called "pairing" to verify these signatures. BLS signatures are widely used by verifiers because they aggregate multiple signatures into one. Validators rely on BLS signatures based on BLS12-381 curves (although they can also be implemented using any curve that supports pairing, such as BN254).zkSNARK Verification of proof, where pairing is used to verify proof. Additionally, KZG commitments for large chunks introduced by Dencun hard forks also use pairing to validate block commitments.
If you want to verify BLS signatures or zkSNARK proofs in a smart contract, you have to calculate these "pairs", which is computationally expensive. Ethereum already has a precompiled contract (EIP-196 and EIP-197) for BN254 curve operation. However, the BLS12-381 curve (now considered safer and more widely used today) has not yet been implemented as precompiled. In the absence of such precompilation, implementing pairing and other curve operations in smart contracts requires a lot of calculations, as shown here, and consumes huge gas (about ~10^5 to 10^6 gas).
This EIP opens the door to many potential applications, especially in cheap BLS signature verification based on the BLS12-381 curve. This makes it possible to achieve threshold solutions for various purposes. As mentioned earlier, Ethereum validators have used BLS12-381-based signatures. With this EIP, standard smart contracts can now efficiently verify aggregated verifier signatures. This can simplify the bridging of proof of consensus and across network assets, as BLS signatures are widely used in blockchains. Threshold BLThe S signature itself allows the construction of many efficient threshold schemes for voting, decentralized random number generation, multi-signature, etc.
The cheaper zkSNARK proof verification will in turn unlock a large number of applications. Many zkSNARK-based solutions are currently hampered by high proof verification costs, which makes certain projects almost impractical. This EIP has the potential to change that.
EIP-2935: Save the historical block hash in the stateReference: EIP-2935
This EIP proposes to store 8192 (approximately 27.3 hours) historical block hashes in the blockchain state, providing extended history for stateless clients (such as rollups) and smart contracts. It recommends retaining the current behavior of the BLOCKHASH opcode, maintaining a limit on 256 blocks, while introducing a new system contract designed specifically for storing and retrieving historical hashes. This contract performs the set() operation when the execution layer processes the block. Its get() method is accessible to anyone to retrieve the required block hash from the ring buffer.
Currently, it is possible to reference historical block hash in EVM, but access is limited to the most recent 256 blocks (about 50 minutes). However, access to older block data is critical in some cases, especially for cross-chain applications (data that requires proven previous blocks) and stateless clients, which periodically require access to early block hashes.
This EIP extends the timeframe available for rollup and cross-chain applications, allowing them to directly access historical data in the EVM without having to collect it externally. As a result, these solutions become more robust and sustainable.
EIP-7623: Increase calldata costReference: EIP-7623
calldata cost adjustment The available size of the transaction payload, which can be large in some cases (e.g. when passing large arrays or binary buffers as parameters). Significant calldata usage is mainly attributed to rollups, which send payloads through calldata containing the current rollup state.
Tour large, provable binary dataEntering the blockchain is crucial to rollup. The Dencun (Deneb-Cancun) upgrade introduces an important innovation to such use cases - blob transactions (EIP-4844). Blob transactions have their own special "blob" gas fees. Although their subject is temporarily stored, its cryptographic proof (KZG promise) is integrated into the consensus layer along with its hash. Therefore, blob provides a better solution for rollup than using calldata to store data.
Encourage rollup to transfer its data to the blob. It can be achieved by "carrot and stick". The reduced blob gas fee is used as a "carrot", and this EIP suppresses excessive data storage in transactions by increasing calldata cost as a "leverage". This EIP complements the next EIP-7691 (increased Blob throughput), which increases the maximum number of blobs allowed per block.
EIP-7691: blob throughput increasesReference: EIP-7691
At the previous The Dencun hard fork introduces blobs, and the initial values of the maximum and target number of blobs per block are conservative estimates. This is due to the complexity of predicting how the p2p network will handle the propagation of large binary objects between validator nodes. The previous configuration has proven good, which makes this the right time to test new values. Previously, the target/maximum blob number for each block was set to 3/6. These restrictions are now raised to 6/9 respectively.
Combined with previous EIP-7623 (increasing calldata costs), this adjustment further incentivizes rollup to transfer its data from calldata to blobs. The work of finding the best blob parameters continues.
EIP-7840: Add blob scheduling to EL configuration fileReference: EIP-7840
This EIP proposes to add the target and maximum "per-block" blob count (discussed earlier) and the baseFeeUpdateFraction value to the Ethereum Execution Layer (EL) configuration file. It also enables clients to retrieve these values through the node API. This feature is for estimating blobsTasks such as gas fees are particularly useful.
EIP-7702: Set the EOA account codeReference: EIP-7702
This is a A very important EIP will bring significant changes to Ethereum users. As we know, EOA (external owned account) cannot have any code, but can provide a transaction signature (tx.origin). In contrast, smart contracts have bytecode, but cannot proactively propose a direct signature of "it". Any user interaction that requires additional, automatic and verifiable logic can currently only perform the required actions by calling external contracts. However, in this case, the external contract becomes the msg.sender of the subsequent contract, causing the call to "the call from the contract, not the user".
This EIP introduces a new SET_CODE_TX_TYPE=0x04 transaction type (we had the old 0x1 transactions, new 0x02 transactions from Berlin and EIP-1559 upgrades , and the 0x03 blob transaction introduced in Dencun). This new transaction type allows setting codes for EOA accounts. In fact, it allows EOA to execute external code "in the context of its own EOA account." From an external perspective, during the transaction process, EOA seems to "borrow" the code from the external contract and execute it. Technically, this is achieved by adding a special authorized data tuple to the "code" store of the EOA address (this "code" store was always empty for the EOA before this EIP).
Currently, the new 0x04 transaction type proposed by this EIP contains an array:
authorization_list= [[chain_id,address,nonce,y_parity,r,s],...]
Each element allows the account to use the code from the specified address (from the last one). a valid authorization item). When processing such transactions, the given EOA's code is set to a special 0xef0100 || address value (23 bytes), where the address points to a contract with the required code, || means the connection, and 0xef0100 means that the regular smart contract cannot be included Special magic value (according to EIP-3541). This magic value ensures that this EOA cannot be considered a regular contract, nor can it be performed like a regular contractCalled.
When this EOA initiates a transaction, the specified address will be used to call the corresponding code in the context of the EOA. While the full implementation details of this EIP are not clear, it is certain that it will bring significant changes.
One major impact is the ability to make multiple calls directly from EOA. Multiple calls are a persistent trend in DeFi, and many protocols provide this feature as a powerful tool (such as Uniswap V4, Balancer V3, or Euler V2). With this EIP, you can now initiate multiple calls directly from EOA.
For example, this new feature solves a common problem in DeFi: approve() + anything() requires the inefficiency of two independent transactions. This EIP allows common "pre-authorization" logic, so that approve(X) + deposit(X) can be completed in a single transaction.
Another advantage of being able to "represent" EOA commissioned transaction execution is the concept of sponsorship. Sponsorship is a frequently discussed and highly desireable feature to help new users enter Ethereum.
The programmable logic associated with EOA unlocks many possibilities such as implementing security restrictions, setting spending caps, mandatory KYC requirements, etc.
Of course, this change also raises many design issues. One problem is the use of chain_id, which determines whether the same signature can be valid across multiple networks, depending on whether it is included or not included in the signature. Another complex problem is the choice between using the address of the target code and embedding the actual bytecode. These two methods have their own unique characteristics and limitations. In addition, the use of nonce plays a key role in defining whether permissions are “multi-purpose” or “single-purpose”. These elements affect functional and security issues, including batch failure signatures and ease of use. Vitalik raised these questions in a discussion (here) and deserves further exploration.
It is worth noting that this change will affect a security mechanism of Ethereum, tx.origin. More details about this EIP implementation are necessary, but it looks like require(tx.origin == msg.sender) behavior will change. This check has always been the most reliable way to make sure that msg.sender is EOA, not a contract. Other methods, such as checking EXTCODESIZE (to check if it is a contract), usually fails and can be circumvented (e.g. by calling the constructor or deploying the code at a predefined address after a transaction). These checks are used to prevent reentry and lightning loan attacks, but are far from ideal, as they also hinder integration with external protocols. After this EIP, even the reliable require(tx.origin == msg.sender) check seems to become obsolete. The protocol must be adapted by removing these checks, because the difference between "EOA" and "Contract" will no longer apply - now there may be relevant code for each address.
The separation between traditional EOA and smart contracts continues to be blurred. This EIP brings Ethereum closer to a design like TON, where every account is essentially executable code. As interactions with protocols become more complex, using programmable logic to improve the end user experience is a natural process of this evolution.
ConclusionThe Prague /Electra (Pectra) upgrade is scheduled for March 2025. Its most significant plan changes include:
Variable valid staking, up to 2048 ETH, which will significantly change the staking distribution and verifier schedule. And simplify the management of large staking providers by integrating smaller staking
Improve the interaction between the execution layer and the consensus layer, and simplify the Eth1 execution block and the beacon chain block. data exchange. This will greatly simplify deposits, activations, withdrawals and exits, speed up these processes, and lay the foundation for further interaction between the consensus layer and the execution layer
In smart contracts Support for cheaper BLS signatures and zkSNARK verification directly with new "pair-friendly" BLS12-381 precompilation
Encourage Rollups by increasing blob transaction thresholds and increasing calldata Cost using blob transactions
make EOAs a programmable account, giving it multiple calls, sponsorships and other advanced features
As you can see, Pectra will have a significant impact on the end user experience at the staking and consensus layer, as well as the execution layer. While we cannot analyze all these changes in detail through code at this stage, as development is still in progress, we will cover these updates in future articles.