FROST Federation

Radpool depends on a federation of nodes that run the FROST threshold signature protocol as well as a distributed key generation protocol included in the same paper (called KeyGen). We have an implementation of a node for running a syndicate that uses KeyGen protocol to determine a shared public key. The syndicate then uses the FROST threshold signature protocol to sign messages that settle futures contracts paying miners from the liquidity provided by the federation members.

The FROST Federation is a Strong Federation as per the definition implied in Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks and used in Liquid: A Bitcoin Sidechain. FROST Federation is both publicly verifiable and and makes progress in the presence of Byzantine failures.

The FROST Federation implementation is an independent project as other applications apart from Radpool can use it for other purposes.

Membership

The DKG protocol provides a BFT consensus between the parties to agree on the membership. Every fixed interval all connected nodes can run a DKG instance to obtain the syndicate public key . However, as we will see later, the syndicate signs DLC contracts that pay miners. This means that we can’t simply depend on a BFT agreement to decide on who gets to sign the DLC contracts.

Recall that all MSP broadcast mining shares mined by their miners. We depend on this information to support the membership with verifiable PoW information. We require that the membership of the syndicate is limited to the MSPs whose miners make the top 60% of hashrate but including at least 2/3rd of the network at the same time.

The membership is therefore determined using the following protocol.

Protocol for Determining Membership

  1. Consider only the shares submitted to the network since the last bitcoin block was found by the pool.

  2. Group all miner shares received from all miners into groups keyed by the MSP that sent the corresponding mining message.

  3. Compute the total hashrate for each MSP in their group.

  4. Order the MSPs by their aggregate hashrate - use the MSP lexicographical ordering on the public key to break ties.

  5. Select the MSPs from the top of the list and add their hashrate. Stop when the total hashrate adds up to 60% of the total network hashrate.

  6. If we have reached 60% of the network hashrate, but haven’t included 2/3rds of the MSP, we continue adding MSPs to the list till the required number is reached.

The above protocol uses PoW to prevent sybil attacks on the syndicate membership. By limiting the hashrate to 60% of the network hashrate we discourage parties from purposely running low hashrate MSPs to obtain more shares in the DKG and TSS protocols. At the same time we require 60% of the Radpool hashrate to decide on the payouts. The approach dis-incentivises MSPs to retain smaller share of the Radpool hashrate. If their hashrate is small, larger MSPs will add up to the 60% threshold hashrate and the smaller MSPs will have no shares in TSS.

At the same time, by also requiring that we atleast include 2/3rd of the network in the syndicate, we avoid the situation where a single MSP has 60% of the network hashrate and can control the payout mechanism.

Syndicate Broadcast Communication

Once the membership is confirmed, the syndicate also provides a byzantine fault tolerant reliable broadcast within the syndicate. We later use this broadcast primitive to replicate shares received by a MSP to all other MSPs. We use the Asynchronous Verifiable Information Dispersal protocol to provide the BFT reliable broadcast. The protocol replicates data across point to point nodes with low communication complexity while tolerating byzantine failures.

Syndicate Signature in Single Round

The FROST threshold signature requires that all parties broadcast their share of the threshold signature. The Radpool payout mechanism requires payouts for all miners to be made at fixed intervals corresponding to the range of expiry times for DLC contracts. We discuss the expiry times in the Bitcoin Contracts page.

Since all parties know when a signature has to be created, say at every block, they look at their locally available hashrate date and immediately broadcast their signature share. The broadcast has a message complexity of , but all the messages are exchaged in a single round. If we generate nonces a priori, the threshold signature can be generated in a single round. We noted this in the blog post: FROST Threshold Signatures for Multiple Channel Updates.

Signing Multiple Messages

As we will explain later, in Radpool the syndicate has consistent local views. With consistent views each syndicate member generates the same message to sign without the need to run an agreement protocol. The syndicate needs to sign a message for each of the miners. We run an optimistic protocol to sign these messages using FROST threshold signatures. In case of failures, we run the signature scheme again with the members that failed removed from the signing party. Such an approach can delay the signing process for payouts to miners, however the signing is not in a critical path for the pool to make progress. We explain the details in the Scalability section.