EigenLayer native restaking under the hood: An in-depth guide to native restaking on Eigenlayer with Chorus One

Summary

• The “EigenPod” is your smart contract that is designed to manage your natively restaked ETH. Native restaking is the act of restaking your Beacon Chain ETH to extend cryptoeconomic security to additional applications on the network.
• To participate in restaking, you need to set your EigenPod as the withdrawal address of the validators you intend to natively restake. If you created your validator with a 0x00 withdrawal address, you could use this legacy format to repoint your validator to an EigenPod. For others, you would need to create new validators since Ethereum validators withdrawal credentials are immutable.
• With the latest EigenLayer upgrade, stakers have the option to delegate to their favorite node operator by calling the delegate() function on the EigenLayer delegation contract.

A technical in-depth guide on native restaking with OPUS Portal to demystify native restaking on Eigenlayer with Chorus One. In a nutshell, the steps are as follows:

1. Go to EigenLayer Dapp and create an EigenPod
2. Go to OPUS Portal and create a validator with withdrawal credentials pointing to your EigenPod
3. Once your validators are created, you can restake your ETH on EigenLayer
4. Delegate to Chorus One

These simple steps will get you ready to participate in the restaking ecosystem. If you’re interested in reading more about what happens in each step, below we will unravel what happens under the hood.

1. Go to EigenLayer Dapp and create an EigenPod

Go to EigenLayer Dapp and create an EigenPod which you will use to manage your restaked ETH.

Restaking offers stakers the flexibility to contribute to the security of multiple networks and thereby earning additional rewards. Users that stake $ETH can opt-in to EigenLayer smart contracts to restake their $ETH and extend crypto economic security to additional applications on the network. To read more about how it works, head to our blog article on Eigenlayer.

Under the hood: The “EigenPod” is your smart contract that is designed to manage your natively restaked ETH by enabling monitoring of balance and withdrawals. The address of your EigenPod will act as your withdrawal address when setting up a new validator, we’ll revisit this in more detail in the next section, first let’s look at how an EigenPod is created. Here you can see an example transaction on goerli testnet which deploys an EigenPod. This is done via the “EigenPodManager”- a smart contract responsible for serving as the entry point for beacon chain ETH restaking. The transaction is validated, to verify that the address doesn’t yet own an EigenPod. Stakers are allowed to only have one EigenPod per wallet address, though the number of beacon chain validators that can be restaked is unlimited.

The EigenPod is deployed as an upgradable smart contract, which holds the latest implementation of the EigenPod logic. Smart contracts by design are immutable, though the beacon proxy pattern is a pattern aiming to provide ways to upgrade smart contracts without changing address and state variables. For smart contracts, the proxy acts like a reverse proxy, delegating the transaction to another smart contract in the background that holds the latest implementation.

Source: https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies

While projects such as uniswap design their smart contracts as fully immutable and non-upgradable, EigenLayer decided to design their smart contracts as upgradable and including paused functionality which can be changed by multisig governance.

As a final step in this process, when your EigenPod is initialised, your address is set to the EigenPod owner, a permissioned role for the EigenPod to restrict functionalities such as initialising withdrawals from the contract. Finally our pod is deployed successfully.

2. Go to OPUS Dedicated and create a validator with withdrawal credentials pointing to a users EigenPod

Go to OPUS Dedicated Portal and create a validator with withdrawal credentials pointing to your EigenPod.

By default, when creating a validator in OPUS, the wallet used for depositing would be set as withdrawal credentials, but there is also the option to configure a different withdrawal address. In short, the withdrawal address is the address that holds custody over the ETH deposited when creating a validator. To learn more about Ethereum withdrawal credentials and addresses involved , dive deep into one of our blog posts on Ethereum validator key generation.

Under the hood: As mentioned in the previous section, we need to set our EigenPod as the withdrawal address of the validators we intend to natively restake. This is because, the EigenPod smart contract (execution layer) needs to consistently verify the state from the beacon chain (consenus layer) e.g. to verify withdrawal credentials of the validator actually point to the EigenPod or check the value of the effective balance, in order to receive rewards.

Here’s an example of an EigenPod deployed on Goerli testnet with the address 0x812e0536A6b…. To enable restaking of your validators, the withdrawal credentials need to point to the EigenPod on depositing them on the Beacon Chain, see an example transaction of two validators being deposited pointing to the above EigenPod here.

You can verify this looking at the decoded input data of the deposit transaction (see screenshot below):

The effect of this is that we can’t just simply update an already running validator unless you’ve configured it with a 0x00 (BLS) withdrawal address. If you want to learn more about the legacy format, you can follow up in our blog post on Ethereum validator keys. Essentially this means, if you created a validator with a 0x00 address, you could use this legacy format to repoint your validator to an EigenPod. For others, you would need to create new validators since Ethereum validators withdrawal credentials are immutable.

3. Once your validator was deposited, you can restake on EigenLayer

Once your validators were deposited, you can natively restake your ETH on EigenLayer.

Here’s an example transaction of a user restaking their validators on Eigenlayer. To be able to initiate the restaking mechanism, you will need to submit a proof that the validators are indeed pointing to the EigenPod. When clicking the “restake” button on the Eigenlayer button this is done under the hood and the following information is submitted to craft this proof:

• Validator indices: Once deposited, every validator receives an index on the beacon chain as a unique identifier on-chain
• Validator fields: Represents the fields from the validator object, e.g. public key or withdrawal_credentials used to proof that the validators point to the respective EigenPod
• State root proof: A proof that will verify current state root, the state root is a hash of the Merkle Tree representing the state of the Ethereum network
• Validator fields proof: A proof that the fields belong to the validator index included in the state root proof
• Oracle timestamp: A timestamp to fetch the beacon block root from the oracle

Essentially, we use two Beacon Chain proofs. Using the beacon state root proof and the validator fields proof, along with the validator fields and validator index, we can cryptographically prove the validator with the provided information is indeed recorded on-chain and pointing to the given EigenPod. This is important, since the rewards (partial withdrawals) will be paid out from the Ethereum Protocol automatically to your EigenPod. As well as when withdrawing your funds (full withdrawals), the funds will move via your EigenPod. In a future series, we’ll touch on rewards and withdrawals on EigenLayer in more detail.

This process of verifying the withdrawal credentials is done for each validator you want to restake. If done successfully, validator index, effective balance are stored and the validator status is set to ACTIVE indicating that you’ve successfully restaked your validators. To finalise the process, the number of shares in the EigenPodManager are updated- if the stake is already delegated to a node operator, the delegated shares are updated.

4. Delegate your restaked assets to Chorus One

As of the time of writing, delegation functionality on EigenLayer is paused. The diagramme below outlines the process of restaking and delegating.

As described above, a (re-)staker restakes their Beacon Chain ETH by calling the verifyWithdrawalCredentials() function on their EigenPod, where they prove that the validators point to the EigenPod and thereby increase the number of delegatable shares, a record kept in the EigenPodManager.

Now with the latest upgrade, staker have the option to delegate to their favorite node operator by calling the delegate() function on the EigenLayer delegation contract. By current design, all of your restaked assets will be delegated to a single node operator you’ve chosen to delegate to. The delegation function only has to be called once, if you decide to restake more, the EigenPodManager will automatically increase the number of delegatable shares in the DelegationManager and delegate the assets to your chosen node operator.