Add pczt frost-sign

[conradoplg]

This is just a proof of concept to gather feedback. The code is ugly; I'm looking for feedback on (1) is the API something acceptable? and (2) is this something that could be possibly merged after cleaning up?

I documented how to run it here: https://frost.zfnd.org/zcash/devtool-demo.html

Regarding the API, currently it is supposed to work along the frost-client CLI for the participants (and the frost-server in the same repo to handle comms), but if we want to go ahead it might make sense to add a new command for participants (pczt frost-sign does the coordinator logic) so that using frost-client is not required.

Regarding what is currently missing:

• Handling multiple inputs
• Sending the PCZT for the participants to validate (critical!)
• Deciding how to handle FROST key material (currently uses the frost-client config file which stores everything in cleartext)
• Incorporating ZIP-312 when that is done

[nuttycom]

In starting to review this, I'm surprised that FROST signing is the first thing that was implemented, because in order to perform signing we need to have keys in the wallet database, and in order to have those keys we need the DKG process implemented. Is the DKG on your agenda for implementation in the devtool?

[conradoplg]

In starting to review this, I'm surprised that FROST signing is the first thing that was implemented, because in order to perform signing we need to have keys in the wallet database, and in order to have those keys we need the DKG process implemented. Is the DKG on your agenda for implementation in the devtool?

As it stands, the keys need to be generated with frost-client (BTW I documented how to run it the ZF FROST Book). I think the easiest approach would simply incorporate all the functionality of frost-client into zcash-devtool, the tricky part is deciding how to store the key data in the devtool wallet file (instead of a separate file managed by frost-client which is what this PR does).

The goal of this PR is mostly to do a proof of concept and gather feedback on the overall idea and the API. I agree that if we go forward it would be better to move to the DKG first. If you also have any feedback on the key data storage, that would be helpful.

[nuttycom]

As it stands, the keys need to be generated with frost-client (BTW I documented how to run it the ZF FROST Book). I think the easiest approach would simply incorporate all the functionality of frost-client into zcash-devtool, the tricky part is deciding how to store the key data in the devtool wallet file (instead of a separate file managed by frost-client which is what this PR does).

The overall approach that we will want is:

In the wallet backend (in the WalletWrite trait) add a method that creates an account that will be associated with the signing set. That creation step should result in inputs to the FROST DKG, and then the account storage should be updated with the results of that DKG process. I'd be happy to pair with you to get you oriented with the things that will need to be added when you have time. The process is basically: design the API in terms of a set of semantically relevant types, then implement that API in terms of storing the relevant bits of information in the SQLite database (adding columns/tables as necessary via a migration) and then ensure that the WalletRead API exposes enough information to be able to perform signing ceremonies.

Then, the signing process should be integrated with the transaction proposal -> PCZT -> transaction finalization workflow.

[zmanian]

I've opened #150 which supersedes this PR with a complete FROST implementation, integration tests, and documentation.

Implementation (behind the frost feature flag):

• wallet frost-dkg -- Full interactive DKG ceremony (3 rounds) producing FROST key shares and importing the Orchard UFVK as a view-only wallet account. Key material encrypted at rest with age.
• pczt frost-sign -- Coordinator-side signing: extracts sighash/alphas from PCZT, orchestrates 2-round ceremony, aggregates shares into orchard_redpallas::Signature<SpendAuth>, applies to PCZT.
• pczt frost-participate -- Participant-side signing: loads encrypted key package, generates commitments and signature shares with rerandomization.
• frost_config.rs -- FROST config (frost.toml) management with age encryption.
• frost_serde.rs -- Hex-encoded JSON serialization for all FROST protocol messages.

Tests (17 tests in frost_serde.rs and frost_config.rs):

• Full 2-of-3 DKG ceremony with JSON serde round-trips on every message
• Full signing ceremony with rerandomization and JSON round-trips
• Round-trip tests for all serde types (KeyPackageStore, PublicKeyPackageStore, DkgRound1PackageStore, DkgRound2PackageStore, SigningCommitmentsStore, SigningPackageStore)
• Error-path tests for malformed inputs
• DKG-to-Orchard FVK bridge test (group key to FullViewingKey to UnifiedFullViewingKey with address derivation and ak sign bit handling)
• FROST signature to orchard_redpallas::Signature<SpendAuth> conversion test (the exact bridge used before apply_orchard_signature())
• FrostConfig TOML round-trip and age encrypt/decrypt tests

Documentation (doc/frost-walkthrough.md):

• Key architecture, DKG ceremony walkthrough, signing ceremony with message flow diagram, file layout, security considerations, full test suite reference, and troubleshooting.

This addresses the DKG gap noted in the review -- all functionality from frost-client is now incorporated directly into zcash-devtool.