Disclaimer: This article has been written by a community member
Quote from the writer
I’m pretty new to the Ethereum ecosystem and the Eth2 transition seemed interesting to me and that’s what led me to Ankr. Being a software engineer and architect, I’m always curious about how other people build things. So between the white paper, the logs while running my validators, the sheer curiosity, the request for community submissions, and the people asking questions in #eth-providing on Discord, I thought it would help Ankr to have something that gave people more insight into how it works and hopefully answer some of their questions. Around the time the community call went out, I was trying to put some effort into estimating the results from my Provider nodes while waiting for the dashboard updates, so it seemed like a win for us all to at least note down how I was thinking the system worked.
As many people know, Ethereum 2.0 is a Proof-of-Stake blockchain that relies on a decentralized cluster of validators to vote and finalize blocks to the blockchain.
What do you need
To stake on Ethereum 2.0, each validator has a few requirements and restrictions:
• a deposit of 32 Eth exactly
• hardware running the beacon-chain and validator software tied to the deposit.
• no liquidity of the deposited 32 Eth. (One deposited, it’s stuck in the contract until Ethereum 2.0 later phases, maybe 2 years from now)
• staking rewards to well-functioning validators and penalties to dysfunctional validators
• two sets of keys per deposit: one for signing by the validator during attestation/proposal, one for withdrawing the deposit and rewards in the future
When Ethereum 2.0 staking became available, StakeFi (formerly Ankr Staking / Stkr) was built to bring together two sets of people: people interested in staking but who have less than 32 Eth, and people who are interested in staking by running validator nodes. Thus the Stakers and Providers.
The goal is to take Staker’s Eth, bundle them into 32 Eth deposits, then have the Provider’s validator hardware handle the validation.
The Providers get a 15% share of the rewards for the Eth handled by their validator. Providers are responsible for the validator’s upkeep, therefore also bear the responsibilities of the penalties and share in the rewards of their validator node.
The Stakers get an 85% share of the rewards earned by their Eth.
“As a Staker, where is my staked Ethereum?”
Because Ethereum 2.0 requires exactly 32 Eth per deposit, the only way to allow smaller stakes is to aggregate them. It could be visualized as creating 32 Eth Deposits out of the Eth supplied by Stakers as they come in. Once a bucket is filled, it is deposited to the Eth2 network and becomes a signing key to run as a validator
That first 32 Eth bucket is made up of the first 4 Stakers, up until 32 Eth has been aggregated. The remainder of the 4th Staker’s Eth (24–2 = 22 Eth) starts a new bucket, to be filled as more Stakers join in.
As a receipt, the Staker receives aETH that can be redeemed for the staked Eth + staking rewards in the future.
“Which validator is attesting on my behalf?”
It’s actually elastic! StakeFi needs to onboard Providers to help run the validator processes. Any deposit which isn’t signed for during their slot/epoch will receive penalties for downtime, so all deposits must be signed for whenever possible.
Prysm’s Validator supports remote wallets so that management of the signing keys can be done remotely by StakeFi.
In addition, since validators can be configured with any number of signing keys, StakeFi can be flexible with which keys to distribute to which enrolled Providers each epoch. This allows StakeFi to automatically spread the validation duties across an elastic pool of validators as Providers come and go. Coupled with monitoring via the sidecar, StakeFi can even proactively migrate keys off of validators that may have problematic behaviors or performance issues and thereby optimizing both stability and earnings.
In this scenario, with StakeFi having 10 deposits (as in 10 32-Eth buckets were filled), and 3 Providers, Likely each of the 3 Providers is on duty for more than just a single 32-Eth deposit.
This diagram has 2 of them handling 4 deposits, and 1 of them handling 2 deposits.
When the time comes to attest to the slot, the validator will request from StakeFi to sign the attestation. This remote signing wallet call makes it possible for StakeFi to manage the keys for the validator pools without having the validators actually own the keys themselves.
If a problem occurs with a Provider’s validator node, then the keys can be remapped to the remaining validators to continue attestation duties. Missed attestations may occur on the epoch where the node issues occurred, but subsequent epochs can be handled properly due to the migration.
“Wouldn’t this mean validators on StakeFi operate as a centralized service?”
At first thought, this sounds like centralizing control over many validators with StakeFi and therefore making a single weak point for failures and attacks. However, that’s an incorrect oversimplification.
StakeFi’s innovative key management system is implemented as a decentralized system in order to protect the infrastructure and the keys from system failure and security compromises.
With other ETH2 staking services, key management is a real security concern, but Ankr has developed a cutting-edge solution for this that makes their key management absolutely bulletproof.
“As a Provider, how much am I making?”
The calculation as taken from the StakeFi docs is as follows:
Expected Provider Rewards per Year = ( ( Deposit * APY ) * 15% ) + (StakeFi Provider Insurance Deposit * APY * 85%) — Penalties.
Hypothetically, with a 8% APY, and a 2 Eth Provider Insurance Deposit:
Expected Provider Rewards per Year = (32 Eth * 0.08 * 0.15) + (2 * 0.08 * .85) — 0 = 0.52 Eth per year
The sidecar package that is provided for each StakeFi Provider Insurance Deposit not only helps StakeFi set up your instance of the Prysm Beacon Chain and Validator, but it also lets StakeFi know if your node is online and functioning so that it doesn’t accidentally assign you keys that you aren’t ready to sign. This avoids some penalties for missing attestations and facilitates the migration mentioned previously.
In short, if a Provider had an attestation record that was perfect (which I know mine is far from) and there was an average of 10 32-Eth deposits for each Provider node, then a single Provider who deposited 2 Eth for insurance could actually earn up to 5.2 Eth per year.
As a reminder, these are hypothetical numbers based on factors out of our individual control and used for illustrative purposes only.
“What about the penalties?”
The Beacon Chain and Validator processes require a number of things in order to successfully attest to a slot.
• A functioning Eth1 node to refer to, as staking right now is effectively merging the Eth1 chain into the Eth2 chain.
• Enough CPU and Memory to maintain the data for the Beacon Chain
• Being able to sign the attestation that is submitted.
Each of these require a component to talk to another, and each has a timeout attached to it.
If you miss the deadline, your attestation is not included for that epoch, and the associated 32 Eth receives a small penalty for missing the attestation.
This effectively means that a validator process could be penalized multiple times in a single epoch if your validator node is not functioning well simply because you were assigned multiple keys.
Furthermore, if you miss a block proposal, that’s an even more significant penalty.
The block proposals are rare, but earn more than the basic attestation as they aggregate the attestations. For the most part, if you see validators on beaconcha.in where they started the same as another validator but their APY is higher, it’s because they were lucky enough to be selected to propose blocks more times.
Ankr and StakeFi have clearly stated that slashing penalties are applied against the Provider’s Insurance Deposit only and not against the Staker’s deposit. However, it seems this isn’t the case for missed attestation and block penalties, as missed attestations can occur during key movement and random network latency. If my understanding is correct, missed attestations and blocks are reductions on earnings for a given 32 Eth deposit.
As StakeFi’s signing infrastructure and Prysm’s local databases do an excellent job of protecting honest validators from slashable offenses, I’ll not cover those here. If you’re interested in the details of slashable offenses, I found https://ethos.dev/beacon-chain to be helpful.
“Great, as a Provider, how much am I really making?”
The short answer is, I don’t know. I tried a little to figure this out myself. But without logs from StakeFi with regards to exactly when my node was on duty for which key, I can’t be sure.
Plus, doing the actual query to a Beacon Chain node to find out how much was earned for each epoch was pretty slow when I tried. If I go back to all my logs from the beginning and parse them, I should be able to get a ballpark of rewards and penalties.
I hope this article helps shed some light on how StakeFi works, why it’s cool, and for Providers, how it might be more profitable than you originally expected. In due time, we’ll know the real numbers. But I hope this tide you over.
Website | Twitter | Telegram Announcements | Telegram English Chat| LinkedIn | Instagram | Ankr Staking | Discord