Hi Folks,
Blockchain Commons has put forth a proposal to provide wallet integration for the ZF FROST libraries (https://frost.zfnd.org/), starting with VSS, highlighting Zcash’s role as a leader pushing forward the whole digital-asset community.
Here’s our gallery view of the proposal:
The project is laid out in six phases, so that we could initially work toward less than the whole project, if desired. To support strong integration of ZF FROST and its VSS capabilities into third-party wallets would require advancement through at least Phase Three. Additional Phases continue to improve standardization (Four, Six) and developer support (Five, Six)
We had a bit of a delay between submission of this proposal (in late January) and this posting due to forum permissions(!), which would push back the initial phase deadlines by that same amount.
Title:
ZF FROST Wallet Integration
Applicant name:
Blockchain Commons
Team member names:
Christopher Allen
Wolf McNally
Shannon Appelcline
Pitch: A one-liner elevator pitch version of your proposal
Encourage usage of ZF FROST and expand its reach through interoperability with other standards and projects.
Total Request (USD):
$157600.00 USD
Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?
No
Are you seeking or have you received funding from other sources for this proposed project?
No
Applicant background:
Christopher Allen is the coauthor of the TLS and DID standards and is currently working with the IETF to advance dCBOR and the Envelope data format for standardization. Recognized as a “Top 100 Influencer in Identity,” he was Principal Architect at Blockstream, Vice President at Blackphone, and CTO of Certicom. Today, he is the Executive Director of Blockchain Commons.
Blockchain Commons has been working for almost five years on bringing together wallet developers across the blockchain ecosytem to create secure & interoperable systems that protect the human dignity of their participants.
Some of Blockchain Commons’ major achievements include the introduction of an interoperable Animated QR specification (Animated QRs - Developer Resources), development of the Lifehash visual hash specification (LifeHash - Developer Resources) and of course the dCBOR (draft-mcnally-deterministic-cbor-07 - dCBOR: A Deterministic CBOR Application Profile) and Envelope structured data formats (draft-mcnally-envelope-06 - The Gordian Envelope Structured Data Format) for the IETF. More information on Blockchain Commons’ extensive recent work can be found in the 2023 Yearly Overview (Blockchain Commons 2023 Overview - Blockchain Commons) as well as overviews from previous years (Posts by Tag - Blockchain Commons).
Description of Problem or Opportunity:
Private key material and the seeds that generate them are threatened by loss and by theft. Methodologies such as Shamir’s Secret Sharing have offered some proof against loss, but seeds and keys are still threatened when they are reconstructed.
Newer methods such as Verifiable Secret Sharing (VSS) and Distributed Key Generation (DKG), which are available as part of ZF FROST, offer next-generation solutions to these problems, notably decreasing the threat level. For them to become a reality, FROST development needs to be finalized and standardized, and real-life references need to be created to show developers the possibilities.
Since VSS and DKG are available in the ZF FROST libraries, highlighting their usage offers Zcash the opportunity to be seen as a leader in the entire blockchain ecosystem, creating new interest in Zcash and its blockchain.
Proposed Solution: Describe the solution at a high level.
Blockchain Commons already has a set of reference libraries, CLI applications, and other tools that demonstrate the usage of classic Shamir’s Secret Sharing. We want to expand it to include VSS, Trusted Dealer Generation, and eventually more, all drawn from ZF FROST.
But the initial goal is to make ZF FROST’s VSS solution fully available to wallet developers. It builds on our long-standing work with over a dozen wallet developers who have implemented interoperable Blockchain Commons specifics such as Uniform Resources (URs) and Animated QRs (see: UR Implementations - Developer Resources). Though the ZF FROST library is an excellent reference library for cryptography, it’s not quite ready for wallet use; we want to contribute our knowledge and our work with the wallet ecosystem to make that possible.
By empowering wallet developers to use ZF FROST, we can expand the ecosystem that’s aware of Zcash to include a wide variety of developers. Down the line, we plan for standardization of the new protocols to expand that recognition even wider. The ultimate goal is to have VSS protecting not just blockchain assets, but SSH keys, COSE data, Gordian Envelope data, and more.
This process will be broken into six large phases. Though this proposals suggests advancement through all of them, a smaller budget could allow for progress through just the earlier stages, allowing for assessment of initial milestones before continuing work.
-
Phase One: Identify a broad base of open-source developers working with FROST, not just those releasing libraries. Organize at least two Round Tables to allow FROST developers to communicate their trials and triumphs working with the technology, and fully document those Round Tables.
-
Phase Two: Create a 2.0 release of Blockchain Commons’ security-reviewed SSKR library that adds ZF FROST’s Trusted Dealer Generation methods, offering an alternative to traditional Shamir’s Secret Sharing.
-
Phase Three: Acquire a new security-review of updated library.
-
Phase Four: Review the wide variety of formats for public and private keys, incuding classic 33-byte public keys (as used by Zcash), modern Bitcoin x-only public keys, formats for storing keys on disk, formats for storing keys with metadata, and methods for deriving child keys. Write a specification that integrates those with VSS and Trusted Dealer key formats.
-
Phase Five: Expand Blockchain Commons’ existing reference CLIs, keytool and seedtool, to include VSS from ZF FROST and standardized key formats from Phase Four. (Possibly extend envelope-cli as well, if there is interest and reason.)
-
Phase Six: Further expand reference CLIs to offer keys on other curves, such as the 25519 and Ristretto curves usable by ZF FROST.
Solution Format: What is the exact form of the final deliverable you’re creating?
-
Phase One: Full documentation of FROST Round Tables, similar to the documentation of a preliminary meeting we held in November 2023: FROST Round Table I: Overview - Developer Resources. Also, an overall summary including a community map of who’s involved in FROST at various places and who’s been missing from the Round Tables.
-
Phase Two: SSKR 2.0 Reference Library that includes VSS created by Trusted Dealer Generation in ZF FROST library.
-
Phase Three: Security review of SSKR and updated SSKR 2.0 Reference Library for any security problems detected.
-
Phase Four: Specification of key data formats, such as an Internet Draft for IETF and/or CBOR object listing for IANA, as well as initial submission to the appropriate standards organization.
-
Phase Five: Updated keytool and seedtool apps (and possibly envelope) that allow for sharding, verifying, and reconstructing keys using VSS and ZF FROST Library as well as usage of new key format.
-
Phase Six: Updated envelope, keytool, and seedtool apps (as appropriate) that support 25519 and Ristretto keys.
Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!
Our standard workflow at Blockchain Commons is to: (1) identify problems faced by digital identity & asset holders and the wallet community; (2) write specifications to address those problems; (3) revise specifications with community feedback; (4) write reference libraries to support the community specification; (5) write reference apps to exercise our reference libraries; (6) advance specifications into standards; and (7) revise specifications, reference libraries, and reference apps for evolving standards.
For this ZF FROST-focused VSS project, we feel the project is already hovering between steps (2)-(4) of this process. There is a reference library, and work is being done to create an informational RFC for the IETF.
Blockchain Commons wants to advance work beyond this stage, creating a more developer-friendly reference library (4), expanding our reference apps to exercise the new VSS functionality (5), and working with IETF to transition FROST work and new specifications to the Applications & Real Time [ART] area (6-7). (The IETF Security [SEC] area has largely ignored multisig to date, and so we don’t find it a viable path for advancement.)
As part of our technical process we will also ensure that our work is future-proofed, particularly so that it can support Distributed Key Generation in a future iteration of the project.
Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?
This project is primarily dependent on ZF FROST (GitHub - ZcashFoundation/frost: Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation) and Blockchain Commons’ own SSKR reference library (GitHub - BlockchainCommons/bc-sskr: Sharded Secret Key Reconstruction (SSKR) reference library in C) as well as our keytool (GitHub - BlockchainCommons/keytool-cli: Cryptocurrency key & address derivation for the command line) and seedtool (GitHub - BlockchainCommons/seedtool-cli: Cryptographic Seed Tool for the command line) CLI apps. Both ZFFROST and the original C++ version of SSKR have been security-reviewed, so we think that together they offer the opportunity for a production-ready VSS solution. The goal is to make that immediately usable via the expanded SSKR library.
We expect that that ZF FROST engineers will remain involved in our additional Round Tables, as they participated in our first round table in November 2023 and multiple participants requested we hold more. They should also provide some review of our work to ensure that it remains consistent with ZF FROST. More support would be lovely, but those are the only requirements.
Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?
We will be freshly working with the ZF FROST library and we’re currently unaware of its limitations or dangers, so that’s likely to be the largest obstacle. However, as the first library to offer a security-reviewed VSS, the ZF FROST library is a critical addition to the whole blockchain ecosystem, and we think it’s worth that effort.
Different opinions on FROST usage could cause disagreements on how to advance on specifications. However, our preliminary FROST Round Table had a very congenial atmosphere, and we hope that maintaining that through additional Round Tables will be beneficial for the whole project.
When we get to the expansion of our own CLI apps, the two older tools, keytool and seedtool, will first need to be transitioned from C/C++ to Rust. Since we’ve previously transitioned other work in this way, we consider it a known problem, but obstacles are always possible in this sort of work.
Finally, work with standards bodies can always add arbitrary obstacles to a project, but that lies somewhat outside the scope of this project, whose intent is to lay out a specification and begin the process. Pushing new key specifications through the entire standardization process could be an additional seventh phase after this initial work. It’s a phase that we have more than 30 years of experience with, including recent work with the IETF on the dCBOR spec.
Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.
Obviously, Trusted Dealer Generation is a transitional intermediary mechanism for key/seed security. We like it as a crucial first step before eventually transitioning users to Distributed Key Generation because it’s easy to implement now in current systems. The danger is that VSS might be considered an end solution, robbing developers of the ability to later advance to DKG.
There are also approaching DKG solutions that may have different properties, STORM prime among them as it’s explicitly not publicly verifiable. These differences could cause issues with early solutions such as this one. For example, people may begin building solutions depending on publicly verifiable VSS, and then be unable to move on to a version that doesn’t have that property. (We are tracking this issue in particular, and hope to have a presentation on STORM at a future Round Table.)
Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?
-
Phase One:
-
Full reports of at least two additional FROST Round Tables, including qualitative discussions of what FROST developers are feeling about the technology and what obstacles they’re facing.
-
Published overview of ecosystem.
-
Phase Two:
-
GitHub release of SSKR 2.0 with ZF FROST VSS, plus backport of Rust content into C API for use with Swift.
-
Phrase Three:
-
Successful security review of updated SSKR library.
-
Phase Four:
-
Specification of Key Data Format.
-
Report-outs on any meetings held to discuss Key Data Format.
-
Phase Five:
-
GitHub release of Seedtool, converted to Rust, with VSS output.
-
GitHub release of Keytool, converted to Rust, with new key-data-format output.
-
Optionally, an update of Envelope-CLI if new key-data-formats or VSS seem appropriate for inclusion.
-
Phase Six:
-
GitHub release of Seedtool and/or Keytool as necessary to support keys on the 25519 and Ristretto curves.
Hardware/Software total budget:
$0.00 USD
Please provide justification for the total hardware/software budget:
No hardware or software needed.
Services total budget (cloud, hosting, etc.):
$0.00 USD
Please provide justification for the total services budget:
Any services will be trivial in overall budget.
Compensation total budget:
$157600.00 USD
Please provide justification for the total compensation budget:
This covers architect, administration, engineer, and technical writer time for this project, as well as overhead to keep Blockchain Commons running while we focus on this. Estimated cost is $100 an hour across the board, times 1.5 for overhead.
For the security review of the SSKR library (Milestone 3), cost is solely based on third-party cost of a security review.
Here’s the breakdown:
MILESTONE 1. Each round table is estimated at 8 hours for each of the three core team members of Blockchain Commons, for prep and attendance, plus 8 additional hours total afterward for recording. There are two meetings planned, so 32 hours total x 2 = 64 hours.
MILESTONE 2. This expansion of libraries is specced out at six man-weeks, which is 240 hours. We expect this to be mainly engineer time. It includes review of the Trusted Dealer portion of ZF FROST and integration of VSS into SSKR 2.0.
MILESTONE 3. Our cost for a full security review of the SSKR library previously was $10,000 with Radically Open. We are presuming a similar cost; if preferred the actual cost can be paid directly to the security reviewer rather than to Blockchain Commons.
This milestone also includes 40 engineering hours for discussing the security review with reviewers, researching issues undercovered, and resolving them.
MILESTONE 4. Our production of a key format and our first presentation is estimated at 80 hours, mostly research, architecture, and engineering.
MILESTONE 5. Our updates of the keytool and seedtool apps to Rust and to incorporate VSS functionality is estimated at six weeks of time (240 hours) to maintain the full functionality of both tools (limited functionality could be accomplished in less time).
MILESTONE 6. Our updates of the keytool and seedtool apps to incorporated 25519 and Ristretto is estimated at eight weeks of time (320 hours).
Do you require startup funding?
No
Milestone 1 - estimated completion date:
07/31/2024
Milestone 1 - USD value of payout upon completion of deliverables:
$9600.00
Deliverable 1.1
Phase One. Two FROST Round Table meetings, with full documentation and recording, as with our preliminary meeting. The meetings are expected to be completed by 6/30/24, full deliverables done by 7/31/24.
Milestone 2 - estimated completion date:
08/31/2024
Milestone 2 - USD value of payout upon completion of deliverables:
$36000.00
Deliverable 2.1
Phase Two. Updated SSKR library with VSS from ZF FROST.
Milestone 3 - USD value of payout upon completion of deliverables:
$16000.00
Milestone 3 - estimated completion date:
09/30/2024
Deliverable 3.1
Security reviewed SSKR 2.0 library in Rust. We can’t guarantee the timing of this milestone because it will depend on a third party for the reviewing.
Milestone 4 - USD value of payout upon completion of deliverables:
$12000.00
Milestone 4 - estimated completion date:
09/30/2024
Deliverable 4.1
Specification for key data format. Initial submission to standards organization. we expect this to be informed by the first milestone (meetings) and to occur in parallel with the next two (production & security testing of SSKR 2.0).
Milestone 5 - estimated completion date:
12/31/2024
Milestone 5 - USD value of payout upon completion of deliverables:
$36000.00
Deliverable 5.1
Updated versions of keytool-cli and seedtool-cli for Rust + VSS.
Milestone 6 - estimated completion date:
04/30/2025
Milestone 6 - USD value of payout upon completion of deliverables:
$48000.00
Deliverable 6.1
Updated versions of keytool-cli and seedtool-cli for 25519 + Ristretto.
Total proposed USD value of grant:
$157600.00 USD
How was the project timeline determined?
The project was carefully broken down into phases, and the time costs of each phase were estimated based on experience.