Worth expanding a little on the Discord post, and explaining what this suggestion is and what it is not.
The idea is to allow some way to provide a social consensus system that restricts the “change withdrawal credentials” operation for a given set of source withdrawal credentials to only be considered valid if they have a specific target withdrawal credential.
The change withdrawal credentials operation is not yet fully specified, but is likely to have at least the following fields:
- validator index
- current withdrawal public key
- proposed (execution layer) withdrawal address
- signature by withdrawal private key over prior fields
In a situation where multiple users have access to the withdrawal private key it is impossible for the network to differentiate the “legitimate” holder of the key from the “illegitimate”. However, there are signals that could be considered in a wider sense. The most commonly cited one is that the legitimate holder is also in control of the execution layer deposit address, in which case the suggestion is to require the proposed withdrawal address to match the deposit address. This is not something that can be enforced in-protocol, partly due to lack of information on the beacon chain about the deposit address and partly due to the fact that this was never listed as a requirement so it is possible that deposit addresses will no longer be under the control of the legitimate holder of the withdrawal private key. But it may be possible for individual nodes to locally restrict the changes they wish to include in blocks they propose, and which they propagate around the network.
The proposal is as follows: beacon nodes take an additional parameter pointing to a file. That file contains multiple lines of the format withdrawal credentials,withdrawal address where each line is a restriction on the contents of withdrawal change operations. Specifically:
- if a node is presented with a withdrawal change operation via the REST API it will reject it if there is a line in the file that contains a matching withdrawal credentials and the related withdrawal address does not match that in the operation
- if a node is presented with a withdrawal change operation via P2P it will drop it if there is a line in the file that contains a matching withdrawal credentials and the related withdrawal address does not match that in the operation
Note that these restrictions do not apply to withdrawal credential change operations in blocks. If an operation has been included on-chain it is by definition valid regardless of its contents.
It is critical to understand that this is not a consensus change. Nothing in this proposal restricts the validity of withdrawal credential change operations within the protocol. It is a voluntary change by client teams to build this functionality in to their beacon nodes, and a voluntary change by node operators to accept any or all of the restrictions suggested by end users.
Because of the above, even fully implemented it will be down to chance as to which validators propose blocks, and which voluntary restrictions those validators’ beacon nodes are running. Node operators can do what they will to help, but there are no guarantees of success. Those who wish to put time and resources in to building this or any similar proposal should be remain aware of this fact at all times.
I hope that I have made it clear that this is very much a voluntary effort on the part of all involved. I don’t see this being driven by anyone in the core dev team, as their focus will rightly be elsewhere. Those that are affected by this situation will need to organize and at the least get together a plan for doing the following:
- formalize the above in to a clear proposal of exactly what they want from client teams and node operators
- approach the client teams regarding the feasibility of them doing the required work
- approach the major node operators (i.e. staking services) regarding their requirements for adding entries to the list
- build a list, with relevant proofs as required by the major node operators
The good news here is that the community as a whole will want to help those who have genuinely lost control of their withdrawal keys. But there will no doubt be contentious issues along the way, not least the general premise of what I am suggesting above. Again, at this point I suggest that those affected organize early and so are ready to present their best case to the client teams once they start to look at the capella hard fork.
(And for the record: I am not in the situation described above. I’m outlining this because it is the result of various conversations had on Discord and elsewhere with affected parties, and as an attempt to help them find a resolution. Equally, I am not championing or endorsing this proposal; that is up to those affected.)