CBSA Consensus Mechanisms 3 ā Questions and Answers
Question 1: In the Tendermint consensus protocol, what happens if a proposer fails to broadcast a block within the timeout period?
- The network halts until the proposer recovers
- Validators vote nil and the round advances to a new proposer (Correct answer)
- The previous block is re-proposed by another validator
- A new genesis block is created
Correct answer: Validators vote nil and the round advances to a new proposer
Tendermint uses round-based consensus where a timeout triggers validators to vote nil/timeout, advancing to the next round with a new proposer selected by a deterministic rotation.
Question 2: Stellar's Federated Byzantine Agreement (FBA) differs from classical BFT because:
- It requires all nodes to agree on the same validator set
- Each node defines its own quorum slice, enabling decentralized trust (Correct answer)
- It uses Proof of Work as a fallback mechanism
- It only works in permissioned blockchain networks
Correct answer: Each node defines its own quorum slice, enabling decentralized trust
FBA allows each node to choose which nodes it trusts (quorum slices), enabling open membership while still achieving Byzantine fault tolerance without a globally fixed validator set.
Question 3: Which consensus mechanism does Avalanche use to achieve sub-second finality?
- Classical BFT with an all-to-all broadcast
- Metastable consensus via repeated random subsampling of validators (Correct answer)
- Longest-chain rule with 6-block confirmations
- Delegated voting through elected committee
Correct answer: Metastable consensus via repeated random subsampling of validators
Avalanche uses Snow family protocols where nodes repeatedly sample random subsets of validators and adopt the majority preference, converging exponentially fast to consensus.
Question 4: In blockchain consensus, what does 'liveness' guarantee?
- That no two nodes ever commit conflicting blocks
- That the network will eventually make progress and commit new transactions (Correct answer)
- That all nodes maintain identical copies of the ledger at all times
- That validators are always online and responsive
Correct answer: That the network will eventually make progress and commit new transactions
Liveness ensures that valid transactions are eventually included in the blockchain, meaning the system continues to make progress rather than stalling indefinitely.
Question 5: A blockchain architect needs deterministic finality with high throughput for a consortium supply chain network with 20 known participants. Which consensus is most appropriate?
- Nakamoto Proof of Work
- Delegated Proof of Stake with public voting
- BFT-based consensus (e.g., PBFT or Raft) (Correct answer)
- Proof of Elapsed Time (PoET)
Correct answer: BFT-based consensus (e.g., PBFT or Raft)
BFT-based consensus provides immediate deterministic finality and high throughput for small, known validator sets typical in enterprise consortium networks.
Question 6: What role does a 'proposer' play in most BFT consensus protocols?
- It verifies the digital signatures of all transactions in a block
- It collects and orders transactions into a candidate block for validators to vote on (Correct answer)
- It adjusts the mining difficulty target for the network
- It distributes validator rewards at the end of each epoch
Correct answer: It collects and orders transactions into a candidate block for validators to vote on
In BFT protocols, the proposer (or leader) is responsible for collecting pending transactions, forming a candidate block, and broadcasting it to validators who then cast votes.
Question 7: Proof of Elapsed Time (PoET), developed by Intel, achieves random leader election by:
- Requiring validators to submit zero-knowledge proofs of computation
- Using Intel SGX trusted execution environments to generate verifiable random wait times (Correct answer)
- Hashing validator public keys with the previous block hash
- Weighting selection probability by validator stake amount
Correct answer: Using Intel SGX trusted execution environments to generate verifiable random wait times
PoET uses Intel's SGX secure enclaves to ensure each validator waits a cryptographically random time, with the node finishing first earning the right to propose the next block.
In the Tendermint consensus protocol, what happens if a proposer fails to broadcast a block within the timeout period?