oasisprotocol / oasis-core

Performant and Confidentiality-Preserving Smart Contracts + Blockchains
https://oasisprotocol.org
Apache License 2.0
334 stars 110 forks source link

proactivize is done after shares are distributed and system is in use; current interfaces don't work for that #5871

Open bennetyee opened 1 week ago

bennetyee commented 1 week ago

https://github.com/oasisprotocol/oasis-core/blob/7bf22960f37d1c74ca08cba6b091bbfb8a95a59d/secret-sharing/src/shamir/dealer.rs#L34

proactive secret sharing is to periodically randomize shares to be using a different secret polynomial after the system has been in use. so the dealer's role is gone; or, alternatively, there is a new dealer who only deals a zero-hole polynomial, which is verifiable when doing VSS.

here proactivize adds a random zero-hole polynomial to the dealer's polynomial, and is confusing to me since that's not when proactive randomization occurs.

proactive updates (before adversary could compromise too many shareholders) is done by either a single trusted dealer of zero-holed polynomials, or several, in VSS style, so that no subthreshold number of zero-holed dealers could be compromised just like shareholders could be compromised (VSS so shareholders can check that the shares came from a zero-hole polynomial; multiple so that leaking some of the zero-hole polynomials won't affect the proactivization). so we need two kinds of dealers, one for the initial secret sharing and one for sharing zero-holed polynomial shares, and this is possible using this by providing a zero value for secret in the Dealer<F>::new ctor, but the proactivize wouldn't actually be used. the shares created by the zero-hole dealer would just be added to the shares from the original secret sharing dealer in Shareholder, which should have a way to accept proactive shares of a zero-hole polynomial.