Dynamic Stake Consensus (DSC): The Penta Concensus Algorithm for Optimized Decentralization, Scalability, and Security

Abstract

As an addendum to the Penta Whitepaper, this article provides a technical overview and description of the Penta blockchain consensus algorithm. Designated ‘Dynamic Stake Consensus,’ the objective of ‘DSC’ is an algorithm for generating validated blocks, and one that attains a functional optimum between decentralization, scalability and security.

Motivation

In part, Dynamic Stake Consensus is a novel consensus algorithm designed by a motivation to avoid forks and to promote ‘fairness’. Fairness, in the sense that participating nodes have equal opportunity to engage in the consensus process, and thereby receive an incentive token (PNT) allocation as compensation for their contribution(s).

There are a number of general features that characterize DSC. Primary is consistently achieving ‘finality’ within a decentralised and multi-stakeholder ecosystem. Finality, being a guarantee that the blockchain data will be immutable, in other words: will never be changed. Following close to ‘finality’ is a triplet of properties: control over processing-time latencies, a secure operating environment and a nominal high transactions per second (tps) throughput rate.

DSC Consensus Process

Terminology

Actor or Agent — any participating node in the consensus process

Authorization — mechanism by which nodes are granted access to participate in the consensus process. For computer networks, Authorization generally is the process of granting access rights and privileges giving someone (or nodes) permission to do something with, or have administration of system resources

BFT — Byzantine Fault Tolerance is the system or process characteristic defined as one that can tolerate the class of failures belonging to the Byzantine Generals’ Problem

Block — a cryptographically signed data structure for storing a group of valid transactions, permanently recording the data on a blockchain (shared ledger) network

Blockchain or Chain — a shared ledger for storing data in which groups of valid transactions, called blocks, form a chronological linked chain. Each block is cryptographically linked to the previous as a historical record of all transactions. Blockchains serve as a way to prevent data fraud and promote immutability of the data.

Candidate — a block nominated, and put forward as validated for appending to a Penta blockchain prior to final block selection

Candidate Node Batch or Candidate Batch — a set of validated Candidate blocks generated from all Consensus Groups

Candidate Pool — the set of authorised nodes that can participate in the consensus process to generate and validate blocks

Commit Message — a message sent to all nodes prior to appending of a block to the chain

Consensus Group — a subset of the Candidate Pool, a group participating with other Consensus Groups to generate and validate blocks

Consensus protocol — encoded in software, a process by which a decentralised computer network reaches agreement on the veracity of a set of data ensuring that shared ledgers are exact copies of one another.

Decentralization — a distributed network where nodes operate in a peer-to-peer fashion. And, an informal measure of a network’s resistance to attack, a function of how broadly control is distributed among different nodes.

Decentralized or Distributed Network — a type of computer network where processing power and data are spread over nodes rather than having a centralised data centre.

Digital Signature — a hash of input data (a document) also called a ‘signature’ using a private key such that anyone with the corresponding public key, the signature and the input data can verify as being secure, not tampered with.

Distributed Ledger — shared ledgers in which data is stored across a network of decentralized nodes.

DSC Cycle, Epoch or Time Window — a specified amount of time, a ‘time window’, ‘cycle’ or ‘epoch’ during which DSC is carried out to generate, validate and append a block to the chain

Ethereum — an open software platform based on blockchain technology enabling developers to deploy smart contracts and build and deploy decentralized applications.

Fairness — a measure of the probability for DSC delegates to be designated as generators (producers) of candidate or validated blocks. If all delegates have an equal probability to become producers then the process is termed ‘completely fair’.

Fork — forks create an alternate version of a blockchain, leaving two or more possible blockchains to run simultaneously on different parts of a network. Forks can mark changes in a blockchain’s validation protocols.

Genesis Block — also known as Block 0 is the block that every other in a blockchain can be linked back to.

Hash or Hashing — taking an arbitrary amount of input data, applying an algorithm to it and generating a fixed-size output data called a ‘hash’. A ‘good’ hash is a one-to-one map of input to output.

ICOs, or Initial Coin Offerings — a form of blockchain project (company) financing where project tokens are made available privately and/or publicly sold on a market exchange.

Incentive Redistribution — a token allocation between nodes taking part in the consensus process.

Ledger — an append-only record store, where records are designed to be immutable, and may hold more general information than just financial transaction data

Message — a data packet transmitted between two nodes in a peer-to-peer network

Node — any one of a group of computers forming part of a decentralised network. Nodes each receive a synchronised, consensus-reached and validated copy of a distributed ledger, called a blockchain.

Participant Pool — the assembly of validated Delegates and Witnesses.

Project — a blockchain startup company. Or literally, an experiment in blockchain technology development

Proposer — a Delegate node selected out of the Delegates in a Consensus Group to put forward a candidate block in the middle processing phase of DSC

Protocols — formal network messaging rules describing how to transmit or exchange data

Public Key Encryption (PKE) — an encryption method where there is a process for generating two keys at the same time (typically called a private and a public key), such that data encrypted using one key can be decrypted with the other

‘RESET’ Block — an empty block containing no transactions, utilised as part of the DSC ‘RESET’ mechanism to abort, restart and reinitialise a DSC cycle

RSA — Random Sorting Algorithm, is Penta’s unique algorithm designed by the Penta research team and underpinning DSC node selection processes. RSA selects (samples) objects out of a ‘bag’ of similar objects, randomly and without bias.

PNT — Penta Network Token, a utility token used as incentive for the DSC consensus process and block validation in the Penta Network.

Staking — purchasing and holding tokens for a fixed period, and possibly earning interest on them

Token — a token is a digital identity for something that can be owned, an alternative and extension to fiat currency.

Transaction — a digitally signed data packet (message) authorizing some particular action associated with the blockchain

Wallet — is a file that contains a collection of private, public keys and ancillary transaction data.

The DSC Consensus Mechanism Diagram

DSC Overview and Description

DSC Participants

Delegates — nodes that take part in block generation and/or validation process. The requirements for nodes to function as delegates include pledging, or ’staking’ an amount of token while securing a specified number of ‘votes’ (node confirmations) to participate in the DSC process.

Witnesses — nodes that function to validate generated blocks. Network voting selects nodes to function as witnesses. As with Delegates, Witnesses are required to stake a token amount, though smaller, to participate. Witnesses verify and cryptographically sign each generated block.

Witness and Delegate Eligibility

A systematic method authorizes nodes to function either as Delegates or Witnesses. During DSC block generation and validation cycles, both Delegate and Witness nodes enter into a dedicated Candidate Pool to participate in the DSC consensus process. Candidate nodes must satisfy at least three criteria in order to take part, including:

1. candidates must receive a minimum number of qualifying votes from active nodes in the network;

2. candidates must stake a specified amount of PNT as incentive to prevent sabotage or other malicious behaviour in the consensus process;

3. candidates must satisfy a basic set of hardware performance and high-availability configuration requirements.

Consensus Groups and Proposer Delegates

From the Candidate Pool, multiple sub-networks called Consensus Groups are formed using the Penta Random Sorting Algorithm, RSA, to select Delegates and Witnesses. Consensus Groups run a BFT to elect a single Proposer (node) from among the Delegates present in each Consensus Group. A Proposer then generates a new, signed block containing a set of transactions. Signed blocks are broadcast to the entire Consensus Group for supermajority approval (66%) and selection to be a Candidate Block.

Each Consensus Group has a total of n Delegate and Witness nodes. The number of Delegates nodes (n1), are bounded as:

and with the number of Witnesses (n2) per group:

n2 = n — n1.

Block Finality

The Candidate Node Batch or Batch contains a set of validated blocks generated from the Consensus Groups. RSA advances one of these for appending to the blockchain. To achieve finality a single block is promoted and appended per DSC cycle. Penta DSC finality is in strong contrast to ‘probabilistic transaction finality’ of other blockchain consensus mechanisms, meaning that transactions are not immediately immutable, but only become so eventually, over time and with subsequent block commits.

Algorithm Model Flow

This section outlines the process flow of the DSC algorithm for Delegates and Witnesses, as applicable to a typical use case.

1. Allocate in-coming transactions to memory — all Delegates receive every transaction. Each transaction is added to an in-memory stack awaiting commitment to a newly generated block by a particular Delegate. But, potentially each Delegate can hold a differently ordered set of transactions on their stack. And, not all transactions will necessarily be committed to the block subsequently generated.

2. Selection to join a consensus group, Delegates and Witnesses, as members of the Candidate Pool, may receive a message for membership in a particular Consensus Group.

3. BFT mechanism initiated, as part of the BFT consensus phase each Consensus Group selects one Delegate as Proposer. The role of the Proposer is to generate a new Candidate Block for their Consensus Group.

4. Candidate Block generated, Proposers group verified transactions together before generating the Candidate Block. Post generation, Proposers sign their candidate block prior to broadcasting a ‘generate’ message to all Consensus Group Witnesses.

5. Block validation, each Consensus Group Witness verifies and signs the messaged candidate block.

6. Consensus Group Proposer collects votes, the Proposer must collect a supermajority (66%) of verification votes to validate the Candidate Block.

7. Candidate Node Batch generated, each Candidate Block is added to the Candidate Node Batch. RSA then selects one of the contained Candidate Blocks, and it is this block that is the final ‘pre-commit candidate’ broadcast to the entire network for appending to the chain.

8. Commit Message sent, the end of a DSC cycle is with all nodes receiving a Commit Message to add the received Candidate Block to their copy of the blockchain (shared ledger). With all nodes agreeing to commit and append the Candidate Block to the ledger, finality is reached and the DSC cycle ends.

9. Cycle restart.

Discussion

Failure Modes

This section outlines the general behaviour of the DSC algorithm following occurrence of a number of different failure modes.

1. Malicious Proposer, if a Consensus Group member discovers that the Proposer is not acting in accordance with consensus policies, the Proposer will be subject to ‘loss of stake’ penalties, and consensus will not be reached. In this case a ‘RESET‘ message is broadcast, and the on-going DSC cycle aborted to ensure stability of the ledger.

2. Transmission error, in case of a network communications issue it might happen that the Proposer does not receive sufficient numbers of votes to validate a Candidate Block. Then, a ‘RESET‘ message is triggered and the current DSC cycle stopped.

3. Timeout, If consensus is not reached within a specified time slice, a ‘RESET‘ message is triggered and all delegates will run BFT to produce a ‘RESET‘ block. ‘RESET’ blocks are empty, not containing any transactions and end the current DSC cycle.

4. ‘RESET‘ message, If consensus is not reached within a specified timeout period or in the case of a malicious event, a ‘RESET’ mechanism (message) is triggered and all delegates will run BFT to produce a ‘RESET’ block that reinitializes a new DSC cycle for continued operation and performance of the Penta Network.

Advantages

Penta’s Dynamic Stake Consensus is designed to provide and judged as having a number of strategic advantages as part of its overall goals and objectives.

Avoiding bad actors, any Delegate or Witness discovered through reporting by a majority of nodes to be engaging in malicious behaviour, or attempts to sabotage the network during the consensus process, will be subject to loss of stake penalties and suspension from participation for a specified time. Additionally, bad actors may lose Delegate or Witness status.

‘RESET’ blocks, in the case of a specific failure mode, if malicious behaviour or bad network activity is discovered, then a ‘RESET’ block can be automatically generated to restart the consensus process. ‘RESET’ events may be initiated by any member of a Consensus Group.

Fault tolerance, for DSC is an increasing function that goes with the size of the Candidate Pool (the number of nodes participating as Delegates or Witnesses). As there is no upper limit on the number of Witness nodes, the number of block validators are then unbounded, resulting in higher probabilities that failure modes will be successfully resolved in a timely way.

Fairness, membership in a particular Consensus Group is determined completely at random. Every node has the same opportunity (equal probability) to participate in the consensus process.

Incentive redistribution — redistribution of PNT incentives is separated into three categories to ensure a fair distribution and avoid any one node asserting undue influence over algorithm decisions.

Considerations and Challenges

RSA, the Random Sorting Algorithm is a key feature of Penta’s DSC Algorithm. Prior to production release RSA needs to be verified as having negligible biases, if any, and validated as robust when subjected to attack. RSA also needs to be shown as capable of the required DSC throughput rates too.

Balancing performance and fairness, DSC is an innovative approach to consensus mechanisms for a distributed peer-to-peer network. The hallmark of DSC is that it seeks to simultaneously optimize three strategic properties of a blockchain consensus mechanism: scalability, security and decentralisation. To date, most and possibly all other algorithms have optimised two of the three, by letting one ‘float’. For instance, maximizing scalability by sacrificing fairness, through limiting block validation authority to a smallish number of trusted ‘super’ nodes.

The realities of network technology infrastructure present another set of challenges for the Penta Network. As an international blockchain platform with opportunity and incentive for anyone from around the world to participate in block generation/validation, it is anticipated that network connectivity, latency, and bandwidth issues will negatively impact the overall performance of the Penta network.

Conclusions

This addendum presented a technical overview to the Penta network Dynamic Stake Consensus algorithm (DSC). A key strategy in its design is achieving an optimised balance between fairness, inclusive participation and scalability requirements. Technical features of DSC include the Random Sorting Algorithm (RSA, a unique random sampling algorithm), multiple Consensus Groups to increase participation and strengthen security, and a Byzantine Fault Tolerant (BFT) mechanism to ensure block finality.

DSC has a high degree of decentralisation through RSA node selection, for high tps operating throughput without a central authority. Plus, Consensus Groups work through ‘short’ interconnected messaging pipelines, minimising network latencies within a group, and optimising overall network performance. Integrated are solutions to potential known failure modes, and a global ‘RESET‘ mechanism to ensure the stability of the entire network.

There are pending technical challenges facing DSC, as with any blockchain consensus algorithm. The proposed resolutions of these issues will require stringent testing in real-world operating environments as part of both TestNet and production platform releases. But, we do not anticipate any immediate limitations on implementations of DSC and Penta blockchain technology to a diverse range of application areas.

As Penta blockchain technology then matures by: international adoption, widespread application, and innovative adaption to a constellation of use cases, it fulfils a leadership role and delivers a host of socio-economic benefits for blockchain’s bright future ahead.