FROST implementation

[Fiono11]

Project Abstract

This document outlines the proposal for implementing FROST, a threshold signature protocol based on the Schnorr signature scheme, within the Substrate ecosystem. It provides a more scalable, cheaper, more user-friendly and privacy-preserving alternative to current multisig solutions. This protocol is particularly designed for scenarios with a large number of signers, ensuring both efficiency and signer anonymity.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) address in the application).
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Fiono11]

I have read and hereby sign the Contributor License Agreement.

[takahser]

@Fiono11 thanks for your patience here and sorry for the delayed feedback. I'm still talking to our research and will give you more detailed feedback soon. For the meanwhile, I've left you some inline comments.

[takahser]

@Fiono11 since this happens off-chain (if I understand correctly), which address/network protocol (see step 1) does the server use to contact the participants?

[Fiono11]

This would happen off-chain, yes. The network protocol used would be Secure WebSockets (WSS). The idea is that each client (wallet), if interested, would connect to the server (whose address would be hardcoded in the wallet) through an authenticated channel and the server would do the mapping between the public key addresses (accounts) and the network addresses of the clients, so that it can forward the messages between them.

[takahser]

Has Talisman consent to you using their logos and branding here? If not, I suggest to change it.

[takahser]

Could you add the Docker deliverable here as well, as it's usually mandatory?

[Fiono11]

I force pushed by mistake doing this, sorry.

[burdges]

I'll remark that FROST like protocols fit concensus poorly, due to their aborts problem. In FROST, the FRO represents an attempt to address this, but not really successful, and afaik its abandonded in standards work. As an exception a third round concensus protocol like BEEFY could deploy something more complex.

Anyways..

FROST-like protocols are quite useful for accounts of course, which you're seemingly focused on here. In principle, any DKG works among a small signer set, but there is seemingly new DKG work that should be considered asking for code. We'll look into it some. It's worth discussing soft derivations perhaps too.

As an aside, there were two original proofs of security for FROST-like protocols, the one by me, and the one by blockstream. FROST never had a security proof, though later Mary Maller & Elizabeth crites did one that's more modular than the original proofs.

Anyways..

I doubt substrate has much bearing upon the threshold signing by accounts. We'd instead want:

• schnorrkel to have a threshold DKG of some sort, but maybe not the FROST one,
• schnorrkel to have threshold multi-signatures, which should replace my outdated musig module,
• Parity Vault to integrate the new schnorrkel threshold DKG and multi-signatures,
• the untrusted communications component. Ain't exactly a "server" per se, but integrated into polakdot.js makes sense. Another "more raw" idea would be first some local command line or node tool, with which user cut & paste the communications over IM instead.

Afaik, there is no substrate integration at all, but maybe something like the bip39 thing being sucked in makes a mess of derivations.

I'm happy to dizcuss this further, maybe on some call, but I really should get cautht up on the Dan Boneh's new DKG idea first. It's maybe just overkill for accounts, but..

[burdges]

Anyways, these are the two schnorrkel issues on doing this:

w3f/schnorrkel#12
w3f/schnorrkel#11

As you're only asking for $10k, I think the schnorrkel side plus some sort of proof-of-concent usage, even just command line, suffices. In other words, the crypto devliverables should be schnorrkel PRs.

The one part that I'm kind picky about is that the abstraction in schnorrkel be clean-ish. I do not seem to have explained what that means well in those issues, but one reasons is it maybe worth doing the VRF version too sometime in the future. Anyways let's chat briefly sometime.

We can ignore Dan Boneh's DKG I think, since at minimum it'd require defining some new curve, and using bulletproofs.

[Fiono11]

I'll remark that FROST like protocols fit concensus poorly, due to their aborts problem. In FROST, the FRO represents an attempt to address this, but not really successful, and afaik its abandonded in standards work. As an exception a third round concensus protocol like BEEFY could deploy something more complex.

Anyways..

FROST-like protocols are quite useful for accounts of course, which you're seemingly focused on here. In principle, any DKG works among a small signer set, but there is seemingly new DKG work that should be considered asking for code. We'll look into it some. It's worth discussing soft derivations perhaps too.

As an aside, there were two original proofs of security for FROST-like protocols, the one by me, and the one by blockstream. FROST never had a security proof, though later Mary Maller & Elizabeth crites did one that's more modular than the original proofs.

Anyways..

I doubt substrate has much bearing upon the threshold signing by accounts. We'd instead want:

• schnorrkel to have a threshold DKG of some sort, but maybe not the FROST one,
• schnorrkel to have threshold multi-signatures, which should replace my outdated musig module,
• Parity Vault to integrate the new schnorrkel threshold DKG and multi-signatures,
• the untrusted communications component. Ain't exactly a "server" per se, but integrated into polakdot.js makes sense. Another "more raw" idea would be first some local command line or node tool, with which user cut & paste the communications over IM instead.

Afaik, there is no substrate integration at all, but maybe something like the bip39 thing being sucked in makes a mess of derivations.

I'm happy to dizcuss this further, maybe on some call, but I really should get cautht up on the Dan Boneh's new DKG idea first. It's maybe just overkill for accounts, but..

Thanks for the feedback, Jeff! What about ROAST? It may provide the robustness that FROST like protocols lack. Interestingly, while doing research, I found this thread where Victor Shoup hints that IC is adapting their robust threshold ECDSA to Schnorr here. However, I did not find any public development about this.

[Fiono11]

Anyways, these are the two schnorrkel issues on doing this:

w3f/schnorrkel#12 w3f/schnorrkel#11

As you're only asking for $10k, I think the schnorrkel side plus some sort of proof-of-concent usage, even just command line, suffices. In other words, the crypto devliverables should be schnorrkel PRs.

The one part that I'm kind picky about is that the abstraction in schnorrkel be clean-ish. I do not seem to have explained what that means well in those issues, but one reasons is it maybe worth doing the VRF version too sometime in the future. Anyways let's chat briefly sometime.

We can ignore Dan Boneh's DKG I think, since at minimum it'd require defining some new curve, and using bulletproofs.

I will have a look at these issues and then send you an email so that we can chat more. Overall, I think that this work may provide a good basis for future developments and new important use cases .

[Fiono11]

After some more research, my comments regarding Jeff's feedback are the following:

• Lack of FROST standardization: there is an Active Internet Draft with that goal.
• Security concerns about the Pedersen DKG, which is used in FROST: a recent paper proved the security of FROST2 (an optimization of the original) using the Pedersen DKG.
• Lack of robustness of the signing protocol of FROST: like I previously mentioned, ROAST can be implemented in the future if needed/wanted, which uses concurrent signing sessions that do not seem to hurt performance too much.

Taking this into account, I think it makes sense to close this application and create a new one that follows the direction of Jeff's ideas in this initial stage. So, the milestones of the project would be something like this:

• Milestone 1: Integrate FROST into Schnorrkel, with the following deliverables:
  • Deliverable 1: a PR that implements the DKG subprotocol.
  • Deliverable 2: a PR that implements the signing subprotocol.
• Milestone 2: Implement a Proof of Concept of FROST, with the following deliverable:
  • Deliverable 1: a CLI tool (in a separate repo?) that uses out-of-band communication and broadcasts a valid extrinsic to a Polkadot testnet.

What do you think, @burdges ? Either way, I sent you an email if you want to talk more.

[takahser]

I think it makes sense to close this application and create a new one that follows the direction of Jeff's ideas in this initial stage

@Fiono11 in that case, I'm going to close this PR. Feel free to open up a new one, once you think it's ready. You can still comment on this PR to keep the conversation going, or you can do it via email, it's up to you.

@burdges thanks for your participation!

[burdges]

In milestone 1, I do deliverables 1 & 2 in the opposite order myself, but they're kinda orthogonal really, so this maybe a matter of taste.

We'll chat with Elizabeth Crites sometime, since she works for us now. We've many issues beoing discussed by the standards folk, only some of which I've followed closely.

We'll want linear combination shared across participants I think, not sure what they call this. I still dislike this being called FROST beccause the FRO part failed completely.

How do we index participants? I'd lean towards randomly becuase then one can hide the number of participants this way. I'm afraid this kills FFT options, but that's not really available in curve25519-dalek anyways, and the merkle tree usage could mess things up. Ain't so clear this matter though.

[Fiono11]

In milestone 1, I do deliverables 1 & 2 in the opposite order myself, but they're kinda orthogonal really, so this maybe a matter of taste.

We'll chat with Elizabeth Crites sometime, since she works for us now. We've many issues beoing discussed by the standards folk, only some of which I've followed closely.

We'll want linear combination shared across participants I think, not sure what they call this. I still dislike this being called FROST beccause the FRO part failed completely.

How do we index participants? I'd lean towards randomly becuase then one can hide the number of participants this way. I'm afraid this kills FFT options, but that's not really available in curve25519-dalek anyways, and the merkle tree usage could mess things up. Ain't so clear this matter though.

I do not think the FRO refers to the robustness of the protocol but to the fact that you can commit many pair of nonces in the preprocessing signing stage. If you do that, you can sign with only one round instead of two, hence the flexible part.

I believe the linear combination shared across participants you are referring to is the FROST2 optimization (being Elizabeth Crites one of the authors of the paper), where the hash value used in the linear combination of each pair of nonces is shared between signers.

Anyway, I will write the new application and then we can iron out the details.

[burdges]

FRO = Flexible round optimized

It refers to batching the first round. If you batch the first round, then you must prevent nonce reuse somehow, which becomes a hardware problem, meaning you cannot simply persist them to disk on a typical computer. Instead, you need either the ephemeral natue of RAM, which you enforce in rust using session types, or else if you must persist them then you need special hardware that prevents missuse, like a hardware signer or TEE.

In brief, we should not implement FROST per se, in the sense that we should use session types to prevent the FRO. I think the standards process envisions removing the FRO but keeping the name FROST, FROST2, etc.

Anyways..

Appologies for being MIA over the last week, at a conference. I'm basically not worried about the struggle over exact security assumptions, so I'm happy to use the most flexible FROST flavor, afaik none of them become too complex.

We can chat voice sometime maybe?

[Fiono11]

FRO = Flexible round optimized

It refers to batching the first round. If you batch the first round, then you must prevent nonce reuse somehow, which becomes a hardware problem, meaning you cannot simply persist them to disk on a typical computer. Instead, you need either the ephemeral natue of RAM, which you enforce in rust using session types, or else if you must persist them then you need special hardware that prevents missuse, like a hardware signer or TEE.

In brief, we should not implement FROST per se, in the sense that we should use session types to prevent the FRO. I think the standards process envisions removing the FRO but keeping the name FROST, FROST2, etc.

Anyways..

Appologies for being MIA over the last week, at a conference. I'm basically not worried about the struggle over exact security assumptions, so I'm happy to use the most flexible FROST flavor, afaik none of them become too complex.

We can chat voice sometime maybe?

Makes sense. But, in practice, is encrypting and deleting the nonces from the disk after using it good enough, security wise? Anyway, they indeed removed the FRO in the standard draft but kept the name FROST, which is a little bit confusing.

Sure! Feel free to respond to the email I sent you to arranje a meeting. Either way, I submitted the new application in PR #2250, if you want to review it.