Schnorr multisig support

[youtpout]

The current mechanism to upgrade a verification key in case of hardfork may pose a problem for many protocols, the privates key's owner will be the only ones able to update these contracts, being able to deploy malicious code or never update them and block their use.

Hence, we need a native Schnorr multisigs (e.g. FROST), that support Mina.

Thankfully, native Schnorr multisigs are already somewhat widely implemented, see e.g. Zcash Frost.
This however won’t work out of the box for Mina, both because the curve used is different, and the concrete Schnorr protocol might be slightly different than that of ZCash.

Implementing FROST from scratch in o1js might also be feasible.

[45930]

@mrmr1993 I think this issue in the token standard is referencing a similar issue: MinaFoundation/mina-fungible-token#112 (comment)

I think we should be explicit with what changes we think we can make in the next HF with respect to permissions, and see if this multisig approach is complimentary to that, or if it becomes unnecessary.

On its own merits, a native multisig sounds interesting, but if it's also required for security, then we should think about making it an immediate focus.

[youtpout]

@45930 What non-multisig solution would you like to provide?

[45930]

I'm specifically referencing Matthew's comment that I linked. I'm not sure of the details, so I'd like him to explain more. I think we have this issue where, after a hard fork, it's possible for verification key upgrades to happen by signature, even if the intention is that the VK cannot be upgraded, or can only be upgraded by proof.

One way to mitigate this would be to enable a native multisig so that a single person cannot execute the upgrade themselves, although this doesn't truly solve the problem.

Since Matthew has publicly alluded to another option, and the community is coalescing around this issue, I'd like to understand all the options at our disposal.

[andrewferrone]

@kantp flagging for visibility