Yeah I agree with this, I think it’s a good idea independent of this one. It should not be hard to allow instant key changes, and keep the old key around for a while for slashability.
go against the ongoing efforts of: reducing consensus overhead (e.g. via validator consolidations)
This is fair, though it’s designed to not make the worst case worse. That is the reason behind the “you must have >= 32 * n" rule.
Such entities are probably quite capable of running out-of-protocol DVT options, Vouch+Dirk or a couple of Vero instances.
I think this is the crux of the matter. I’ve personally seen the inside of organizations and ETH whales (incl myself) trying to figure out Vouch/Dirk/Vero, and it’s a big headache to wrap our heads around and understand. If running DVT were as simple as “run 7 independent nodes, the only change is a one-line difference in config file” (maybe even the line of change in the config is not required, as it could autodetect your key’s membership in a DVT set), then I’m pretty sure both others and myself would have been DVT-staking for a while now.
So I feel confident that this style of in-protocol DVT would be pretty decisive in terms of enabling people (esp. whales and smaller institutions) to stake on their own
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.
yeah I agree this is a weakness. Though I guess (i) I expect it to be rare and not a large penalty to revenue, because most attestations do come on time [and we can further penalize edge case attestations by adding penalties in proportion to how much people behave differently wrt an attestation], and (ii) we can treat each action separately from a rewards perspective, eg. if you break it down to (i) “voted for X” vs “voted for nothing”, (ii) voted for parent Y, then you can give such a voter a reward for voting for parent Y without a reward for voting for X or nothing.
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
I appreciate the research, thank you!
I do agree that it has fewer edge cases to go through a single leader and have a single action; though the thing to trade it off against is devops ccomplexity.
It’s possible that the right thing to do is to figure out a way to do it natively but in a way that still avoids tracking partial participation onchain (eg. leader sends their signature, the other nodes see it in the p2p net and follow the leader). In that case, the tradeoff would become just latency (though maybe it’s not that bad)