The Beldex private blockchain network upgraded its consensus mechanism in December 2021 to Proof of Stake (PoS) via the Bucephalus hardfork after being on the Proof of Work (PoW) consensus. The primary objective of the change was to enhance the network efficiency by reducing the block time, and thereby reduce energy consumption, increase block rewards and maximize scalability.
While PoW requires significant computing and energy-intensive mining, PoS enables users to protect the network with their BDX holdings. This change helps Beldex to become more environmentally friendly and scalable while maintaining its mission of enabling private and censorship-resistant communication through products such as the BChat, BelNet and the Beldex Browser.
So how does the PoS consensus work on the Beldex network? Let us find out.
What is Beldex PoS?
BeldexPoS is the Proof of Stake consensus on the Beldex network. It is a consensus mechanism to validate transactions and append new blocks to the blockchain. While POS validators are selected based on the amount of money they stake or lock up within the network, it works differently in the Beldex network.
While a user can run several masternodes, with each masternode they can only stake a maximum of 10,000 BDX.
These nodes are picked at random to verify and create a block. However, there’s a certain predictability in selecting the masternode validators, which we will delve into later in this article.
The PoS process in Beldex is managed in a way that eliminates challenges and provides safe communication between participating Masternodes through the Quorum, a communication path within the Beldex network.
How Does POS Work in Beldex?
1. Wait for the New Block
The network has to wait until the given time before the next block is created. This is computed using the genesis block of PoS for base time-stamp and the top block hash and height for signatures. The average target block time is 30 seconds.
In case the due time is not yet here, the network will sleep. Once the time is right, it gets ready to enter the next consensus round.
The ideal next block timestamp is determined by
G*Timestamp + (height*TARGET_BLOCK_TIME)
Where ‘G’ is the base POS genesis block, i.e. the hardforking block activating POS (HardFork 17). The actual next block timestamp is determined by
P.Timestamp + (TARGET_BLOCK_TIME ±15s)
Where ‘P’ is the previous block. The block time is adjusted ±15s depending on how close/far away the ideal block time is.
2. Round Preparation
At this stage the network:
The system gets ready for the next PoS round, quorum and stage durations are being calculated with references to the current round by comparing the clock with the ideal block timestamp.
In case any of the stages such as handshake or validation fails, it automatically goes back to the Prepare for Round stage in an attempt to retry, except in cases when POS cannot proceed due to insufficient masternode network.
In such cases, PoS freezes and manual reactivation is required. In this period, PoW blocks are accepted temporarily until the network is prepared to accept PoS once again.
Zoom image will be displayed
POS Consensus in Beldex
3. Wait for the Round to Start
Now, the block producer and validators that are participating in this round verifies the following:
Checks the clock against the next expected POS timestamps. If the expected POS timestamp has arrived, it proceeds, otherwise continues sleeping.
A validator checks for ‘Submit Handshakes’ from other validators. A block producer skips the ‘Wait for Handshake Bitset’ and awaits the final handshake bitsets from all the Validators. (because there are a total of 11 validators and 1 block producer)
4. Send and Wait for Handshakes (Validators)
As a validator, you have to send a handshake first, which confirms that you are online and ready to participate.
You also connect handshakes of other validators, to make sure they are working as well.
5. Send Handshake Bitsets
Once the handshakes are received, each validator transmits a bitset, which is a short data packet containing a list of all validators participating in the round.
This allows the group to verify its quorum participation.
6. Wait for Handshake Bitsets
All participants wait for bitsets from other validators. Once there is agreement (at least 60% participation), the round can proceed.
If this criterion is not met, the round fails, and the procedure begins again, reverting to Prepare for Round.
Agreeing upon the bitsets, Validators skip the ‘Submit Block Template’ round and proceed to the ‘Wait for Block Template’ round.
7. Submit Block Template (Block Producer)
The block producer (a Masternode assigned to this task) now prepares a block template (a candidate block), signs it with the bitset from the block validators and the POS round applied to the block. It then sends it to the selected block validators.
This template provides all the validators with the list of validators for the round as well as any unfinished transactions.
Now, the block producer’s work is done and it awaits the next round (in case a subsequent round fails) or next block.
8. Wait for the Block Template (Validators)
The validators get the block template. They validate it by checking for the signature from the block producer. Once the signature is validated, each validator creates their part of the random value and corresponding hash. These data are then utilized to complete and sign the block.
9. Send and Wait for Random Value Hashes (Validators)
All Validators:
Send the hash of the random value.
Wait for hashes from others.
If not all hashes from the participating validators are received, then we revert to Prepare for Round. This restricts anyone from cheating by altering their value based on what others have sent.
10. Send and Wait for Random Values (Validators)
Once all hashes have been collected, validators share their real random values and wait for random values from others. These are combined to get the final random number used in the block.
If any of the values are missing or invalid, the round fails and resets to Prepare for Round.
11. Send and Wait for Signed Blocks
Every validator now:
Signs the finalized block with the combined random value.
Send their signature to the remainder of the quorum and wait for other such signatures.
Ensures that the same block template that was received at the beginning of the round is signed and no alterations are detected.
The signatures in the block are added in no particular order, as soon as the first N signatures arrive the block can be P2P-ed.
The step by step process and the POS code can be found here:
https://github.com/Beldex-Coin/beldex/blob/master/src/cryptonote_core/pos.cpp
Why Does This Process Matter?
The Beldex PoS consensus process can seem complex, yet every step plays an important part in ensuring:
Security: Only known, staked masternodes may participate.
Participation: The handshake and bitset methods ensure that only active nodes contribute to the block creation process.
Fairness: Random values prevent manipulation in determining who creates or verifies the following block.
Energy Efficiency: Unlike mining, PoS does not require a lot of power or expensive hardware.
Benefits of Beldex PoS
Decentralization: It allows anyone with enough BDX to host a Masternode and participate in governance.
Sustainability: Energy usage is significantly lower compared to PoW.
Speed: Blocks are created on an ongoing timetable, and the process is fast.
Network Resilience: If validators or block producers go down, the system recognizes this and starts with a new round.
Reward Queue: The masternode that produced the block is placed at the end of the reward queue. Thus, every other masternode gets to be a block producer, ensuring fairness in reward distribution.
Closing Thoughts
Making the transition to PoS was an important milestone in Beldex’s growth. It gives the community more authority, improves efficiency, and keeps Beldex’s vision of a private, secure, and censorship-resistant ecosystem.
Understanding how PoS works in Beldex allows users and developers to understand the strong design decisions that support privacy products such as the Beldex Browser, BelNet, and BChat.
However, even PoS has its limitations which can be overcome by continually innovating the way in which block consensus is achieved on the Beldex chain. For this reason, the Beldex team is working to implement the Verifiable Random Functions, an enhanced consensus mechanism that further randomizes the selection of masternodes and increases the number of participating nodes in the quorum, thereby maximizing security, privacy, network’s reliability and resilience against a myriad of attack vectors.
Listen
back to blog