How Venom’s BFT consensus mechanism works in a nutshell
The advent of blockchain technology changed the conventional methods of operation across several industries — Bitcoin transformed financial transactions and Ethereum changed the status quo via smart contracts which helped to create even more advancements. In this treatise, we introduce Venom — a Turing complete Proof-of-Stake blockchain protocol that uses Byzantine Fault Tolerant (BFT) consensus mechanism to validate and execute transactions as well as secure the network. This allows the distributed network to reach a consensus even when some of the nodes in the network fail to respond or respond with incorrect information.
Venom is a fork of Everscale, a new and unique blockchain design that proposes a scalable decentralized world computer, paired with a distributed operating system. Venom, however, presents some novel and distinct properties, such as heterogeneity and dynamic sharding which enables it to be scalable, fast, and secure at the same time. The protocol provides a strong foundation for central bank digital currencies and DApps, empowering many applications in DeFi, NFT, and tokenization domains. In this discourse, we explain Venom BFT consensus mechanism.
Venom BFT Consensus Mechanism Explained
The Byzantine Fault Tolerance (BFT) is an ever-evolving feature of a decentralized protocol that enables it to successfully identify and withstand the actions of rogue nodes or components. This feature is indispensable in systems where the participating nodes are either not well-known or fully trusted. Venom protocol uses this mechanism for block validation and creation as well as securing the network from long-range attacks that are directed toward PoS networks. In order to successfully execute it, the attacker needs to have a large stake (more than half) in the PoS network — analogous to a 51% attack in a PoW network where the attacker needs to have more than half of the total hash rate.
The Venom Blockchain ultimately consists of Masterchain, Workchain, and Shardchain blocks. These blocks must be created, validated, and propagated through the network to all parties concerned, in order for the system to function smoothly and correctly. During the block creation process, validators follow the Catchain consensus algorithm, propose a candidate block, and has voting for a candidate block proposed by other validators. Once the voting is complete, it sends a block receipt — a block hash to other network participants referred to as broadcast protectors (BP). When a BP collects 51% (simple majority) of receipts it will broadcast multiple receipts and a numbered list of validators it got receipts from.
Blockchain data structure — Blocks are sequentially chained together via hash pointers.
The Validators that do not send Block Receipts over some period of time or delay sending are deemed malicious and slashed. Slashing refers to when part or all of a validator’s staked asset is seized when the validator misbehaves (e.g., goes offline, delays block validation, attacks the network, or runs a modified node). The Masterchain will verify the broadcasted message by decrypting the block hash via the multiplication of public keys of validators that provided the receipts and comparing it with the collator’s block hash. If the check for 51% of validators is passed i.e voting threshold is reached, the block will be finalized and included in the chain.
The Masterchain must keep track of the states of the workchains and shardchains (each validator is responsible for validating and creating new blocks in a certain subset of workchains and shardchains), perform all computations requested by the smart contracts in these components, and receive updates about them.
The mechanism of block verification is done by a random validator set from a global set. This help to decrease the threshold of the consensus validation, reducing the amount of time necessary for block finality while simultaneously improving the thread security making it impractical to corrupt any block data.
It is worth mentioning that there is a rotating priority order in each task group. There is a certain priority order imposed on the members of a shard task group, depending on the hash of the previous masterchain, workchain and shardchain block sequence number. This order is determined by generating and sorting some hashes as described above. When a new block needs to be generated, the task group validator (sometimes referred to as Thread in Workchains) selected to create this block is normally the first one with respect to this rotating priority order. If it fails to create the block, the second or third validator may do it and the validator is rewarded accordingly.
Essentially, all of them may suggest their block candidates, but the candidate suggested by the validator having the highest priority wins as a result of the Byzantine Fault Tolerant (BFT) consensus protocol.