Seven chain Consensus
Consensus is a fault-tolerant mechanism that is used in blockchain systems to achieve the necessary agreement on the single state of the network. Seven Chain network is using a Delegated Proof of Stake (DPoS) consensus model. DPoS is a variation of Proof of Stake consensus. In PoS there are a set of validators that are responsible for keeping the network updated and validating the network's state. They do this in turns, every validator has their turn in line. On their turn the validator updates the network's state, and the rest of the validators check that the update is valid.
Consensus contract is used to manage the list of the network validators and delegators
BlockReward contract is calculates the reward amount that validators and delegators will receive on each block validation. The reward size is proportional to validator's stake.
With Voting contract validators are vote on various changes on these 3 base level contracts. All those contracts are proxied with implementation that handles the logic. The implementations can be changed only by the Voting process.
The bridge is used to transfer the Seven Chain native token between Seven Chain and Ethereum networks.
This contract is responsible for handling the network DPos consensus. The contract stores the current validator set and chooses a new validator set at the end of each cycle. The logic for updating the validator set is to select a random snapshot from the snapshots taken during the cycle.
The snapshots are taken of pending validators, who are those which staked more than the minimum stake needed to become a network validator. Therefore the contract is also responsible for staking, delegating and withdrawing those funds.
Stake amount for a validator is the sum of staked and delegated amount to it's address.
This contract is based on non-reporting ValidatorSet described in Parity Wiki
This contract is responsible for generating and distributing block rewards to the network validators according to the network specs (5% yearly inflation).
Another role of this contract is to call the snapshot/cycle logic on the Consensus contract
This contract is based on BlockReward described in Parity Wiki.
This contract is responsible for opening new ballots and voting to accept/reject them. Ballots are basically offers to change other network contracts implementation.
Only network validators can open new ballots, everyone can vote on them, but only validators votes count when the ballot is closed.
Ballots are opened/closed on cycle end.
This contract is responsible for holding network contracts implementation addresses and upgrading them if necessary (via voting).
This page contains :
1. Contracts Overview
2. Stake, Delegate and Withdraw
The basic requirement to become a Seven Chain chain validator is to have a stake amount of at least 100,000 Seven Chain tokens. The stake amount is the sum of staked and delegated Seven Chain tokens of the address. This guide walks trough the process of using MEW (MyEtherWallet.com) in the process of using Seven Chain network.Roadmap - Those functionalities will be built into our Studio and will not require any technical knowledge in the future.
Stake
There are two options to stake (both should be called from the address which would be the validator)
1.Send Seven Chain tokens to the consensus contract - 0x786Aa3227317A2e513cFE20c5897F122650bd671 on the fuse network.
2.Call the `stake` function on the consensus contract - 0x786Aa3227317A2e513cFE20c5897F122650bd671 on the fuse network.
Delegate
Seven Chain token holders who don't want to run a node by themselves but still wish to participate in governing the network can delegate any amount to one of the validators.Delegating is done by calling the `delegate` function on the consensus contract with the validator address as data (see screenshot from MEW).
Withdraw
Both stakers and validators can withdraw their Seven Chain tokens, up to the staked/delegated amount, at any time. The withdrawn amount will be deducted from the validator stake amount, and if the stake amount becomes below the minimum stake amount - the validator will be removed from the Seven Chain chain validators list.There are two options to withdraw:
1.Call the `withdraw` function on the consensus contract with one parameter - the amount to withdraw. This call is for stakers, and will reduce the stake amount of the sender address.
2.Call the `withdraw` function on the consensus contract with two parameters - validator address and amount to withdraw. This call is for both stakers (who can use their own address as the parameter) and for delegators to withdraw their delegated stake on a specific validator.
3. Vote
Seven chain functionality can be change by voting on the contracts implementations. New implementations can be deployed, and opened to vote by validators for others to decide on whether to accept/reject the changes.
Open a new ballot
In order to open a new vote, a validator needs to call the `newBallot` function on the voting contract with the following params:
startAfterNumberOfCycles - number of cycles (minimum 1) after which the ballot is open for voting
cyclesDuration - number of cycles (minimum 2) for the ballot to remain open for voting
contractType
1 - Consensus
2 - BlockReward
3 - ProxyStorage
4 - Voting
proposedValue - address of the new implementation deployed for the relevant contract type
description - text description which should contain the reason/change introduced in the ballot
Check ballot info
Everyone can check all the ballots that were created using the `getBallotInfo` function. This function receives two params:
id - the ballot id
key - account address
Vote
Everyone can vote on open ballots, after the start block has passed and until the end block hasn't yet.
It's important to note that at the end of a vote, only validators count towards the final result.
Voting is done by calling the `vote` function, which receives two params:
id - the ballot id
choice - 1 is accept, 2 is reject
Some other useful functions on the voting contract are:
getQuorumState
Returns the state of a specific ballot id: 1 - in progress, 2 - accepted, 3 - rejected
getAccepted/getRejected
Returns the number of accepts/reject of a specific ballot id.
activeBallots
Returns an array of active ballot ids.
4. 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
2.Consensus.cycle is responsible for several functions. Eventually does the following two actions:
1.Sets the boolean Consensus.ShouldEmitInitiateChange to true
2.Calls BlockReward.onCycleEnd which sets the boolean BlockReward.shouldEmitRewardedOnCycle to true as well
3.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):
1.Consensus.emitInitiateChange
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 fuseoracle-initiate-change and fuseoracle-rewarded-on-cycle are responsible for listening to above events.
3.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).
4.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).
5.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.
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 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)
1.Consensus.emitInitiateChange transaction on fuse - hhttps://explorer-svc.ceewen.xyz/
2.BlockReward.emitRewardedOnCycle transaction on fuse - https://explorer-svc.ceewen.xyz/
3.Successful validators update transaction on mainnet - https://etherscan.io/tx/0xf43b2abebd64537dbd7d834c9ac7a42ce8a925da5cb5278002ce0687187c8882
4.Successful fuse minting transaction on mainnet - https://etherscan.io/tx/0x2bd70ecbff6e84c18306701eb380e558a7340fab61aadf1af7690021aeeef5ce
5. Contract Addresses
Contract
Seven Chain address
Spark Testnet address
Consensus
0x786Aa3227317A2e513cFE20c5897F122650bd671
0xC8c3a332f9e4CE6bfFFcf967026cB006Db2311c7
Block Reward
0x63D4efeD2e3dA070247bea3073BCaB896dFF6C9B
0x52B9b9585e1b50DA5600f7dbD94E9fE68943162c
Voting
0x4c889f137232E827c00710752E86840805A70484
0xcD2601FaDDeD8032fBB5186d928d48D331254B46
Last updated