With the upcoming Capella hard fork, Ethereum stakers will have an option to set their withdrawal address “BLSChangeToExecution” for the first time if not already set. Consensus Layer Withdrawal Protection “CLWP” EIP-4736 is a volunteer project which aims to help Ethereum validators who either know or have concerns that their validator seed phrase has been compromised. CLWP will broadcast their change request at the hard fork to help beat an attacker.
We are asking Lido node operator to voluntarily load the 2000+ validator signed withdrawal address messages we have collected on our GitHub site on a beacon node (Prysm, Lighthouse, or Lodestar):
These verifiable submissions can be loaded by following the instructions under the README for volunteer. I am happy to help answer any questions regarding this project. If anyone has a compromised validator seed phrase, we are happy to try to provide help.
Thanks for raising in discord and the forums – I’ve also copied the message in the node operators’ chat and they’re invited to take a look and participate at their discretion.
@benjaminchodroff thanks for sharing!
I recall a while back there were conversations about delaying other BLS → EL withdrawal address changes to prioritize this.
Lido itself has a large number of these changes to make for its own node operators. Would your recommendation be that Lido NOs load the signed messages from CLWP, process those, and then start processing the Lido credential changes?
@timbeiko Appreciate the consideration from Lido on CLWP. Ideally, any Lido local or shared submissions may be loaded first, and then proceed to load the CLWP submissions before the Capella hard fork. The order will not matter for Lido as their validator seed phrases have been stored securely and/or using multi-signature support.
A safe plan would be:
- Now: Any requested early Lido change credentials may be loaded first locally on Capella compatible beacon nodes that support submissions in advance (Prysm, Lighthouse, Lodestar)
- Next, and before mainnet Capella: Lido Node operators may optionally load CLWP change credentials locally on Capella compatible beacon nodes that support submissions in advance (Prysm, Lighthouse, Lodestar).
- After mainnet Capella: Any remaining Lido change credentials not previously shared may be broadcast at the operator’s discretion on any Capella client (including Teku or other clients not supporting local caching of BLSChangeToExecution). All clients which have loaded Lido and CLWP local submissions will begin gossiping to peers their submissions.
The compatible beacon nodes which support local caching of these BLSChangeToExecution messages (Prysm, Lighthouse, Lodestar) will gossip the cached messages after the Capella hard fork, and immediately reject gossip from any peers that conflict with these submissions. This may give the Ethereum community an edge against an attacker using a compromised validator seed phrase attempting to propagate a conflicting message.
How does CLWP check against the possibility that a malicious actor may actually be using the CLWP to “front-run” credentials rotation before an unsuspecting victim (e.g. who is not aware of CLWP) has the chance to rotate them “normally”?
I see mention of Kleros on the main site (https://clwp.xyz/), is the purpose of it to serve as a mechanism for disputes if e.g. multiple parties have submitted rotation requests for the same set of credentials? I guess the primary problem is thus “make sure that as many (possible) victims have seen / heard of CLWP” so having the initiative repeated in as many places is definitely a good thing.
@Izzy Great question. We are aware that a bad actor could try to use CLWP to submit a compromised address, but it is not in their favor. The transparency of the CLWP GitHub and Kleros submission process gives any victim an early chance to see and contest a submission before it goes live at Capella. Without CLWP, a bad actor will simply submit the attack silently on their own nodes and likely win against a victim at Capella. We kept CLWP as open as possible to encourage any bad actors to reveal their attack early to give the victim a last chance to beat the attack at Capella.
For this reason, we have stopped all new submissions via GitHub on 2/28 to give any potential victims ample time to contest the submissions prior to the Capella hard fork. New and contested submissions will only be allowed via Kleros where it requires staking 0.474 ETH for 7 days while the submission is verified. An attacker would be foolish to try this process as they will likely lose their staked ETH if the submission is invalid or contested with evidence. CLWP on Kleros gives victims an opportunity to submit additional evidence - such as a signature from their deposit address or fee recipient address - that proves they are a legitimate validator owner with optional on execution layer chain data.
You may see the Kleros submissions and additional evidence here:
Thanks for the additional info Benjamin, that makes a lot of sense and the possibility for additional evidence from “related” addresses that however aren’t necessarily also compromised is a neat idea on how to tackle the possible dispute complexity.