Node Operator Onboarding | Tech Explainer

About Stader

Stader is a multi-chain, non-custodial liquid staking protocol on six chains, including Polygon, Fantom, BNB, NEAR, Hedera and Terra 2.0. With over $120 Mn in TVL across chains, Stader is trusted by 70K+ wallets and a community of 150K+ members.

Stader’s mission is to unlock a passive income opportunity for 1Bn+ people through staking and DeFi. We aim to achieve this by simplifying staking & offering the best yield opportunities with our liquid staking solution across multiple blockchains.

ETHx (following Stader’s convention of an x-for-suffix for liquid tokens) is the liquid staking token for staked Ethereum offered by Stader. ETHx aims to provide stakers, a decentralized and scalable solution with diverse DeFi integrations.

This blog post aims to give the reader a deeper understanding of the inner workings of ETHx. We will cover the ETHx architecture through a series of posts as outlined below:

1. Node Operator onboarding
2. Deposit workflow
3. Rewards management
4. Oracle updates
5. ETH withdrawals
6. Security

Node Operator Onboarding

Before we get into the details, here are the prominent actors in the ETHx ecosystem

1. Staker: A party that deposits ETH to mint ETHx at a corresponding exchange rate.
2. Node Operator: A party that runs a node by making themselves eligible for running a node for Stader.
3. Validator: A daemon that a node operator runs. Each validator stakes 32 ETH to the Beacon chain and is expected to perform duties in exchange for rewards. Failure to perform these duties and malintent will result in loss of staked Ethereum.
4. Oracle: A group of entities that relay information between the Beacon chain and the Execution chain. Oracle results are optimistically trusted based on a consensus mechanism unless proof of malintent is submitted.
5. ETHx smart contracts: Smart contracts that liaison between Stakers, Node Operators and Oracle. These smart contracts are permissionless for the most part.

ETHx is built to reduce technical and capital barriers to running nodes on Ethereum. Empowering smaller node operators is of the highest importance. Stader’s ETHx permissionless pool lets anyone operate a node with 4.4 ETH of asset collateral [4 ETH + 0.4ETH worth of SD (Stader’s governance token)per validator]. To remain scalable and have the backup capacity, the permissioned pool will onboard a few select operators with a history of running nodes at no collateral. Depending on eligibility, a node operator can be onboarded to the permissionless or permissioned pool.

There are two types of eligibility that a node operator could qualify for:

1. Deposit 4 ETH and 0.4 to 8 ETH worth of Stader governance token (SD) per validator as a security bond and run one or more validator clients. Qualifying for this criterion enables the node operator to join ETHx’s permissionless pool.
2. Show qualifications of prior expertise in running Ethereum nodes and pass KYC checks subject to Stader DAO approval. These operators can run validators without needing a security bond at mainnet launch. Qualifying for this criterion and a DAO approval enables the node operator to join ETHx’s permissioned pool. In subsequent updates to the ETHx protocol, permissioned operators must also provide an SD bond by purchasing SD from the market or borrowing SD in exchange for a share of their staking revenues.

Operators from both pools can leverage the Stader node to interact with ETHx smart contracts and allocate Staker’s ETH to their validators. Follow the node support guide to set up validators and understand the validator lifecycle.

Here are the two lifecycle flowcharts that explore the sequence of operations involved with onboarding an operator and registering validators. The flows vary, depending on the type or Node Operator: Permissionless v/s Permissioned.

Here are a few design considerations for these pools (both Permissionless and Permissioned), different operator and validator lifecycle steps.

• Execution and Beacon clients:

1. We allow NOs to select the consensus and execution clients they prefer to operate. Alternatively, NOs can yield back this choice and let the Stader node recommend a client based on the NO’s setup. This helps with client diversity reducing correlated failures with these builds.
2. We allow NOs to configure these clients to fine-tune validator performance. For example, if a NO has excess RAM, they can increase the peer count to ensure they get the information of attestations at the right time.
3. We set up MEV boost for NOs to increase their profits by proposing blocks that benefit them. Furthermore, we provide a complete monitoring setup for NOs to monitor their performance and system metrics using Prometheus and Grafana.

• ETH and SD collateral
  Permissionless operators must provide a 4 ETH bond to the permissionless node registry. To accommodate operators with different risk profiles, we also offer the flexibility for an operator to bond between 0.4 ETH to 8 ETH worth of SD per validator. At first glance, these two bonds require two transactions per validator.
  However, these flows are streamlined so an operator can add ETH collateral for multiple validators in one transaction. For example, an operator could provide 40 ETH along with 10 validator keys & metadata as a single transaction. This reduces gas fees incurred by operators. To further streamline interactions, an operator can deposit SD for any number of validators. Before validators are added to the ETHx smart contracts, proper checks are made to ensure that at least 0.4 ETH worth of SD per validator is available on the operator’s account. Operators must note that SD price fluctuates against ETH and may have to revisit their collateralization ratio requirements periodically.
• Invalid key data
  An operator could, purposefully or accidentally, pass an invalid signature for the first deposit during validator registration. On submitting permissionless validator data to ETHx smart contracts, Stader instantly deposits the 1 ETH front the node operator’s security bond of 4 ETH to the ETH deposit contract. This is the first step to registering the validator on the Beacon chain. In case of incorrect validator data, this 1 ETH becomes unrecoverable. Stader checks for the validity of the registered validator after this step, which ensures that further ETH is not lost. Despite this incorrect submission, a node operator still gets 3 ETH back and no further penalty. No staker ETH is at risk.
• Frontrunning
  A validator can deliberately front-run the first deposit transaction to gain custody of the subsequently deposited ETH. To avoid this situation, Stader splits the 32 ETH deposit into 2 steps — 1 ETH deposit followed by 31 ETH deposit. Between the two-part deposits, the validator data on the Beacon chain is verified to ensure no front-running occurs.
  For the permissionless pool validators, any attempt to front-run results in losing a node operator’s own 1 ETH. The remaining 3 ETH of their security deposit is penalized and transferred to the Stader Insurance Fund. We see no need to disable the node operator, as each validator in the pool has its security bond.
  For the permissioned pool validators, each front-run validator results in a transfer of 1 ETH from the Stader Insurance Pool to compensate for the 1 ETH lost. Further, this permissioned node operator is disabled from adding more validators and receiving staker ETH.
  Effectively, Stader ensures that staker assets are never at risk because of frontrunning incidents, despite node operator mal-intent.
• Pre-signed exit message check
  With the Shapella (Shanghai + Capella) update, node operators can broadcast an exit message to exit their validators. Stader mandates exit messages and records them before onboarding validators into the permissionless and permissioned pools. These pre-signed exit messages ensure Stader can exit validators based on performance or at a node operator’s request. This is a crucial lever to enforce alignment between staker assets and validator behavior and prevent loss of rewards. As part of the check between the two-part deposits, Stader also ensures that a valid pre-signed was provided. The Stader node stack has a daemon running to pre-sign messages. This has several advantages for the node operators.

1. Node operators don’t need to manually pre-sign the exit messages
2. Manual signing is simply not feasible for node operators with 100s of nodes
3. Presigned exit messages become void after every second Ethereum network hard fork. Running the daemon will avoid manual work and coordination in getting all node operators to sign a new pre-signed exit message

In this post, we’ve briefly covered how the node operator onboarding would be with Stader Node and ETHx smart contracts. In subsequent posts, we will cover the other portions of ETHx product– deposits, withdrawals, rewards and oracles.

For any questions you may have, please reach out to us at https://discord.gg/Dp9GZrUfA7.

Join our ETHx alpha list today and be the first to know about $1M in DeFi rewards.

https://www.staderlabs.com/eth/