I believe Shamir will be used here as well.
The issue has more has to do with the fact that five individuals have the ability either through mistake or intention to leak or use validator keys in unauthorized or damaging ways. These keys can be used maliciously to mass slash all validators in the distributed environment at worse or force out validators via withdrawal without DAO approval first.
Additionally, I assume this is a 3 of 5 setup meaning you only need 3 individuals in this group of 5 to leak or maliciously conspire to use their key shared to construct the validator key sets.
Horcruxes for the stakewise/non-distributed operators have these same properties today per my understanding so this proposal can be viewed as equal in terms of risk I think. It all comes down to who those 5 individuals are and how well they do their job as securing their key shards.
At least that is my laymen’s read of the proposal/limited understanding of things.
There are ways to wrap SSS with mutli-sig for additional protection, auditability, and re-keying capabilities but Muli-Sig in general is still a beast to use in most cases and using it correctly is required to keep things secure; lest all the song and dance is for nothing.
As a person who’s career is built on building secure stuff (and as a proposing operator for stakewise) the KISS method is generally the golden rule. The simpler the system, the easier it is to secure and keep it that way. So I think the proposed arrangement makes a lot of sense, and it has worked well thus far for in a similar arrangement for the stakewise platform horcruxes.
My only real questions are the following
-
Is it possible to make the holders of the Validator committee Shards on the core team a different set of people than the present holders of the horcruxes? It may not be if the team isn’t big enough to accommodate such an arrangement or maybe stakewise core team has already got that covered.
-
As far as the external parties it is possible to ensure there isn’t overlap in horcrux holders and validator committee holders? Is that even possible/already covered?
-
Was there consideration around making the committee 7 instead of 5 members? This would result in a 5-7 setup which makes it harder to collude across a diverse of committee members but at the same time increases the risk of key leakage (more keys more vectors)
-
Is there a plan in place or process defined for what happens when a committee member(s) must change for any reason? Are there documented processes for how a re-sharding/re-keying would take place if required?
Otherwise, as a hopeful future operator for the stakewise platform this is awesome and I am glad to see efforts being taken to address these cases. It will only help to bolster stakewise going forward and helps establish a very high bar of trust, transparency, and accountability across different participants of the platform.