End-of-Cycle Flow

Search…
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
BlockReward.reward is called every block and when the cycle ends calls the Consensus.cycle
Consensus.cycle is responsible for several functions. Eventually does the following two actions:
Sets the boolean Consensus.ShouldEmitInitiateChange to true
Calls BlockReward.onCycleEnd which sets the boolean BlockReward.shouldEmitRewardedOnCycle to true as well
The fuse-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):
Consensus.emitInitiateChange
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.
The above calls emit the following events:
Consensus.InitiateChange
BlockReward.RewardedOnCycle
The bridge oracles fuseoracle-initiate-change and fuseoracle-rewarded-on-cycle are responsible for listening to above events.
Those oracles should run on all validators and call submitSignature on the HomeBridgeNativeToErc contract in fuse network - each validator should submit the signature for each of the oracles (events).
Once enough validators have submitted their signatures (majority of the current validators), an event CollectedSignatures is emitted by the home bridge (again one event for each one of the previous events in section 4).
The bridge oracle fuseoracle-collected-sigantures is responsible for listening to the CollectedSignature 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.
Eventually on mainnet we are supposed to see two transactions to the ForeignBridgeNativeToErc each cycle - one updating the new validators and one minting the fuse tokens which were created during this cycle on fuse.
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 fuse 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.
​
Example for a successful flow (from 7/6/2020)
Consensus.emitInitiateChange transaction on fuse - https://explorer.fuse.io/tx/0xfc44d6ded7521fe00de3167b4845adc0df91df2021680cc3dea588179b14bdc4​
BlockReward.emitRewardedOnCycle transaction on fuse - https://explorer.fuse.io/tx/0x76ae7870209c878c1eb120ecde9704902d5c823d67df3ecd55e340aab89e97fe​
Successful validators update transaction on mainnet - https://etherscan.io/tx/0xf43b2abebd64537dbd7d834c9ac7a42ce8a925da5cb5278002ce0687187c8882​
Successful fuse minting transaction on mainnet - https://etherscan.io/tx/0x2bd70ecbff6e84c18306701eb380e558a7340fab61aadf1af7690021aeeef5ce​
​
Vote
Contract Addresses
Last modified 15d ago
Copy link