Prague / Electra (Pectra) upgrade is scheduled for March 2025.
Written by: Sergey Boogerwooger, Dmitry Zakharov, MixBytes
Compiled by: AI Translator, Deng Chain Community
Introduction
In our previous article, we reviewed the lifecycle of Ethereum validators in detail, discussing various aspects related to the upcoming Electra hard fork. Now, it is time to focus on the changes introduced in the upcoming Electra and Prague upgrades and explain them in detail.
The history of Ethereum 2.0's "Proof of Stake" hard forks is complex. It began with the addition of a beacon layer to the existing execution layer, while the beacon layer initiated Proof of Stake consensus, the execution layer continued to maintain Proof of Work (Phase 0 and Altair hard forks). Subsequently, PoS was fully activated in the Bellatrix hard fork (though withdrawals were not enabled). Then, the Capella hard fork allowed withdrawals, completing the validator lifecycle. The recent hard fork Deneb (part of the Dencun (Deneb/Cancun) upgrade) made minor revisions to the beacon chain parameters, such as including proof time windows, handling voluntary exits, and limiting validator replacements. The main changes in Dencun occurred in the execution layer, introducing blob transactions, blob gas, KZG commitments for blobs, and deprecating the SELFDESTRUCT operation.
Now, the Prague/Electra (i.e., Pectra) hard fork introduces significant upgrades to both the execution and consensus layers. As auditors of the Lido project, we primarily focus on the consensus and staking-related changes in this hard fork. However, we cannot overlook the changes in the execution layer in Prague, as they include important features that affect the Ethereum network and validators. Let’s delve into the details of these changes.
Higher-Level Overview of Pectra
Electra introduces numerous features for the beacon layer. The main updates include:
Allowing validators' effective balance to vary between 32 and 2048 ETH (instead of a fixed 32 ETH).
Allowing validators to initiate exits through secondary "withdrawal" credentials (no longer requiring active validator keys).
Changing the way the beacon layer processes Eth1 deposits (no longer parsing events from the deposit contract).
Adding a new generic framework for handling requests from regular Eth1 contracts on the beacon layer (similar to the management of deposits prior to Electra).
Meanwhile, Prague introduces the following changes to the execution layer:
A new precompiled contract supporting the BLS12-381 curve for verifying zkSNARK proofs (in addition to the popular BN254 curve).
A new system contract for storing and accessing up to 8192 historical block hashes (very useful for stateless clients).
Increasing calldata gas costs to reduce block size and encourage projects to migrate calldata-intensive operations (such as rollups) to the blobs introduced in Dencun.
Supporting more blobs per Eth1 block and providing an API to read these quantities.
Allowing EOAs (Externally Owned Accounts) to have their own account code, greatly expanding the operations EOAs can perform, such as executing multicalls or delegating execution to other addresses.
Let’s refer to the relevant Ethereum Improvement Proposals (EIPs) for further discussion:
EIP-7251: Increase MAXEFFECTIVEBALANCE
EIP-7002: Execution layer-triggered exits
EIP-6110: On-chain provision of validator deposits
EIP-7549: Move committee index out of proof
EIP-7685: Generic execution layer requests
EIP-2537: Precompiled operations for BLS12-381 curve
EIP-2935: Save historical block hashes in state
EIP-7623: Increase calldata costs
EIP-7691: Increase blob throughput
EIP-7840: Add blob scheduling to EL profiles
EIP-7702: Set EOA account code
Some of these EIPs primarily involve the consensus (beacon) layer, while others relate to the execution layer. Some span both layers, as certain operations (like deposits and withdrawals) require synchronized 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 affected Ethereum components in each case.
EIP-7251: Increase MAXEFFECTIVEBALANCE
Reference: EIP-7251
Since the first Phase 0 hard fork, in preparation for Ethereum's Proof of Stake, the maximum effective balance for validators was fixed at 32 ETH until Electra. Activating a validator required at least the spec.minactivationbalance (32 ETH). After activation, validators started from this maximum effective balance but could reduce their effective balance to the spec.ejectionbalance (16 ETH) and be expelled upon reaching that threshold. This "minimum" logic remains unchanged in Electra, but now the spec.maxeffective_balance has been increased to 2048 ETH. Therefore, validators can deposit between 32 and 2048 ETH to activate, all of which will contribute to their effective balance. This shift marks a transition from "32ETH - Proof of Stake" to "Proof of Stake" :)
This variable effective balance will now be used to:
Increase the probability of becoming a block proposer, proportional to the effective balance
Increase the probability of becoming a member of the sync committee, proportional to the effective balance
Serve as the basis for calculating relative penalties and inactivity penalties
The first two activities are the most rewarding operations for validators. Therefore, after Electra, validators with large stakes will participate more frequently in block proposing and sync committees, with frequency proportional to their effective balance.
Another impact relates to penalties. All penalty reductions are proportional to the validator's effective balance:
"Immediate" and "delayed" penalty reductions are greater for validators with large stakes.
"Delayed" penalty reductions alongside validators with large stakes are also greater, as the "reduced" portion of total staking becomes larger.
Reporters of validators with higher effective balances receive a larger proportion of the reduced stake.
Electra also proposes changes to the reduction ratio, defining a portion of the reduced validator balance that is received by reporters.
Next is the impact of inactivity. When a validator goes offline while active (proving or proposing), an inactivity score accumulates, leading to inactivity penalties imposed each cycle. These penalties are also proportional to the validator's effective balance.
With the increase in effective balance, the "replacement limit" for validators has also changed. In Ethereum "before Electra," validators typically had the same effective balance, and the exit replacement limit was defined as "no more than 1/65536 (spec.churnlimitquotient) of the total stake can exit in one cycle." This created a "fixed" number of validators exiting with the same stake. However, "after Electra," it is possible for only a few "whales" to exit, as they represent a significant portion of the total stake.
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 stakes, splitting them into 32 ETH portions. With Electra, this behavior is no longer mandatory. From a financial perspective, this change has little impact, as rewards and probabilities scale linearly with the stake amount. Therefore, 100 validators each with 32 ETH are equivalent to one validator with 3200 ETH. Additionally, multiple active validator keys can have the same Eth1 withdrawal credential, allowing all rewards to be extracted to a single ETH address, thus avoiding gas costs associated with reward merging. However, managing a large number of keys incurs additional administrative costs.
The ability to aggregate validator balances has introduced a new type of execution layer request. Previously, we had deposits and withdrawals. Now, there will be another type: aggregation requests. It will merge two validators into one. This operation request will include the public keys of the source and target validators and will be processed similarly to deposits and withdrawals. Aggregation will also have pending requests and balance replacement limits, just like deposits and withdrawals.
In summary:
For small independent validators, Electra introduces the ability to automatically increase their effective balance (and rewards). Previously, any surplus beyond 32 ETH could only be withdrawn, but after Electra, this surplus will ultimately contribute to their effective balance. However, the effective balance can only increase in multiples of spec.effectivebalanceincrement (1 ETH), meaning increases only occur upon reaching the next "1 ETH threshold."
For large independent validators, Electra provides significant management simplification by allowing multiple active validator keys to be consolidated into one. While this does not change the game, managing a 1x2048 stake is undoubtedly much simpler than managing 64x32 stakes.
For liquid staking providers, who collect small stakes from users and distribute them among validators, Electra adds more flexibility to staking distribution schemes but also requires a significant restructuring of validator accounting based on a fixed 32 ETH effective balance.
Another important topic is the historical data and profit estimation for validators, which is particularly relevant for new participants trying to assess risks and returns. Before Electra (as of the time of this writing), the 32 ETH cap (whether minimum or maximum, in practice) created uniformity in historical data. All validators had the same effective balance, rewards, individual penalty reductions, block proposal frequency, and other metrics. This uniformity allowed Ethereum to test its consensus mechanism without statistical outliers, thereby collecting valuable network behavior data.
After Electra, the distribution of stakes will undergo significant changes. Large validators will participate more frequently in block proposals and sync committees, face greater penalties during slashing events, and have a larger impact on delayed reductions, activation queues, and exit queues. While this may pose challenges in data aggregation, Ethereum's consensus ensures that nonlinear calculations are minimized. The only nonlinear component uses sqrt(totaleffectivebalance) to calculate base rewards, which applies to all validators. This means that validator rewards and penalties can still be estimated on a "per 1 ETH" basis (or more accurately, according to spec.effectivebalanceincrement, which may change in the future).
For more details, please refer to our previous article on validator behavior.
EIP-7002: Triggerable Execution Layer Exits
Reference: EIP-7002
Each validator in Ethereum has two key pairs: an active key and a withdrawal key. The active public BLS key serves as the validator's primary identity on the beacon chain, and this key pair is used to sign blocks, proofs, penalties, sync committee aggregates, and (prior to this EIP) voluntary exits (to initiate the validator's consensus exit after a delay). The second key pair (the "withdrawal credential") can be another BLS key pair or a regular Eth1 account (private key and address). Currently, withdrawals to an ETH address require a withdrawal message signed by the active BLS private key. This EIP changes that.
In practice, the owners of these two (active and withdrawal) key pairs can be different. The active key of the validator is responsible for validation duties: running the server, keeping it operational, etc., while the withdrawal credential is typically controlled by the staking owner, who receives rewards and is responsible for the funds. Currently, only the staking owner controlling the withdrawal credential cannot initiate the validator's exit and can only withdraw rewards. This situation allows the owner of the validator's active key to effectively hold the validator's balance as "hostage." The validator can "pre-sign" an exit message and hand it to the staking owner, but this workaround is not ideal. Additionally, both withdrawals and exits currently require interaction with the beacon layer validator through a specialized API.
The best solution is to allow staking owners to trigger withdrawal and exit operations simultaneously through a regular smart contract call. This involves standard Eth1 signature checks, greatly simplifying the operation.
This EIP allows staking owners to trigger withdrawals and exits by sending standard transactions from their ETH addresses to a dedicated smart contract (similar to the existing deposit process using the "deposit" contract). The withdrawal (or exit when sufficient stake is removed) process is as follows:
The staker sends a withdrawal request ("in" request) to the system's "withdrawal" contract.
The contract charges a specific fee (in ETH) to mitigate potential malicious attacks, and similar to EIP-1559, fees increase when the request queue is busy.
The contract saves the "in" withdrawal/exit request in its storage.
When a block is proposed to the beacon layer, the "in" withdrawal/exit requests in the queue are retrieved from storage.
The beacon layer processes the "in" requests, interacts with the active validator's balance, arranges for the validator to exit, and forms "out" withdrawal requests.
The "out" withdrawal requests are processed in the execution layer, and the staker receives their ETH.
While deposits are operations triggered in Eth1 blocks and then "moved" to the beacon layer via a "pending" deposit queue, withdrawals follow a different scheme. They are triggered on the beacon layer (via CLI) and then "moved" to Eth1 blocks. Now, both schemes will operate through the same generic framework (as described below): creating requests at the Eth1 layer, processing the "pending" deposits/withdrawals/merges queue, and handling them at the beacon layer. For "output" operations like withdrawals, the output queue will also be processed, and the results will be "settled" in Eth1 blocks.
With this EIP, stakers can withdraw and exit their validators using regular ETH transactions without directly interacting with the validator CLI or accessing the validator's infrastructure. This greatly simplifies staking operations, especially for large staking providers. The validator's infrastructure can now be almost completely isolated, as only the active validator's keys need to be maintained, while all staking operations can be handled elsewhere. It eliminates the need for independent stakers to wait for active validators to act and significantly simplifies the off-chain components of Lido services like the Community Staking Module.
Thus, this EIP "completes" the staking operation, fully migrating it to the Eth1 layer, significantly reducing infrastructure security risks, and enhancing the decentralization of independent staking initiatives.
EIP-6110: On-Chain Provision of Validator Deposits
Reference: EIP-6110
Currently, deposits are implemented through events in the system's "deposit" contract (as detailed in previous articles). The contract accepts ETH and validator credentials, emitting "Deposit()" events, which are then parsed and converted into deposit requests on the beacon layer. This system has many drawbacks: it requires voting on eth1data on the beacon chain layer, which adds significant delays. Additionally, the beacon layer needs to query the execution layer, further increasing complexity. These issues are discussed in detail in the EIP. A simpler approach, which avoids many of these problems, is to include deposit requests directly in Eth1 blocks at designated locations. This mechanism is similar to the withdrawal processing flow described in previous EIPs.
The changes proposed in this EIP are promising. The eth1data processing can now be completely removed, eliminating the need for voting between events on the Eth1 side and deposit inclusion on the beacon layer or long delays (currently about 12 hours). It also removes the logic for deposit contract snapshots. This EIP simplifies deposit processing and aligns it with the aforementioned withdrawal processing scheme.
For stakers and validators, these changes significantly reduce the delay between deposits and validator activation. When validators are slashed, necessary supplements will also be faster.
There is nothing more to say about this EIP other than that it removes outdated logic, simplifies the process, and creates better outcomes for all parties involved.
EIP-7685: Generic Execution Layer Requests
Reference: EIP-7685
This EIP was intended to be introduced before the first three EIPs related to deposits/withdrawals/merges, as it lays the groundwork for these EIPs. However, it is presented here to emphasize the growing need for consistent movement of specialized data between Eth1 (execution) and beacon (consensus) chain blocks (layers). This EIP affects both layers, making the processing of requests triggered by regular ETH transactions more efficient. Currently, we observe:
Deposit events in Eth1 blocks are "moved" to beacon blocks for processing.
Withdrawal requests in beacon blocks (using CLI) are "moved" to Eth1 blocks for processing.
Validator merges need to be processed, which is also an Eth1->beacon request.
These three operations highlight the necessity for consistent handling of various types of requests during the transition 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, thereby enhancing security. Therefore, a generic solution for managing such requests is both practical and necessary.
This EIP establishes a framework for at least three main scenarios: deposits, withdrawals, and merges. This is why early EIPs introduced fields like WITHDRAWALREQUESTTYPE and DEPOSITREQUESTTYPE, and now the merge will add another field, CONSOLIDATIONREQUESTTYPE. Furthermore, this EIP may also include a generic mechanism for handling limits on such requests (reference constants: PENDINGDEPOSITSLIMIT, PENDINGPARTIALWITHDRAWALSLIMIT, PENDINGCONSOLIDATIONS_LIMIT).
While the detailed implementation specifics of this framework are still unavailable, it will certainly include key request types, integrity mechanisms (e.g., hashing and merkleizing requests), as well as pending queue processing and rate limiting.
This EIP has architectural significance, enabling Eth1 to trigger key operations in the beacon layer through a unified framework. For end users and projects, this means that all requests triggered at the Eth1 layer will be transmitted and processed more efficiently on the beacon layer.
EIP-2537: Precompiled Operations for BLS12-381 Curve
Reference: EIP-2537
If you don't want to delve into the details, you can think of the BLS12-381 precompiled as a complex cryptographic "hash" operation that can now be used in smart contracts. For those interested, let's explore further.
Mathematical operations on elliptic curves like BLS12-381 (and its counterpart BN-254) are currently used primarily for two purposes:
BLS signatures, which use a special operation called "pairing" to verify these signatures. BLS signatures are widely used by validators because they allow multiple signatures to be aggregated into one. Validators rely on BLS signatures based on the BLS12-381 curve (though they can also implement any curve that supports pairing, such as BN254).
Verification of zkSNARK proofs, where pairing is used to verify the proofs. Additionally, the KZG commitments for large blobs introduced by the Dencun hard fork also use pairing to verify block commitments.
If you want to verify BLS signatures or zkSNARK proofs in a smart contract, you must compute these "pairings," which is computationally expensive. Ethereum already has a precompiled contract for BN254 curve operations (EIP-196 and EIP-197). However, the BLS12-381 curve (now considered more secure and widely used today) has not yet been implemented as a precompiled. Without such a precompiled, implementing pairings and other curve operations in smart contracts requires significant computation, as shown here, and consumes enormous gas (approximately ~10^5 to 10^6 gas).
This EIP opens the door to many potential applications, particularly in the inexpensive verification of BLS signatures based on the BLS12-381 curve. This makes it possible to implement threshold schemes for various purposes. As mentioned earlier, Ethereum validators are already using BLS12-381-based signatures. With this EIP, standard smart contracts can now efficiently verify aggregated validator signatures. This can simplify consensus proofs and bridging across network assets, as BLS signatures are widely used in blockchains. Threshold BLS signatures themselves allow for the construction of many efficient threshold schemes for voting, decentralized random number generation, multi-signatures, and more.
Cheaper zkSNARK proof verification, in turn, will unlock a multitude of applications. Many zkSNARK-based solutions are currently hindered by high proof verification costs, making certain projects nearly impractical. This EIP has the potential to change that.
EIP-2935: Storing Historical Block Hashes in State
Reference: EIP-2935
This EIP proposes to store 8192 historical block hashes (approximately 27.3 hours) in the blockchain state, providing extended history for stateless clients (such as rollups) and smart contracts. It suggests retaining the current behavior of the BLOCKHASH opcode, maintaining the limit of 256 blocks, while introducing a new system contract specifically designed for storing and retrieving historical hashes. This contract executes the set() operation when processing blocks in the execution layer. Its get() method is accessible to anyone, retrieving the required block hashes from a circular buffer.
Currently, referencing historical block hashes in the EVM is possible, but access is limited to the most recent 256 blocks (about 50 minutes). However, in some cases, accessing older block data is crucial, especially for cross-chain applications (which require proof of previous block data) and stateless clients that periodically need to access early block hashes.
This EIP extends the time range available for rollups and cross-chain applications, allowing them to directly access historical data in the EVM without needing to collect it externally. As a result, these solutions become more robust and sustainable.
EIP-7623: Increasing calldata Costs
Reference: EIP-7623
Calldata costs regulate the available size of transaction payloads, which can be significant in certain cases (for example, when passing large arrays or binary buffers as parameters). Significant calldata usage is primarily attributed to rollups, which send payloads by including calldata containing the current rollup state.
Introducing large, provable binary data into the blockchain is crucial for rollups. The Dencun (Deneb-Cancun) upgrade introduced an important innovation for such use cases—blob transactions (EIP-4844). Blob transactions have their own dedicated "blob" gas fees; although their body is temporarily stored, their cryptographic proof (KZG commitment) along with its hash is integrated into the consensus layer. Therefore, blobs provide a better solution for rollups compared to using calldata to store data.
Encouraging rollups to transfer their data to blobs can be achieved through a "carrot and stick" approach. The reduced blob gas fees serve as the "carrot," while this EIP increases calldata costs as the "stick," thereby curbing excessive data storage in transactions. This EIP complements the next EIP-7691 (Blob Throughput Increase), which raises the maximum number of blobs allowed per block.
EIP-7691: Blob Throughput Increase
Reference: EIP-7691
Blob transactions were introduced in the previous Dencun hard fork, and the initial maximum and target number of blobs "per block" was a conservative estimate. This was due to the complexity of predicting how the p2p network would handle the propagation of large binary objects among validator nodes. The previous configuration has proven effective, making this an appropriate time to test new values. Previously, the target/maximum number of blobs per block was set to 3/6. These limits are now increased to 6/9, respectively.
Combined with the earlier EIP-7623 (Increasing calldata costs), this adjustment further incentivizes rollups to transfer their data from calldata to blobs. Work is ongoing to find the optimal blob parameters.
EIP-7840: Adding Blob Scheduling to EL Configuration
Reference: EIP-7840
This EIP proposes to add the target and maximum number of "per block" blobs (discussed earlier) as well as the baseFeeUpdateFraction value to the Ethereum execution layer (EL) configuration. It also enables clients to retrieve these values via the node API. This functionality is particularly useful for tasks such as estimating blob gas fees.
EIP-7702: Setting EOA Account Code
Reference: EIP-7702
This is a very important EIP that will bring significant changes to Ethereum users. As we know, EOAs (Externally Owned Accounts) cannot have any code but can provide transaction signatures (tx.origin). In contrast, smart contracts have bytecode but cannot proactively provide "its" direct signature. Any user interaction requiring additional, automated, and verifiable logic can currently only be executed by calling external contracts. However, in this case, the external contract becomes the msg.sender of subsequent contracts, making the call "from a contract, not from a user."
This EIP introduces a new transaction type SETCODETX_TYPE=0x04 (we previously had the old 0x1 transaction from Berlin, the new 0x02 transaction from the EIP-1559 upgrade, and the 0x03 blob transaction introduced in Dencun). This new transaction type allows code to be set for EOA accounts. In effect, it allows EOAs to "execute external code in the context of their own EOA account." From an external perspective, during the transaction process, the EOA appears to "borrow" code from an external contract and execute it. Technically, this is achieved by adding a special authorization data tuple to the "code" storage of the EOA address (which was always empty prior to this EIP).
Currently, the proposed new 0x04 transaction type contains an array:
authorizationlist = [[chainid, address, nonce, y_parity, r, s], …]
Each element allows the account to use code from the specified address (from the last valid authorization item). When processing such transactions, the code of the given EOA is set to a special value of 0xef0100 || address (23 bytes), where the address points to the contract with the desired code, || indicates concatenation, and 0xef0100 represents a special magic value that cannot be included in regular smart contracts (according to EIP-3541). This magic value ensures that this EOA cannot be treated as a regular contract and cannot be called like a regular contract.
When this EOA initiates a transaction, the specified address will be used to call the corresponding code in the context of that EOA. While the complete implementation details of this EIP are not yet clear, it is certain that it will bring significant changes.
One major impact is the ability to perform multicalls directly from an EOA. Multicalls are a continuing trend in DeFi, with many protocols offering this feature as a powerful tool (e.g., Uniswap V4, Balancer V3, or Euler V2). With this EIP, multicalls can now be initiated directly from an EOA.
For example, this new feature addresses a common issue in DeFi: the inefficiency of requiring two separate transactions for approve() + anything(). This EIP allows for generic "pre-authorization" logic, enabling actions like approve(X) + deposit(X) to be completed in a single transaction.
Another advantage of being able to "represent" EOA delegated transaction execution is the concept of sponsorship. Sponsorship is a frequently discussed and highly desired feature to help new users enter Ethereum.
The programmable logic associated with EOAs unlocks many possibilities, such as implementing security restrictions, setting spending limits, enforcing KYC requirements, and more.
Of course, this shift also raises many design questions. One question is the use of chain_id, which determines whether the same signature can be valid across multiple networks, depending on whether it is included in the signature. Another complex issue is the choice between using the address of the target code and embedding the actual bytecode. Both approaches have unique characteristics and limitations. Additionally, the use of nonce plays a key role in defining whether permissions are "multi-purpose" or "single-use." These elements affect functionality and security issues, including batch invalidation of signatures and usability. Vitalik raised these questions in a discussion (here), which merits further exploration.
It is worth noting that this change will affect one of Ethereum's security mechanisms, tx.origin. More details on the implementation of this EIP are necessary, but it appears that the behavior of require(tx.origin == msg.sender) will change. This check has always been the most reliable way to ensure that msg.sender is an EOA and not a contract. Other methods, such as checking EXTCODESIZE (to see if it is a contract), often fail and can be circumvented (e.g., by calling a constructor or deploying code at a predefined address after the transaction). These checks are used to prevent reentrancy and flash loan attacks, but they 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 outdated. Protocols must adapt by removing these checks, as the distinction between "EOA" and "contract" will no longer apply—now every address may have associated code.
The traditional separation between EOAs and smart contracts continues to blur. This EIP brings Ethereum closer to designs like TON, where every account is essentially executable code. As interactions with protocols become increasingly complex, using programmable logic to enhance the end-user experience is a natural progression of this evolution.
Conclusion
The Prague/Electra (Pectra) upgrade is scheduled for March 2025. Its most significant planned changes include:
Variable validator effective staking, up to 2048 ETH, which will significantly change staking distribution, validator schedules, and simplify the management of large staking providers by integrating smaller stakes.
Improved interaction between the execution layer and the consensus layer, simplifying data exchange between Eth1 execution blocks and beacon chain blocks. This will greatly simplify deposits, activations, withdrawals, and exits, accelerating these processes and laying the groundwork for further interactions between the consensus layer and the execution layer.
Support for cheaper BLS signature and zkSNARK verification directly in smart contracts through the new "pairing-friendly" BLS12-381 precompiled.
Encouragement for rollups to adopt blob transactions by increasing blob transaction thresholds and raising calldata costs.
Enabling EOAs to act as programmable accounts, granting them multicall, sponsorship, and other advanced features.
As you can see, Pectra will have a significant impact on staking and the consensus layer, as well as the end-user experience of the execution layer. While we cannot analyze all these changes in detail through code at this stage, as development is still ongoing, we will cover these updates in future articles.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
