This is a proposal to create a special Validator Committee that will have the power to perform a forced exit of the validators run by external node operators. It is a crucial proposed component of StakeWise Metro and is the final decision to make before we start onboarding external node operators. Read on to learn more about the Committee and its role for StakeWise. We highly recommend leaving your comments on this one because it may prove controversial.
Motivation
A common criticism of decentralized staking protocols is that their users must trust external node operators to comply with DAO’s requests to share MEV rewards and unstake ETH from the validators. The reason for this is the node operators controlling the validator keys, which gives them influence over MEV- and exit-related decisions. Especially at a large scale of decentralization, this issue puts protocols at risk of offering a significantly lower yield and not being able to process customer requests to withdraw the funds from the validators, leading to the de-pegging of token representations of staked ETH. It is the opinion of the StakeWise core developer team that any plans to decentralize the architecture of StakeWise must consider this risk and appropriately mitigate it, all while remaining as permissionless as possible.
As a solution to this problem, we suggest the creation of a Validator Committee that has the power to eject the node operators that don’t comply with the DAO’s requests to share MEV rewards or exit the validators to allow users to withdraw ETH.
We expect that the existence of the Validator Committee will prevent malicious behavior by creating a disincentive to misbehave. Instead of wielding unlimited power over the validators, the operators will be forced to comply or be removed from StakeWise forever.
Let’s examine a couple of scenarios to make the role of the Validator Committee clear:
i) A malicious node operator stops sharing MEV rewards with StakeWise DAO. The Validator Committee is summoned to eject the validators run by the node operator from the network. The ETH from ejected validators is either immediately available for reinvestment into new validators by the DAO, or will become available for reinvestment once withdrawals are enabled.
ii) A malicious node operator refuses to exit the validators it is hosting despite the request to exit that was submitted by the StakeWise DAO. The Validator Committee is summoned to eject the validators run by the node operator from the network. The ETH from ejected validators becomes immediately available for withdrawal by the interested users, with any unclaimed amount being reinvested into new validators by the DAO.
We believe that having such leverage over the node operators will ensure only appropriate behaviour on their end. It would also mean that StakeWise becomes the only protocol to have protection against the node operators abusing their power – something that could prove very useful down the line.
Specification
The power of the Validator Committee to exit the validators of mischievous node operators will stem from its ability to recreate the validator keys of said operator, and use them to sign the validator exit request on the Beacon Chain.
The order of steps would be the following:
- Node operator uses the StakeWise CLI to create the validator keys it plans to run for the StakeWise DAO
- The StakeWise CLI will automatically split the keys into shards and ask the node operator to send each shard to the corresponding Committee Member
- Each Committee member will verify the validity of the shard using their private key
- Upon confirmation of the validity of the shards from all the Committee members, the node operator will be able to proceed to the next step of onboarding
- 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
The Committee will be composed of the individuals and organizations that have the most alignment of interest with the protocol. We propose to have 5 committee members, of which 2 would come from the StakeWise core team, 2 would come from some of the biggest SWISE holders, and 1 would be an independent party. As it stands, the three external parties would be gleb0x.eth, alirun, and ottodv.
The transaction required to create the Validator Committee is the following:
[
{
"to": "0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41",
"operation": "0",
"value": "0.0",
"method": "setText(bytes32,string,string)",
"params": [
"0xdf35e32bab5d1e75e6e40e4bcf4d3047a8f6fc46bf73a793d00f32c5a6bb2357",
"oraclesconfig",
""
]
},
{
"to": "0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41",
"operation": "0",
"value": "0.0",
"method": "setText(bytes32,string,string)",
"params": [
"0xdf35e32bab5d1e75e6e40e4bcf4d3047a8f6fc46bf73a793d00f32c5a6bb2357",
"operators_committee",
"ipfs://QmcxbqLSC1NvjfCDPGMP93R2zRdrUMH9Ge5pFarDtM53iM"
]
},
{
"to": "0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41",
"operation": "0",
"value": "0.0",
"method": "setText(bytes32,string,string)",
"params": [
"0xdf35e32bab5d1e75e6e40e4bcf4d3047a8f6fc46bf73a793d00f32c5a6bb2357",
"snapshot",
"ipfs://QmSnDnF4Y7QXx6gQWAaKjZXVKzeWLLoRnGHxJBFj1ATy65"
]
}
]
Risks
The main risk associated with having the Validator Committee is precisely its power to recreate the validator keys. It means that either intentionally or unintentionally – in a situation where enough of the Committee members’ private keys and shards are compromised - the Committee has the means to slash all the protocol’s validators. It represents a meaningful threat to decentralization of power in our protocol, even if in good faith, as well as an operational security risk.
As means of mitigating the risks, we would expect the Committee members to adhere to the highest standards of operational security like keeping the private keys and shards in cold storage, itself kept in a secure place. Having a diverse set of Committee members also adds a level of safety.
Discussion
What does the StakeWise DAO think of this proposal? The core team has been at the crossroads internally regarding the subject. On the one hand, we see a meaningful risk that our protocol may come across a malicious node operator who refuses to obey DAO’s requests to exit the validators when the time comes. However, we also recognize that the power of mere 5 individuals to hurt all the validators may be sufficient for some in the community to reject the idea of a Validator Committee. Hence, we ask all interested parties to leave their thoughts in this thread, so we could have a temperature check on whether this proposal should go through.
