Multi-Chain Merge Mining

Flare brings together existing networks into a unified composable system so that they can operate together via smart contracts, and without levying any changes on how the underlying networks already work today. Therefore, Flare adopts a 'merge-mining' like approach for its own block production whereby the miners of these underlying networks gain the opportunity to share responsibility in producing blocks on Flare in parallel to their mining responsibility on their host chain, earning mining rewards on Flare for doing so.

The key design decisions of this mechanism are:

- The set of underlying chains used for merge-mining is based on the chains leveraged in the F-asset protocol.
- The relative validation power of each underlying chain on Flare is shared uniformly among all the underlying chains.
- Miners gain more
*sampling probability*in consensus, i.e. more importance to the safety of the network, based on their relative mining power output on their underlying chain.- For example, if a miner from an underlying chain mines 40 out of the past 100 blocks, then their chain-level sampling probability is 0.4. This number is then normalized such that it sums to 1 when added to the chain-level sampling probabilities of other miners from its host chain; this step accounts for incomplete participation from the miners from the underlying chain as merge-mining validators on Flare. This resultant normalized number is then divided by the number of chains in the F-asset protocol,
*N*, to obtain the global sampling probability of the underlying chain node.

- Miners from underlying chains link their Flare account to their underlying-chain mining beneficiary account via a simple transaction on the underlying chain originating from the mining beneficiary account which contains the Flare account listed in the 'memo' field.
- The previous two points are publicly verifiable and require no trusted third party to derive them. Each week, this data is used to construct the consensus sampling probability distribution of validators on Flare, which is supplied independently to each node on Flare by its node operator, without need for a multi-signature or any governance process to sign this into effect.
- All Flare nodes can optionally deviate from this '
*ground truth*' consensus sampling probability distribution (for safety validation, not leader-election) by a certain amount as described in detail in this paper in section 2.1.1 "Consensus".

Below is an example Flare consensus sampling probability distribution:

1

{

2

"validators": [

3

{

4

"nodeID": "NodeID-GQ4292fG2RMRWa7RtphPJTYHeMR5YAQPM",

5

"origin": "chain-0",

6

"weighting": 25

7

},

8

{

9

"nodeID": "NodeID-GMHrauiUPGikdbT4Z65dEBFpfQWKovLy5",

10

"origin": "chain-1",

11

"weighting": 20

12

},

13

{

14

"nodeID": "NodeID-DhdvGK268cNmDPzvh1Vw7rzSmT1tptSUB",

15

"origin": "chain-3",

16

"weighting": 19

17

},

18

{

19

"nodeID": "NodeID-hBfmpWJ87GSPHUtxthGd2fHsVdaGmkgq",

20

"origin": "chain-2",

21

"weighting": 14

22

},

23

{

24

"nodeID": "NodeID-LtahNtUH9tb4VCZZipLNqkBCxzjpFTdHs",

25

"origin": "chain-1",

26

"weighting": 11

27

},

28

{

29

"nodeID": "NodeID-34KwvqefLeXYPrzcNjc4yMPRpMfE89ppw",

30

"origin": "chain-2",

31

"weighting": 8

32

},

33

{

34

"nodeID": "NodeID-G9CJC4te7FyH1XyMugsRqVYYZBuTreFvd",

35

"origin": "chain-3",

36

"weighting": 2

37

},

38

{

39

"nodeID": "NodeID-HhAo3hwTn73UB1LxU131gXrs7HMnMxmdE",

40

"origin": "chain-0",

41

"weighting": 1

42

}

43

]

44

}

45

Copied!

The probability of any particular validator

$V$

in the above list being sampled during consensus is then:$\frac{\texttt{weighting}_V}{\sum{\texttt{weighting}}}$

Validator rewards are based on rewarding elected leader nodes during consensus, with leader nodes being drawn automatically based on their 'ground-truth' consensus sampling probability.

Last modified 1mo ago

Copy link