Are you sure this system works out when it comes to block proposals? (and by the same token inclusion lists)
Isn’t it a likely outcome that the virtual identities split over multiple proposals and nothing gets included? You would have to race N-M+1 proposals to ensure optimal liveness, (up to N-M can be offline) and non-proposing nodes can only safely sign one proposal, so unless they all independently decide the same way everyone will miss the proposal rewards. We can play with the tradeoff a bit, but I’m skeptical something practical would come out.
Of course on the other hand you could run some kind of consensus algorithm between the identities, even a fast n≥5f+1 if we want, but we would be re-introducing some of the downsides of current DVT since nodes will have to set up maintain reliable connections with each other. The kicker is that they will be seldom used, so you might not notice if they have an issue. (Still at least we are getting rid of private one-to-one channels for the DKG)
As a result I think this could work well for “pure” consensus signatures under synchrony: FFG and Casper votes, and sync committee — the same signatures that can be heavily aggregated, but it breaks for roles where nodes have millions of bits of discretion such as inclusion and proposal. Maybe what we should do instead is allow validators to group for the purposes of voting, but retain independent proposal slots. That way you still socialize 87.5%¹ of your revenue with let’s say your validator *coalition*, the design stays nice and simple, and the chain still gets the benefits of diversity. (since a few bugged proposers aren’t what causes harm)
Of course unbundling validator roles is not a new idea and has been explored in 3TS most recently. These could go well together.