Skip to main content

Consensus Mechanism

BBAChain employs a hybrid consensus mechanism combining Proof of Stake (PoS) and Proof of History (PoH) to achieve reliable consensus among nodes in a distributed system. This approach solves the Byzantine Generals Problem, ensuring the system operates correctly even if some nodes are malicious or unreliable.

Table of Contents​

Proof of Stake (PoS)​

Proof of Stake (PoS) is BBAChain's primary consensus mechanism. BBAChain employs a Proof of Stake mechanism, requiring Node Validators to keep a certain amount of BBA in their wallets to participate in the transaction validation process.

How PoS Works​

  1. Validator Staking: Validators must stake BBA tokens to participate in the network
  2. User Staking: Users can stake their BBA on validator nodes in BBAChain's network
  3. Block Selection: When a validator node is selected to execute a new block, stakers are rewarded with BBA
  4. Network Control: This feature gives users more control over BBAChain's network
  5. Energy Efficiency: PoS considerably reduces the cost and energy required for BBA voting compared to Proof of Work systems

Benefits of PoS​

  • Energy Efficient: Significantly lower energy consumption than Proof of Work
  • User Participation: Users can stake BBA and earn rewards
  • Network Security: Validators have economic incentives to act honestly
  • Scalability: Enables high transaction throughput

Proof of History (PoH)​

Proof of History (PoH) is BBAChain's secondary validation mechanism used to ensure the integrity and trustworthiness of system-wide transactions. PoH is a system independent of PoS and is used to verify the timing of transactions on the network.

How PoH Works​

  1. Cryptographic Timestamps: Leader nodes generate cryptographic proofs that verify a specific duration of time has passed since the last proof
  2. Transaction Timing: Every transaction on the network is validated via PoH before being confirmed and added to a new block
  3. Independent System: PoH operates independently from PoS, providing an additional layer of security
  4. Timing Verification: PoH verifies the timing of transactions on the network, ensuring accurate ordering

Benefits of PoH​

  • Security Enhancement: Helps reduce the risk of 51% attacks
  • Network Integrity: Strengthens the security of the BBAChain network
  • Accurate Ordering: Ensures transactions are ordered correctly based on cryptographic timestamps
  • High Throughput: By ordering transactions before consensus, validators can process transactions in parallel
  • Low Latency: Block time is approximately 800ms, providing near-instant confirmation

Derived of Half (DoH)​

Derived of Half (DoH) is BBAChain's mechanism for controlling the supply of new BBA tokens. This mechanism ensures a limited number of new BBAs are generated into BBAChain's network, protecting the value of BBA and preventing inflation in the long run.

How DoH Works​

  1. 12-Month Cycle: The DoH algorithm operates on a 12-month cycle
  2. Halving Mechanism: At the start of every DoH cycle, the number of BBAs generated in the BBAChain network is halved compared to the previous cycle
  3. Supply Reduction: As the supply of new BBA is halved, BBA becomes more scarce
  4. Value Protection: This scarcity could increase the value of BBA should demand rise in the future

DoH Cycle Impact​

  • Community Monitoring: BBAChain's DoH cycle is often viewed as an important event closely monitored by the crypto community
  • Inflation Control: Prevents long-term inflation by reducing new token supply
  • Value Preservation: Protects the value of existing BBA tokens

Algorithm of Dichotomy (AoD)​

Algorithm of Dichotomy (AoD) is BBAChain's consensus algorithm that ensures unanimous agreement among Node Validators across the network, even when some Nodes act maliciously or transmit inaccurate data to the BBAChain network.

How AoD Works​

  1. Unanimous Agreement: Ensures all validators reach the same consensus
  2. Fault Tolerance: Works correctly even when some nodes are malicious
  3. Data Integrity: Prevents inaccurate data from being accepted by the network
  4. Byzantine Fault Tolerance: Handles Byzantine failures where nodes may act arbitrarily

Benefits of AoD​

  • Network Security: Ensures network integrity even with malicious nodes
  • Reliable Consensus: Guarantees validators reach unanimous agreement
  • Data Accuracy: Prevents incorrect data from being accepted
  • Fault Tolerance: System continues to operate correctly despite node failures

Commitment Status​

The commitment metric provides clients with a standard measure of network confirmation for blocks. Clients can use this information to determine their own level of confidence in a transaction's finality.

Commitment Levels​

BBAChain has three commitment levels, each representing a different degree of network confirmation:

  1. Processed: The transaction has been received and processed by the leader node, but not yet confirmed by the network.

  2. Confirmed: The transaction has been confirmed by a supermajority of the cluster (more than 2/3 of validators). At this level, the transaction is very likely to be finalized.

  3. Finalized: The transaction has been finalized and cannot be rolled back. This is the highest level of commitment and represents absolute finality.

tip

For most applications, Confirmed commitment is sufficient. Use Finalized only when absolute finality is required.

Proof of History (PoH)​

Proof of History (PoH) is BBAChain's innovative approach to timestamping and ordering transactions. Unlike traditional blockchains that rely on wall-clock timestamps (which can be inaccurate due to clock drift), PoH uses cryptographic proofs to verify that time has passed.

How PoH Works​

  1. Cryptographic Timestamps: Leader nodes generate cryptographic proofs that verify a specific duration of time has passed since the last proof.

  2. Verifiable Ordering: All data hashed into a PoH proof must have occurred before the proof was generated, creating an immutable ordering of events.

  3. Replay Capability: Blocks can arrive at validators in any order or even be replayed years later, and validators can still verify the correct ordering using PoH proofs.

Benefits of PoH​

  • High Throughput: By ordering transactions before consensus, validators can process transactions in parallel
  • Low Latency: Block time is approximately 800ms, providing near-instant confirmation
  • Reliable Ordering: Cryptographic proofs ensure accurate transaction ordering regardless of network conditions

Fork Generation​

Overview​

In BBAChain, nodes take turns being the leader and generating PoH that encodes state changes. The system can tolerate loss of connection to any leader by synthesizing what the leader would have generated had it been connected.

The number of possible forks is limited to a "there/not-there" skip list of forks that may arise on leader rotation slot boundaries. At any given slot, only a single leader's transactions will be accepted.

Message Flow​

The consensus process follows these steps:

  1. Transaction Ingestion: Transactions are received by the current leader node.

  2. Transaction Filtering: The leader filters and validates incoming transactions.

  3. State Execution: The leader executes valid transactions, updating its local state.

  4. Entry Packaging: The leader packages transactions into entries based on its current PoH slot.

  5. Entry Transmission: The leader transmits entries to validator nodes in signed shreds.

    • The PoH stream includes ticks (empty entries) that indicate leader liveness and the passage of time.
    • A leader's stream begins with tick entries necessary to complete PoH back to the leader's most recently observed prior leader slot.

  6. Entry Propagation: Validators retransmit entries to peers in their set and to further downstream nodes.

  7. Transaction Validation: Validators validate transactions and execute them on their local state.

  8. State Hashing: Validators compute the hash of their state.

  9. Voting: At specific PoH tick counts, validators transmit votes to the leader.

    • Votes are signatures of the hash of the computed state at that PoH tick count.
    • Votes are also propagated via gossip protocol.

  10. Vote Execution: The leader executes votes (as transactions) and broadcasts them to the cluster.

  11. Vote Observation: Validators observe their own votes and all votes from the cluster.

Leader Rotation​

Why Leader Rotation?​

At any given moment, a cluster expects only one validator to produce ledger entries. Having only one leader at a time ensures all validators can replay identical copies of the ledger.

However, a malicious leader could potentially censor votes and transactions. Since censoring cannot be distinguished from network packet loss, the cluster cannot elect a single node to hold the leader role indefinitely.

How Leader Rotation Works​

BBAChain minimizes the influence of a malicious leader by rotating which node takes the lead:

  • Each validator selects the expected leader using the same deterministic algorithm
  • When a validator receives a new signed ledger entry, it can verify that the entry was produced by the expected leader
  • The order of slots assigned to each leader is called the leader schedule
info

Leader rotation happens automatically based on the leader schedule. Validators don't need to manually coordinate leader changes.

Synchronization​

Fast, reliable synchronization is the key reason BBAChain achieves such high throughput.

Traditional Blockchain Limitations​

Traditional blockchains synchronize on large chunks of transactions called blocks:

  • In Proof of Work systems, block times need to be very large (~10 minutes) to minimize the odds of multiple validators producing valid blocks simultaneously
  • In traditional Proof of Stake systems, without reliable timestamps, validators cannot determine the order of incoming blocks
  • The common workaround is to tag blocks with wall-clock timestamps, but due to clock drift and network latency variance, these timestamps are only accurate within an hour or two
  • To compensate, these systems lengthen block times to ensure timestamps are always increasing

BBAChain's Approach​

BBAChain uses Proof of History to solve these synchronization challenges:

  1. Cryptographic Timestamps: Leader nodes timestamp blocks with cryptographic proofs that verify time has passed
  2. Entry Streaming: Blocks are broken into smaller batches called entries, which are streamed to validators in real-time
  3. Optimistic Processing: Validators process entries optimistically before consensus, allowing near-zero delay between receiving the last entry and voting

Optimistic Concurrency Control​

BBAChain implements Optimistic Concurrency Control (introduced in 1981):

  • Validators process transactions optimistically before consensus
  • If consensus is not achieved, a node simply rolls back its state
  • This technique eliminates delays between receiving entries and voting
  • The cluster votes on a hash representing the full ledger up to a specific block height

How It Works​

The Complete Flow​

  1. Transaction Submission: Users submit transactions to the network
  2. Leader Processing: The current leader receives, validates, and executes transactions
  3. PoH Generation: The leader generates PoH proofs to timestamp and order transactions
  4. Entry Creation: Transactions are packaged into entries and streamed to validators
  5. Validator Processing: Validators receive entries, validate transactions, and update their state
  6. Voting: Validators vote on the state hash at specific PoH tick counts
  7. Consensus: When a supermajority of validators agree, the state is confirmed
  8. Finalization: After additional confirmations, the state is finalized

Block Time​

BBAChain technically never sends a "block" in the traditional sense. Instead, it uses the term to describe the sequence of entries that validators vote on to achieve confirmation. The current implementation sets block time to 800ms, providing fast finality while maintaining security.

Next Steps: Explore BBAChain's network architecture or learn how to set up a validator.