Consensus Mechanisms

Introduction

A blockchain is not merely a replicated database. It is a database in which mutually distrustful participants must agree on one ordered history of transactions, often without a central administrator. This agreement is called consensus. A consensus mechanism defines how participants propose blocks, validate proposed histories, resolve conflicting transactions, and determine when a transaction is sufficiently final.

Consensus mechanisms must address two related problems. First, participants must agree on the contents and order of the ledger. Second, the system must remain reliable when some participants are dishonest, unavailable, malicious, or technically faulty. The central design challenge is therefore to achieve agreement under imperfect conditions while balancing security, performance, energy consumption, cost, and decentralization.

This chapter compares Proof of Work (PoW), Proof of Stake (PoS), Byzantine fault-tolerant (BFT) protocols, and related models. It also explains the difference between probabilistic and deterministic finality, evaluates common attacks, and provides a framework for selecting a suitable mechanism for a blockchain application.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and operating principles of blockchain consensus.
2. Distinguish crash faults from Byzantine faults.
3. Describe how PoW, PoS, and BFT protocols select proposers and validate blocks.
4. Compare consensus models using security, performance, energy, and decentralization criteria.
5. Explain finality, forks, validator incentives, and common attacks.
6. Apply a consensus-selection framework to a practical blockchain scenario.

1. The Consensus Problem

In a conventional database, a trusted administrator can decide which transaction is valid and which version of the database is authoritative. In a public blockchain, participants may not trust one another, and identities may be pseudonymous. A consensus mechanism must establish a shared ledger without assuming that every participant is honest.

A useful consensus protocol seeks several properties:

• Agreement: honest participants do not permanently accept different histories.
• Validity: an accepted transaction satisfies the protocol’s rules.
• Termination: honest participants eventually make progress.
• Consistency: the ledger state can be reproduced independently by other nodes.
• Fault tolerance: the network continues to operate despite specified failures.

These properties are subject to assumptions. A protocol may tolerate a certain proportion of malicious voting power, but not unlimited adversarial control. It may require messages to arrive within a known time, or it may work under weaker timing assumptions at the cost of slower finality.

Crash Faults and Byzantine Faults

A crash fault occurs when a node stops responding or becomes unavailable. A Byzantine fault is more serious: a node may send contradictory messages, approve invalid transactions, censor users, or deliberately attempt to confuse other participants. Blockchain protocols are especially concerned with Byzantine faults because participants cannot always be identified or trusted.

The classic Byzantine Generals Problem illustrates the issue. Several commanders must coordinate an action, but some commanders may be traitors. Honest commanders need a common decision even though messages may be deceptive. Blockchain consensus is an operational application of this general problem.

2. Core Design Dimensions

Consensus mechanisms differ along several dimensions.

2.1 Permissioned and Permissionless Networks

A permissionless network allows participants to join without prior approval. Bitcoin and many public smart-contract networks use this model. Since identities are difficult to trust, the protocol must resist Sybil attacks, in which one actor creates many pseudonymous identities.

A permissioned network restricts participation to approved organizations or validators. Membership may be controlled by a consortium, regulator, or network operator. Permissioned systems can use known identities, legal agreements, and efficient BFT protocols, although governance and collusion remain important risks.

2.2 Sybil Resistance

A consensus mechanism needs a scarce resource that limits an attacker’s influence. PoW uses computational work; PoS uses economic stake; permissioned BFT systems use authenticated identities and membership rules. Sybil resistance is not the same as general security: a mechanism may prevent multiple identities but still be vulnerable if one participant controls enough of the scarce resource.

2.3 Safety and Liveness

Safety means that conflicting valid histories are not both finalized. Informally, nothing bad happens. Liveness means that valid transactions continue to be processed. Informally, something good eventually happens.

Safety and liveness can conflict during network instability. A protocol may pause rather than finalize conflicting blocks, preserving safety but reducing availability. Alternatively, it may continue processing under uncertain conditions and risk a fork. This trade-off is particularly important in distributed systems.

2.4 Finality

Probabilistic finality means that the probability of a transaction being reversed decreases as additional blocks are added. PoW chains commonly use this model. A block is not absolutely irreversible merely because it has been included; a competing chain could become longer or more cumulative-work intensive.

Deterministic finality means that, once protocol conditions are satisfied, a block cannot be reversed without violating the protocol’s assumptions or explicitly breaking a finality rule. Many BFT protocols offer deterministic finality. Some modern PoS systems combine a chain-selection mechanism with a separate finality gadget.

3. Proof of Work

3.1 Operating Principle

In Proof of Work, miners compete to solve a computational puzzle. A miner constructs a candidate block and repeatedly changes a nonce or other variable until the block header hash is below a target.

The acceptance condition can be represented as:

where H is a cryptographic hash function, header is the candidate block header, and T is the target threshold. A smaller target represents greater difficulty. The hash function is assumed to behave approximately like a random function, so miners cannot predict a successful nonce more efficiently than repeated trial.

The expected number of trials is approximately:

where p is the probability that one hash attempt satisfies the target and N is the number of attempts until success. This is an expectation, not a guarantee: a miner may succeed immediately or may perform many unsuccessful attempts.

The miner that finds a valid block broadcasts it. Other nodes independently verify the proof, validate the transactions, and follow the chain-selection rule, commonly the chain with the greatest cumulative work. A block’s computational cost makes rewriting history expensive, because an attacker must reproduce the work for the target block and subsequent blocks.

3.2 Security Model

PoW security is commonly discussed in terms of an attacker’s share of total effective hash power. If an attacker controls a sufficiently large share, the attacker may reorganize recent blocks, censor transactions, or perform double-spending attacks. The precise probability of a successful reorganization depends on attacker share, honest-network growth, confirmation depth, network conditions, and the chain-selection rule.

A 51% threshold is a useful warning concept, not a universal exact boundary. An attacker with majority hash power can generally dominate block production, but cannot automatically create coins from nothing or spend coins without valid signatures. The attacker remains constrained by the protocol’s validity rules.

3.3 Strengths and Weaknesses

PoW has several strengths:

• It supports open participation without requiring a trusted identity registry.
• Its security is tied to a measurable external cost.
• Its rules are comparatively simple to verify.
• It has a long history of practical deployment.

Its weaknesses include high energy consumption, specialized hardware, mining-pool concentration, uncertain transaction finality, and relatively limited throughput. Mining also creates geographic and economic dependencies on electricity prices, hardware supply chains, and regulatory conditions.

3.4 Energy and Decentralization

Energy use is not a property of the hash function alone. It depends on the amount and efficiency of hardware deployed, the reward structure, electricity prices, and the value miners expect to receive. PoW converts energy and capital into resistance against history manipulation. The social question is whether that expenditure is justified by the network’s benefits.

PoW can be open to anyone, but practical decentralization may be reduced by economies of scale. Large operators may obtain cheaper electricity, better hardware, and improved access to financing. Mining pools reduce variance for individual miners but concentrate coordination power.

4. Proof of Stake

4.1 Operating Principle

Proof of Stake replaces computational competition with economic commitment. Validators lock native tokens or another approved asset as stake. The protocol selects validators to propose and attest to blocks, usually using pseudo-random procedures influenced by stake and other anti-manipulation techniques.

A validator that behaves correctly earns rewards or fees. A validator that signs conflicting histories, violates protocol rules, or fails specified duties may lose part of its stake. This penalty is called slashing, although not every PoS system uses the same penalty structure.

PoS systems typically separate three roles:

1. Proposal: a selected validator proposes a block.
2. Attestation or voting: other validators evaluate and vote for the block.
3. Finalization: the protocol applies a rule for irreversible or strongly confirmed agreement.

The exact architecture varies. Some systems use a single integrated PoS protocol; others combine a block-production chain with a BFT-style finality layer.

4.2 Security Model

The scarce resource in PoS is economic stake. An attacker generally needs substantial stake or control over validators to influence block selection and finality. However, stake-based security has distinct risks:

• Nothing-at-stake behavior: if signing competing histories is cheap, validators may support multiple branches unless penalties or protocol rules discourage this.
• Long-range attacks: former validators may attempt to create an alternative history using old keys, especially if new nodes lack reliable checkpoints.
• Stake concentration: large holders, exchanges, custodians, or liquid-staking providers may accumulate voting power.
• Correlated failure: validators may use the same cloud provider, client software, or infrastructure.
• Governance capture: wealthy or coordinated stakeholders may influence protocol upgrades.

PoS security therefore depends not only on token ownership but also on validator diversity, slashing rules, key management, client implementation diversity, and social or cryptographic methods for bootstrapping trust.

4.3 Performance and Energy

PoS generally consumes much less energy than competitive PoW mining because validators do not need to perform enormous quantities of hash computations. Hardware requirements are usually lower, although reliable infrastructure, monitoring, storage, and networking remain necessary.

PoS can support faster block production and more explicit finality than many PoW systems, but performance depends on communication patterns, validator count, geographic distribution, block size, and protocol design. Increasing the validator set may improve participation but may also increase message overhead.

4.4 Incentives and Delegation

A validator’s expected return can be represented conceptually as:

where R is net expected return, B is protocol reward, F is fee income, C is operating cost, and P is expected penalty. This is an accounting model rather than a universal protocol equation. Its applicability assumes that rewards, fees, costs, and expected penalties can be estimated over the same time period.

Delegated PoS allows token holders to assign voting power to validators. Delegation may improve participation by allowing non-technical users to participate indirectly. However, it may also create concentration if many users delegate to a small number of popular providers.

5. Byzantine Fault-Tolerant Protocols

5.1 General Principle

BFT protocols are designed for networks in which a known or controlled set of participants may include malicious nodes. They commonly use authenticated messages and several rounds of voting. A representative protocol may have a leader propose a value, validators exchange votes, and a value become committed after sufficient agreement.

For a classical partially synchronous BFT protocol with n validators, a common safety condition is:

where f is the maximum number of Byzantine validators the protocol is designed to tolerate. Under this condition, the protocol can tolerate up to f Byzantine faults, assuming its communication and cryptographic assumptions hold. The condition is associated with many classical authenticated BFT designs; it is not a universal rule for every consensus protocol.

The reason for the threshold is that two conflicting decisions must not both obtain the required quorum. A quorum of 2f + 1 votes is commonly used. Two such quorums among 3f + 1 validators must overlap in at least f + 1 validators, meaning at least one overlapping validator is honest. Honest validators are assumed not to approve conflicting decisions under the protocol rules.

5.2 Example of the Threshold

Suppose a permissioned network has n = 7 validators. The formula gives:

Thus, the protocol is designed to tolerate up to two Byzantine validators. A typical quorum is:

At least five validators must support a decision. This example assumes authenticated communication, the relevant timing assumptions, and correct implementation of the protocol.

5.3 Practical Characteristics

BFT protocols provide fast confirmation and deterministic finality when a quorum can communicate. They are well suited to consortium networks, financial settlement systems, supply-chain networks, and enterprise applications in which participants are known.

Their limitations include membership management, communication overhead, weaker suitability for very large open networks, and vulnerability to liveness failures when more than the tolerated number of validators are unavailable or when the network cannot make progress under its timing assumptions. A malicious leader may delay progress, although many protocols use leader rotation or view changes.

Examples of BFT families include Practical Byzantine Fault Tolerance (PBFT), Tendermint-style protocols, HotStuff-style protocols, and quorum-based protocols used in enterprise blockchain platforms. Their details differ substantially, so the name “BFT” identifies a broad design family rather than one single algorithm.

6. Related Consensus Models

Delegated Proof of Stake

Delegated PoS uses token-holder voting to select a smaller active validator set. It can improve throughput because fewer validators participate directly in each decision. The trade-off is potential political and economic concentration, vote buying, cartel formation, and reduced direct participation.

Proof of Authority

Proof of Authority selects validators based on recognized identities, reputation, legal responsibility, or organizational approval. It is efficient and common in permissioned or consortium settings. Its security depends on the authority-selection process, accountability, and resistance to collusion or censorship.

Proof of History and Hybrid Designs

Some systems use a cryptographic time-ordering mechanism, often called Proof of History, to help nodes agree on event order. Such a mechanism is generally not a complete consensus protocol by itself; it may be combined with PoS or another voting system.

Hybrid systems combine mechanisms. For example, PoW or PoS may determine block production while a BFT-style committee provides finality. Hybrid designs can achieve useful performance and security properties, but they also increase implementation complexity and require careful analysis of interactions between layers.

7. Comparative Evaluation

No mechanism dominates on every criterion. A public monetary network may value open participation and censorship resistance more than low latency. A settlement consortium may value deterministic finality and governance accountability more than anonymous participation.

8. Common Attacks and Defences

Double Spending

A double-spending attack attempts to use the same funds in conflicting transactions. PoW systems reduce this risk by requiring an attacker to replace accumulated work. PoS and BFT systems rely on voting rules, signature checks, economic penalties, and finality conditions.

Censorship

Validators or miners may refuse to include certain transactions. Censorship resistance depends on validator diversity, transaction-relay design, fee markets, governance, and the ability of users to access alternative block producers. No consensus mechanism automatically eliminates social or regulatory censorship.

Eclipse Attacks

In an eclipse attack, an adversary controls a node’s communication partners and isolates it from the honest network. Peer-diversity measures, authenticated communication, address rotation, and independent network connections can reduce the risk.

Selfish Mining and Strategic Withholding

A miner may withhold blocks and later publish them to gain an advantage. The effectiveness of such strategies depends on attacker hash power, network propagation, reward rules, and competing miners’ behaviour. Better block propagation and protocol monitoring can reduce incentives.

Nothing-at-Stake and Long-Range Attacks

PoS protocols address these risks through slashing, checkpointing, withdrawal delays, fork-choice rules, weak subjectivity, and client safeguards. Users joining a PoS network may need a trusted recent checkpoint or social consensus about the canonical chain.

Denial of Service

Attackers may flood validators, exploit transaction-processing costs, or target leaders. Rate limits, fees, redundant infrastructure, leader rotation, and careful resource accounting are important defences.

9. Performance, Scalability, and the Blockchain Trilemma

The term blockchain trilemma commonly refers to the difficulty of maximizing decentralization, security, and scalability simultaneously. It is a useful design heuristic, not a formal theorem that proves no better design is possible.

Throughput is often measured in transactions per second (TPS), but TPS alone is inadequate. A better evaluation includes:

• latency to inclusion;
• latency to finality;
• throughput under realistic transaction sizes;
• validator bandwidth and storage requirements;
• recovery time after failures;
• geographic and organizational distribution;
• cost per transaction;
• resistance to censorship and reorganization.

For a simple capacity estimate, if a block contains B bytes, blocks are produced every τ seconds, and the average transaction occupies s bytes, then idealized transaction capacity is:

This estimate assumes every block is full, transactions have uniform size, and protocol overhead is ignored. Real throughput is lower or different because of signatures, headers, execution limits, propagation delay, contention, and failed transactions.

Scaling techniques include larger or more efficient blocks, sharding, rollups, payment channels, sidechains, and application-specific networks. These techniques may move some consensus work away from the base layer, but they introduce additional trust assumptions, bridge risks, proof systems, or availability requirements.

10. Governance, Ethics, and Regulation

Consensus mechanisms are governance systems as well as technical systems. They determine who may participate, whose decisions count, how failures are punished, and how protocol changes occur.

Important governance questions include:

• Who can change the consensus rules?
• How are validators admitted or removed?
• Who decides whether a controversial fork is legitimate?
• Are penalties proportionate and transparent?
• Can users appeal mistaken slashing or censorship?
• What legal responsibilities attach to validators and infrastructure providers?

PoW raises concerns about energy consumption, emissions, local environmental effects, and hardware waste. PoS raises concerns about wealth concentration, custodial control, and the political power of large token holders. Permissioned BFT systems raise concerns about exclusion, accountability, surveillance, and dependence on institutional authorities.

Regulatory treatment varies by jurisdiction. Organizations should examine energy regulation, financial law, sanctions, data protection, cybersecurity, consumer protection, and legal obligations associated with operating validators. Consensus design does not remove compliance responsibilities.

11. Best Practices for Selecting a Mechanism

A professional selection process should begin with requirements rather than popularity.

1. Define the trust model. Are participants anonymous, known, or legally accountable?
2. Specify fault assumptions. Estimate the number and type of nodes that may fail or collude.
3. Set finality requirements. Distinguish acceptable probabilistic confirmation from deterministic settlement.
4. Measure performance realistically. Test latency, throughput, storage, bandwidth, and recovery.
5. Assess decentralization. Count independent operators, organizations, jurisdictions, clients, and infrastructure providers.
6. Model incentives. Examine rewards, penalties, delegation, operating costs, and attack profitability.
7. Review governance. Document upgrades, emergency procedures, dispute resolution, and validator admission.
8. Plan key and operational security. Use secure signing, monitoring, backups, separation of duties, and incident response.
9. Audit implementation diversity. Avoid dependence on one client, cloud provider, or software library.
10. Conduct adversarial testing. Test partitions, Byzantine messages, leader failure, censorship, overload, and recovery.

12. Illustrative Case: Consortium Trade Settlement Network

Background

A group of eight banks wishes to operate a shared blockchain for recording trade-finance settlements. Participants are known legal entities. Transactions must be final within a few seconds, regulators require auditability, and the network should continue operating if one or two banks experience outages or act maliciously.

Problem

A public PoW network would provide open participation, but its probabilistic finality, variable confirmation time, and energy profile do not match the consortium’s requirements. A fully open PoS network would introduce unnecessary token-governance and validator-admission complexities.

Analysis

The network has n = 8 validators. For a classical BFT design, the tolerated Byzantine fault count is:

A quorum of 2f + 1 = 5 validators is required for a decision. The consortium can use authenticated identities, an agreed membership policy, and deterministic finality. It should nevertheless plan for network partitions and avoid assuming that legal identity alone prevents collusion.

Approach and Solution

The consortium selects a BFT-style protocol with rotating leaders, authenticated messages, quorum certificates, and a formal membership authority. Each bank operates an independent validator node in a separate organization and, where possible, a separate jurisdiction or infrastructure environment. Transactions require authorization from the relevant business parties, while the consensus layer orders and commits valid transactions.

The design includes audit logs, hardware-backed signing keys, monitoring, incident response, and a governance process for adding or removing banks. Performance testing measures finality latency under normal traffic, leader failure, and the loss of two validators.

Outcome

The system achieves rapid deterministic confirmation while preserving a transparent record of which organizations participated in each decision. It does not provide the censorship resistance or open membership of a public blockchain, but those properties were not primary requirements.

Learning Points

The appropriate consensus mechanism depends on the trust and governance environment. A BFT protocol is attractive when membership is known and fast finality is essential. Its security still depends on the membership process, implementation quality, independent operation of validators, and the assumption that no more than the tolerated number of validators behave maliciously.

13. Contemporary Developments

Current blockchain engineering increasingly uses modular architectures. Execution, data availability, ordering, and settlement may be provided by different layers. This can improve specialization and scalability but complicates security analysis because the overall system inherits assumptions from several components.

Restaking and shared-security models allow one economic stake to support multiple services. They may improve capital efficiency but can create correlated slashing, governance conflicts, and systemic contagion if many applications depend on the same validator set.

Zero-knowledge proofs can reduce the data required to verify computation, but they do not replace consensus. A proof may show that a computation was performed correctly; a consensus protocol is still needed to determine which valid state transition is accepted and in what order.

Artificial intelligence can assist with validator monitoring, anomaly detection, capacity forecasting, and incident response. It should not be treated as an autonomous source of consensus truth. AI systems may generate false positives, be manipulated by adversarial data, or lack explainability. Consensus-critical decisions should remain governed by deterministic protocol rules and auditable human governance.

Chapter Summary

Consensus mechanisms allow distributed participants to agree on a shared blockchain history despite failures and adversarial behaviour. PoW uses computational expenditure as Sybil resistance and provides robust open participation, but generally consumes substantial energy and offers probabilistic finality. PoS uses economic stake, validator selection, rewards, and penalties; it is energy-efficient but must address stake concentration, long-range attacks, and governance risks. BFT protocols use authenticated communication and quorum voting to achieve rapid deterministic finality when participants are known and fewer than the tolerated fault threshold behave maliciously.

The comparison of consensus models must include security assumptions, finality, performance, energy, decentralization, governance, and operational cost. No model is universally superior. Permissionless monetary networks may prioritize censorship resistance and open participation, whereas enterprise consortia may prioritize identity, accountability, and fast finality. Professional blockchain design begins with requirements, makes assumptions explicit, tests adversarial conditions, and evaluates the complete socio-technical system rather than the consensus algorithm in isolation.

Key Terms

Consensus: The process by which distributed participants agree on a common ledger state.

Proof of Work: A mechanism that uses computational effort to secure block production.

Proof of Stake: A mechanism that uses locked economic value and validator voting to secure the network.

Validator: A participant that proposes, verifies, or votes on blocks.

Miner: A participant that performs PoW computation and proposes blocks.

Byzantine fault: A malicious or arbitrary failure in which a node may behave inconsistently or deceptively.

Crash fault: A failure in which a node stops operating or communicating.

Finality: The degree to which a confirmed transaction is protected from reversal.

Probabilistic finality: Finality that becomes more likely as additional blocks accumulate.

Deterministic finality: Finality achieved after a protocol decision that should not be reversed under its assumptions.

Sybil attack: An attack using many false identities to gain disproportionate influence.

Slashing: A protocol penalty that removes stake from a validator for specified misconduct.

Quorum: The minimum set of votes required to approve a decision.

Censorship: Deliberate exclusion or delay of valid transactions.

Fork: A divergence in competing versions of blockchain history or protocol rules.

Permissionless network: A network that does not require prior approval to participate.

Permissioned network: A network whose participants or validators are controlled through membership rules.

Delegated Proof of Stake: A model in which token holders elect or delegate authority to a validator set.

Proof of Authority: A model that relies on approved and identifiable validators.

Blockchain trilemma: The design tension among decentralization, security, and scalability.

Review Questions

Short Answer Questions

1. What is the difference between safety and liveness in a consensus protocol?
2. How does Proof of Work provide Sybil resistance?
3. What role does slashing play in Proof of Stake?
4. What is meant by deterministic finality?
5. Why are BFT protocols often suitable for consortium blockchains?

Long Answer Questions

1. Compare Proof of Work and Proof of Stake in terms of security, energy, performance, and decentralization.
2. Explain the significance of the condition n ≥ 3f + 1 in classical BFT protocols.
3. Discuss the main governance and ethical issues associated with PoW, PoS, and permissioned BFT networks.
4. Explain why throughput measured only in transactions per second is insufficient for evaluating a blockchain.
5. Describe how a hybrid consensus architecture may combine block production and finality.

Analytical / Application Questions

1. A permissioned network has seven validators and uses a classical BFT protocol. Determine the maximum Byzantine faults tolerated and the typical quorum size. State the assumptions behind your answer.
2. A public blockchain project values open participation, low energy use, and rapid finality but has a small number of wealthy token holders. Which consensus risks should its designers prioritize, and what mitigations would you recommend?
3. A consortium must choose between PoW, PoS, and BFT for high-value settlement among ten known institutions. Construct a decision using trust model, finality, performance, governance, and fault tolerance as criteria.

Multiple Choice Questions with Answers

Question 1

Which resource primarily provides Sybil resistance in Proof of Work?

A. Computational effort

B. Legal identity

C. Locked voting stake

D. A fixed validator roster

Correct Answer: A. Computational effort

Question 2

What does deterministic finality mean?

A. A transaction becomes cheaper over time

B. A confirmed decision cannot be reversed under the protocol assumptions

C. A miner has found a valid nonce

D. Every node stores every historical transaction

Correct Answer: B. A confirmed decision cannot be reversed under the protocol assumptions

Question 3

For a classical BFT protocol with n = 7 validators, what is the usual maximum f and quorum 2f + 1?

A. f = 1 and quorum = 3

B. f = 2 and quorum = 5

C. f = 3 and quorum = 6

D. f = 2 and quorum = 4

Correct Answer: B. f = 2 and quorum = 5

Question 4

Which is a principal risk specific to economic stake concentration?

A. Mining hardware overheating

B. Large holders controlling validator influence

C. Failure to authenticate consortium members

D. Inability to calculate hash functions

Correct Answer: B. Large holders controlling validator influence

Question 5

Which consensus model is generally most appropriate for a network of known institutions requiring rapid deterministic finality?

A. Classical BFT

B. Uncoordinated PoW mining

C. A network with no validators

D. A purely random transaction order

Correct Answer: A. Classical BFT

Question 6

In the idealized capacity estimate TPS ≈ B/(sτ), what does s represent?

A. The number of validators

B. The block reward

C. The average transaction size in bytes

D. The staking penalty

Correct Answer: C. The average transaction size in bytes

Question 7

What is a Byzantine fault?

A. A node that only loses electrical power

B. A node that behaves arbitrarily or maliciously

C. A block with a small transaction count

D. A validator that earns no fees

Correct Answer: B. A node that behaves arbitrarily or maliciously

Question 8

Why can mining pools reduce practical decentralization in PoW systems?

A. They eliminate cryptographic hashing

B. They concentrate coordination and block-production influence

C. They prevent all users from broadcasting transactions

D. They make finality deterministic

Correct Answer: B. They concentrate coordination and block-production influence

Question 9

Which statement best describes probabilistic finality?

A. Reversal probability generally decreases as additional blocks accumulate

B. A transaction is immediately irreversible by definition

C. Only permissioned networks can use it

D. It requires no chain-selection rule

Correct Answer: A. Reversal probability generally decreases as additional blocks accumulate

Question 10

Which measure can help reduce the risk of a validator eclipse attack?

A. Reducing all network connections to one peer

B. Using diverse peers and independent communication paths

C. Removing transaction signatures

D. Allowing conflicting finalized blocks

Correct Answer: B. Using diverse peers and independent communication paths