Consensus Security and Distributed-System Threats

Introduction

A blockchain is not secure merely because it uses cryptography. Digital signatures can authenticate messages, and hash functions can make tampering evident, but neither mechanism alone determines which valid transaction history a distributed network should accept. That task belongs to consensus: the set of protocols by which independent participants agree on an ordered, shared state despite failures, delay, manipulation, and sometimes deliberate attack.

Consensus security is therefore a problem in distributed systems as well as cryptography. Participants may disagree because messages arrive at different times, because a node has crashed, or because an adversary has created many false identities. A robust protocol must distinguish temporary disagreement from a permanent violation of the system’s safety or liveness.

This chapter compares proof-of-work (PoW), proof-of-stake (PoS), and Byzantine fault-tolerant (BFT) consensus. It examines forks, probabilistic and deterministic finality, Sybil attacks, 51% attacks, selfish mining, validator collusion, and long-range attacks. It also develops practical methods for assessing consensus risk in blockchain design and operations.

Learning Objectives

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

1. Explain the purpose and security assumptions of blockchain consensus.
2. Distinguish crash faults, Byzantine faults, safety, liveness, and finality.
3. Compare PoW, PoS, and BFT consensus across security, performance, cost, and governance.
4. Analyse forks, reorganisations, Sybil attacks, 51% attacks, selfish mining, validator collusion, and long-range attacks.
5. Apply quantitative reasoning to confirmation risk and Byzantine quorum requirements.
6. Recommend appropriate mitigations for consensus threats in a blockchain deployment.

1. Consensus as a Distributed-Systems Problem

In a distributed ledger, nodes maintain replicas of a state. The state may contain account balances, smart-contract storage, or records of asset ownership. A transaction changes the state only if the protocol considers it valid and sufficiently agreed.

Three properties are especially important:

• Safety: honest nodes do not finalise conflicting states.
• Liveness: valid transactions eventually receive an opportunity to be processed.
• Consistency: honest nodes that follow the protocol converge on the same history or state.

Safety and liveness are not identical. A system that never confirms anything may preserve safety but fail as a usable payment system. Conversely, a system that confirms rapidly without adequate agreement may be live but unsafe.

Fault models

A crash fault occurs when a node stops operating or becomes unavailable. A Byzantine fault is more serious: a faulty participant may send different messages to different peers, sign conflicting statements, censor transactions, or deliberately violate protocol rules. Byzantine behaviour includes both malicious action and arbitrary software malfunction.

Consensus protocols also operate under timing assumptions:

• In a synchronous model, message-delay bounds are known.
• In a partially synchronous model, useful delay bounds eventually hold, but may fail temporarily.
• In an asynchronous model, no fixed upper bound on message delay is assumed.

The classical FLP result shows that deterministic consensus cannot guarantee both safety and liveness in a completely asynchronous system with even one possible crash failure. Practical systems address this limitation by using randomisation, timing assumptions, leader rotation, economic penalties, or accepting temporary unavailability.

2. Security Terminology and Models

Adversarial control

Consensus security depends less on the number of identities than on the resource controlled by an adversary. In PoW, the relevant resource is computational work. In PoS, it is economically bonded stake. In a permissioned BFT system, it is the number of authorised validator identities or organisations.

A useful abstraction is the adversarial fraction:

Here, α is dimensionless. “Consensus resource” means hash power in PoW, effective stake in PoS, or validator voting power in a weighted BFT system. The expression is a measurement, not a universal attack threshold. The threshold depends on the protocol, synchrony assumptions, quorum rules, network topology, and whether the adversary seeks censorship, reorganisation, or conflicting finality.

Sybil resistance

A Sybil attack creates many apparently independent identities. If one identity equals one vote, identity creation can defeat the protocol. Public blockchains therefore use a scarce resource or an admission system:

Sybil resistance does not eliminate collusion. Ten validators may be ten independent operators, or ten identities controlled by one organisation.

Safety, liveness, and finality

Probabilistic finality means that the probability of a reversal decreases as additional blocks are added, but does not become mathematically zero under the protocol’s model. Classical longest-chain PoW systems generally provide this type of finality.

Deterministic or economic finality means that a protocol treats a block as final after a defined voting event or checkpoint. Deterministic finality may rely on a quorum certificate, while economic finality may rely on penalties that make conflicting decisions costly. Finality is never independent of assumptions: a cryptographic key compromise, governance intervention, or sufficiently powerful attack may still threaten the system.

3. Proof-of-Work Consensus

Operation

In PoW, miners assemble transactions into candidate blocks and search for a nonce or related value whose hash satisfies a difficulty condition. A simplified condition is:

H is a cryptographic hash function and T is the target threshold. A smaller target implies a more difficult puzzle. Assuming hash outputs are uniformly distributed, the probability that one trial succeeds is approximately:

where b is the hash output length in bits and T is interpreted as an integer target. The expected number of trials is approximately 1 ÷ p. This calculation applies to independent hash attempts and does not predict the exact time of an individual success.

The chain-selection rule commonly selects the valid chain with the greatest accumulated work, not necessarily the greatest number of blocks. Honest miners extend the chain they regard as authoritative. Temporary differences in propagation can produce competing blocks, called a fork.

Security strengths

PoW has several important properties:

1. Participation can be open without a central identity registrar.
2. Rewriting history requires reproducing or surpassing substantial physical computation.
3. The cost of attack is linked to electricity, hardware, and opportunity cost.
4. Participants need not trust the identities of other miners.

Security limitations

PoW does not prevent an entity with sufficient hash power from censoring transactions, causing reorganisations, or attempting double-spending. It also does not make a blockchain immutable in an absolute sense. Rather, it makes alternative histories increasingly expensive to create.

PoW systems may be exposed to mining-pool concentration, rented hash power, hardware supply-chain dependence, energy-price shocks, and geographic or regulatory concentration. The system’s effective security may be lower than the nominal global hash rate if a small number of pool coordinators control block construction.

4. Proof-of-Stake Consensus

Operation

PoS assigns block-production or voting rights according to stake committed to the protocol. A validator may be required to lock assets, operate software, and sign protocol messages. Selection may be randomised and weighted by effective stake.

PoS commonly separates two roles:

• Block proposal: a selected validator proposes a block.
• Attestation or voting: other validators vote on the block or checkpoint.

A PoS protocol may impose penalties for equivocation, invalid blocks, prolonged inactivity, or attempts to support conflicting histories. The security model therefore combines cryptography, stake accounting, validator monitoring, and governance.

Security strengths

PoS can provide rapid finality, lower energy use, and a direct relationship between protocol influence and economically committed value. Slashing can make certain attacks financially unattractive. Validator participation may also be more accessible than industrial-scale mining, although hardware, capital, custody, and operational expertise remain barriers.

Security limitations

PoS introduces attack surfaces that do not arise in the same form in PoW. Important examples include:

• Nothing-at-stake behaviour: if conflicting branches are cheap to support, validators may sign multiple histories unless the protocol detects and penalises this behaviour.
• Stake concentration: large holders, custodians, exchanges, or liquid-staking intermediaries may accumulate voting power.
• Key compromise: a stolen validator key may be used to sign conflicting messages or participate in historical attacks.
• Stake centralisation through economies of scale: large operators may obtain better infrastructure, liquidity, and delegation access.
• Governance capture: changes to slashing, validator admission, or finality rules may favour dominant stakeholders.

The phrase “nothing at stake” should not be treated as a universal description of all PoS systems. Modern protocols may use slashing, fork-choice rules, withdrawal delays, and checkpoint mechanisms to make conflicting participation detectable and costly.

5. Byzantine Fault-Tolerant Consensus

BFT protocols are designed explicitly to reach agreement despite a bounded number of Byzantine validators. They are common in permissioned blockchains and in PoS systems that use a committee or voting layer.

A typical BFT protocol has proposal, voting, and certificate phases. Validators exchange signed messages. When sufficient voting power supports a block or sequence, the system creates a quorum certificate or equivalent proof.

For an unweighted system with n validators and at most f Byzantine validators, the classical requirement for many partially synchronous BFT protocols is:

The corresponding quorum size is often:

The assumptions are important: the protocol must use an appropriate authenticated-message design, the adversary must control no more than f validators, and the protocol’s timing and view-change conditions must hold. These expressions are not a universal rule for every BFT algorithm.

The safety intuition is quorum intersection. Two quorums of size 2f + 1 in a system of 3f + 1 validators overlap in at least f + 1 validators. At least one member of that overlap must be honest, so honest protocol rules prevent the two quorums from certifying conflicting decisions.

Weighted BFT

Public PoS systems often use voting power rather than equal validator counts. If total voting power is W and Byzantine power is at most F, a common safety condition is that honest voting power exceeds the relevant quorum-intersection threshold. Exact requirements vary by protocol, but a simple majority calculation must not be substituted for a protocol-specific weighted quorum rule.

Strengths and limitations

BFT protocols can provide low-latency deterministic finality and high transaction throughput when validator membership is controlled and network communication is reliable. Their limitations include communication overhead, validator-set governance, denial-of-service risk against known participants, and reduced scalability when every validator must communicate with many others.

6. Comparative Assessment

The correct choice depends on the threat model. A public, censorship-resistant monetary network may value permissionless participation and tolerate probabilistic settlement. A consortium ledger may prefer known validators and fast finality. A hybrid architecture may combine PoS-based validator selection with a BFT finality gadget.

7. Forks, Reorganisations, and Finality

A fork occurs when honest nodes temporarily or permanently follow different valid histories. Forks may be:

• Accidental, caused by simultaneous block production or delayed messages.
• Protocol-induced, caused by a software upgrade or rule change.
• Adversarial, caused by deliberate withholding, censorship, or history rewriting.

A chain reorganisation occurs when a node replaces its previously preferred non-final chain with another chain. In a probabilistic-finality system, users should wait for sufficient confirmations before treating a transaction as economically settled.

Confirmation risk

Suppose an attacker controls a fraction q of the effective PoW hash power, while honest miners control p = 1 − q. If q < p, the attacker’s probability of eventually catching up from a deficit generally decreases as the honest chain’s lead grows. The exact probability depends on the protocol and attack strategy; it should not be reduced to a universal simple exponential formula without stating assumptions.

Operationally, confirmation policy should consider:

• transaction value and reversibility;
• attacker incentives;
• observed hash-power concentration;
• network propagation conditions;
• exchange or merchant risk tolerance;
• whether a checkpoint or finality layer exists.

A finality gadget may allow ordinary blocks to be produced quickly while making selected checkpoints final after a voting threshold. This improves settlement confidence but creates dependence on validator availability and honest voting assumptions.

8. Sybil Attacks

A Sybil attacker manufactures identities to appear more influential than it really is. The attack is especially effective when a protocol uses identity count rather than a scarce resource or trusted admission process.

In a peer-to-peer blockchain network, a Sybil attacker may create many nodes that surround a target node. This can facilitate eclipse attacks, isolate the victim from honest peers, delay information, or present a misleading local chain. Sybil identities may therefore amplify other attacks even when they cannot directly control consensus.

Mitigations

• Require PoW, stake, or authorised credentials for consensus influence.
• Maintain diverse peer connections and periodically rotate peers.
• Use authenticated discovery and rate limits where appropriate.
• Avoid relying on a single network provider, geographic region, or autonomous system.
• Monitor peer-degree changes, unusual inbound connection patterns, and asymmetric views of the chain.
• Use checkpoint or finality information from multiple independent sources.

Sybil resistance must be evaluated at both the consensus layer and the networking layer. A chain may have strong consensus rules but still expose users to eclipse or routing attacks.

9. 51% Attacks

A “51% attack” is an informal term for majority control of a protocol’s effective consensus resource. In PoW it usually means majority hash power; in PoS it may mean a sufficiently large share of stake or voting power; in BFT it means exceeding the protocol’s Byzantine tolerance.

A majority attacker may be able to:

• censor selected transactions;
• reorder transactions;
• perform short-range reorganisations;
• double-spend its own payments;
• prevent honest blocks or votes from being incorporated.

A majority attacker normally cannot create valid signatures for other users, spend coins without their keys, or violate transaction validity rules merely by controlling consensus power. Consensus control and cryptographic key compromise are distinct threats.

In a BFT system designed for n = 3f + 1, controlling more than f validators can threaten safety or liveness, depending on the attack. The threshold is protocol-specific and may be lower in practical terms if one entity controls several nominally independent validators.

10. Selfish Mining

Selfish mining is a PoW strategy in which a miner withholds discovered blocks, privately extending a branch and releasing it strategically to obtain more revenue or cause honest miners to waste work on an inferior branch.

The attacker’s objective may be:

1. increase its share of accepted blocks above its hash-power share;
2. reduce the revenue of honest miners;
3. induce temporary chain instability;
4. discourage miners from joining competing pools.

The profitability of selfish mining depends on attacker hash power, the fraction of honest miners that choose the attacker’s branch during a tie, network propagation, block reward structure, and pool incentives. There is no single universal profitability threshold independent of these variables.

Mitigations include fast block propagation, reducing exploitable tie advantages, transparent pool accounting, diversified mining, protocol rules that discourage strategic withholding, and monitoring unexpected orphan-rate changes. Pool operators should distinguish ordinary temporary forks from statistically unusual withholding patterns.

11. Validator Collusion and Censorship

Validator collusion occurs when several validators coordinate in ways that violate the system’s intended decentralisation or neutrality. Colluding validators may censor transactions, manipulate ordering, vote for conflicting histories, extract maximal value from ordering, or coordinate downtime.

Collusion risk has at least four dimensions:

• Control concentration: voting power held by a small number of entities.
• Organisational commonality: validators operated by the same company or service provider.
• Infrastructure correlation: dependence on the same cloud, data centre, software client, or network route.
• Economic correlation: common investors, custodians, delegation platforms, or liquid-staking tokens.

A validator distribution that appears diverse by address may be centralised by operator, jurisdiction, or infrastructure.

Governance and technical responses

Protocols can use stake caps, delegation transparency, validator-set rotation, geographic and infrastructure diversity, slashing for equivocation, inclusion lists, encrypted transaction ordering, and independent monitoring. However, each intervention has trade-offs. Stake caps may reduce efficiency; inclusion rules may shift power to block proposers; encrypted ordering may complicate auditability; and slashing may punish honest operators during ambiguous network failures.

Censorship resistance is not identical to transaction ordering fairness. A protocol may include every valid transaction eventually while still permitting profitable ordering or short-term priority manipulation.

12. Long-Range Attacks

A long-range attack is most associated with PoS systems in which historical validators can create or endorse an alternative chain from far in the past. If old keys have been withdrawn or sold, former validators may have little economic exposure to the consequences of signing an alternative history. The attacker can attempt to present a fabricated but cryptographically valid-looking chain to a new or offline node.

Long-range attacks exploit the difference between:

• cryptographic validity: signatures verify under known keys; and
• social or protocol legitimacy: the chain is recognised as the canonical history under current rules and checkpoints.

Mitigations

• Weak subjectivity checkpoints obtained through trusted or independently verified channels.
• Finality checkpoints that prevent routine rewriting beyond a finalised point.
• Key-evolution or forward-secure signing designs where appropriate.
• Withdrawal delays and slashing windows that preserve accountability after signing.
• Reliable bootstrapping procedures for new and long-offline nodes.
• Multiple checkpoint sources and governance transparency.

Weak subjectivity is not necessarily a defect; it is an explicit acknowledgement that a node joining after a long absence may need recent external information. The security question is whether checkpoint acquisition is governed transparently and independently rather than hidden as an unexamined trust assumption.

13. Worked Technical Examples

Example 1: BFT quorum sizing

An unweighted BFT network has 10 validators. Using the condition n ≥ 3f + 1, the largest integer f satisfying the condition is found from:

10 ≥ 3f + 1

Therefore 3f ≤ 9, so f ≤ 3. The network can tolerate up to three Byzantine validators under the stated protocol assumptions. A quorum of 2f + 1 = 7 votes is commonly required. If four validators collude, the original fault-tolerance guarantee no longer applies.

Example 2: PoW target probability

Assume a simplified PoW puzzle uses a 32-bit hash output and accepts integer outputs from 0 through 999, inclusive. The target therefore represents 1,000 acceptable outputs out of 2³2 possible outputs. The success probability per independent trial is:

p = 1000 ÷ 2³2 ≈ 2.33 × 10^-7

The expected number of trials is approximately:

1 ÷ p ≈ 4.29 × 10⁶

This is an expectation, not a guarantee. Some miners will succeed earlier and some later. The calculation assumes independent, uniformly distributed hash outputs.

Example 3: Stake concentration

Suppose five entities control voting power of 28%, 22%, 18%, 17%, and 15%. The largest three together control 68%. Even if there are thousands of validator addresses, the effective governance and censorship risk may be concentrated among three entities. Address count alone is therefore an inadequate decentralisation metric.

14. Applied Case: Illustrative Consortium Supply-Chain Blockchain

Background

A consortium of manufacturers, logistics firms, and auditors deploys a permissioned blockchain to record shipment custody. Twelve organisations operate validator nodes. The consortium initially chooses a BFT protocol because participants require rapid finality and membership is governed by contractual admission.

Problem

After deployment, monitoring shows that seven validator nodes use the same cloud provider and two organisations control four validator identities. During a cloud outage, eight nodes become unreachable. In a separate incident, two organisations coordinate to delay records involving a commercial competitor.

Analysis

The nominal validator count suggests a 12-member network, but the independence of those validators is lower than it appears. If the protocol tolerates only three Byzantine validators, controlling four identities can exceed the safety assumption. The cloud concentration creates correlated crash failures, while collusion creates a governance and censorship risk. Fast finality does not compensate for weak membership independence.

Approach and solution

The consortium should:

1. revise the validator policy so one legal entity cannot control multiple voting identities without disclosure;
2. distribute validators across cloud providers, data centres, jurisdictions, and network operators;
3. publish quorum and reconfiguration rules;
4. implement independent audit logs and alerts for conflicting votes;
5. establish a transaction-inclusion and dispute-resolution policy;
6. test validator loss and collusion scenarios before production upgrades;
7. separate operational authority from audit authority;
8. require transparent governance for adding, removing, or replacing validators.

A weighted model may be appropriate if organisations differ in responsibility, but weights should not conceal excessive control by one commercial group.

Outcome

After restructuring, the consortium has fewer correlated failure points, clearer accountability, and a more realistic fault model. The system remains permissioned, but its governance assumptions are now explicit and auditable.

Learning points

The case demonstrates that consensus security depends on organisational and infrastructure independence, not only on protocol mathematics. A formally correct BFT algorithm cannot protect a network whose effective quorum is controlled by one provider or colluding group.

15. Security Assessment Framework

A professional assessment should answer the following questions:

1. What resource determines consensus influence: hash power, stake, identity, or a combination?
2. What is the maximum adversarial resource assumed by the protocol?
3. Is finality probabilistic, deterministic, economic, or hybrid?
4. Can two conflicting blocks or votes receive valid support?
5. What happens when network communication is delayed or partitioned?
6. How are validator keys protected, rotated, and recovered?
7. Can former validators attack old histories?
8. Are operators, cloud providers, jurisdictions, and software clients independent?
9. What evidence detects censorship, equivocation, withholding, or unusual reorganisations?
10. Who can change protocol rules or override finality during an emergency?

Useful operational metrics include reorganisation depth, orphan rate, validator participation, voting-power concentration, missed proposals, peer diversity, client diversity, finality delay, and time to detect equivocation. Metrics must be interpreted with context: a low missed-vote rate does not prove independence, and a high validator count does not prove decentralisation.

16. Ethical, Legal, and Governance Considerations

Consensus design distributes power. Decisions about validator admission, rewards, slashing, emergency intervention, and transaction ordering affect users, businesses, and public institutions.

Ethical governance requires clear rules, due process, proportional penalties, transparent evidence, and a mechanism for correcting protocol defects. Automated slashing should distinguish intentional equivocation from failures caused by software defects, key theft, or ambiguous network conditions. Emergency powers should be narrowly scoped, logged, time-limited, and subject to independent review.

Regulatory obligations may include sanctions compliance, data-protection requirements, operational resilience, financial settlement rules, and reporting duties. Immutability can conflict with privacy obligations when personal data is written directly to a ledger. A secure design should minimise personal data on-chain and use references, commitments, or controlled off-chain records where appropriate.

Artificial intelligence may assist anomaly detection by identifying unusual validator behaviour, peer changes, or voting patterns. It should not independently decide finality or impose irreversible penalties without explainable evidence and human-governed procedures. Adversaries can also manipulate training data and deliberately mimic normal behaviour.

17. Best Practices

• Define the adversary and fault model before selecting a consensus protocol.
• Separate validator identities from assumptions about independent organisations.
• Protect signing keys with hardware security, role separation, and controlled recovery.
• Monitor voting-power concentration and common infrastructure.
• Use finality-aware application logic; do not treat every visible block as irreversible.
• Build alerts for equivocation, deep reorganisations, abnormal orphan rates, and censorship.
• Test network partitions, cloud outages, key compromise, and validator collusion.
• Maintain client, geographic, provider, and governance diversity.
• Document checkpoint and long-offline-node bootstrapping procedures.
• Review consensus parameters after changes in token distribution, delegation, mining economics, or validator ownership.
• Treat emergency governance as part of the security model, not as an exception outside it.

Chapter Summary

Consensus is the mechanism that converts independently observed transactions into a shared ledger history. Its security depends on a resource or membership model that limits Sybil influence and on assumptions about faults, timing, network connectivity, and governance.

PoW secures participation through computational expenditure and generally offers probabilistic finality. Its major concerns include majority hash power, mining concentration, selfish mining, and reorganisations. PoS replaces physical work with economic commitment and may provide efficient finality, but introduces stake concentration, key-management, collusion, and long-range risks. BFT protocols can provide rapid deterministic finality when validator membership and quorum assumptions are controlled, commonly requiring conditions such as n ≥ 3f + 1 for classical unweighted settings.

Forks are not automatically failures; temporary forks may arise from normal network delay. The critical distinction is whether conflicting histories remain reversible or become finalised. Sybil attacks exploit identity multiplicity, 51% attacks exploit majority consensus control, selfish mining exploits block withholding, validator collusion exploits organisational concentration, and long-range attacks exploit historical key and checkpoint weaknesses.

Effective security assessment combines protocol analysis with operational evidence. Validator independence, infrastructure diversity, key protection, governance transparency, monitoring, and recovery procedures are as important as the consensus algorithm itself.

Key Terms

Consensus: The process by which distributed participants agree on a shared state or transaction history.

Safety: The property that honest participants do not finalise conflicting outcomes.

Liveness: The property that valid operations eventually progress.

Byzantine fault: Arbitrary or malicious behaviour by a distributed-system participant.

Proof-of-work: Consensus based on demonstrating computational expenditure.

Proof-of-stake: Consensus based on economically committed stake and validator participation.

BFT: Byzantine fault-tolerant consensus that tolerates a bounded number of malicious participants.

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

Fork: A divergence in valid histories or protocol rules.

Reorganisation: Replacement of a node’s previously preferred non-final chain.

Probabilistic finality: Finality whose reversal probability decreases but is not immediately zero.

Deterministic finality: Finality established by a protocol certificate or quorum event.

51% attack: Majority control of the effective consensus resource.

Selfish mining: Strategic withholding and release of PoW blocks to gain advantage.

Validator collusion: Coordinated validator behaviour that undermines neutrality or protocol assumptions.

Long-range attack: An attack that constructs an alternative historical PoS chain using old validator authority.

Quorum certificate: Evidence that sufficient voting power approved a block or decision.

Weak subjectivity: The requirement that a long-offline or new node obtain trusted recent chain information.

Equivocation: Signing or supporting conflicting protocol statements.

Censorship: Deliberate exclusion or delay of valid transactions.

Review Questions

Short Answer Questions

1. What is the difference between safety and liveness in consensus?
2. Why does a blockchain need Sybil resistance?
3. Define probabilistic finality and deterministic finality.
4. What resource does a classical PoW system use to limit consensus influence?
5. Why can validator address count overstate decentralisation?

Long Answer Questions

1. Compare PoW, PoS, and BFT consensus in terms of resource model, finality, scalability, and principal security risks.
2. Explain how forks arise and distinguish accidental forks, protocol-induced forks, and adversarial reorganisations.
3. Describe selfish mining and analyse the factors that influence its profitability.
4. Explain long-range attacks in PoS systems and evaluate at least four mitigations.
5. Discuss why organisational, infrastructure, and governance diversity are necessary complements to consensus mathematics.

Analytical / Application Questions

1. A BFT network has 13 equal-weight validators. Using the classical condition n ≥ 3f + 1, determine the maximum Byzantine-fault tolerance and a commonly used quorum size. State the assumptions behind your calculation.
2. A PoS network has 40% of its voting power controlled by one liquid-staking provider and 18% controlled by a related exchange. Analyse the principal risks and recommend governance and technical controls.
3. A merchant accepts a high-value payment after one unfinalised PoW block. Identify the relevant threats, explain why one block may be insufficient, and design a confirmation policy using transaction value, attacker incentives, and observed network conditions.

Multiple Choice Questions with Answers

Question 1

Which property means that honest nodes do not finalise conflicting states?

A. Liveness

B. Safety

C. Availability

D. Throughput

Correct Answer: B. Safety

Question 2

In classical PoW, what primarily provides Sybil resistance?

A. Identity documents

B. Computational expenditure

C. Validator elections

D. Transaction size

Correct Answer: B. Computational expenditure

Question 3

For an unweighted classical BFT system with n validators and f Byzantine faults, which condition is commonly required?

A. n ≥ 2f

B. n ≥ f + 1

C. n ≥ 3f + 1

D. n ≥ 4f + 2

Correct Answer: C. n ≥ 3f + 1

Question 4

What is the main characteristic of probabilistic finality?

A. Reversal probability decreases as additional blocks are added

B. No block can ever be reorganised

C. Finality requires no network communication

D. Only authorised identities may transact

Correct Answer: A. Reversal probability decreases as additional blocks are added

Question 5

Which activity best describes selfish mining?

A. Stealing private keys from users

B. Creating many network identities

C. Withholding and strategically releasing mined blocks

D. Encrypting transactions before broadcast

Correct Answer: C. Withholding and strategically releasing mined blocks

Question 6

A 51% attack generally gives an attacker the ability to do which of the following?

A. Create valid signatures for any user

B. Censor or reorganise some consensus history

C. Recover passwords from hashes

D. Read encrypted private messages

Correct Answer: B. Censor or reorganise some consensus history

Question 7

What is a central concern in a long-range PoS attack?

A. Old validators may sign an alternative historical chain with limited current exposure

B. Hash outputs become non-random

C. BFT quorums become larger automatically

D. Transaction fees disappear

Correct Answer: A. Old validators may sign an alternative historical chain with limited current exposure

Question 8

A Sybil attack primarily exploits which weakness?

A. A protocol that gives influence based mainly on identity count

B. A protocol with excessive block size

C. A protocol that uses hardware security modules

D. A protocol with deterministic finality

Correct Answer: A. A protocol that gives influence based mainly on identity count

Question 9

A BFT network has 10 validators. Under n ≥ 3f + 1, what is the largest f it can tolerate?

A. 1

B. 2

C. 3

D. 4

Correct Answer: C. 3

Question 10

Which measure most directly reduces correlated validator failure?

A. Using identical infrastructure for every validator

B. Increasing transaction data stored on-chain

C. Distributing validators across providers and jurisdictions

D. Removing all monitoring systems

Correct Answer: C. Distributing validators across providers and jurisdictions