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

[andrewferrone]

@45930 a few of Mina ecosystem's most prominent projects - Lumina DEX, Zeko, MinaNFT - see a pressing need for a solution to solve today's security risk. What would you suggest be the next steps for agreeing a solution?

[45930]

I think the solutions could span o1js, Mina Protocol, and proof systems upgrades, and I can really only speak to o1js. I'm not even sure if implementing this FROST protocol in o1js would do anything about the issue, if Mina Protocol doesn't recognize or accept the new signatures.

I'd like to get a more holistic view on this from technical leadership at o1Labs. I will speak with some people this week about this and provide an update.

[kantp]

@mrmr1993, over on the fungible token issue, you said you had an easy fix for the upgradeability of smart contracts, MinaFoundation/mina-fungible-token#112 (comment)

Can you elaborate on that fix? In particular, suppose we implement multisig in a smart contract and use that to guard updating the verification key. Can we expect that to work beyond a breaking update once the fix is in place? If not, is there a plan for implementing native multi sig?

[45930]

Hey, I was able to chat with Matthew yesterday. We like this approach to the issue since it's well-scoped and has no side effects that might haunt us later (at least in the protocol side). I wrote up a quick spec of what the solution should look like IMO:

FROST for Mina

Objective

By implementing FROST over the Pallas elliptic curve, a signature can be produced with private key shares that will look to Mina like any other Schnorr signature.

The objective is to enable ZkApps on Mina to enforce a multisignature approval to upgrade its logic, in the event that a proof system upgrade requires a change to the verification key of the ZkApp.

Deliverables

• A FROST library, ideally written in rust or typescript, that allows key share holders to collaboratively sign an input.
• A demonstration of a ZkApp upgraded by multisignature on the Mina blockchain

Requirements

• The output signed data and composite public key must be verifiable by Mina, e.g. the mina-signer library, o1js, and the Mina blockchain all agree on the validity of the signature.
• An auxiliary ZkProgram can prove the number of key shares used, and an individual with one of the keyshares can prove that they are one of the keyholders.

[45930]

We think this is a great task for community members who understand the cryptography, and I can staff someone from our exploration team to support if needed. @youtpout are you or anyone on the Lumina/Zeko side interested in working on this implementation?

[L-as]

An auxiliary ZkProgram can prove the number of key shares used, and an individual with one of the keyshares can prove that they are one of the keyholders.

Why would you want this? Does this mean you would want the circuit implemented, or just for it to be feasible?

[L-as]

A FROST library, ideally written in rust or typescript, that allows key share holders to collaboratively sign an input.

There is already an audited implementation by Zcash: https://github.com/ZcashFoundation/frost

We would just need to add support for Pallas and Mina's variant of Schnorr if there are any differences in the concrete protocol.

[45930]

Why would you want this? Does this mean you would want the circuit implemented, or just for it to be feasible?

If the reason for this work is to prevent a single signature from rugging an application, I imagine users will want assurances that the admin key for a given contract is a composite private key that no single entity knows.