cdesaintguilhem
commented
4 weeks ago In Sui, validator's proportion of the total stake in the system is converted into Voting Power by a smart contract. Currently, the total voting power is set to 10,000 and the maximum voting power any validator can have is 1,000 (so 10% of the total), except when there are fewer than 10 validators. In that case, each validator can have at most $10,000 / n$ voting power.
When doing MPC with different voting power per validator, some things are different:
- the "quorum" requirement for messages is not $2n/3$ any more, but instead it should be $6,667$ voting units, where each message contributes as many voting units as the voting power of the Validator who sent it. So, if Validator $V_i$ has 500 voting power, then a message from $V_i$ contributes 500 units towards the requirement. When enough messages have been received to reach 6,667 voting units, then quorum has been received. This already happens in Sui when a Validator checks whether a transaction submitted by a User has received a quorum's worth of signatures from other Validators.
- Threshold decryption cannot be performed like the rest of the protocols. For the other protocols, it is enough to say "one Validator contributes one message per round", but for threshold decryption, each Validator should have as many shares of the secret key as they have units of voting power. During threshold decryption a Validator should send a partial decryption value for each share of the secret key that it owns. (Here there is a possible optimisation to aggregate these shares before sending them, but it requires knowing the identity of the parties who will make up the quorum, something that we don't have in the asynchronous case.)
zeevmoney
Understand from Erik & cyprien what exactly that means