FROST in the non-direct funding model

Technology
1

Continuing the discussion from Proposal for a Zcash Governance Bloc (“zBloc”), to separate the tech-for-governance discussion from the governance discussion:

(My opinion and not Zcash Foundation’s)

I also think FROST (" Flexible Round-Optimized Schnorr Threshold" a threshold signature scheme, similar to a multisig, which works for shielded wallets) is the perfect fit to being used in a non-direct funding model where a t-of-n quorum of parties decide to fund grants, where they can run FROST to sign the transaction that would fund it. (If you’re unfamiliar with FROST I recommend reading Understanding FROST - The ZF FROST Book). I believe its downsides are not blockers for this scenario:

  • Lack of robustness: this means that a member can refuse to participate in a signing sessions, and this blocks the session from completing even if there are more than the threshold number of participants willing. It’s not a big deal because this can be detected: the Coordinator will know that a member is not cooperating, and can simply re-run the signing session without them. I also just realized that this would be also part of the regular process: if a member does not approve a grant they also would end up stopping the process anyway. (So in practice it may be better to poll the members beforehand and run a signing session with just the members that intende to approve). Additionally, members who did participate can show their signining share (which can be verified by anyone if verifying shares are published), so if a malicious Coordinator is claiming someone refused to participate, that someone can show their signing share and disprove it.
  • Attribution: as Pacu mentioned this can be solved by using verifying shares, it just wouldn’t be able to be validated onchain (which I don’t think is required anyway)

Also, we just managed to get the “Nested FROST” proof of concept working, where each party/org would also use FROST to generate their signing share in a share-of-shares approach, so I’m sure that is a possibility too.

10 Likes
2

Technically, it is looking awesome. Thanks to all who made this possible.

3 Likes
3

My primary worry is that the process of gathering signatures needs to be trivially easy, because it’s probably be going to have to be done very frequently; suppose that there are a couple of dozen grants being funded, and the signers need to execute the process for signing a disbursement for each grant once a month as milestones are delivered. If there is friction in the process due to non-participation, it’s likely that the process will break down. Hence, my preference would be for a process that doesn’t require multiple rounds and can be executed fully asynchronously.

I do however find the argument that we should use FROST in order to make FROST better highly persuasive; I just think that there is a nontrivial engineering effort required in order to make the UX of the two-round process good enough that it won’t be an impediment. Of course, there’s probably no better way to do this than to just start with a small set of signers who are willing to put up with significant inconveniences, and then work to improve everyone’s experience by removing those inconvenient edges over time.

The nested FROST capability is also a pretty compelling argument; in using that approach, it then requires the UX to be even better, because you encounter the potential to stall at each layer of the roll-up.

3 Likes