End-of-Cycle Flow

This is a description of the End-of-Cycle flow that completes the Cycle and handles rewards and enforces the consensus

  1. BlockReward.reward is called every block and when the cycle ends calls the Consensus.cycle

  2. Consensus.cycle is responsible for several functions. Eventually does the following two actions:

    1. 1.Sets the boolean Consensus. Should EmitInitiate Change to true

    2. 2.Calls Block Reward. onCycle End which sets the boolean BlockReward. should EmitRewarded OnCycle to true as well

  3. The $BBC-validator-app (fuseapp container on validator vms) checks the value of the above two booleans and when true calls the following two functions (two separate transactions):

    1. 1.Consensus.emitInitiateChange

    2. 2.BlockReward.emitRewardedOnCycle

Note that only one validator can make this call successfully so the 1st one succeeds and all others fail. But it’s ok because those are 0-gas transactions. So actually the validator who is the next one to validate a block is the one who is successful in making those calls.

  1. The above calls emit the following events:

    1. Consensus.InitiateChange

    2. BlockReward.RewardedOnCycle

  2. The bridge oracles fuse oracle-initiate-change and fuse oracle-rewarded-on-cycle are responsible for listening to above events.

  3. Those oracles should run on all validators and call submit Signature on the Home Bridge Native To Erc contract in Butane network - each validator should submit the signature for each of the oracles (events).

  4. Once enough validators have submitted their signatures (majority of the current validators), an event Collected Signatures is emitted by the home bridge (again one event for each one of the previous events in section 4).

  5. The bridge oracle fuse oracle-collected-signatures is responsible for listening to the Collected Signature events and all validators should get it. The validator responsible for transmitting the transaction to mainnet is actually the last one to submit the signature in section 7 and its address is part of the event details so other validator oracles “know” it’s not their turn and skip the event. If a validator is down or out of money or infura is deaf - the next one in line (in the ValidatorSet) is responsible for transmitting to mainnet.

  6. Eventually on mainnet we are supposed to see two transactions to the ForeignBridgeNativeToErc each cycle - one updating the new validators and one minting the besc tokens which were created during this cycle on BBC.

Note that if the new validator set transactions fail on mainnet there’s a chance the minting will fails as well, because before transmitting it checks if all signatures are valid and there can be a situation where new validators were added on a cycle and were fast enough to submit their signatures on $GAS end-of-cycle transactions but weren’t updated on mainnet due to failure of the 1st transactions so the 2nd one will actually contain “invalid” signatures from the mainnet perspective.

Last updated