The Extremely Lean Chain

[OisinKyne]

I appreciate the post, and there are a lot of interesting aspects, for now I’ll list my worries/concerns and maybe you’ll take the time to address some of them.

• I think we over-index on the potential for a solo staker to take part in the chain, and under-index on the risks of a small minority controlling the chain. Its the ‘mountain man’ idea but in PoS. Do you think this design might hide centralisation more than it enables decentralisation? Imo it hides centralisation by way of key rotation, withdrawal credential hiding, etc. It doesn’t really enable decentralisation (other than maybe taking pseudonymity to anonymity). A particular concern of mine is that so far Lean intends to drop the ability to stake in groups. This has been a design goal since ~2018 for the chain, and not one that we should silently drop. Would you be willing to explain why its no longer a design goal, or to commit to working on an architecture until we can keep it?

@dankrad

One of the design goals of Ethereum 2.0 is, however, to make the spec MPC-friendly, so that it is easy for (a) validator pools to be set up in a secure, trustless manner and (b) allow one-party validators to spread their secret across several machines, reducing the risk of secrets getting compromised.

• If we are losing transparency into the health of the validator set, how might we assure certain levels of decentralisation? I believe CROPS should apply to the CL and not just the app layer, and have campaigned for the EF to set a minimum tolerable Nakamoto for the chain. 1) would you go on record as to your minimum tolerable nakamoto, and aspirational target nakamoto? (Mine are 10, 100) and 2) have you any ideas how we might track these in a world where we lean very hard into unlinkability of the validator set?

• Although I don’t believe social slashing is a credible defence of the network under compromise because of the principal agent problems involved, but how might we enable them given your option 1) + 2) for enabling slashing of previous pubkeys. IIUC, in option 2 (and 1), this covers pre-existing on-chain slashings. Is there any ability to socially slash in this paradigm other than in the ~24 hour window of a pubkey lifetime? (Which would be too short a window to coordinate).

  • Related point, what do you think of ‘social exit’ instead of social slashing? Imo force exiting malicious validators is far more mild of a punishment, and thus far more realistic of a penalty we could socially coordinate to execute. I don’t think its likely we can coordinate to destroy a large amount of retail ether for actions taken by their delegates. I do think we could co-ordinate to kick them out of the attester set without the same amount of blowback. If you agree maybe we could build out the tech to social exit with a coordinated config change to clients rather than code changes?

Thanks!