Underlying Chain Miners as Validators on Flare

Leveraging miners from underlying chains for consensus on Flare Network

Flare is unique as a network in that it is focused on bringing together liquidity from all other networks into a unified composable system so that they can operate with smart contracts, and without levying any changes on how the underlying networks already work today. Flare's validator structure takes advantage of this idea; succinctly: control over the Flare network is proportionally given to the miners that contribute the most to the safety of underlying blockchains on Flare, weighted by market cap.

Constructing the Validator List on Flare

Each week, a ground truth list of miners from underlying networks will be deterministically generated, weighted according to their contribution to the safety on their own network. This is a publicly verifiable process and it is not controlled by a centralized party. For example, in the case of a proof of work network this is calculated based on how many blocks a miner has successfully mined over a period of time. There is no limit to the size of this list of validators, and the list is comprised of any interested miner from an underlying chain integrated to Flare.

Example: suppose 3 miners from an underlying chain wish to become validators on Flare.

  • Miner 1 mined 20 of the past 100 blocks on their chain

  • Miner 2 mined 5 of the past 100 blocks on their chain

  • Miner 3 mined 10 of the past 100 blocks on their chain

The relative weighting of each of these miners as validators on Flare is then:

  • Miner 1: 0.2/(0.2+0.05+0.1) == 0.2/0.35 == 0.57

  • Miner 2: 0.05/0.35 == 0.14

  • Miner 3: 0.1/0.35 == 0.29 Note that: 0.57 + 0.14 + 0.29 == 1.

Then, the relative weighting of this underlying chain compared to other underlying chains on Flare is calculated as follows:

  • Underlying chain 1 has a $1Bn market cap

  • Underlying chain 2 has a $2Bn market cap

The relative weighting of these underlying chains on Flare is then:

  • Chain 1: 0.33

  • Chain 2: 0.66

This is because chain 2 has twice as large a market cap compared to chain 1. To obtain a miner from chain 1's weighting as a validator on Flare, multiply their chain's weighting by their own weighting within their chain:

  • Chain 1, miner 1: 0.57x0.33 = 0.19

  • Chain 1, miner 2: 0.14x0.33 = 0.05

  • Chain 1, miner 3: 0.29x0.33 = 0.09

The weightings above define the probability of sampling each validator during consensus on Flare. For example, suppose two validators exist on Flare. Validator 1 has a weighting of 0.25 and validator 2 has a weighting of 0.75. Although they are only two nodes, validator 2 behaves as if they are 3 nodes because they will be sampled 3 times as often during consensus on Flare compared to validator 1.

Note that there will be a cap on the sampling probability distributed to any one blockchain and any one miner or pool.

Validator Rewards

Any validator that exists on the weekly ground truth list is permitted to compete in submitting data availability proofs concerning the state of their origin chain. This is known as the state connector system, and success in this game supplies the validators on Flare an inflationary mining reward akin to block-producing on other networks. A validator's probability of winning a data-availability proof competition is based on:

  • Validator uptime

  • The validator's consensus sampling probability on Flare

  • Producing a block on the underlying chain gives a validator faster access to the data than others

Code

Updating the validator set on Flare with custom sampling probabilities: vm.go, line 771 -> https://gitlab.com/flarenetwork/flare/-/blob/master/fba-avalanche/avalanchego/vms/platformvm/vm.go#L771

func (vm *VM) updateVdrSet(subnetID ids.ID) error {
vdrs := validators.NewSet()
for _, validator := range vm.ValidatorConfig.Validators {
err := vdrs.AddWeight(validator.ShortNodeID, uint64(validator.Weighting))
if err != nil {
return err
}
}
err := vm.vdrMgr.Set(constants.PrimaryNetworkID, vdrs)
if err != nil {
return err
}
return nil
}

Independently providing sampling probabilities via command-line input on launch using the --validators-file flag:

./build/avalanchego \
--http-host= \
--public-ip=127.0.0.1 \
--snow-sample-size=2 \
--snow-quorum-size=2 \
--http-port=9650 \
--staking-port=9651 \
--db-dir=$(pwd)/db/node04/ \
--staking-enabled=true \
--p2p-tls-enabled=true \
--network-id=coston \
--bootstrap-ips=$(curl -sX POST --data '{ "jsonrpc":"2.0", "id":1, "method":"info.getNodeIP" }' -H 'content-type:application/json;' https://coston.flare.network/ext/info | jq -r ".result.ip") \
--bootstrap-ids=$(curl -sX POST --data '{ "jsonrpc":"2.0", "id":1, "method":"info.getNodeID" }' -H 'content-type:application/json;' https://coston.flare.network/ext/info | jq -r ".result.nodeID") \
--staking-tls-cert-file=$(pwd)/config/keys/node04/node.crt \
--staking-tls-key-file=$(pwd)/config/keys/node04/node.key \
--log-level=debug \
--log-dir=$LOG_DIR \
--validators-file=$(pwd)/config/validators/coston/1619180000.json \
--alert-apis=https://flare.network \
--xrp-apis=$XRP_APIs_JOINED

Example validators.json definition:

{
"validators": [
{
"nodeID": "NodeID-GQ4292fG2RMRWa7RtphPJTYHeMR5YAQPM",
"evmAddress": "0x3769119b83c2f53c182a4f725917065179795542",
"origin": "ltc",
"weighting": 25
},
{
"nodeID": "NodeID-GMHrauiUPGikdbT4Z65dEBFpfQWKovLy5",
"evmAddress": "0x2cae9302f38b62425eebfe83fe78d49d6f2f8707",
"origin": "doge",
"weighting": 20
},
{
"nodeID": "NodeID-DhdvGK268cNmDPzvh1Vw7rzSmT1tptSUB",
"evmAddress": "0xd5147e4f21385355c2c4735830f716cd5a50f778",
"origin": "xrp",
"weighting": 19
},
{
"nodeID": "NodeID-hBfmpWJ87GSPHUtxthGd2fHsVdaGmkgq",
"evmAddress": "0xba2ac417f2d878c48028400b26fec3ecc0adf8a3",
"origin": "xlm",
"weighting": 14
},
{
"nodeID": "NodeID-LtahNtUH9tb4VCZZipLNqkBCxzjpFTdHs",
"evmAddress": "0x4f6e59dd6186aca90bb15ae6e4993bc3a570c013",
"origin": "doge",
"weighting": 11
},
{
"nodeID": "NodeID-34KwvqefLeXYPrzcNjc4yMPRpMfE89ppw",
"evmAddress": "0x9e32c568279a54874ef0dcad4f0e34f04c34ea45",
"origin": "xlm",
"weighting": 8
},
{
"nodeID": "NodeID-G9CJC4te7FyH1XyMugsRqVYYZBuTreFvd",
"evmAddress": "0xcbb8f758007062ad35073d306a89216917dc370b",
"origin": "xrp",
"weighting": 2
},
{
"nodeID": "NodeID-HhAo3hwTn73UB1LxU131gXrs7HMnMxmdE",
"evmAddress": "0x20a236b2ad0f6fff7702cf4ceec77b17ae140d2f",
"origin": "ltc",
"weighting": 1
}
]
}

The probability of any particular validator VV in the above list being sampled during consensus is:

weightingVweighting\frac{\texttt{weighting}_V}{\sum{\texttt{weighting}}}

Flare's consensus definition is deterministically generated and the validator list can be generated by anyone, without relying on a trusted third party. Flare's unique advantage is that it represents an alternative consensus scaling methodology to proof-of-stake that gives direct control to miners from underlying chains to enable the amassing of liquidity from their chains into a unified, composable system for the purpose of interacting with smart contracts.