Threshold Signature Validator Client Spec Application

[mikereinhart]

Grant Application

This application is (select one):

• Speculative (use this by default)
• an RFP response

This application is (select one):

• Public (fully)
• Public with private finances

Abstract

We intend to specify and design a threshold signature validator client for Substrate blockchains in the form of a PSP. We view this as an important step in advancing validator security and aligning development teams around a common goal.

Checklist

• The grants document has been read and understood.
• The Google Form will be completed accurately. Note that the Google Form requires the pull request URL.
• Abstract (above) is succinct and complete.
• The application is being included into the correct directory: either 'targeted' or 'speculative'.
• The application includes a project description.
• The application includes all names of team members.
• The application includes a description of the team's experience.
• The application includes all necessary links (e.g. GitHub and LinkedIn)
• The "Development Roadmap" section in the application has a timeline of development ("milestones").
• The "Development Roadmap" section in the application has an estimate of funds required.
• The "Development Roadmap" section gives an indication of the team's long term plans.
• The "Development Roadmap" section includes documentation as a deliverable for at least one milestone.

[burdges]

I think doing a threshold schnorrkel VRF makes sense eventually, but depends upon both (1) adding some threshold secret key type ala w3f/schnorrkel#5 before (2) doing threshold multi-signatures well ala w3f/schnorrkel#11 as well as (3) a proper implementation for the DKG being developed in w3f/PSPs#7 using session types. I suppose multi-signer or threshold VRFs leak the VRF output before the signature completes, which sounds fine, but maybe tweaks the threat model slightly.

I'll contribute to (1) myself when I find time. We've outsourced (2) and (3) which might hopefully yield fruit later this year, but any further work should wait until those reach our standards for cryptography code. In particular, all multi-party computations must be expressed using session types like the musig algorithm in https://github.com/w3f/schnorrkel/blob/master/src/musig.rs which could require closer work with the contractor.

Also..

I noticed the code https://gitlab.com/polychainlabs/threshold-ed25519/-/blob/master/pkg/ed25519.go looks abysmal:

• It's vulnerable to k-sum attacks. I'd forgive a k-sum vulnerability if this were 2018, but they're amateur hour in 2020.
• Worse, it never imposes correct witness generation, so deployments would normally expose their secret keys outright.
• It's vulnerable to rogue key attacks. I think thresholds avoids rogue key attacks technically, but not with the interface given here.
• It lacks a DKG which makes key management error prone.

All these require session types for compile-time correctness, but you'd need runtime checks for an implementation in Go. I'd surely find more problems if I kept digging but the above show just how far that go code lies from acceptable cryptography.

[burdges]

We'd need similar threshold code for ed25519 for GRANDPA too, not just schnorrkel. I think kzen has code for this in https://github.com/KZen-networks/multi-party-eddsa which beats that polychain labs garbage, but still sucks and should not be used by substrate. Ideally, one might port whatever code emerges from (1-3) above into an ed25519-dalek fork, which avoids the timing attacks, etc.

[burdges]

After all this, we face two more serious longer term challenges:

1. Sassafras shall replace BABE, but Sassafras uses a ring VRF built with SNARKs. We could make this SNARK verify another Schnorr DLEQ based VRF, which allows threshold operation, but doing so costs some performance and complicates the code. We maybe want this anyways for HSMs, etc., although many HSMs designs make validators less safe.
2. We'll need signature aggregation for GRANDPA eventually, but we're considering fancier tricks beyond just BLS, so not sure whatever we do yields nice threshold signing here either.

[burdges]

We're more than 12 months away from anything like this, but I'll attempt to keep HSM and threshold operation in mind during upcoming crypto churn.

[swdee]

@burdges
Back in April you write that outsourcing of threshold multi signatures was done. What progress has been made on that? Does that work also include m-of-n multisig?

[burdges]

We were speaking about a DKG grantee I think. I've heard nothing from that grantee afaik, although maybe the grants team did.

At this point, there is one respectable DKG implementation around that should be ported to schnorrkel, or more likely made generic, and at least one cool new DKG paper that improves things, so we'll just do it in house or ask for help from those folks.

We also finished our security proof for doing the two round version https://eprint.iacr.org/2020/1245 and blockstream https://eprint.iacr.org/2020/1261 independently produced another security proof concurrently, so now the two round protocol is basically cast in stone.

We'll get this done within the next six months I'd think, although not before parachains get working since that consumes much of my time.

[alxs]

@mikereinhart this has been open for a while without any updates. Are you still interested in working on something along these lines?

[ApolloUnicorn]

@alxs stepping in here for Mike, yes we would still be interested in this effort. I'm less familiar with the grant program than I'd like to be so if you could help me navigate the next step(s) I would greatly appreciate it.

[alxs]

Good to hear that. You may have noticed that we're in the process of deprecating the General Grants Program in favour of an overarching Grants repository, so as a first step I'll go ahead and close this PR. It's also been open for a little too long so it probably won't hurt to start afresh. Then the next steps would be:

1. Reassess the relevance and feasibility of the project. Without much background myself, I think @burdges was implying above that you'd have had a hard time working on this and you'd have mostly been building on moving parts. Progress has been made, but it may still be too soon. You can reach out to him directly on Element under @jeff:web3.foundation.
2. Reapply following the process outlined here. Please reference this PR from the abstract you'll be asked to provide in your first comment. If you can, follow the public application process, otherwise you can apply via the form and optionally create a PR. You may have to modify a few aspects of your application to meet the current requirements (e.g. the way deliverables are structured).
3. The rest of the process is outlined in the link above. Assuming you apply publicly, you'll be able to start as soon as your application has received the approval from 3 members of the committee.

If you have any questions, you're welcome to reach out to us under grants@web3.foundation.

[ApolloUnicorn]

@alxs thanks!

[twisty18]

Hmm...