FROST, which stands for Flexible Round-Optimized Schnorr Threshold, is an advanced cryptographic protocol designed to improve threshold signature schemes. Unlike traditional single-party signatures, FROST enables a group of participants to collaboratively generate digital signatures using shares of a private key, so that only a specified threshold of participants is needed to authorize a transaction. This approach boosts both security and resilience against key loss or compromise.
FROST is notable for reducing network overhead during signing operations, supporting efficient two-round (or even single-round, with preprocessing) signing without sacrificing security or concurrency. These features make FROST especially suitable for Zcash.
What is FROST for Zcash?
Our rationale from the onset of this project was that “Zcash transactions should be publicly indistinguishable (i.e. an adversary observing the blockchain should not be able to gain any information about who the payment is for, how much the payment is, or who authorized the payment). Zcash previously did not have a good mechanism to achieve this goal in a multi-party setting, where a group of users want to jointly control funds and authorize transactions. Prior to FROST, the best protocols to perform this signing process required either undesirable implementation complexity, high network overheads to perform signing operations, the inability to support a threshold number of signers, or undesirable privacy leaks such as exposing the number of signers. Consequently, our decision to design a new threshold scheme stemmed from the desire to improve the state of threshold signature research to match the needs of Zcash users today.”
When it comes to advancing privacy and security in digital transactions, the FROST for Zcash implementation we developed stands out with several important features. Notably, it is designed to keep the same security guarantees of RedDSA, in particular unlinkability, which is required by the Zcash protocol. This prevents attackers from linking two FROST-generated signatures to the same person. This makes integration straightforward for developers and organizations without the need for major infrastructure changes.
To support adoption, Zcash Foundation (ZF) provides user-friendly libraries, demo applications and tutorials, making it easy for anyone to incorporate FROST for Zcash into their projects.
Why did we develop FROST for Zcash?
ZF committed to building FROST for Zcash to address several important needs within the Zcash ecosystem. One of these primary motivations was to develop a secure, privacy-preserving multisignature implementation for shielded transactions, a functionality that was previously missing. The goal from the onset was to ensure seamless compatibility with existing Zcash standards and protocols, like RedDSA. This allows developers and projects to integrate FROST for Zcash into their systems without having to overhaul their infrastructure.
ZF also wanted to make advanced cryptographic tools more accessible through user-friendly libraries, demo applications, and tutorials to help developers adopt FROST quickly and easily.
What is the current state of FROST for Zcash?
We have now concluded our development work on the FROST reference implementation, frost-core, along with the ciphersuite crates. To help with deployment, we have also developed tools to help participants communicate with each other: a frost server, frostd, and the command line tool frost-client whose purpose is to work as a standalone tool but also as reference for wallets to integrate FROST.
What Happens Next?
The next step is for wallets to integrate FROST using those tools directly or as reference, knowing that ZF is willing to provide guidance as needed. If wallet developers are hesitant to run their own frostd servers, the team is open to deploying a production version. Importantly, the frostd server doesn’t need to be trusted, as all messages are end-to-end encrypted; it only relays information, similar to lightwalletd, and leaks minimal metadata that can be further protected with tools like Tor.
There are some existing concerns about the lack of a standardized key generation specification for FROST, which currently limits interoperability; progress on this front is ongoing, and we hope to complete that soon with guidance from ECC engineers.
FAQs
Why does Zcash require its own implementation? Why isn’t there one FROST implementation for all protocols?
Zcash requires a custom FROST implementation to maintain its privacy guarantees and protocol-specific needs, as generic FROST variants lack critical features like rerandomized signatures (ensuring threshold-signed transactions mirror single-party ones for anonymity) and compatibility with Zcash’s shielded transaction systems (Sapling/Orchard). Additionally, Zcash integrates share recovery mechanisms, identifiable aborts, and safeguards against concurrency attacks-adaptations unnecessary for non-privacy chains. Since blockchain protocols prioritize divergent tradeoffs (e.g., Bitcoin’s simplicity vs. Zcash’s unlinkability), a universal FROST standard is impractical due to cryptographic nuances (curves, serialization) and ecosystem-specific security requirements.
Does FROST for Zcash have commercial applications outside of Zcash?
No, this reference implementation was created specifically for the Zcash ecosystem.
Has FROST for Zcash been audited?
Yes, there have been two audits: the first one by NCC audited the core crates which implement the cryptographic part of FROST; check the complete report. The second audit covered the frostd and frost-client helper tools and was done by Least Authority; the complete report is available here.
Why is a FROST server needed? What is the risk of using it?
The FROST server simply helps participants to communicate with each other; most devices today are behind firewalls or routers which make direct peer-to-peer communication difficult. Technically the server is not even aware that it is being used for FROST!
Additionally, the frost-client tool we have developed (which also serves as reference for other implementations and also works as a library) does end-to-end encryption of all messages. This means that the server does not need to be trusted and won’t be able to see the content of the messages. The server is able to gather metadata though (e.g. who is talking to who at what times), but that risk can be mitigated by using e.g. Tor. The risk is very similar to the risk that wallets take by using lightwallet servers.
Also note that using the FROST server is optional. We believe that it’s the easiest path forward until a better solution is developed, but wallets are free to handle user communication as they wish.
What is missing for a regular Zcash user to be able to use FROST?
The missing piece is for wallets to integrate FROST. The required tooling to make that happen has already been completed by ZF (though of course wallets are free to use the implementation and design they wish to). Technical-inclined users can use FROST with Zcash today using our frost-client command line tool.
Is this reference implementation of FROST capable of being included in NU 6.1?
Due to the way FROST works, it’s not required to change the protocol in order to use FROST with Zcash. Therefore, yes, FROST can be used in NU 6.1, or even now with NU 6.
What is the best way for wallet developers to contact ZF with questions?
Open an issue or discussion in the repo and reach out on the #frost channel of the R&D Discord.