Consensus

Overview

A blockchain serves as a decentralized ledger system with numerous nodes independently storing identical transaction records. To append new transaction data to the ledger, the approval of these nodes is essential. Achieving this in an untrusted distributed environment is a complex challenge. Normal operation of a blockchain system implies that each node consistently maintains an identical ledger, contingent on the honesty and reliability of the majority of nodes. To ensure trustworthy nodes collectively oversee ledger transactions, each blockchain system establishes its consensus, akin to the constitution of the blockchain. When the vast majority of nodes adhere to consensus requirements, it guarantees the unquestionable credibility of outcomes, even amid an untrusted distributed environment. Therefore, consensus is a pact among honest nodes, crucial for upholding blockchain stability.

Various blockchain systems employ unique implementations, with several consensus types available, including Proof of Work (PoW), Proof of Stake (PoS), and Delegated Proof of Stake (DPoS). This article will predominantly delve into DPoS consensus, the foundation of the pox blockchain, elucidating its essential components and mechanisms.

Block Producing Process

In a blockchain network, witnesses play a crucial role by gathering freshly generated transactions, scrutinizing their legitimacy, and subsequently bundling them into a block. This block is then documented as a new entry in the ledger, acting as a collective record. The witnesses broadcast this updated ledger page to the entire blockchain network. Subsequently, other nodes within the network receive the new ledger entry, validate the legality of the transaction data it contains, and integrate it into their own ledgers. This iterative process continues as witnesses consistently perform these actions, ensuring that all emerging transaction data within the blockchain system is accurately recorded in the ledger.

DPoS Overview

Consensus in a blockchain system is responsible for selecting witnesses who play crucial roles such as verifying transaction data, maintaining accounts, broadcasting new accounts to other nodes, and securing approval from their peers. In the specific case of Delegated Proof of Stake (DPoS) consensus, the process unfolds as follows:

DPoS identifies certain nodes as witnesses based on the votes they receive. At the blockchain system's inception, a set number of tokens is issued and distributed among nodes. Nodes can apply to become witness candidates by staking a portion of their tokens. Token-holding nodes in the system can vote for these candidates. At regular intervals (every t period), votes for all candidates are tallied, and the top N candidates with the most votes become witnesses for the next t period. This cycle repeats, ensuring a dynamic selection of witnesses through continuous voting and evaluation.

Let us see how it's realized in the context of Pollux:

Definition

  • Pollux: Refers to the Pollux network. The document does not distinguish between Pollux, Pollux blockchain, Pollux blockchain system, etc.

  • POX token: Refers to the equity token issued by and circulating in Pollux, known as POX.

  • Witness Candidates: Nodes eligible for becoming witnesses in POLLUX.

  • Witnesses: Nodes in POX qualified for book-keeping. They are usually called witnesses in DPoS. There will be 27 witnesses in POX, also referred to as super nodes (or SR). Here, we will not distinguish between a bookkeeper, witness, supernode, SR, etc.

  • Bookkeeping: The process of verifying transactions and recording them in a ledger. Because blocks carry ledgers in POLLUX, the bookkeeping process is also called block generation. We will not distinguish between bookkeeping and block generation in the document.

  • Bookkeeping Order: Refers to the block generation order, determined by the descending order of the 27 witnesses based on the number of votes they receive.

  • Block Time: POX sets the block time to be 3 seconds, indicating that a block is generated every 3 seconds.

  • Slot: After each block is generated, it is assigned to a slot, and each block occupies a single slot. For instance, there are 20 slots per minute. If a block is generated during the block time, the corresponding slot is filled. Conversely, if no block is generated, the corresponding slot remains empty until the next block fills a new slot.

  • Epoch: POX defines an Epoch as 6 hours. The last two block times of an Epoch constitute the maintenance period, during which the block generation orders for the next Epoch are determined.

  • Maintenance Period: POX designates a period of two block times, equivalent to 6 seconds, for maintenance. This duration is utilized to tally votes for candidates. In a 24-hour cycle, there are 4 Epochs, and consequently, four maintenance periods. Witnesses pause block production during these maintenance periods, and the block generation order for the next epoch is established.

Election Mechanism:

  • In Pollux, the election mechanism is straightforward, where 1 POX equals one vote.

  • Votes:

    • Each vote in Pollux is represented by 1 POX.

  • Voting Process:

    • Voting for candidates in Pollux is executed through a distinct transaction. Nodes can cast their votes by generating a voting transaction.

  • Vote Counting:

    • At each maintenance period, the votes for candidates are tallied. The top 27 candidates with the highest vote counts secure positions as witnesses for the subsequent Epoch.

Block Generation Mechanism:

The block generation mechanism in Pollux operates within each Epoch, where the 27 witnesses sequentially take their turns based on the predetermined bookkeeping order. It's important to note that witnesses can exclusively generate blocks during their assigned turn in the order. These blocks serve as containers for multiple verified transactions, and witnesses sign the block data using their private key. Vital information, including the witness's signature, address, block height, and the time of block generation, is incorporated into each block.

During this process, witnesses compile the data from various verified transactions, forming a cohesive block. Notably, the hash of the previous block becomes an integral part of each new block, acting as the parent Hash. This inclusion of the previous block's hash establishes logical connections, creating a chain-like structure. As a result, these logically connected blocks collectively form the foundation of the blockchain in Pollux. The interconnected nature of the blocks ensures the integrity and sequential order of transactions within the blockchain system.

  1. Network Issues:

    • Poor network conditions may lead to instances where blocks generated by certain witnesses cannot be received by others at specific times, resulting in invalid transactions (refer to Figures b1 and b2).

  2. Node Reliability:

    • The consistent and reliable operation of every witness cannot be guaranteed at all times (refer to Figure c). Unforeseen circumstances may disrupt the normal functioning of individual witnesses.

  3. Malicious Activities:

    • The presence of malicious witnesses introduces a threat where fork blocks are generated intentionally, aiming to create disruptions and fork the blockchain (refer to Figure d). Such activities can compromise the integrity of the blockchain system.

In an ideal scenario within a DPoS consensus-based blockchain system, the bookkeeping process unfolds seamlessly according to the precalculated bookkeeping order. Witnesses diligently generate blocks in a predetermined turn (refer to Figure a). However, the reality of a blockchain network introduces complexities due to its distributed and untrusted nature, manifesting in the following three challenges:

Operational Foundations of Pollux Blockchain:

The fundamental operational premise of the Pollux blockchain system hinges on the assumption that the majority of nodes within the system are honest and reliable. Essential to the system's security is the integrity of the ledger, wherein malicious attempts to inscribe illegal data are thwarted, and ledger copies across all nodes remain consistent. In the realm of DPoS consensus, the bookkeeping process is entrusted to witnesses, making the reliability of these witnesses paramount for Pollux's safety.

Confirmed Block Principle:

In Pollux, the system introduces the concept of confirmed blocks to ensure irreversibility. Newly produced blocks start as unconfirmed, and only those blocks "approved" by over 70% (27 * 70% = 19, rounded up) of the 27 Witnesses achieve the status of irreversible, commonly referred to as solidified blocks. These solidified blocks, recognized by the entire blockchain network, affirm the confirmation of contained transactions. Noteworthy is that the approval process involves Witnesses producing subsequent blocks after the unconfirmed state block. Importantly, the Witnesses producing these 18 blocks must be distinct from each other and from the Witnesses generating the 103rd block.

Longest Chain Principle:

In the face of a fork, Pollux adheres to the longest chain principle. Honest witnesses, when confronted with a fork, consistently opt to produce blocks on the longest chain, ensuring the network's stability and coherence.

Incentive Model for POX Blockchain:

The POX blockchain implements a robust incentive model aimed at fostering node engagement and network expansion, thereby ensuring the secure and efficient functioning of the blockchain system. Witnesses actively participating in block production tasks are incentivized with POX rewards. As per the model, each confirmed block produced by a witness results in a reward of 48 POX. Furthermore, during the maintenance period of each Epoch, the first 127 witnesses (inclusive of witness candidates) with the highest votes receive proportionate rewards, promoting continuous involvement and support.

Proposal-based Parameter Adjustment:

A distinctive feature of DPoS is the ability to propose on-chain parameter adjustments, wherein witnesses collectively decide the approval of proposals through voting. This approach offers a notable advantage by eliminating the need for hard fork upgrades when introducing new features. The proposal-based parameter adjustment mechanism enhances flexibility and adaptability within the blockchain system, allowing for seamless evolution without the complexities associated with hard forks.

Last updated