Consensus

A consensus mechanism(algorithm) is a method of reaching consensus among trustless parties. Blockchain technology is used to determine whether a block is valid. A blockchain network's performance depends on the chosen consensus mechanism's performance and significantly impacts the usability of blockchain applications. This document will look at how WEMIX implemented a high-performance consensus process.

RAFT(Reliable And Fault Tolerant) Algorithm

RAFT is a consensus method that ensures consistency of datastores on all nodes in the cluster by selected leader. Nodes participating in RAFT are either a Leader or a Follower; anyone can become a Candidate during a leader selection. A Leader must create and share data that needs to be synchronized with followers. A Leader announces the leader's existence by periodically sending a heartbeat message to all followers. Each follower randomly selects a timeout value for the leader's heartbeat, and if a heartbeat receives during the timeout period, the timeout resets again. On the other hand, if they do not receive a heartbeat during the timeout, the follower changes the status to a candidate and participates in the leader selection. Conflicts occur if multiple nodes simultaneously participate in a leader selection, so the timeout is determined according to random backoff logic.

WEMIX3.0 Consensus Mechanism

SPoA(Stake base Proof of Authority)

The WEMIX Blockchain is a public blockchain that aims for high-performance real-time service, and block generation is possible only by authorized members in advance. Therefore, the basic consensus algorithm follows PoA. However, WEMIX forces to stake more than a specific amount to give a physical penalty for the malfunction of the elected authority on-chain. This WEMIX blockchain consensus method is defined as SPoA.

Authority

Authority participating in the consensus algorithm of the WEMIX Blockchain implies a consortium that performs the same role as the miner of the consensus mechanism PoW, such as Bitcoin/Ethereum. WEMIX Blockchain, the process of being included in or deleted from the Authority, is determined by voting the existing authority members.

1. Clear identity

2. Legally effective contract with WEMIX Foundation offline

3. Disclosure of basic personal information

4. Staked WEMIX to the system registry contract

After staking is confirmed, any of the existing authority members propose a member add proposal to the governance contract. If more than 50% of the current authority members approve, they will be registered as a new Authority members.

When the Authority receives the transactions created by users, it verifies the transaction details and temporarily stores the transactions that have passed the verification in the Mempool. When an Authority member is elected as a miner, it creates a block header including hash information of the previous block. This process is done automatically by software, and there is no need for the authority member to monitor the network status continuously. However, the authority member should be responsible for managing the firewall and private key of the account so that the computer generating the block is not used maliciously.

Voting, which can be processed in the On-chain Governance contract, is currently supported in the form of dApp by voting for or against and will support various votes in the future. In Phase 1, voting weight is proportional to the amount of staked WEMIX and in Phase 2, the same voting weight is applied regardless of the amount of staked WEMIX. If malicious behavior is detected, the party can be forcibly disqualified from the Authority's voting, and the staked WEMIX is confiscated and may not receive block generation compensation.

The reason for the staking and reward system is to create a justification for all participating authority members to operate under the agreed protocol and to maintain the soundness of the WEMIX blockchain network autonomously.

Miner Selection

Taking Bitcoin's PoW as an example, a miner that generates a block header hash that satisfies the difficulty calculated by the protocol can generate and propagate blocks. Since there is no independent authority for block creation, blocks are created by mutual competition. For this reason, resources are inevitably wasted for block generation competition. Work that satisfies the difficulty condition must be proven, so the block generation time is given a physical constraint (BTC 10 min avg. ETH/15 sec). As a result, PoW has a scalability trilemma, and the introduction of PoS or sharding has been proposed and researched as a realistic solution to solve this problem. However, so far, no public blockchain has operated as PoS in a fully distributed manner.

The WEMIX Blockchain determined that providing the desired service in the public domain was impossible using methods such as PoW or PoS. Initially, consensus such as DPoS, PoA, and PBFT was considered methods, but the WEMIX Blockchain devised SPoA. This new Consortium consensus mechanism borrowed the advantages of DPoS and PoA as the most suitable consensus algorithm. SPoA is introducing the concept of staking to prevent inappropriate actions of the authority members who have formed the Authority and participated through transparent identity information and legal contracts.

The WEMIX Blockchain uses etcd, the implementation of RAFT as a miner selection algorithm to select a miner who creates blocks. Etcd is an open-source distributed key-value repository used to store and manage sensitive information needed by distributed systems. Miner stores lockable tokens in the etcd distributed system and generates blocks. The reason for not using efficient miner selection, such as Round Robin, is to prevent the branching of consensus node networks in distributed systems. Etcd is an efficient way to provide immediate finality of many (40+) authorities with clear responsibilities and authority.

Reward Distribution

Existing consensus algorithms have a structure in which the subject who created the block takes both the block reward and the collected fee. For this reason, in systems that are not based on competition, such as DPoS and PoA, the most critical problem to solve is to divide the Authority of block creation fairly. However, this constraint increases the message to and from Block Producers (BPs) who need to process transactions at high speed, and when traffic is stacked in the queue, frequent changes to the leader to evenly divide the opportunity for block generation cause failure to achieve the best performance. To compensate for these shortcomings, SPoA is designed so that no matter which of the authority members creates a block, a reward may be given in proportion to the amount of WEMIX stacking stored in the authority member. The authority member who created the block must include the block reward distribution in the block header. If it violates the set rules (i.e., recorded in the governance contract), the block is not propagated by other authorities.

All accounts that receive rewards (one per member) are registered by voting, except for the governance coinbase account, which distributes the first system contracts to the governance contract, and the authority member generating the block updates the balance state of the accounts. The calculation result is reflected in the root hash value of Patricia Trie.

If all full nodes, including the authority member, verify the header of the received block and detect that the rule recorded in the governance contract is not accurately reflected, discard the block, remove the member through voting, and confiscate the staked WEMIX.

Block Generation

The governance contract determines the interval between block creation of the WEMIX Blockchain. BP has the logic of generating blocks at a set time (1 sec. of the initial set value) to ensure activity and block finality, regardless of transactions in the mempool. The block creation interval is the value of a variable that can be changed by permission voting.

Block Verification

When a block generated by a miner is propagated to a network through p2p, each full node (including an authority member) receiving the block must self-verify and determine the validity. Authority nodes verify whether the block is generated by a member selected as the miner, the reward is customarily distributed, and transaction details are reflected in the state of the entire system. After the verification, the authority nodes spread the blocks to the neighboring nodes.

The non-authority full node that receives this propagation checks whether the signature of the member included in the header is correct and verifies the transaction details. When it is determined that the transaction recorded in the block is generated according to the rule, it stores the block on the local disk and propagates it to neighboring nodes.

When verifying the propagated block, there are two things that all full nodes must verify first before proceeding with the above process: Miner_Limit and Max_Consecutive_Blocks.

Miner_Limit is defined as follows. When a specific member is determined as a Miner in RAFT, an epoch that can create a block is given, and the purpose of this epoch is to prevent it from being given continuously. All blocks are valid only when the following Miner_Limit is satisfied.

Miner_Limit = floor(SIGNER_COUNT / 2) + 1 (Number of consecutive epochs out of which a miner may only occupy one)

Max_Consecutive_Blocks is the maximum number of consecutive blocks the same Miner can create in an epoch. This value is a variable introduced to limit the height of a diverged block when a hacker attacks the network. In WEMIX3.0, Max_Consecutive_Blocks is 1.

The above two values are a method for ensuring block finality and are designed to minimize the damage a malicious authority member can cause to the network.