Expected Changes on Beacon Chain with Shapella Upgrade

Expected Changes: Networking, Validators' Responsibilities, Fork Choice, Independent State & Block Historical Accumulators Conclusion

Expected Changes on Beacon Chain with Shapella Upgrade

Shapella Upgrade is successfully tested on devnets and public testnets. Ethereum Mainnet upgrade is scheduled for April 12th. Shanghai is the execution layer upgrade, whereas Capella will upgrade the consensus layer of the Ethereum Blockchain. The main highlight of the Shapella Upgrade is activating ETH withdrawals. While many people knew about the activation of EIPs on the execution side, only a few people were aware of the changes in the consensus layer, i.e., Capella Upgrade. This article aims to provide an overview of the Capella upgrade.

What is Capella Upgrade?

The Capella upgrade is the third major upgrade to the consensus layer or Beacon Chain after the Altair and Bellatrix upgrades.

It includes features related to validator withdrawals, such as automatic withdrawals of withdrawable validators and partial withdrawals sweep for validators with 0x01 withdrawal credentials and balances in excess of MAX_EFFECTIVE_BALANCE (32 Ether).

Timeline of the Beacon Chain Upgrades:

How was the name decided?

Capella is the brightest star in the northern constellation of Auriga. It is also the sixth-brightest star in the night sky and the third-brightest in the northern celestial hemisphere, after Arcturus and Vega.

During the Eth2 protocol upgrade naming theme brainstorming, developers decided that beacon chain upgrades will be named after stars, in English alphabetical order. Thus, the first upgrade was named Altair, and the second was named Bellatrix.

Expected Changes

Let's take a look at the expected changes in the Capella Upgrade.

Independent State & Block Historical Accumulators

The Capella upgrade introduces independent state and block historical accumulators. This new feature replaces the original singular historical roots and offers a more streamlined and secure method for validating the block history leading up to a specific state. By maintaining separate accumulators for block and state histories, the Ethereum network can ensure improved efficiency, security, and scalability.

With these independent accumulators in place, the process of validating block history and state becomes simpler, reducing the complexity involved in verification. The separation of accumulators also enables better support for potential future upgrades or modifications to the Ethereum network.

The process_historical_summaries_update function is responsible for updating the historical summaries of the state. The function checks if the next epoch is an epoch at which the historical summary should be updated. If this condition is met, a new HistoricalSummary object is created with the current block roots and state roots.

The HistoricalSummary class is a container that holds two root elements: block_summary_root and state_summary_root. These roots correspond to the independent historical accumulators for the block and state, respectively. By having separate accumulators for block and state, it becomes possible to validate the entire block history leading up to a particular state without any additional information beyond the state and the blocks.


In the Capella upgrade, changes have been made to the gossip network topics and messages, which impact communication among nodes in the Ethereum network. A new topic has been introduced to support gossiping withdrawal credential change messages, while the existing beacon block topic has been updated to accommodate the modifications in Capella.

Capella-Related Changes in Global Topics

  • beacon_block: The payload type of the beacon block topic has been updated to include the bls_to_execution_changes field within the BeaconBlockBody. This change corresponds to the modified SignedBeaconBlock in Capella, which is designed to support validator withdrawals.
  • bls_to_execution_change: This new global topic has been added in Capella to propagate signed BLS-to-execution change messages. These messages are used to include withdrawal credential change messages in future blocks. The network should only forward the signed_bls_to_execution_change messages that pass specific validation rules.

Capella-Related Changes in Req/Resp Domain
In addition, the Req/Resp domain messages have been updated with the introduction of the Capella fork-digest to the context enum. This change specifies the Capella block type:

  • BeaconBlocksByRange v2: The Capella fork-digest has been added to the context enum for this message. Based on the fork_version and genesis_validators_root, the context enum determines the appropriate chunk SSZ type.
  • BeaconBlocksByRoot v2: Similar to BeaconBlocksByRange v2, the Capella fork-digest has been introduced to the context enum for this message. The chunk SSZ type is determined based on the fork_version and genesis_validators_root.

The Capella fork-digest is a unique identifier that represents the Capella upgrade in the Ethereum network. It is used to differentiate between different fork versions of the Ethereum network, allowing nodes to properly handle protocol changes introduced in each upgrade.

Validators' Responsibilities

The beacon chain validators contain a field known as "withdrawal credentials". The first two bytes of this credential are known as the withdrawal prefix. The withdrawal credential is a commitment to a private key that can be used to withdraw funds from the validator's balance on the beacon chain.

Name Value

BLS_WITHDRAWAL_PREFIX: The beacon chain was initially launched with only BLS-style withdrawal credentials, so all early stakers used this. With this type of credential, in addition to a BLS signing key, stakers need a second BLS key that they will later use for withdrawals. This mechanism involves a BLS key pair to trigger withdrawals.

ETH1_ADDRESS_WITHDRAWAL_PREFIX: It is a much simpler approach for stakers to withdraw their beacon chain funds to an Ethereum account. It specifies a 20-byte ETH1 address (Execution layer address) as the recipient for all withdrawals.

Validators with ETH1_ADDRESS_WITHDRAWAL_PREFIX withdrawal credentials can participate in an automatic withdrawal process. Validators using BLS_WITHDRAWAL_PREFIX must change their withdrawal credentials by creating a one-time BLSToExecutionChange message to enable withdrawals.

The get_payload function returns an upgraded ExecutionPayload type. The main change in prepare_execution_payload is calling get_expected_withdrawals() to set the new withdrawals field of PayloadAttributes. This function is responsible for preparing the payload, considering both pre-merge and post-merge conditions.

For validators wanting to change their withdrawal credentials, they must create a valid BLSToExecutionChange message containing their validator_index, from_bls_pubkey, and to_execution_address. The validator then signs this message with their withdrawal BLS secret key and creates a SignedBLSToExecutionChange message. Once submitted to the consensus layer network and included on-chain, the withdrawal credential change takes effect, allowing the validator to participate in the automated withdrawal process.

It's important to note that the change in withdrawal credentials is irreversible, so validators should ensure the correctness and accessibility of the execution layer address before submitting the SignedBLSToExecutionChange message.

Fork Choice

The fork will be triggered at epoch CAPELLA_FORK_EPOCH, which is on April 12, 2023, at 10:27:35pm UTC.

In the Capella upgrade, all previous functionality from Bellatrix is inherited. One modification that has been made in the Capella upgrade is to the notify_forkchoice_updated function in the ExecutionEngine protocol. This function is crucial for the communication between the consensus layer and the execution layer in Ethereum.

The primary change involves the addition of withdrawals to the PayloadAttributes container. The PayloadAttributes container is extended with a new field called withdrawals. Apart from this modification, the notify_forkchoice_updated function inherits all other functionality from Bellatrix.


The Shapella Hard Fork has been successfully tested on multiple Devnets, Mainnet Shadow Forks, and Public Testnets. We are looking forward to a seamless Mainnet upgrade. EIP-4844 is the anchor upgrade for the upcoming Dencun upgrade. Stay tuned for more news on the Ethereum Blockchain with EtherWorld.


Related Videos


Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Support us at Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.

Share Tweet Send
You've successfully subscribed to EtherWorld.co
Great! Next, complete checkout for full access to EtherWorld.co
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.