Table of contents

Decentralized mining pool

This article explores a specification for a decentralized mining pool implemented in Kulupu’s protocol level, assuming signed mining.

Those changes are built on top of 53-KSIGNED.

Proof of work seals

Proof of work operates on seals, and each of them have a corresponding difficulty. Two seals of difficulty A should have the same effect as one seal of difficutly 2 * A, because the former is equivalent to having the block time cut in half as the later.

On protocol level, we change signed mining to allow multiple seals to be included in a block header, with each of them having a difficulty of D / N, where D is the current difficulty, and N is the number of seals.

type MultiSeal = Vec<Seal>;

The seals in the array are built on top of each other. The first Calculation uses the pre_hash of the header. The second one use the pre_hash of the completed first Seal, and so forth.

Note that each seal in this sequence will have the same difficulty. Otherwise, a centralized mining pool can game the system by providing itself a seal with a low difficulty, and asking real miners to provide a seal with a high difficulty.

Reward calculations

At this moment, block rewards are calculated and deposited in the same block. This works with single seal system because the sealer is always known in advance. However, with the new system that multiple miners will be building on the same block, we need to move the reward calculation to the beginning of next block.

The runtime, upon initialization, will read the seal data of the previous block and compute its reward. It then handles the reward deposit logic from there.

Pool sub-networks

Built with the protocol changes, multiple decentralized mining pools can be implemented for Kulupu.

Those pools operate on another network layer. Each pool differs in its respective difficulty level, by setting up a fixed number of how many seals it expects to be built in one block.

  • Upon receiving a new Kulupu block in the network. Peers in a pool drop any existing work, and set the pre_hash to be a new block that itself is building. Note that at this moment, peers in a single pool will build on different pre_hash, because they each generates new blocks individually.

  • The first peer that finds a seal with difficulty D / N publishes the header with the seal to the sub-network of the decentralized pool.

  • Other peers, upon receiving the header, will first verify the runtime logic of the received header, and verify the consensus of the received seal. It then starts to build upon the seal.

  • Once there are N seals accumulated in the header, the sub-network publishes the block to the Kulupu network.