Origin ,
What is a Consensus Algorithm or agreement in a blockchain, a Vexanium-based Blockchain is a blockchain with rules that are distributed very efficiently, deterministically, and can operate in a decentralized way. The Vexanium Blockchain tracks transactions in the order in which blocks are related. Each block is cryptographically connected and connected to the previous block along the same chain. Therefore it is very difficult to modify transactions recorded on a particular block without violating the cryptographic examination of the block simultaneously and successively. This simple fact makes blockchain transactions irreversible and secure.
Block Producers
In the Vexanium ecosystem, the block production and block validation processes are carried out by special nodes called “Block Producers”. The producer was chosen by the voters / users on the Vexanium chain. Each manufacturer runs an instance of the vexanium node through the nodeos service. For this reason, producers who are on an active schedule for producing blocks are also called “active” or “producing” nodes.
The Importance of a Consensus
Consensus (consensus) in the sense according to the Indonesian dictionary, is a phrase to produce or make an agreement that is mutually agreed between groups or individuals after a debate and research carried out in a collective intelligence to obtain consensus decision making
To validate a block on the vexanium blockchain actually presents a challenge among the nodes / Block Producers in the blockchain network, therefore a consensus model (an agreement) is needed to validate the block to the block, so that a tolerant way is agreed upon in a way. errors in decentralized systems. Consensus is a way for distributed nodes and users to agree on what is happening at the current blockchain (see the next section VEXANIUM Consensus (DPoS + aBFT)
CONSENSUS Model (Consensus)
Before moving to discussing the Consensus Vexanium, it helps us to recognize various ways to reach consensus (agreement) that is popular among a group of Nodes that are distributed in a decentralized system. Most consensus models reach agreement through some evidence. the most popular are Proof of Work (PoW), Proof of Stake (PoS), and DPOS (Delegate Proof Stake), there are indeed several other methods but for learning blockchain 3 these popular methods already represent
1. Proof Of Work
Proof of Work (PoW)
POW is a Popular Consensus and is used by many First Generation blockchain such as Bitcoin, POW (proof of work) is a method of agreement made from a Proof of Work or Proof of Work and Proof of Mining. In POW, the miner node (Miner) competes to find a number added to the block header which causes the block to have some desired properties (usually a zero number in the most significant bit of cryptographic hash of the block header). Making it computationally expensive to find nonce that makes a valid block (nonce is an arbitrary number that can be used only once in cryptographic communication)
The main disadvantage of Proof of Work is that network security depends on spending a lot of resources on computing power to find nonces.
2 Proof Of Stake ( POS)
In Proof-of-Stake, the node that has the largest stake or percentage of assets (the coin used in the blockchain utility has equal decision power. In other words, the power of choice is proportional to the stake owned. One interesting variant of POS is a Delegated Proof-of-Stake (DPoS) where a large number of participants or stakeholders choose a small number of delegates, who in turn make decisions for them.
3. Delegate Proof Of Stake (DPOS) ,Vexanium Consensus
DPOS (Delegate Proof of Stake) was discovered by a Blockchain developer named Dan Larimer, founder of Blockchain Bitshares, Steem and Eos, a Vexanium-Based Blockchain based on a delegated ownership (DPoS) to select active Blockproducers who will be authorized to validate valid blocks in Vexanium-Based Blockchain based on a delegated ownership (DPoS) to select active Blockproducers who will be authorized to validate valid blocks in Vexanium-based Blockchain. Blockchain network. However, this is only half of the Vexanium consensus process. The other half is involved in the actual process of confirming each block to be final (irreversible), which is done by asynchronous byzantine fault tolerant (aBFT). Therefore, there are two layers involved in the Vexanium consensus model:
Layer 1 – Native Consensus Model (aBFT).
Layer 2 – Delegate Proof of Stake Consensus (DPoS).
The original consensus model used in Vexanium does not have the concept of delegating / voting, staking, or even tokens. This is used by the DPoS layer to produce the block manufacturer’s first schedule and, if applicable, update the most sets of each schedule round after each producer block has been rotated. These two layers are functionally separated in the vexanium software.
Layer 1: Native Consensus Model (aBFT)
Layer 1: Original Consensus (aBFT / Asynchronous Byzantine Fault Tolerant)
This layer 1 finally decides which blocks, received and synchronized between (selected blockproducers), finally become final, and therefore permanently recorded in the blockchain, then Blockproducers gets the block production schedule proposed by the second layer layer (DPos) delegated) and use the schedule to determine which blocks are correctly signed by BP (Blockproducers) as appropriate.
For Byzantine fault tolerance (BFT), layer 1 uses a two-stage block confirmation process in which the majority (2/3) two-thirds of the blockproducers of the scheduled schedule currently confirm each block twice. The first confirmation stage proposes the last irreversible last irreversible block (LIB) block. The second stage confirms the proposed last irreversible block (LIB) as final. At this point, the block becomes irreversible. This layer is also used to mark the blockproducer schedule changes, if any, at the beginning of each schedule round.
Algoritma Finality
The Vexanium Blockchain consensus model achieves algorithmic finality through the Digital validation (signature) of the selected set of specific participants (active Block Producer) arranged in a schedule to determine which party is authorized to validate the block at a particular time slot. (It is undeniable that for finality, the best finality can be achieved in the Proof of Work model)
changes to this schedule can also be done with a special smart contract running on the Vexanium blockchain, but any changes that start on the schedule do not take effect until after the block initiating the schedule change has been completed by two confirmation stages. Each confirmation stage is carried out by a supermajority (2/3 Block producer from the active BP series currently scheduled.
Layer 2 Delegated Proof of Stake
The DPoS layer or Proof of Stake Delegation introduces the concepts of tokens, Staking, Voting / proxying, vote reduction, election counting, BlockProducers / Validator ratings, and payment of inflation rewards. The Layer 2 layer is also tasked with producing a new Block Producers schedule from the rankings produced by producer voting. This happens in a schedule rotation of about two minutes (126 seconds) which is the period required for the block manufacturer to be given a time slot to produce and validate the block. Lot time lasts a total of 6 seconds per producer, which is the producer round, where a maximum of 12 blocks can be produced and signed. The DPoS layer is activated by the smart contract / WASM Smartcontrat
Stake Holder dan Delegasi
The actual selection of active producers / Block producers is open to selecting each round of the schedule and involving all the stakeholders who exercise their right to participate. But in practice, the ranking of active producers does not change often. Stakeholders are regular VEXANIUM (VEX) account holders who choose their preferred block producers to act on their behalf as DPoS delegates. However, the main deviation from the regular DPoS is that, once elected, all block producers have the same power regardless of the votes obtained. In other DPoS models, the voting power is proportional to the number of votes obtained by each delegate.
Proses Consensus
The Vexanium Blockchain consensus process consists of two parts:
- Voting / scheduling of producers – done by layer 2 DPoS
- Block production / validation – carried out by original
consensus Layer 1 (ABFT / asynchronous byzantine fault tolerant)
Both of these processes are independent and can be executed in parallel, except for the first schedule round after the boot sequence when the genesis block or block no 1 / first block when the blockchain is created.
Voting and Scheduling Producer
Voting (voting) of active block producers to be included in the next schedule is carried out by the DPoS layer. Actually, the token holder must first have a stake of several VEX coins to become a Stake holder and thus be able to choose the power of the given stake.
Voting Process / Voting Process on Blockchain
Each Vexanium stake holder can actually choose up to 30 block producers in one selection act, but for each block producers selected, the vote value will split, for example, if you choose 2 blockproducers, your votes will be divided (2). well, the main Block Producers or active producers are 21 Block Producers, for the top 21 selected block producers will then act as DPoS delegates to produce and sign the block on behalf of the stake holders. Other remaining Block Producers are placed in the Standby / Standby blockproducers list in the order in which the votes were obtained. The voting process repeats each round of the schedule by adding the number of votes obtained by each Block producers. Block Producers did not choose to retain their old votes, even though they depreciated due to decay. Blockproducers who vote can also retain their old votes, except for the contribution of the final vote weight for each voter, which will be replaced by their new vote weight.
Voting Weight
Voting weight of each stakeholder is calculated as a function of the number of VEX coins that are stored and the time elapsed since the time of the Vexanium block timestamp, defined as January 1, 2000. In the current implementation, the weight of the voting is directly proportional to the amount Token and Base-2 tokens are proportional to the time elapsed in the year since 2000. Actual weight increases at a rate of 2 1/52 = 1.013419 per week. This means that the weight of the vote changes every week and doubles every year for the same amount of coin.
Vote Decay
An increase in votes (voting) results in the current depreciation of votes held by each blockproducers. Such noise reduction is intentional and there are two reasons:
Encourage participation by allowing newer votes to weigh more than older votes.
Give more votes to users who are actively involved in important governance issues.
Producers schedule
After Bock Producers are selected and selected for the next schedule, they are only sorted alphabetically by producer name. This determines the order of production. Each producer receives the proposed set of producers for the next schedule round in the first block that will be validated from the current schedule round that will start. When the first block containing the proposed schedule is deemed irreversible by the supermajority of the blockproducers plus one, the proposed schedule becomes active for the next round of schedules.
Production Parameters
The block production schedule is divided equally among the selected Block producers. The producer is scheduled to produce the expected number of blocks each round of the schedule, based on the following parameters (per schedule round):
| Parameter | Description | Default | Layer |
| P (producers) | the number of Active blockproducers | 21 | 2 |
| Bp (blocks/producer) | the number of adjacent blocks per Blockproducers | 12 | 1 |
| Tb (s/block) | Producksi block time per block (s: seconds) | 0,5 | 1 |
It is important to mention that Bp (number of adjacent blocks per producer), and Tb (production time per block) are layer 1 consensus constants (ABFT). In contrast, P (number of active producers) is a layer 2 constant that is configured by the DPoS layer, which is activated by the WASM contract.
The following variables can be defined from the parameters above (per round schedule):
| Variable | Description | Equation |
| B (blocks) | Total number of blocks | Bp (blocks/producer) x P (producers) |
| Tp (s/producer) | Production time per producer | Tb (s/block) x Bp (blocks/producer) |
| T (s) | Total production time | Tp (s/producer) x P (producers) |
Therefore, the P value, which is defined at layer 2 (Layer DPos), can change dynamically in the Vexanium blockchain. In practice, however, N is strategically assigned to 21 Block Producers, which means that 15 blockproducers are needed for supermost two-thirds of producers plus one to reach consensus.
Production Default Values
Production Default Value
With the current default: P = 21 Blockproducers selected, Bp = 12 blocks created per producer, and blocks produced every T = 0.5 seconds, current production time is as follows (per round of schedule):
Variable Value
Tp: Production time per producer Tp = 0.5 (s / block) x 12 (block / producer) ⇒ Tp = 6 (s / producer)
T: Total production time T = 6 (s / producer) x 21 (producer) ⇒ T = 126 (s)
When a block is not produced by a particular producer during the specified time slot, the gap results in a blockchain. If the manufacturer continues not to produce blocks outside the given time limit (set by layer 2 constant), the manufacturer is downgraded to the standby list.
Block Lifecycle
The blocks created by BP Blockproducers are active according to a schedule for a specified period of time, then forwarded to other producer nodes to synchronize and validate. This process continues from producer to producer until the producer’s new schedule is approved in the next round of schedules. When a valid block meets consensus requirements (see the Consensus Section above), the block becomes final and is considered irreversible. Therefore, the blocks undergo three main phases during their useful life: production, validation, and finality. Each phase goes through various stages too.
Block Structure
As a sequence of blocks that are chained in a chain of chains called blockchain, the basic unit in a blockchain is a block. The block contains pre-validated transaction records and additional cryptographic overhead such as hashes and signatures required for block confirmation, transaction re-execution during validation, blockchain replays, protection against replay attacks, etc. (See block scheme below).
block schema
| Name | Type | Description |
timestamp | block_timestamp_type | expected time slot this block is produced (ends in .000 or .500 seconds) |
producer | name | account name for producer of this block |
confirmed | uint16_t | number of prior blocks confirmed by the producer of this block in current producer schedule |
previous | block_id_type | block ID for previous block |
transaction_mroot | checksum256_type | merkle tree root hash of transaction receipts included in block |
action_mroot | checksum256_type | merkle tree root hash of action receipts included in block |
schedule_version | uint32_t | number of times producer schedule has changed since genesis |
new_producers | producer_schedule_type | holds producer names and keys for new proposed producer schedule; null if no change |
header_extensions | extensions_type | extends block fields to support additional features (included in block ID calculation) |
producer_signature | signature_type | digital signature by producer that created and signed block |
transactions | array of transaction_receipt | list of valid transaction receipts included in block |
block_extensions | extension_type | extends block fields to support additional features (NOT included in block ID calculation) |
id | block_id_type | UUID of this block ID (a function of block header and block number); can be used to query block for validation/retrieval purposes |
block_num | uint32_t | block number (sequential counter value since genesis block 0); can be used to query block for validation/retrieval purposes |
ref_block_prefix | uint32_t | lower 32 bits of block ID; used to prevent replay attacks |
Some parts of a block are known beforehand when a block is created, so it is added during block initialization. Others are calculated and added during block finalization, such as the Merkle root hash for transactions and actions, block numbers and block IDs, validation of blockproducers that create and validate blocks, etc.
Produksi Block / Block Production
During each block production round schedule, producers on schedule must make Bp = 12 adjacent blocks that contain as many validated transactions as possible. Each block is currently produced in the range Tb = 500 ms (0.5 s). To guarantee sufficient time to produce each block and send to other nodes for validation, the block production time is further divided into two configurable parameters
Maximum processing Interval : time window to push transactions into the block (currently set at 200 ms).
Minimum Propagration Time : time window to propagate blocks to other nodes (currently set at 300 ms).
All transactions that are floating and that have not expired, or fallen as a result of previous failed validations, are stored in the local queue for both inclusion and synchronization blocks with other nodes. During block production, scheduled transactions are applied and validated by the manufacturer on schedule, and if valid, pushed to the block that is delayed in the processing interval. If a transaction falls outside this window, it is not applied and rescheduled for inclusion in the next block. If there are no more block slots available to producers at this time, the transaction is finally taken by another production node (via a peer-to-peer protocol) and pushed to another block. The maximum processing interval is slightly less for the last block (from the producer block Bp rotation) to compensate for network latency during the handoff to the next producer. At the end of the processing interval, no more transactions are allowed on the pending block, and the block passes the finalization stage before being broadcast to other block producers for validation.
The block goes through various stages during production: approve, finalize, sign and validate.
