-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Trustless" definition for pooled staking options #6452
Comments
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:
The first two parts are already considered within the current definition and this should continue to remain the case.
The second two points are not currently considered and yet provide two areas where trust can fall upon an individual:
Addressing your specific questions @wackerow: Does this mean we should consider all of these services trusted until withdrawals are enabled by the protocol? What mechanisms exist today for non-node operating pooled stakers to force exit a validator balance? Which services use these mechanisms? How should this change over time? 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? |
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.
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" 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.
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:
|
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 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.
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.
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. |
Another thought with slight addition
|
@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". |
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. * 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
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. |
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. |
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.
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.
Fully agreed. |
This issue is stale because it has been open 45 days with no activity. |
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
And this seems to be where we left off before in terms of a potential update to the "trustless" definition:
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 |
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. |
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"?
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:
|
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.
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. |
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:
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:
|
This issue is stale because it has been open 30 days with no activity. |
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 issueThe 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 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. |
This issue is stale because it has been open 30 days with no activity. |
github actions |
100k eth |
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:
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.
The text was updated successfully, but these errors were encountered: