Demo for FROST for Zcash Library

The Zcash Foundation engineering team has been working on an implementation library for FROST (Flexible Round-Optimized Schnorr Threshold Signatures) for Zcash. To support this we have built demos, which are NOT to be used in a production environment nor with any secrets. The purpose of these demos are to:

  1. Identify gaps in our documentation
  2. Provide usage examples for developer facing documentation
  3. Provide reference implementations for developers wanting to use FROST in a “real world” scenario

THREE DEMOS

We have three demos in this project covering each of the corresponding roles, which are: 

  1. Trusted Dealer: a third party or participant who is trusted to:
    • Generate good randomness
    • Keep secret values confidential
    • Delete secret values after distributing key shares to each participant
  2. Participant: a recipient of a key share
  3. Coordinator: a third party or participant who is responsible for:
    • Determining which participants will take part in generating a signature
    • Coordinating FROST signature rounds
    • Aggregating signature shares generated by each participant
    • Publishing the resulting signature

Note: We also have a demo which covers Distributed Key Generation (DKG), where there is no trusted dealer role and participants generate key shares among themselves.

We invite you to  test the demos for yourself by following our tutorial, which was showcased during our presentation at ZCon4. The demos allow you to choose one of two journeys—either with a trusted dealer or DKG for key generation. This tutorial describes the trusted dealer journey.

HOW WE BUILT THEM

The method for building these demos included:

  • Reading the FROST paper
  • Reading the FROST draft
  • Reading documentation in the FROST crate
  • Reading documentation in library while building the demos
  • Referring to the draft paper to match the documentation

When building a protocol library from a paper, names are likely to change and you need to document the code well; it’s not uncommon to find mismatches. We tried to build the demo from the perspective of someone who had not seen FROST before, and so we went through all the documentation without any assumptions. We also started publishing releases more often so the demos could be updated as we found different API changes we needed to make. This encouraged us to properly document throughout the process.

NEW FUNCTIONALITY

We realized that we hadn’t created a way for the trusted dealer to accept an existing key rather than allowing the application to generate one for you. Originally we weren’t able to specify an existing secret because generate_trusted_dealer() generated a secret for you. We compared this functionality to that specified in the draft paper and  it was discovered this was missing; so we added split_secret() to handle this functionality and trusted_dealer_keygen()would generate one instead.

We also took this opportunity to add serde support to our FROST library. Serde is a library that helps encoding structures into multiple formats such as JSON or XML. We’d had a request to implement serde in our FROST library and decided that the demos created a good opportunity to get this done, since they require copying and pasting structures between terminals. It was pretty straightforward and it meant we could copy structures encoded as a single line JSON object between our terminals, instead of having to copy and paste each field of each structure.

Working on these demos has enabled us to make the library more robust and easier to use for implementers. We’d love to know if you agree!

We hope that this will help anyone understand how frost works and what you can do with it. Please do let us know if you’ve found this useful by reaching out to us on the ZF Discord FROST channel.