A few considerations from our end, mostly in-line with whats flagged before.
My primary concern is how this contends against other ongoing research trying to lower the amount of signatures on the chain to facilitate the move to ZK and 3SF, e.g. your proposals to get to 8192 signatures per slot, and efforts like EIP7251 (Max EB), as well as flagging that taking DVs in protocol doesn’t mean we no longer have extra communication to make them viable.
I also think the problem to be solved here could be more clearly specified. If the goal is to come up with a solution for distributed validators in post quantum (lean) ethereum, I outline Obol’s research on the topic to date below.
I don’t think it is that simple. Take an attestation’s head vote component (or a sync message); If you have e.g. 7 honest operators taking part in a DV, three might not see a proposers block in time, and attest to a missed slot, while 4 (or 3 or 2) might see the block, and propose it instead. This will result in no majority for the attestation (or at least an incorrect head vote if the protocol can introspect the constituent parts of an attestation and sees quorum votes for correct source and targets) and lost rewards. For a sync message, it would be an outright penalty. These distributed validators have to coordinate to reach a super majority, and now we’d either be doing it on the main p2p network (a bad idea), or doing it in a dedicated p2p channel between the nodes like the status quo.
I find this property of the proposal particularly exclusionary for the long tail of stakers and worth commenting on. Restricting distributed validators to those of significant means does not seem like a reasonable choice. Particularly due to the lack of progress on designs like Orbit which intended to lower the minimum participation, (or to at least hold the level at its current eth denominated terms while lowering the amount of signatures per slot). If DVs are to be taken in-protocol, their marginal extra costs should be subsidised by the protocol imho. The current minimum stake to participate in validating Ethereum is north of $100k, which is almost double the OECD annual salary, and more than 5 times the global average salary. Technology like Distributed Validators, and decentralised liquid staking protocols, lower the minimum participation to $10k and below through squad staking. This is worth keeping in my eyes, at least without an alternative route to more modest barriers to participation.
This I think is the most important problem to solve as it pertains to post-quantum distributed validators. (Whereas I think the chain’s declining nakamoto co-efficient is the most important problem to solve for Ethereum’s validator set. DV enshrinement is not likely to be a big fix for that). All of the aforementioned DV(-adjacent) designs rely on BLS signature aggregation.
At Obol, we have been working on Distributed Validators for Lean Ethereum for over a year now, I’ll briefly describe some avenues that we don’t think will work, then will focus on our most promising avenue to date, which is more or less in line with the design in this post anyways in my opinion.
- Firstly, we looked at using pure MPC protocols to complete the hash based signature schemes being considered for Lean Ethereum. In short, these involve too many round trips to be viable at the slot times Lean aspires to. Towards Practical Multi-Party Hash Chains using Arithmetization-Oriented Primitives [1]
- Next we worked on a combinatorics based approach to calculate a threshold HBS, inspired by your 2018 post here: thbs_combinatorics/doc/main.pdf at 653155fc62265646850bf173576c1a89130d06e5 · ObolNetwork/thbs_combinatorics · GitHub Unfortunately, the security reduction was too large such that the scheme was not viable on the preferred lean hash chain parameters.
- Most recently, we have extended the LeanMultisig repo to support threshold XMSS signatures. leanMultisig/docs/threshold_xmss_design.md at feature/threshold_xmss · ObolNetwork/leanMultisig · GitHub This is the most promising work to date, and in my eyes, not dissimilar to the plans in this post (enshrinement), just in a ZKP paradigm where threshold signatures are supported within the proof system rather than handled transparently in the STF. These threshold signatures do have a negative impact on the resulting proof size, and aggregation of the threshold signatures as well as aggregation of a mix of threshold signatures and standard XMSS signatures are still an open item for implementation before we can consider this viable for the finalised Lean Ethereum protocol. Nonetheless I think its worth doing and our best avenue yet.
To conclude; I don’t think enshrinement pre-lean Ethereum has a strong enough need. Post-lean I would support an approach that keeps DVs viable yet out of the core protocol complexity if we could, but we don’t yet have such a design. So including them in-protocol is our best option. I certainly think distributed validators are critical for Ethereum to survive its struggles with (mostly unavoidable) centralisation forces, and can’t be dropped from the staking model outright without all but assuring that the chain will be co-opted by a small number of parties in the not so distant future. Small groups are more credibly neutral than individual parties, and are more likely to make the best decision for the wider community beyond their group.
Alexandre Adomnicăi, Towards Practical Multi-Party Hash Chains using Arithmetization-Oriented Primitives: With Applications to Threshold Hash-Based Signatures. IACR Communications in Cryptology, vol. 2, no. 4, Jan 08, 2026, doi: 10.62056/ahp2tx4e-. ↩︎