Build and Coverage

Note: Rust code coverage misses lines. We are sharing links to the report for transparency.

FROST Federation

A federation of nodes running FROST to generate threshold signatures for itself and on the request of clients.

The federation also saves and synchronises data and commands sent by clients. The federation then runs a priori known validation scheme on the data before generating a threshold signature.

DKG and TSS

We are using the KeyGen and TSS as defined in the FROST paper. We add an additional round of reliable byzantine broadcast to provide agreement in the round 2 of the KeyGen protocol. See discussion on the ZCash FROST repository for details.

More on TSS as we get closer to adding support for it.

System Model

1. A federation of nodes with point to point network connectivity.

2. All point to point connections are authenticated and confidential using the Noise framework.

3. All point to point connections are reliable with no ordering guarantees.

4. Provide an echo-broadcast implementation between all nodes to satisfy the FROST broadcast channel requirements.

Federation Clients

1. Clients connect to any node in the federation and then send data/commands to that node.

2. The federation members synchronise data and commands received from clients.

Threshold Signatures

1. The federation runs preprocessing DKG rounds every fixed interval or when a new member joins.

   1. Membership is not a simple problem and we depend on the Bitcoin consensus for it. Membership is determined by keys that control inputs into a bitcoin transaction that spends to a key federation’s DKG key.

   2. To join the federation, an applicant provides such an input and sends a request to all members of the existing federation. The federation signals the willingness to accept the new member by running a DKG protocol to generate a new key for the federation. Members do not run a DKG protocol more than once every two weeks. This prevents DDoS attacks and frequent changes to membership.

   3. The new membership is confirmed by creating a new bitcoin transaction that spends all the member inputs to a federation public key.

2. Threshold signatures are generated Whenever a client requests a one or the federation needs one.

Validate Before Signing

1. The federation will run an application dependent validation protocol on the synchronised data. Members locally run validation using only the data available locally. Members then run the threshold signature protocol only after they have validated their local view of the data.

2. Signing also provides an agreement that members are signing the same data. If data is different, the signing operation will fail.

3. This allows clients to use the federation as a BFT validation and signature generation service.