Open in app

Sign in

Write

Sign in

Nethermind logo + Lido logo

A Path To Permissionless Liquid Staking

Nethermind
Nethermind.eth
18 min readSep 29, 2022

--

Table of Contents

Introduction

After the Merge, the Ethereum Network has committed to a Proof of Stake (PoS) consensus mechanism. There has been controversy about the centralization that this mechanism could entail. Among the concerns, it has been said that the entry cost to stake is steep (32 ETH) and that funds will remain locked until staking withdrawals are implemented on Ethereum, which may discourage parties in need of liquidity from staking.

To address these difficulties, Ethereum has seen the rise of alternatives to the native staking mechanism, i.e., solo staking — such as delegate staking, and liquid staking. It is essential to highlight that different types of staking services convey various centralization problems. For example, there are various challenges on whether the service is handled by an exchange, a DAO (with all the variety of approaches a DAO can opt for), or in a permissionless way.

Although staking is used in multiple proof-of-stake networks, this article focuses solely on Ethereum. We will briefly discuss other types of staking, but our main area of interest is the various flavors of liquid staking. We will cover the current state of affairs in services that provide liquid staking, and discuss what an ideal permissionless staking mechanism could look like. To conclude, we will introduce our project of helping the Lido DAO to transition from a permissioned staking service into a permissionless one. Our ultimate goal is to increase capital efficiency as much as possible while building a secure and permissionless solution.

Approaches to staking

Before we discuss liquid staking, let us recall what staking is. In Ethereum, staking is the process of locking up ETH to participate in the consensus mechanism and gain rewards for that.

In solo staking, the operator (a party that runs one or many Ethereum validators) runs its own validator by staking a pre-defined amount of crypto assets (32 ETH ≈ 42000 USD per validator at the time of writing) and participates in the network consensus, validating the transactions. Being a validator is not an easy task. Validators must maintain high uptime service on the internet (90% to 95%) and ensure that their software is up to date to avoid missing attestations. Another significant limitation is illiquidity — the network locks the deposited funds. The operators can’t even unstake the deposited ETH until after the Shanghai/Capella hard fork. Hence, it is clear that not all network participants could, or should, run validators on their own.

Notice that in solo staking, the entity that runs a validator node is both a staker and an operator. It is easy to imagine a scenario in which an entity is able or willing to take part in only one of those two roles. For example, a user may have the capital required for staking and operating an Ethereum validator but may not have the technical capacity to carry out such a task. On the other hand, a tech-savvy party may be willing to run an Ethereum validator (in exchange for a certain reward) but may be unwilling to make an initial deposit of 32 ETH.

This showcases the need for services that connect stakers and operators. One could imagine that such a service allows the stakers to lend their funds to the operators and distributes the staking rewards between them. A simple approach could be to create a marketplace where operators offer their services and stakers choose who to delegate their funds to. We could call this scenario staking by delegation. Notice that, in particular, this enables stakers to contribute with less than the minimum amount of funds required to run a validator.

This is a perfectly reasonable solution as long as stakers are fine with the illiquidity that staking entails. More complex approaches feature a liquid derivative given to stakers in exchange for their delegation of funds. The derivative is often designed to be an asset whose value is pegged to one of the deposited funds. This type of service is called liquid staking.

Taxonomy of staking. In exchange staking, the user stakes funds on a centralized exchange with full control over the staked funds. Permissioned staking refers to a service where the service provider curates the set of admitted operators. In permissionless staking, any party that meets well-defined criteria may become an operator.

The rest of this post focuses on the three subtypes of liquid staking outlined in the figure above. Our primary focus is “permissionless staking.” We discuss what we mean by it, why it is essential, and the challenges it entails.

Types of liquid staking through the lens of decentralization

By lack of decentralization, we understand a scenario in which a few parties control a large ratio of the validation capabilities. Such a scenario is clearly opposed to the ethos of networks such as Ethereum. Decentralization is related to the minimum Nakamoto coefficient metric of decentralization. The metric reflects the minimum number of entities that can disrupt the blockchain system. Later on, we discuss issues around centralization in a more thorough manner.

The threat of the centralization of stake is not the same for all staking methods. Some argue that the most decentralized one is solo staking. However, this approach has severe drawbacks as discussed in this article. We turn our attention to the liquid staking options.

In exchange staking, all the stake submitted by the users is controlled by a centralized entity — exchange — which is often a private company (for example, Binance, Kraken, Coinbase, etc.), that runs its own validators or delegates this task to a third party. Although this approach may be capital efficient for both the users and the exchange, it comes with multiple systemic risks: First of all, an exchange can usually use the staked funds as it pleases which makes monitoring its movements harder. For example, it could take destructive MEV, try to attest fraudulent transactions, or even use the funds for purposes other than staking them. Furthermore, the exchange could have to change the way it operates to comply with new regulations.

A well-known example of a permissioned staking service is Lido. Here, the operators are whitelisted by Lido but are left to run the corresponding validators independently. This limits the power the organization (in our example, Lido DAO) has over the operators, which is better from a system decentralization perspective. However, due to the operators’ relatively large autonomy, it is difficult to quickly change any misbehaving or malfunctioning operators, making the organization vulnerable to malicious or technically unable operators. The organization must therefore check the operators thoroughly before they are whitelisted.

An alternative name for the above type of staking service could be curated or whitelist-based staking.

Finally, in permissionless liquid staking protocols, operators are onboarded based on a well-defined automated (and not curated) process. In this setup, the threat of centralization could be minimized if the onboarding process has several qualities. For example, it should not allow:

  • Any operator to control more than X% of the staked ether. That is, an operator who controls that amount of staked ether should not have more ether assigned. We emphasize here that the operator have only limited control over the staked funds. Namely, a malicious operator can miss attestations or commit a slashable offence, but cannot withdraw the stake and steal it.
  • A single party to run several operators behind the scenes.

We will discuss an ideal permissionless onboarding mechanism later on. We emphasize that such a type of liquid staking is not a silver bullet for centralization. It is easy to imagine a permissionless protocol that does not check its prospective operators well enough and, for example, allows one party to control a majority of the stake by running multiple operators. This is further discussed in this post by Izzy.

The organization (e.g., a DAO) that created the protocol can only influence the set of validators in a limited way. Anyone who meets the protocol criteria may become an operator. An example of such a service is the Rocket Pool protocol, with the “protocol’s criteria” being, in this case, bonding 16 ETH.

We note that designing a permissionless onboarding mechanism is the right path to achieving decentralization. However, we believe that simultaneously fostering a good quality set of operators (one which indeed leads to decentralization) while ensuring that the staking service is beneficial for both the stakers and the operators, is a hard problem to solve.

Centralization of stake

Decentralization is (one of) the main aspects of blockchain protocols. If only a few parties control a majority of assets, the risk of attacks, like the 51% attack, grows significantly. When there are indications that decentralization may be compromised, concerns appear in the community, and red flags are raised. When can this happen?

As previously mentioned, liquid staking allows the stakeholders (even those not holding 32 ETH) to delegate their stake and earn rewards. This delegation can, in some cases, give indirect or direct power over a significant amount of ETH to the parties providing the liquid staking service. These parties then control much more stake (and therefore obtain much more weight in the PoS attestation system) than they would if they only used their own funds.

Let us elaborate on this. Because of how the Ethereum attestation system is designed, an entity that controls more than 2/3 of the total number of validators can decide which transactions are processed and which are not. Assume for a moment that there are no delegated and liquid staking services, so-called pools. Then, for an entity to control 2/3 of the validators, it would need 2/3 • N • 32 ETH, where N is the total number of validators (N ≈ 422000 at the time of writing). This is a massive amount of ETH (≈ 9 000 000 ETH), and as a result, an entity that holds such an amount of ETH will likely be reluctant to disrupt the Ethereum chain and reduce the value of its stake (see also https://www.coindesk.com/layer2/2022/04/20/is-ethereum-staking-pool-lidos-growth-an-omen-of-centralization/).

On the other hand, pool owners are in charge not only of their stake but also of the stake that is delegated to them. This means that if these entities become huge in the amount of controlled delegated stake, a small number of pool owners can influence the supermajority of the validators and gain some power without even owning this stake. For this reason, many articles have discussed the issue of stake centralization, especially in exchanges and DAOs such as Coinbase and Lido, see the reference section below. We emphasize that the pool owners have various amounts of power over their operators in different setups — from almost total control in CEX-es, through limited power in non-custodial permissioned pools, to minimal control in permissionless pools.

Importance of permissionless operating

In this section, we discuss how to approach permissionless liquid staking. We begin by explaining how and why Lido opted for an initial permissioned approach, even though its roadmap includes transitioning into a permissionless one. Then we review Rocket Pool, an example of a service of the latter type, and describe what an ideal mechanism should look like. We emphasize the term “ideal” here: permissionlessness on its own, albeit necessary, is insufficient to guarantee a lack of centralization. Additional requirements must be met.

As we discuss later, such an ideal mechanism should allow any well-intentioned and technically competent operator to run a validator within the stake pool of the service. Furthermore, it should not be possible for a single entity to control (perhaps in the shadows) the validators associated with a significant fraction of the staked funds. These requirements are designed to prevent the stake centralization issues discussed previously.

Road to permissionless staking

As stated in Lido’s blogposts, Lido was created at a time when a fully permissionless liquid staking solution would not be competitive with centralized exchanges and the convenience of their staking services. A compromise had to be made so that valuable stake could be captured away from these centralizing forces. To this end, Lido opted for a permissioned approach: node operators are authorized via a whitelist registry controlled by LDO holders. Lido smart contracts receive ETH from stakers, mint stETH in return, and set up new validators controlled by the whitelisted parties with the accumulated ETH.

Fast forward to today, to the post-merge world, and Lido has successfully addressed threats of staking centralization by exchanges while achieving uncontested dominance in the liquid staking world. With roughly one-third of all staked ETH under the protocol’s control, its security is crucial for the health of the entire Ethereum community. The next step towards securing Lido is to obtain a stronger, trustless guarantee of the correct functionality of its operator set while making the changes it requires to become a permissionless protocol.

Bond-based permissionless staking

Before we continue to, what we believe, is the ideal liquid staking mechanism, we describe how Rocket Pool incentivizes its operators to behave honestly.

In Rocket Pool, operators can be onboarded without a whitelist. Any prospective operator must contribute 16 ETH (plus 1.6 ETH worth of the RPL token for insurance purposes). This deposit is then complemented with an extra 16 ETH from Rocket Pool’s staking pools. Combining both sources of capital, a new validator is created. In case of misbehavior by an operator that leads to slashing, the corresponding loss of the staked ETH can be covered by the operator’s deposit of 16 ETH. (By design, the operator’s bond does not cover the loss of the accumulated rewards).

Unlike Lido, Rocket Pool manages to stay permissionless by requiring a large amount of collateral from each node operator, which ensures that behaving correctly is in the operator’s best interest. While this provides strong security, it sacrifices capital efficiency and places a steep economic requirement on operators that wish to run Rocket Pool nodes. Ultimately, these factors cause solutions with high bonding requirements to either scale poorly or risk high degrees of centralization.
Check https://hackmd.io/@Izzy-/EthereumStakingCodex#Unconstrained-vs-supply-constrained-staking-growth for more comments on the subject.

Beyond bonding, the ideal mechanism overview

Unless we require the operators to submit a significant bond, the road to permissionless operator onboarding is not easy. Numerous issues are easily solvable or non-existent in more centralized designs but are problematic if the setup is fully permissionless.

First, an exchange-based or permissioned setup allows the gatekeeper to thoroughly check who a prospective operator is, how well it knows its trade, how reputable it is, etc. The promise is that an operator with a reputation at stake is more careful in its operations and ensures best practices to keep its reputation high. For example, we should expect a reputable operator to:

  • Remain online and participate in every assigned attestation — since a validator is rewarded for every performed attestation (that is finalized).
  • Not miss attestations — since each missed attestation results in a penalty that reduces the stake.
  • Make sure not to commit a slashable offense — this could be, for example, attesting two conflicting blocks. Slashable offenses have severe consequences: the validator is forced to exit, and may lose all its stake.

All of that provides a good experience for the stakers, who don’t need to worry about their staked funds and don’t lose any potential gains from staking.

A centralized approach could also easily enforce several policies which keep the system healthy. For example, we could require that the operators:

  • Are geographically diverse. This reduces the risk of operators being forced to halt their operations due to a political decision of some blockchain-averse government, or the risk of operators being offline because of possible location-specific network problems, and so on.
  • Don’t take destructive MEV. The system can promote the operators participating in, say, MEV-boost and discourage those whose actions may put the network’s security at risk.
  • Don’t give up on independent operators. The system may promote small, independent entities to ensure that it doesn’t have any single point of failure and doesn’t become undesirably centralized.
  • Operate on diverse Ethereum clients with diverse setups. Similarly to the previous point, when the system ensures that the operators run various setups on their clients, it reduces the risk of a single point of failure.
  • Don’t hire third parties (so-called white-label operators) to perform operator tasks for them — a system that allows such behavior may suffer from centralization and a single point of failure.

All these properties are equally desirable in an ideal permissionless staking mechanism, though some of them are challenging to implement. Additionally, we believe such a mechanism should evaluate the set of operators according to the criteria from this note by Lido. More precisely:

  • It should have methods for improving the set of operators if there is an option to do so.
  • There should be no need for input from permissioned entities, i.e., there should be no admins/committees. And token holders (e.g., LDO, stETH, ETH holders, in the case of Lido) should have only a very low capacity to impact the mechanism, if any.

From an economical perspective, the ideal mechanism should have several properties that ensure that participation in liquid staking is beneficial for the stakers and the operators. For example:

  • The mechanism has to be capital efficient: Collateral for operators can be used, but it can’t be the single or primary mechanism; it has to function mainly by staking other people’s funds.
  • The mechanism has to account for the bull-bear cycle effect in a way that allows operators to stop validating if it became too expensive. The mechanism design also needs to enable the protocol to shrink the number of operators in bear markets (in a manner where the overall decentralization of the protocol is not substantially adversely affected) or expand in bull markets.
  • Improving operational quality should increase an operator’s revenue, e.g., by increasing the stake or the commission. However, we need to ensure that the stake is distributed approximately equally. No operator should control more than 1% of total ETH staked (globally).
  • New operators should be welcome as well. That is, the mechanism should allow a new operator to enter the set of operators with essentially no collateral or reputation and work its way to an optimal position within the network of operators. That should be possible, although it may take a long time, if the operator has a “good enough” performance and is ecosystem aligned, independent, and runs its hardware in non-concentrated geographical or jurisdictional areas. There might be a need for an insurance pool or collateral to enter at zero or to rise to the top, but it shouldn’t be an essential requirement in the middle.

As mentioned, achieving these properties is much more difficult in a permissionless manner. In a setting where we cannot assume that a DAO or some other body makes the aforementioned checks, all checks need to be automated and decentralized. For more on the permissionless Ethereum staking, see https://research.lido.fi/t/the-road-to-trustless-ethereum-staking-discussion/845

Our project

We will work with Lido to design a mechanism that allows operators to join the Lido network permissionlessly while maintaining a high-quality operator set.

First, we will design a way of permissionlessly and automatically verifying the quality of current and prospective operators. For this, we plan to use data from off-chain and on-chain sources. We emphasize that the on-chain data may not be enough to ensure a high-quality set of operators. Hence it is important to design a mechanism that pulls off-chain data to on-chain. Here we differentiate two sources: issuer data and community data. The former is taken from official institutions and trusted issuers, amongst other sources, while the latter is taken from distributed communities. Such data need to be obtainable and verifiable since the designed systems rely upon it.

Another crucial part of ensuring a good set of validators is to create a robust incentive mechanism that ensures that rational actors behave honestly and in a manner that helps shape the operator set according to our design goals (e.g., having operators be as diverse as possible), being this the behavior with the greatest payoff. To that end, an in-depth analysis of incentivization methods is required.

We also note that an incentive mechanism is needed to obtain good quality data — to have data pulled on-chain and verify it.

The project will be divided into four phases:

  • Phase 1: We will survey the literature and state-of-the-art approaches to identity and attestation schemes. See the section below for specific details.
  • Phase 2: During this phase, we will survey the literature and state-of-the-art approaches to oracles, token-curated assets, and prediction markets.
  • Phase 3: Next, we will proceed to design solutions for assuring a good quality set of operators and economic security of the protocol.
  • Phase 4: This phase is mainly concerned with implementing the solutions designed during Phases 1, 2, and 3. Additionally, we will research further topics and problems, as done in the previous phases. Afterwards, we will implement the solutions designed in the earlier phases of the project. Further information on this phase will be provided later, by the end of Phase 3.

In the remaining part of this article, we discuss the project’s first phase.

Phase 1: Decentralized identifiers and their role in permissionless staking

We have described the requirements and difficulties behind the permissionless operator onboarding problem. Suppose bonding is not to be used as the primary security mechanism. In that case, we need an alternative to take its place — one that is also compatible with a fully decentralized infrastructure. Before we explore other options, let us note a subtle feature that bonding brings to the table which we need to replace.

It turns out that bonding does not only provide insurance against an operator misbehaving. Just like staking, bonding has the convenient property of increasing the cost of a Sybil attack against the operator set — that is, having a single party impersonate a multitude of different identities to gain more influence over the protocol than it should have on its own. With bonding, a Sybil attack has an economic cost — a single party cannot create more nodes than it can afford. Without bonding, we will need a way to verify the identities of the node operators so that we can ensure a reasonable distribution of validators among our operator set, avoiding the concentration of power in the hands of a single party.

Lido currently handles this problem through the off-chain identities of the operator parties so that trust is only given to reputable organizations in the blockchain space. This design, of course, is not without risk and is only apt as a temporary solution. It also requires manual input by the DAO members, which does not lend itself to automation. Finally, it makes it difficult for small players to participate as operators in Lido since they are not likely to have a reputation large enough to offset the misbehavior risks.

To replace the role of the Lido DAO without using a large amount of bond as the integral mechanism incentivizing correct behavior, we need a reliable way to move the concept of identity on-chain. This is where the problems of decentralized identity management and verifiable credentials come into play. Specifically, how can we ensure that a person/ETH address is who they claim to be and possess the characteristics — qualifications, performance, history, location, etc. — they claim to have?

Let us describe at a high level how Verifiable Credentials (VC) and Decentralized Identifiers (DID) work by giving an example.

Assume an entity called holder wants to prove to a verifier that it owns a certificate issued by a trusted organization called an issuer. In our case, the holder would be the operator, the verifier would be Lido, and the issuer could be an oracle that checks the operator’s performance according to some metrics. The certificate could be a document stating, e.g., that the operator has missed no more than 1% of attestations on the Goerli testnet. The certificate verification procedure should satisfy some properties. Namely, the verifier should be able to check that the certificate has not been tampered with (without the issuer’s permission). Additionally, the holder should be able to disclose to the verifier only the information that is needed for the verification.

Initially, both the issuer and the holder should create DIDs. DIDs are public digital identities that can be included in the blockchain and are associated with a set of keys (public key, private key). The public key is visible to everyone who has access to the blockchain in contrast to the secret key owned exclusively by the holder. The holder can prove that it owns this DID using its private key. As a next step, the holder asks the issuer to digitally sign the information the holder wants to disclose to the verifier. Note that the issuer will use its private key to sign this information. Afterward, the holder sends the signed information to the verifier, who can verify the DID associated with the organization that signed the document, as the DID is stored in the blockchain.

As a final remark, we note that the subjects of decentralized identifiers and verifiable credentials are recent in the blockchain space. The jury is still out on whether these systems will be strong enough to provide the guarantees required by decentralized liquid staking. If this is not the case, we can still look into hybrid approaches involving both verifiable credentials and smaller bonds as a complement to mitigate risk. Regardless of the design, our ultimate goal is the same: increasing capital efficiency as much as possible while building a secure and permissionless solution.

References

Nethermind is a team of world-class builders and researchers. We empower enterprises and developers worldwide to access and build upon the decentralized web. Our work touches every part of the Web3 ecosystem, from our Nethermind node to fundamental cryptography research and application-layer protocol development. We’re always looking for passionate people to join us in solving Ethereum’s most difficult challenges. Are you interested? Check out our job board https://nethermind.io/company/

Staking
Permissionless
Liquid Staking
Ethereum
Decentralization

--

--

Nethermind
Nethermind.eth

Written by Nethermind

174 Followers
Editor for

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams