Evaluating Staking Services

Ethereum 2 uses proof of stake to secure its network, where computer processes known as "validators" cast votes on the next block to be included. To receive rewards (and avoid punishments) validators must be active at all times. It is possible, and indeed is part of Ethereum 2's design, to ensure that validators can run on low-end hardware and anyone can run a validator at home. That said, being possible does not mean it is desirable: there are significant costs¹ involved with running a validator and, as such, many people will look to a third party to operate some or all of the validator functions. The process of validation can be handed off to a company that will run the validating hardware and software for a fee (hereafter "staking services").

Every staking service will have a number of features, including control of the deposit, control of the validator, access to staked funds, and payment for the service (cumulatively known as the "model"), but each of them can implement these features differently. There is no single "best" model for a staking service, as each comes with trade-offs and any particular model may fit one staker and not another.

This article looks at the above-mentioned features and sets out some (but by no means all!) of the options that staking services can choose for them, providing an overview of the different types of staking service available, depending on your particular requirements.

---

An Ethereum staking setup

Prior to looking at staking models it is helpful to understand the individual components required to successfully act as a validator in Ethereum 2. They are:

• Ethereum 2 node software, that provides information to the validator to sign;
• Ethereum 1 node software, that provides information about staking deposits to the Ethereum 2 node;
• Validator software, that carries out the work of signing and returning attestations and blocks (hereafter "attesting") provided by the Ethereum 2 node ; and
• Key manager software (or hardware), that contains the keys used by the validator when attesting.

Figure 1: Components of a staking setup

The Ethereum 1 and 2 nodes talk to other nodes to obtain a complete view of the current network:

Figure 2: Ethereum networks in a staking setup

Note that it is possible for the individual staking components to be on separate physical servers, and even operated by different entities.

---

Control of deposit

Prior to validating, someone must deposit funds to be used by a specific validator as a bond against bad behavior² (this someone is called a "staker"). To enable this deposit, someone needs to write the deposit agreement, which contains the identity of the validator and the account to which funds can be returned.

A staker may create their own deposit agreement or a service can provide it for them. Either way, it is important that the staker is able to verify the information in the agreement prior to transmitting funds. Any funds sent to an incorrect validator, or with incorrect withdrawal information, could result in the funds being lost.

---

Control of validator

The validator attests using the stake, and receives rewards commensurate to the size of the stake³. The validator signs its attestations with a private key to verify their authenticity; this key is known as the "validator key". The validator key is held by a key manager, which is a piece of software or hardware designed to protect private keys and sign data when requested.

There are various options for stakers considering the use of staking services, depending on how much they wish to be actively involved in the validating process.

Run the validator and key manager

It is possible for a staker to run their own validator and key manager. In this environment the staking service provides the Ethereum 2 node, which is the link to the Ethereum 2 network. The staker connects to the Ethereum 2 node to obtain details of what it needs to attests, attests locally, and returns the signed attestation to the Ethereum 2 node to add to the network.

Figure 3: Staker running validator and key manager

The benefit to the staker is that the service does not need to keep track of information about validator keys, and its role is reduced to ensuring an up-to-date view of the Ethereum networks and connectivity to validators. This insulates the staker from financial risks that can occur if the staking service is compromised. It would also be possible to move from one such service to another if desired.

However, there are costs involved. The staker will need to manage the hardware, software, network, etc. to ensure their validator remains online and accessible. If a validator is unable to transfer information to the staking service it can be hard to understand where the problem lies (is it with the staker, the service, or the network between the two?). And by running their own keys the staker becomes a target for hackers.

Run the key manager, let the service run the validator

It is also possible for a staker to run only the key manager, with the validator managed by the service.

Figure 4: Staker running key manager

Although the validator software has moved to the staking service the key manager remains with the staker; as such, it has much the same benefits and costs as the previous option. However, in the future it is possible that hardware key managers will become cheap and reliable enough such that running one would be inexpensive in terms of both money and time, at which point this would become a more interesting option.

Let the service run the validator and key manager

Here the staker has no hardware or software to worry about and lets the services carry out all of the work.

The benefits are that the staker does not need to become involved in the day-to-day operation of a validator, and the service's responsibilities are clearly defined.

This does, however, mean that the service has sole access to the validator key and as such movement from one service to another is not practical.

---

Access to staked funds

One of the pieces of information in the deposit agreement is the withdrawal identification⁴. The withdrawal identification is generated from an Ethereum 2 private key, (hereafter "withdrawal key"), and the same key must be used to sign any withdrawal requests made for those funds.

At the point the funds are ready to be withdrawn a transaction will need to be sent, signed with the withdrawal key. So the holder of the withdrawal key has full access to the funds. But who should hold the withdrawal key? Again, there are a number of options.

Trust the operator

One option is to trust the staking service to hold the withdrawal key and return the funds when required. This will entail the operator holding the withdrawal key securely until it is time to be used.

The benefit of this is that the staker does not need to worry about holding and protecting keys. This makes it preferable for those who are after a purely financial transaction.

The risk is that your trust could be misplaced. Even if the operator is trustworthy in terms of not running off with your funds, it may not have the technical ability to keep the keys safe from attackers.

Tokenization

Alternately, it is possible for the staking service to hold the withdrawal key and issue tokens that represent a staker's deposit. For example, if the staker deposited 32Ξ they would receive 32 tokens. The token holder accrues additional tokens as the validator gains rewards. For example, if the validator generates 0.5 Ether in rewards over a period of 6 months the holder of the tokens would receive an additional 0.5 tokens.

The benefit to the staker is that the tokens they hold are fungible: they can trade them, sell them, lock them up in a smart contract, use them as collateral against a loan, etc.

The risk is that the token's value is not based solely on the value of the Ether held in the staking service's validators. It is easy to understand that if there are 10,000 tokens issued by a staking service that is staking 10,000Ξ then a token will be worth 1Ξ. It is not so easy to be sure that the 10,000Ξ is definitely controlled by the staking service, that the staking service is unable to withdraw the Ether for themselves, that the staking services' security is adequate to protect the withdrawal keys from hackers. etc. These difficulties may result in the tokens' market price being significantly below par.

There are also possible tax implications: it is possible that tax authorities would consider the exchange of Ether for tokens as selling Ether and buying a token, in which case it becomes a taxable event. Although there is no final word on this, and treatment is likely to be different from one jurisdiction to another, the possibility exists and should be considered.

Keep the keys

A third option is for the staker to hold the withdrawal key themselves. If the service does not have the staking key it is impossible for it to withdraw the funds for its own use⁵.

The benefit of this is the staker has complete control over the movement of their funds: they are the only entity that can choose when and where to withdraw them. This provides the highest level of assurance that their funds cannot be stolen from, or by, the service.

The risk is that the staker must retain control of their own keys. At current there are no hardware wallets that support Ethereum 2 keys, so they would be reliant on traditional cold storage mechanisms such as writing the key on a piece of paper and keeping it somewhere suitably fireproof. Methods such as Shamir's Secret Sharing can be used to increase security, for example to have three locations and require access to two of them to retrieve the key, but the onus remains on the staker to keep their keys safe.

This also disallows pooling of the staked Ether by the service: each validator will run with a single staker's Ether, and if anything happens to that validator that results in a loss of funds, that loss is born by that validator alone. Losses (and gains) cannot be shared amongst all validators run by the service in the way that it could with the first two options. This could be considered a benefit or a risk, depending on your viewpoint.

---

Payment for service

It is expected that a staking service will require some sort of payment in return for its services. All fees would be recurring, as the service's costs are on-going.

Flat fee

One option is a flat fee for each validator. These will usually be charged in fiat, as they relate to the costs of the service that themselves will be paid in fiat (hosting fees, monitoring costs, network usage etc.).

A big benefit is simplicity: both staker and service are aware of the costs and can budget accordingly. A staker can pay months in advance and have surety that their payment will cover a given timeframe of operation.

The main drawback of this option is that the charge is unrelated to both the funds staked and the rewards earned. This reduces the direct incentive of the service to strive to achieve maximum rewards, although providing lower rewards than other services will still impact it in the long run.

Percentage of stake

Another option is for fees to be based on a percentage of the staked Ether. This is similar to financial services that charge a percentage of assets under management.

Similar to the flat fee, there is no direct incentive for the service to work hard to increase rewards.

As the fee in this case would be in Ether there would either be a requirement to pay in Ether or to agree upon a suitable exchange rate. This can lead to confusion, especially if there are significant movements in the exchange rate between the time a charge is issued and the time said charge is paid.

Percentage of rewards

A third option is for fees to be based on a percentage of rewards. This is similar to financial services such as hedge funds.

This option does align the service's incentives with those of the staker, however it results in a relatively complex calculation of fees that again can cause problems with fluctuating exchange rates. The fact that validator rewards cannot be withdrawn in the early stages of Ethereum 2's operation can hinder this option.

---

Decisions, decisions

Ultimately the best fit for a staking service is the one you are most comfortable with, although some are more viable than others.

• Do you trust to a service that has put significant time and resources in to security but is likely to attract hackers due to its public nature, or do you prefer to run a smaller but possibly less-secure environment and hope it is insignificant enough not to attract attention?
• Do you prefer running a local validator or key manager that gives you the ability to move from one provider to another, or is the time and money you spend setting up and maintaining it too high?
• Do you like having your own withdrawal keys where only you know how to access them, or are you worried that you will lose them, resulting in your stake being inaccessible?

The answers to these and similar questions will guide you towards one staking service or another.

Footnotes

1. Costs are examined in this article. ↩

2. See this article for details. ↩

3. With certain restrictions; see this article for details. ↩

4. Again, described in this article ↩

5. The staking service does control the validator operation and could destroy the funds if it so desired, but it would not benefit from such a move. ↩