Syndicate Operation

The MSPs run all the services that currently centralised pool operators need to run. The difference is the the syndicate is transparent and all members verify correct operations of all other members. Furthermore, syndicate membership is open and members can join and leave the syndicate using the protocols described and implemented in the radpool syndicate node.

The joining protocol is permissioned and if a syndicate has reached a point it can’t scale further, it will start rejecting join requests from entities who want to join the syndicate. Entities can start new syndicates once they can attract enough hashrate. On the other hand, the capital requirements that we explain below will encourage a syndicate to grow as much as it can to support a large hashrate pool and thus a pool with reduced variance.

We provide the tools, people run the syndicates!
MSP Responsibilites

  1. Collaboratively run DKG and TSS protocols as a syndicate member, i.e. run FROST Federation.

  2. Run a syndicate node and a bitcoin node to handle share validation at scale.

  3. Run stratum interfaces for miner interaction.

  4. Provide a miner registration interface.

  5. Generate block templates and stratum work messages.

  6. Receive shares over stratum protocol and maintain a replicated database of received shares.

  7. Contribute capital used to pay miners with a DLC futures contract.

  8. Provide an API exposing miner metrics.

Syndicate Network

The MSPs open a point to point connection with all other MSPs. These channels are authenticated and confidential. We need point to point communication channels between MSPs as the FROST threshold signature protocol requires this and we want to conform with the requirements to avoid any security weaknesses.

Each MSP sends the following message types to all other MSPs:

  1. New block template it is working on.

  2. The stratum job it sends to miners.

  3. All shares received from all miners.

  4. Requests by new MSPs.

  5. Miner public key once it is registered with the MSP.

  6. Requests received from miners to leave the pool.

All of the above messages are sent using reliable, authenticated and secret communication channels. Our current implementation of FROST Federation supports such communication channels.

The replication of shares on all MSPs is important because this transparent share accounting enables all the miners to calculate the payout distribution and validate any new payout and coinbase transactions before signing the syndicate update transaction.

We use a highly efficient BFT reliable broadcast protocol proposed by Cachin et. al.. The protocol has a communication complexity of for broadcasting data of size to nodes connected using a point to point network.

Open Access to Replicated Shares

Once a miner starts sending shares to a MSP, the shares are replicated to the other MSPs. A MSP that receives shares, verifies the shares and then broadcasting them to the rest of the syndicate. A miner can send their shares to multiple syndicates by registering with the syndicate.

This results in an open database of shares that all MSPs and other interested parties can run accounting on. This open access to verified shares is used to build futures contracts using DLCs to pay miners.

Transparent and Open Operations

A mining syndicate results in a transparent pool where all syndicate members validate that all other MSPs are working correctly. If a member is not working according to the agreed upon protocols, the honest MSPs stop rewarding the dishonest member and will eventually remove the dishonest member from the syndicate.

The above is made possible by point to point communication between MSPs as well as the bitcoin contracts between the MSPs.