search

ethereum / ethereum-org-website

Ethereum.org is a primary online resource for the Ethereum community.
https://ethereum.org/
MIT License
5.07k stars 4.81k forks source link

"Trustless" definition for pooled staking options #6452

Open wackerow opened 2 years ago

wackerow commented 2 years ago

Describe the issue Recently our staking content was updated to include more details about different ways to stake, and the products/services that can be used to help in each of those categories. In attempt to prevent/limit subjective bias, some objective attributes were assessed for these products/services.

One of these attributes was a "Trustless" indicator for pooled staking options, and some feedback has suggested it its worth discussing publicly how this label is defined and how it applies to pooled staking services. This issue can be used as a place for discussion around how this term should be defined to best help inform users, and also for presenting arguments for/against the currently listed services being labeled as "Trustless" or not.

Currently this label is defined on the site as:

Service does not require trusting any humans to custody your keys or distribute rewards

The goal of this label was to indicate to users which staking pools rely on trusting someone to either hold onto your keys, or to manually distribute rewards.

This can be confounded by the fact that currently any staked ETH is locked until Shanghai, and although a validator can exit, these funds can still not be retrieved.

I would love to hear input from others regarding these questions, thoughts on this definition in general, and also any input (especially from team members of these projects) regarding how specific products would fit in here. If supporting evidence can be provided that would also help in the discussion and help guide where we go from here.

Jstar101 commented 2 years ago

I agree that it is important to define each indicator as specifically as possible in order to remove any uncertainty around definitions which could leave room for subjective bias. I also agree with the high-level definition of trustless, meaning key steps are taken to remove human/centralised control over pool funds. In my mind, there are 4 key parts to consider: 1) The custody of the keys 2) The distribution of rewards 3) The ability for non-node operating pooled stakers to ensure funds are accessible when requested 4) The ability for a protocol to be changed/smart contracts upgraded by a centralised/controlled

The first two parts are already considered within the current definition and this should continue to remain the case.

1) Custody - tokenisation of deposited ETH alongside the ability for withdrawal credentials to be set by an upgradeable smart contract. 2) Distribution of rewards - a network of decentralised oracles which determine the number of rewards to be minted and automatically distributed at each time period.

The second two points are not currently considered and yet provide two areas where trust can fall upon an individual:

3) Node operators and staking pools have misaligned incentives. Operators want to keep running validators in order to make revenues, however there will be times when the pool needs to return funds to its users and will be required to wind down validators to do so. The risk is that node operators refuse to shut down validators on request and can effectively hold funds hostage. Procedures should be in place to ensure funds can be returned to users on-demand without a human/node operator having the ability to stop this. 4) All of the above points rely on smart contracts and hence the final requirement of a trustless system should require that smart contracts/key protocol parameters cannot be upgraded unless by a decentralised entity (such as a DAO).

Addressing your specific questions @wackerow:

Does this mean we should consider all of these services trusted until withdrawals are enabled by the protocol? I think it is dangerous to consider all staking services as trusted until withdrawals. Pools which do not comply with the agreed trustless definition have fewer incentives to improve their network if they will be auto-marked as trustless for the time being. It will also potentially mislead stakers who believe they are staking with a trustless system which actually ends up not trustless after withdrawals are enabled.

What mechanisms exist today for non-node operating pooled stakers to force exit a validator balance? In the case of StakeWise, the DAO controls the exit signatures of its validators meaning that the DAO can force close validators should the node operators refuse to do so.

Which services use these mechanisms? I can only give StakeWise as an example here as it is the only platform I am aware of with the ability to force close validators. I will leave it to other networks to provide information on how they handle the potential hostage of pool funds.

How should this change over time? The Ethereum network is continuously evolving and the specs are always changing. Until there is an upgrade to the specifications which can improve the implicit trustless nature of each pool (such as when withdrawals to a smart contract were enabled in Mar21), then nothing can change in my opinion.

Does holding keys to a liquidity token affect the application of this label in any way? How do we differentiate the power a user has by holding keys to an ERC-20 liquidity token vs signing/withdrawal keys for a validator? The ERC-20 derivative tokens represent ETH held in validators and provide each holder with the right to access that ETH. Holding a derivative token is one thing, actually having the ability to access the underlying asset is another. It still stands that the underlying assets (pool funds) need to be accessible in a trustless manner.

wackerow commented 2 years ago

I think it is dangerous to consider all staking services as trusted until withdrawals. Pools which do not comply with the agreed trustless definition have fewer incentives to improve their network if they will be auto-marked as trustless for the time being. It will also potentially mislead stakers who believe they are staking with a trustless system which actually ends up not trustless after withdrawals are enabled.

My question here asked about defaulting to "trusted" not "trustless" until withdrawals are enabled... Meaning, none of them are trustless since we still require humans to finish the job. In either case, I agree with your sentiment, which seems to be that even though it's not perfect, there are still objective measures that can be taken to make things as trustless as possible, and we should differentiate that.

In the case of StakeWise, the DAO controls the exit signatures of its validators meaning that the DAO can force close validators should the node operators refuse to do so.

This is an interesting point about the role a backing DAO plays in all of this, and raises a couple other questions. @Jstar101 So it sounds like an individual cannot force exit a validator to get their ETH back, but the DAO can vote to exit a validator, thus overriding the hijacking threat from a node operator... but this still relies on the DAO to approve this, correct?

Existing "Trustless" definition being used here: "Service does not require trusting any humans to custody your keys or distribute rewards" ...Is a DAO considered a "human" here? What if the DAO only has 2 members?

I generally feel like having a DAO be behind forced validator exits and smart contract upgrades should be acceptable under our label of "trustless." Not sure if we should attempt to differentiate DAOs that are pragmatically centralized vs more decentralized and evenly distributed, but open to thoughts on this.

Until there is an upgrade to the specifications which can improve the implicit trustless nature of each pool (such as when withdrawals to a smart contract were enabled in Mar21), then nothing can change in my opinion.

Right, so my question here is more should this be something that changes in time as network changes get rolled out, and it sounds like you're implying yes. I agree we should try to better define this for the current state of the network, but it helps us improve the current criteria if we know future upgrades may adjust this as new features are enabled. In other words, we can be more lenient right now, but once the tech improves, expectations go up.

Overall @Jstar101, thank you so much for the detailed reply. I really appreciate you weighing in on your thoughts on how to break down this term and how we can define it's inclusion criteria.

I like the 4 categories you broke out, and think we could use them to improve the current definition a bit.

Simple suggestion:

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO.

Jstar101 commented 2 years ago

My question here asked about defaulting to "trusted" not "trustless" until withdrawals are enabled... Meaning, none of them are trustless since we still require humans to finish the job. In either case, I agree with your sentiment, which seems to be that even though it's not perfect, there are still objective measures that can be taken to make things as trustless as possible, and we should differentiate that.

Oh yes, my brain just assumed it said "trustless"! We're on the same page regarding the sentiment though - some providers do more than others to improve the trustless nature of their platforms which I believe should be reflected.

This is an interesting point about the role a backing DAO plays in all of this, and raises a couple of other questions. @Jstar101 So it sounds like an individual cannot force exit a validator to get their ETH back, but the DAO can vote to exit a validator, thus overriding the hijacking threat from a node operator... but this still relies on the DAO to approve this, correct?

This is correct. At the end of the day, if you are aiming to provide the most "trustless" service which includes the ability to force close validators, this power needs to lie with someone or some entity. A DAO feels like the natural choice here given the (hopefully) decentralised nature of the entity.

Not sure if we should attempt to differentiate DAOs that are pragmatically centralized vs more decentralized and evenly distributed, but open to thoughts on this.

This is a very important point and the same should be considered for the set of oracles used to update the staking rewards. Categorising what is or isn't 'decentralised' is fundamentally difficult and subjective. Providing clear steps are taken to remove control from a centralised entity (or group) should be sufficient in the case of both the oracle set and the DAO, although I fully appreciate this leaves the door open for subjectivity.

Simple suggestion:

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO.

I feel this is a pragmatic and considered definition (although I am biased as it is based on my own recommendations). I would encourage members of other staking providers to opine here and highlight steps their protocols have taken to improve its trustless nature. Specifically, stakefish and Rocket pool as these are the other 2 entities currently marked as trustless. As I do not know the intricacies of these platforms, I am unable to comment on whether they would still be considered trustless based on the newly suggested definition.

wackerow commented 2 years ago

Another thought with slight addition

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO, but cannot rely on trusting an individual node operator.

isidorosp commented 2 years ago

@Jstar101 Does the stakewise DAO control the validator exit signatures? I thought it was a committee. Can the DAO (i.e. an onchain vote of token holders) trigger a validator exit, or does it require the voluntary action of committee members to agree to do so?

Jstar101 commented 2 years ago

@Jstar101 Does the stakewise DAO control the validator exit signatures? I thought it was a committee. Can the DAO (i.e. an onchain vote of token holders) trigger a validator exit, or does it require the voluntary action of committee members to agree to do so?

Sorry, very good point, I miss-spoke/wasn't particularly clear above. Thank you for flagging. It is the validator committee (VC) which controls the validator exit signatures and which acts upon the direction of the DAO. The process is outlined as "Whenever requested by the DAO, the Validator Committee members will use their respective shards to recreate the validator keys of the misbehaving node operator and use it to sign the exit request in the Beacon Chain".

isidorosp commented 2 years ago

Cross-posting my thoughts here from the discord thread:

In my personal opinion there is no strictly trustless on-chain staking protocol currently (my view may be a bit unorthodox, but I detail it here). All of them require some level of trust, either in node operators (who control validator keys and therefore validator exits), or a committee / threshold encryption signatories (either for BLS withdrawal keys or for pre-signed validator exit messages) related to withdrawals / validator exits. A committee holding the exit sigs is analogous to the horcrux / threshold encryption of BLS keys, so I don't see a difference there. A DAO holding this functionality can be different*, but it's not something that's implementable currently

* There's a separate discussion regarding to what extent a DAO itself triggering exits/withdrawals is trustless or somewhat trustful, but I think when we consider how the word is generally used it's probably safe to (practically speaking) call that trustless, provided the DAO isn't permissioned and anyone can in theory participate.

If we have a clear definition, like this from @wackerow

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO, but cannot rely on trusting an individual node operator.

of what criteria constitute "trustless" in this specific page, I think we can create a matrix that breaks this down point by point for each protocol so there is clarity.

Jstar101 commented 2 years ago

The various elements of 'trustless' fall upon a continuum. The question I ask myself when it comes to withdrawal keys is what is safer - a group of people/DAO in control of validator exits or an individual/single entity? A protocol that can guarantee access to pool funds or one that relies entirely on a third party to access pool funds?

Ensuring a committee, acting under instruction from a DAO, can force close validators and regain access to pool funds is a clear winner here in my opinion. Granted, the risks of permissioned node operators holding pool funds hostage are far less than for permissionless nodes. Despite this, the risks are always there, especially post Merge when staking becomes much more lucrative for validators and it will be the node operators themselves who maintain full control over MEV rewards.

It is also important that the various staking providers are incentivised to continuously look to innovate and improve their protocol - this will benefit the Ethereum ecosystem as a whole. Having a more strict definition of trustless from Ethereum.org will encourage platforms to improve their trustlessness to ensure they get their 'green tick'. This way protocols are incentivised to uphold, and hopefully improve upon, the trustless standards of their peers.

isidorosp commented 2 years ago

Ensuring a committee, acting under instruction from a DAO, can force close validators and regain access to pool funds is a clear winner here in my opinion. Granted, the risks of permissioned node operators holding pool funds hostage are far less than for permissionless nodes. Despite this, the risks are always there, especially post Merge when staking becomes much more lucrative for validators and it will be the node operators themselves who maintain full control over MEV rewards.

I don't think it's a bad mechanism but I'm not sure I'd call it a clear winner. While it adds a vector for possible recovery there are complications. a) The recovery mechanism might make the situation worse by forcing action (vs allowing the dispute to be resolved more slowly over time). Because the NO still has access to the validator key, if we're saying that the "committee" kicks into gear when an NO refuses to exit the validator, then this basically forces a "ransom attack" scenario to play out where the committee will race to exit the validator before the malfeasant NO slashes the validator instead (in an attempt to extort ransom for not doing so). You can argue that there's a negligible chance of this happening (due to risk of reputational damage) since this is currently only used in the case of permissioned NOs with aligned incentives, in which case I'd agree and reiterate that there's also little reason to have the exit-by-committee mechanism for the same reason. b) It actually introduces another attack vector whereby the compromise of N/M committee members means that the validator (all validators in fact) can get exited by a malicious party (or set of parties), thereby opening up another ransom or DoS attack vector.

A protocol that can guarantee access to pool funds or one that relies entirely on a third party to access pool funds?

You're still relying on a set of distinct permissioned third parties here, just a different set of third parties (the committee and/or the operator vs just the operator). Sometimes it's worth it, sometimes it's not, we can argue the finer points about whether one is more trustless than the other -- but I find it difficult to agree that one is trustless and the other isn't.

It is also important that the various staking providers are incentivised to continuously look to innovate and improve their protocol - this will benefit the Ethereum ecosystem as a whole. Having a more strict definition of trustless from Ethereum.org will encourage platforms to improve their trustlessness to ensure they get their 'green tick'. This way protocols are incentivised to uphold, and hopefully improve upon, the trustless standards of their peers.

Fully agreed.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 45 days with no activity.

wackerow commented 1 year ago

Hey folks, how time can slip by. Some good conversation above regarding this topic, and thank you all for chiming in with your thoughts...

Since this post we've seen a successful Merge upgrade, and are now a couple weeks away from Shanghai/Capella which will enable staking withdrawals. This of course will shift the landscape once again in terms of what is possible as far as trust mechanisms.

I think this is a great time to revisit this and see how we could adjust these criteria to fit a post-merge post-withdrawals staking environment.

As a reminder of what is currently on the /staking/pools/ page:

Service does not require trusting any humans to custody your keys or distribute rewards

And this seems to be where we left off before in terms of a potential update to the "trustless" definition:

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO, but cannot rely on trusting an individual node operator.

The main addition here centers around having some form of distributed control over the ability to exit a validator.

Few key points that have been raised:

At this point, I'm curious if people would feel comfortable using the above modified definition for "Trustless" which includes the caveat for DAOs, or if there are additional suggestions to make this even more clear.

Feedback welcome, but if no reasonable opposition, I'd like to circle back to this and update the definition to the one noted above, for what it means to be a "trustless" pooled staking service. With that we'll need to reevalute the products currently being listed to make sure information is up-to-date and accurate.

Also, with Shanghai/Capella planned for about three weeks from now, any other thoughts or comments related to how this may impact pooled staking services is welcome. Personally don't see this making too much of a difference, as staking withdrawals obviously don't remove the potential for slashing, and the ability to set a withdrawal address has been present for quite some time... Shanghai will simply start distributing the excess funds (>32 ETH) and also allow exited validators to actually receive that ETH back to whatever address has been provided.

cc: @Jstar101 @isidorosp -- Encourage others to share and/or chime in as well

Jstar101 commented 1 year ago

Appreciate you following up on this thread @wackerow!

My position on this still stands and agree the wording should be updated to include the ability to exit a validator via a DAO. This becomes even more important post-Shanghai/Capella. Stakers will automatically believe that because Ethereum withdrawals are enabled, staking pools will also have the ability to withdraw assets at will, which is sadly not the case.

For permissioned operator sets like Lido, it is certainly less of an issue given node operators would experience reputational damage for holding funds hostage. For permissionless operator sets, however, this can be very problematic and heavily impact a staking pool's ability to natively un-stake their users.

I believe 0x03 Withdrawal Credentials are going to be prioritised by the EF, which will be a big step in the right direction for trustless staking pools. Until this upgrade is in place and staking pools adopt it, we must rely on exit signatures as the highest standard for 'trustless' staking.

I would personally stay away from complicating the "boolean" indicator much further, it is important that users can quickly understand how well each platform performs in each category. There could be an argument for adding an Orange indicator alongside the existing red and green. For example, StakeWise would be green with the new trustless definition, Lido could be Orange given the operators are known/permissioned and the hostage risks are less, and Rocket Pool would be red.

isidorosp commented 1 year ago

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO, but cannot rely on trusting an individual node operator.

There's a bit of lack of specificity here w.r.t what "handled by a DAO" means. If it's handled by a multisig (or a committee) that in theory represents / executes according to the will the DAO (but technically cannot be forced to), is that still handled by the DAO? Or do we mean "requires a full DAO vote"?

  • Alternatively, we remove the "boolean" nature of this indicator ("trustless", or not), and instead break this category down further to help describe the actual mechanisms being used. This could provide more clarity, but may also lead to confusion and increased overhead in maintaining product details over time.

I think this is actually a good idea. (EDIT: Especially since contract upgrades are probably the most important thing here) Education / information is the best route, and enabling users to a) identify that there's nuance and b) providing them resources on how to dig deeper is probably what's best. It would certainly be immensely confusing to the average reader if e.g. Rocketpool was once green and now becomes red. I would suggest to break trustless into sub-categories:

wackerow commented 1 year ago

There's a bit of lack of specificity here w.r.t what "handled by a DAO" means.

Fully agree that "handled by a DAO" remains ambiguous. Is anyone aware of a mechanism for a DAO vote to automatically trigger (via smart contract) an exit message to be broadcast? I am personally unaware of one, but would love to know if it exists.

Or do we mean "requires a full DAO vote"?

I think this is more in line with what is being discussed here, but also brings up more questions of what is considered a "full DAO vote"? Enough for a quorum? And also as you alluded to, all DAOs are not alike, and are programmable... a "DAO" can be highly centralized, or not.

As to breaking this down further, I would certainly love to get some UX design input here (cc: @konopkja). Huge advocate for education, but there are persistent trade-offs between simplifying concepts for users at the risk of not properly informing, and adding more information at the risk of overwhelming or confusing.

I could see us flipping the "trustlessness" indicator to instead discuss "trust assumptions" for each project. This way we're not trying to brand anything as "zero trust", but instead highlighting areas where trust is required in each setup.

Will also reiterate the challenges involved in maintaining a more detailed breakdown of these products. Aspects of these products can change, new products are introduced, and the more detail we try to go into on a 3rd part site like ethereum.org, the more likely the content will be out of date and inaccurate, as bandwidth is limited. A common approach on this site is to offer an overview that is less likely to change, and direct users to the canonical websites for these projects for the latest information.

Jstar101 commented 1 year ago

For further clarity on the forced validator process, this will be controlled by the oracles of StakeWise V3 (the same ones that relay the consensus rewards etc...). In an ecosystem with potentially thousands of anonymous node operators, requiring a DAO vote to force close set validators would be impractical. Instead, when a user requests to un-stake, the oracles will submit the exit signatures to spin down the necessary validators, fully automating the process.

Regarding the definition, I agree that 'handled by a DAO' is not ideal in this case.

The latest trustless definition we have is:

Service does not require trusting any humans to custody your keys or distribute rewards. Contract upgrades or forced validator exits may be handled by a DAO, but cannot rely on trusting an individual node operator.

It is super important for a trustless protocol that contract upgrades require a DAO vote (and even better, some form of dual governance is in place, like stETH on Lido or Vault operators on StakeWise). We should maintain some reference to a DAO for this part.

For the exit signatures, I think we should instead remove the reference to a DAO, but instead, just refer to the protocol itself.

For example:

Service does not require trusting any humans to custody your keys, distribute rewards or handle validator exits. Contract upgrades require approval from a DAO.

github-actions[bot] commented 5 months ago

This issue is stale because it has been open 30 days with no activity.

wackerow commented 4 months ago

Hey folks, circling back...

Couple notes on completed upgrades since original post:

To my knowledge this means a pre-signed exit message can be generated to provided some additional protections over staked funds, since anyone with this message could force exit/withdraw the staked funds to the preset withdrawal address.

Getting back to the original issue

The indicators on these products are primarily for non-node-operating pooled staking participants, and are meant to shed light on the guarantees they hold over being able to claim the actual ETH locked in the Beacon Chain while staking with any given provider.

@isidorosp @Jstar101 Would either of you say at this point that there is any truly trustless way for someone who holds a pooled staking token to guarantee the ability to redeem (not trade) for the underlying staked ETH, without relying on another person?

If there is a way, this is how I think we should differentiate the products on the metric... if there is not, we could consider just making a general cautionary note about that and consider removing this from the cards entirely for /pools.

Separately, I see some discussion above about the upgradability of contracts, etc... I would argue this is also important, but would probably set that aside as a separate issue beyond just this "Trustless" indicator.

github-actions[bot] commented 3 months ago

This issue is stale because it has been open 30 days with no activity.

Romansharar commented 3 months ago

github actions

Romansharar commented 3 months ago

100k eth

github-actions[bot] commented 2 months ago

This issue is stale because it has been open 30 days with no activity.