A validator that has lost its withdrawal key and is still active under his validating key will definitely want to stay active for as long as possible because he continues to earn when proposing a block on his fee recipient address
This is interesting so I dug through mainnet data a bit. A 0x00 validator earns EL rewards of about 0.04 ETH per year on average (roughly 0.02 on median) while earning CL rewards of 0.77 ETH on average and 0.81 on median per year into the unwithdrawable balance. Anyone operating only for the EL rewards is operating at a loss, so the stay-active incentive really only applies to large entities running many lost-key validators from shared infrastructure.
Also on the ratio of crowd (1) and crowd (2). We know crowd (1) has roughly 1,400 validators by DeprecateBLS’s own registry, and the remaining ~7,300 live validators we cannot classify. Even taking the registry at face value, the convertible crowd likely outnumbers the lost crowd several times over, and blocking the EIP to protect crowd (1) forfeits the conversion nudge for crowd (2).
And blocking the EIP does not actually preserve crowd (1)'s income. Every PQ registry design force-exits validators that never register, so opposition buys roughly two extra years of ~0.04 ETH per validator per year and nothing else, while the cost is arriving at the PQ fork with 9,000 unresolved entries and increased friction for the PQ transition. Sounds to me the cost of blocking outweighs the benefit.
Post exit, those unwithdrawable funds become a honeypot for quantum (which goes against the quantum motivation)
It is the opposite. These funds are quantum proof because the credential is a sha256 commitment and the withdrawal pubkey is never revealed on chain. The exposure only begins the moment a BLSToExecutionChange is broadcast after quantum computers arrive, since the message reveals the pubkey. So keeping the path open into the PQ era means designing a PQ version of BLSToExecutionChange, which I do not know what it would look like, and spending effort to design one is not worth it when usage is already this low.
I cannot imagine a setup where the actors are different and don’t have a line of communication of some sort to coordinate on such EIP rollout.
This is an assumption we cannot verify. It would need to hold for all ~9,000 validators for the payout rule to be safe, and we cannot make protocol decisions based on that.
starting Hegota (or 6 months after Hegota or later, giving people enough time to prepare), when a 0x00 validator propose a block this triggers an exit to his fee_recipient address?
I see a couple of issues:
- fee_recipient is set by the signing key, so it just bypasses the withdrawal key with an extra step
- You can delegate your validator operation to any operator by handing over the signing key. This proposal allows operators to steal the fund by setting fee_recipient (and thus the withdrawal address) to anyone they like
- The payload’s fee_recipient is often not the proposer’s address. Mev-boost for example sets fee_recipient to the builder’s address
- What do you do with the offline but not exited 0x00 validators that will never propose?
