4. Consensus, Incentives and Network EconomicsIntroduction and ContextA blockchain is not merely a replicated database. It is a system in which mutually distrustful participants attempt to maintain a common history without relying on a central administrator. The central technical problem is consensus: how should independent nodes decide which transactions belong in the authoritative sequence, and how should they respond when some participants are dishonest, unavailable, or economically motivated to manipulate the system? Consensus cannot be evaluated only by asking whether a protocol reaches agreement. A useful analysis must also consider the cost of participation, resistance to censorship and rewriting, transaction performance, governance, environmental impact, distribution of power, and the incentives that shape participant behaviour. These concerns connect cryptography and distributed systems with economics. A protocol may be mathematically secure but economically fragile; it may be highly efficient but dependent on a small group of operators; or it may be decentralized in ownership while remaining centralized in governance or infrastructure. This chapter examines Proof of Work (PoW), Proof of Stake (PoS), Byzantine fault-tolerant (BFT) protocols, and alternative consensus models. It also develops an economic perspective based on rewards, penalties, opportunity costs, token supply, market structure, and attack profitability. The objective is not to identify one universally superior mechanism, but to enable informed selection and critical evaluation for different blockchain applications. Learning ObjectivesBy the end of this chapter, students should be able to: 1. Explain the purpose and assumptions of blockchain consensus. 2. Distinguish crash faults from Byzantine faults and relate them to system models. 3. Compare PoW, PoS, BFT, and alternative consensus mechanisms using security, performance, decentralization, energy, and incentive criteria. 4. Analyse security thresholds, finality, forks, liveness, and censorship resistance. 5. Evaluate token economics, validator incentives, attack costs, and the effects of governance decisions. 6. Apply a structured framework to select a consensus model for a practical deployment. 7. Identify professional, regulatory, ethical, and operational risks in consensus design. The Consensus Problem in Open and Permissioned NetworksIn a distributed system, nodes must agree on a shared value or ordered log despite communication delays and failures. Consensus normally involves three related properties. Agreement means that honest nodes do not decide conflicting histories. Validity means that a decided value satisfies the protocol’s rules and reflects acceptable input. Termination, often called liveness, means that honest nodes eventually make progress. Blockchain systems add an ordering problem. It is not sufficient to agree that a transaction is valid; nodes must agree on whether it precedes or follows other transactions. Ordering is important when two users spend the same asset, when smart contracts update shared state, or when the order of trades affects price and execution. A crash fault occurs when a node stops responding or becomes unavailable. A Byzantine fault is more difficult: a node may send contradictory messages, fabricate data, selectively censor transactions, or coordinate with other malicious nodes. Classical Byzantine fault models assume that faulty participants may behave arbitrarily. In an asynchronous network, where message delays have no known upper bound, strong guarantees are difficult to achieve simultaneously. Practical protocols therefore make assumptions about synchrony, network connectivity, participant identity, stake, computational work, or economic cost. Permissionless blockchains allow unknown parties to participate. Since identity cannot reliably be used to limit participation, they require a Sybil-resistance mechanism: a way to prevent an attacker from gaining influence simply by creating many identities. PoW uses expenditure of computational energy; PoS uses capital locked in the protocol; some systems use a permissioned membership system, verifiable credentials, or a combination of resources. Consensus should also be distinguished from governance. Consensus determines which state is accepted under existing rules. Governance determines how those rules are changed, who can propose changes, and how disputes are resolved. A chain may have robust block production but weak governance, creating risks during software upgrades, emergency interventions, or contentious forks. A Framework for Evaluating ConsensusA technically mature evaluation considers several dimensions rather than a single throughput figure. Safety is the probability or guarantee that honest nodes will not accept conflicting final histories. Liveness concerns whether valid transactions continue to be processed. Finality describes when a transaction becomes irreversible under the protocol’s assumptions. PoW often provides probabilistic finality: the likelihood of reversal decreases as additional blocks accumulate. Many BFT protocols provide deterministic or economic finality once a quorum certificate is formed. Performance includes throughput, latency, confirmation time, communication overhead, storage growth, and the ability to handle bursts. High theoretical throughput may be less valuable if it requires excessive hardware or creates a small validator set. Decentralization has several dimensions: the number and diversity of validators, distribution of voting power, geographic and jurisdictional spread, client diversity, access to participation, and independence of infrastructure providers. Counting addresses or nodes alone can be misleading because many apparent participants may be controlled by one entity. Security includes resistance to Sybil attacks, censorship, history revision, key compromise, bribery, collusion, denial of service, and attacks on bridges or ancillary services. A protocol’s security threshold must be stated clearly. For example, a system may be safe if fewer than one-third of voting power is Byzantine, while a longest-chain system may require an attacker not to control a majority of effective block-production power for certain guarantees. Economic sustainability asks whether rewards cover the costs and risks of honest participation, whether issuance is acceptable to users, and whether attackers can profit from manipulation. Energy and environmental impact are particularly relevant where consensus requires continuous computation. Finally, operational complexity concerns implementation maturity, monitoring, key management, upgrades, and recovery procedures. Proof of Work: Security Through ExpenditureIn PoW, miners compete to find a value that makes a cryptographic hash satisfy a difficulty condition. The winning miner proposes a block and receives a reward consisting of newly issued units, transaction fees, or both. The protocol normally selects the valid chain representing the greatest accumulated work, sometimes described as the heaviest chain. PoW converts influence into an external cost. An attacker cannot obtain additional voting power merely by generating identities; it must acquire hardware, electricity, and access to infrastructure. Honest miners are expected to extend the chain with the greatest accumulated work because doing so gives them a chance to earn rewards, whereas work on an abandoned branch may have little value. The main security concern is a majority or substantial-hash-rate attack. An attacker with sufficient computational power may reorganize recent blocks, censor transactions, or perform double spending. PoW does not allow an attacker to create valid coins arbitrarily or violate signature rules, but it can influence ordering and history within the limits of accumulated work. The cost and duration of an attack depend on hardware availability, electricity prices, expected rewards, the market value of the asset, and whether rented capacity is available. PoW has important strengths. It can be open to participation, offers a simple Sybil-resistance story, and may remain operational even when participants do not know one another. It also avoids some forms of wealth-based compounding because block production depends primarily on current computational expenditure rather than existing token holdings. Its weaknesses include energy consumption, specialized hardware, mining-pool concentration, latency associated with probabilistic confirmation, and the possibility of temporary forks. Economies of scale in hardware procurement, electricity contracts, and cooling can concentrate mining. Pools may further centralize transaction selection even when individual miners are geographically dispersed. The environmental impact depends on the energy mix and hardware lifecycle, but the relevant policy question is whether the security value justifies the resource expenditure. Proof of Stake: Security Through Locked CapitalPoS selects validators according to stake committed to the protocol, usually with a pseudo-random procedure and rules defining proposal and voting rights. Validators may receive rewards for correct participation and lose some or all of their deposit for equivocation, invalid proposals, or other defined violations. The deposit is intended to make attacks economically costly. PoS removes the need for continuous hash computation and can support faster finality and lower direct energy use. However, its security depends on careful design. The protocol must address nothing-at-stake behaviour, long-range attacks, stake concentration, validator inactivity, key compromise, and the possibility that liquid or delegated stake creates hidden control relationships. Slashing is a penalty for objectively provable misconduct. It is not a universal solution: some failures are difficult to distinguish from honest outages, and aggressive penalties may discourage participation or create operational risk. Inactivity leaks or comparable mechanisms may reduce the influence of validators that fail to participate, while checkpointing and weak-subjectivity assumptions help nodes determine which historical state to trust when joining after a long absence. PoS can create a feedback loop in which large holders earn more rewards and increase their relative influence. Delegation may improve accessibility but may also concentrate voting power in exchanges, custodians, or liquid-staking providers. Thus, nominal participation may be broad while effective governance is concentrated. The economic attack threshold is not simply the percentage of tokens owned. It depends on token liquidity, borrowing markets, lock-up periods, slashing exposure, validator coordination, market reaction, and the distinction between temporary disruption and permanent control. An attacker may attempt censorship without owning enough stake to rewrite the chain, or may bribe validators rather than acquire tokens directly. Byzantine Fault-Tolerant ConsensusBFT protocols generally operate among a known or controlled validator set. Nodes exchange signed messages in rounds and decide when a quorum supports a block or state transition. A common model tolerates fewer than one-third Byzantine voting power for safety and liveness under suitable network assumptions. The exact threshold depends on the protocol and synchrony model. BFT systems can provide rapid, deterministic finality and high throughput when the validator set is moderate. They are therefore common in consortium networks, payment infrastructures, supply-chain systems, and blockchain platforms that separate a permissionless application layer from a selected validator layer. A quorum certificate provides evidence that sufficient validators approved a block. The principal limitation is communication overhead. Many classical protocols require substantial message exchange, and performance may deteriorate as the validator set expands. Membership management is also significant: the system must define admission, removal, identity, key rotation, and responses to collusion. A permissioned BFT network may be highly secure against outsiders while remaining vulnerable to the organizations that control membership. BFT should not be equated with centralization, but its governance assumptions are usually more explicit than those of permissionless systems. If a small consortium controls validator admission, the network’s resistance to censorship and political pressure may be weaker than its cryptographic safety suggests. Alternative and Hybrid ModelsSeveral systems combine or replace the principal mechanisms described above. Delegated Proof of Stake allows token holders to elect a smaller group of block producers. It may improve performance but introduces election dynamics, voter apathy, campaign financing, and producer cartel risks. Proof of Authority assigns validation to identified entities that meet organizational or legal requirements. It is efficient and useful for enterprise settings, but trust shifts toward identity governance and the authority that grants or revokes validator status. Proof of Capacity or storage uses allocated storage resources rather than continuous computation. It may reduce some energy costs but can create hardware and environmental externalities of its own. Proof of History, in systems that use it, is better understood as a cryptographic time-ordering technique that complements rather than independently replaces consensus. Avalanche-style or gossip-based voting uses repeated randomized sampling to achieve probabilistic agreement with comparatively low communication costs under stated assumptions. DAG-based systems organize events or transactions in a directed acyclic graph rather than a single linear chain, potentially increasing concurrency but often requiring more complex finality and conflict-resolution rules. Hybrid protocols may use PoW for open participation and BFT-style checkpoints for faster finality, or PoS for validator selection and BFT voting for block confirmation. Hybrids can combine strengths, but they also combine failure modes and increase implementation complexity. The correct question is not whether a mechanism sounds innovative, but which threat model and operational environment it addresses. Incentives and Network EconomicsConsensus is an incentive system. Participants compare the expected value of honest behaviour with the costs and risks of alternative actions. A simplified validator calculation is: Expected net return = rewards + fees − operating costs − expected penalties − opportunity cost of locked capital. This expression is incomplete unless it also includes market impact, legal exposure, reputational effects, and the probability of failure. Nevertheless, it helps explain why protocol parameters matter. Block rewards often contain issuance and transaction fees. Issuance funds security but dilutes existing holders. Fees align resource use with demand, but high fees may exclude users or encourage transactions to migrate elsewhere. If rewards fall below sustainable operating costs, honest validators may exit, increasing concentration and reducing security. If rewards are excessively high, the token supply may experience inflation that undermines demand. The security budget is the total economic value available to compensate participants for protecting the network. It should be evaluated against the cost of attacks, not simply against the number of validators. A chain with many low-value validators may be less secure than one with fewer but economically committed participants, although concentration creates its own risks. MEV, or maximal extractable value, is profit obtained by controlling transaction ordering, such as arbitrage, liquidation, or sandwich trading. MEV can reward validators for useful market-making and efficient execution, but it can also disadvantage ordinary users and encourage private transaction channels, collusion, or validator centralization. Protocols may respond through encrypted mempools, fair ordering, batch auctions, proposer-builder separation, or explicit redistribution mechanisms. Token design must also consider vesting, treasury control, governance voting, supply caps, staking ratios, delegation, liquidity, and the distribution between users and insiders. A governance token may function simultaneously as a financial asset, voting instrument, security deposit, and means of paying fees. These roles can conflict. For example, making a token highly liquid may facilitate participation but also make bribery and short-term governance attacks easier. Attack Economics and Strategic BehaviourA rational security analysis asks what an attacker gains, what must be purchased or controlled, how long the attack must persist, and what defensive reaction is possible. Relevant attacks include double spending, censorship, stake grinding, bribery, validator collusion, long-range revision, governance capture, denial of service, and attacks on bridges or oracles. An attack may be profitable even when it does not permanently control consensus. For example, temporary censorship may enable liquidation manipulation, while a governance attacker may alter a parameter and then sell the acquired asset. The cost of acquiring voting power may be lower than the value of the decision being controlled. Consequently, token market capitalization is not a reliable measure of attack cost; the relevant quantity may be the readily available float, borrowing liquidity, or cost of coordinating a quorum. Protocols use several defensive strategies: lock-up periods, unbonding delays, slashing, rate limits, quorum requirements, timelocks for governance changes, independent monitoring, client diversity, checkpointing, and social recovery procedures. Each introduces trade-offs. Long unbonding periods improve resistance to rapid exit but reduce liquidity. Slashing deters misconduct but can punish infrastructure failures. Timelocks improve transparency but provide attackers a window if monitoring is weak. Practical Selection FrameworkA project selecting consensus should begin with its threat model rather than with a fashionable mechanism. The following sequence is useful. First, define the participants: are validators known organizations, pseudonymous operators, or any Internet user? Second, identify the required fault tolerance and whether safety or liveness is more critical during network partitions. Third, specify performance requirements, including peak load and acceptable finality delay. Fourth, estimate the economic value secured and compare it with sustainable rewards and plausible attack budgets. Fifth, evaluate decentralization goals, energy constraints, legal requirements, and infrastructure diversity. Sixth, assess governance, upgrades, key recovery, monitoring, and incident response. Finally, test the design against collusion, bribery, censorship, denial of service, and market shocks. For a consortium settlement network with identified banks, BFT may provide appropriate finality and accountability. For a globally open monetary network that prioritizes permissionless participation, PoW or PoS may be more suitable, depending on the desired security and governance model. For a high-throughput application with a small trusted operator set, authority-based or delegated mechanisms may be acceptable, provided that users understand the trust assumption. Applied Case: Choosing Consensus for a Regional Trade NetworkBackgroundConsider an illustrative consortium of twelve logistics companies, customs agencies, insurers, and port operators. It proposes a blockchain for recording shipment milestones, inspection certificates, and release authorizations. The network must support auditability across organizations, process several thousand events per minute, and provide finality within seconds. Participants are legally identifiable, but they do not fully trust one another. Situation and ProblemThe consortium initially proposes PoW because members associate it with strong public-chain security. A feasibility review shows that continuous mining would consume resources without solving the central problem: the consortium already has an admission process and does not need anonymous global participation. The members must decide whether a BFT network, PoA system, or public-chain anchoring is more appropriate. AnalysisThe assets recorded are valuable, but the primary threat is falsification or suppression by one or more participating organizations, not anonymous Sybil creation. The known validator set supports a BFT model. With twelve validators, the consortium can define quorum rules, authenticated membership, key rotation, and procedures for replacing a compromised organization. However, a single organization should not host most validators, and the network should retain independent monitoring. A purely private BFT ledger may be vulnerable to disputes about historical records if the consortium later becomes divided. Therefore, the design includes periodic publication of a hash commitment to an independent public blockchain. The public chain does not process every trade event; it provides an external timestamp and makes undetected retrospective alteration more difficult. Approach and SolutionThe selected architecture uses BFT consensus among the twelve organizations, with a supermajority certificate for finality, strict identity controls, hardware-backed signing keys, and a governance charter defining admission and emergency procedures. Sensitive commercial data remains off-chain, while the ledger stores hashes, permissions, and event metadata. A public-chain anchor is created at regular intervals. Transaction fees are replaced by membership-funded operating costs, and organizations receive no inflationary token. OutcomeThe design meets the latency and throughput requirements and avoids unnecessary PoW energy expenditure. Its security depends on the independence of the consortium members, the integrity of the identity system, and the ability to respond when several organizations collude. The public anchor improves auditability but does not make the private network permissionless or automatically truthful. Learning PointsThe case demonstrates that consensus must match the trust and participation model. BFT can be preferable where membership is known and rapid finality is required. External anchoring can strengthen evidence of history without replacing application-level controls. Most importantly, a consensus protocol cannot verify whether an off-chain inspection actually occurred; it can only preserve the records submitted under its rules. Challenges, Limitations and Common MistakesA frequent mistake is comparing protocols only by transactions per second. Throughput may be achieved by reducing validator diversity, weakening verification, or moving activity off-chain. Another mistake is treating a token’s market value as equivalent to security. Attack cost depends on liquidity, control concentration, and the value extractable from manipulation. Designers may also confuse cryptographic validity with real-world truth. Oracles, administrators, bridges, wallets, and smart contracts can remain vulnerable even when consensus is sound. Governance assumptions are often hidden: emergency keys, upgrade committees, cloud providers, and major staking pools may exercise more practical control than the formal protocol suggests. Other limitations include software bugs, correlated validator failures, poor randomness, inadequate key recovery, regulatory uncertainty, and centralization caused by economies of scale. Permissionless systems face user-experience and compliance challenges; permissioned systems face collusion and gatekeeping risks. Every design should document assumptions, failure modes, recovery procedures, and the consequences of violating thresholds. Ethical, Governance and Regulatory ConsiderationsConsensus design distributes power. Decisions about validator eligibility, rewards, slashing, and governance can advantage some communities over others. Transparent rules and meaningful participation are therefore ethical as well as technical concerns. Operators should disclose concentration, conflicts of interest, material protocol changes, and the risks of delegated voting. Energy-intensive consensus raises questions about environmental externalities, local infrastructure, and responsible resource use. Financial incentives may encourage speculative participation, market manipulation, or exclusion of users unable to afford fees. In regulated contexts, staking services, token issuance, custody, sanctions compliance, and governance rights may attract legal obligations that differ across jurisdictions. Professional practice requires independent security review, documented threat models, access controls, incident reporting, and separation of duties. A consortium should not assume that contractual trust eliminates the need for technical safeguards; nor should a public network assume that pseudonymity eliminates accountability for service providers. Current Developments and Emerging DirectionsConsensus research increasingly focuses on reducing energy use, improving finality, and limiting concentration. Developments include restaking and shared security, modular architectures that separate execution, consensus, settlement, and data availability, rollups that publish proofs or commitments to a base chain, and more sophisticated MEV-management systems. Zero-knowledge proofs can reduce the data or computation that validators must independently repeat, although proving infrastructure may itself become concentrated. Distributed validator technology can separate signing duties across operators, reducing single-key risk. Verifiable delay functions and improved randomness techniques can strengthen leader selection. Governance research is exploring quadratic voting, conviction mechanisms, futarchy-style proposals, and formalized constitutional rules, but each introduces new assumptions and attack surfaces. The direction of innovation is therefore not simply toward higher speed. It is toward layered systems in which different mechanisms provide execution, ordering, availability, settlement, and dispute resolution. Security analysis must examine the composition of these layers rather than treating the base consensus protocol as the entire system. Best Practices for Evaluation and Deployment- State the threat model, trust assumptions, and fault threshold explicitly.
- Separate safety, liveness, finality, performance, and decentralization claims.
- Measure effective control, not merely the number of validators or token holders.
- Model honest rewards, operating costs, penalties, liquidity, and attack profitability.
- Test censorship, collusion, bribery, key compromise, network partitions, and recovery.
- Use independent implementations, client diversity, secure key storage, and continuous monitoring.
- Design governance timelocks, upgrade controls, and emergency procedures before launch.
- Audit bridges, oracles, staking services, and transaction-ordering infrastructure.
- Disclose energy use, concentration, token distribution, and material conflicts of interest.
- Reassess the protocol after changes in token price, participation, regulation, or application value.
Chapter SummaryConsensus enables independent nodes to maintain a common ordered state despite failures and adversarial behaviour. PoW creates Sybil resistance through computational expenditure and offers open participation, but it consumes energy and may centralize through scale. PoS replaces computation with economically committed stake, reducing direct energy use while introducing issues of concentration, slashing, liquidity, and long-range security. BFT protocols provide fast, often deterministic finality for known validator sets, but depend on membership governance and may incur communication costs. Alternative and hybrid mechanisms should be assessed through their assumptions rather than their labels. A complete evaluation considers safety, liveness, finality, performance, decentralization, energy, governance, and operational complexity. Network economics explains how rewards, fees, issuance, penalties, MEV, liquidity, and attack value influence behaviour. The appropriate consensus model is the one whose security and incentive structure match the application’s participants, threats, performance needs, and governance capacity. Key TermsConsensus: Agreement among distributed nodes on an accepted state or transaction order. Byzantine fault: Arbitrary or malicious behaviour by a participating node. Safety: The property that honest nodes do not accept conflicting outcomes. Liveness: The property that the system continues to make progress. Finality: The condition under which a transaction is considered irreversible under stated assumptions. Sybil resistance: A mechanism preventing influence from being gained cheaply through multiple identities. Proof of Work: Consensus based on demonstrating computational effort through hash-based competition. Proof of Stake: Consensus in which economic stake determines or influences validation power. Validator: A participant that proposes, verifies, or votes on blocks or state transitions. Slashing: A protocol penalty for specified validator misconduct. Byzantine fault tolerance: The capacity to operate despite a defined proportion of malicious participants. Quorum certificate: Cryptographic evidence that enough voting power approved a decision. Probabilistic finality: Finality whose confidence increases but is not absolute after additional confirmations. Security budget: Economic resources available to compensate participants for protecting a network. Maximal extractable value: Value obtained by controlling transaction ordering or inclusion. Delegation: Assignment of voting or staking power to another participant. Governance capture: Control of protocol decisions by a concentrated or hostile group. Long-range attack: An attack that uses historical keys or stake relationships to construct an alternative past. Censorship resistance: The ability of users to submit transactions despite attempts to exclude them. Review QuestionsShort Answer Questions1. Distinguish safety from liveness in a blockchain consensus protocol. 2. Why is Sybil resistance necessary in a permissionless network? 3. What is the economic purpose of slashing in Proof of Stake? 4. Explain probabilistic finality in Proof of Work. 5. Why can a BFT network provide rapid finality with a known validator set? Long Answer Questions1. Compare Proof of Work and Proof of Stake with respect to security, energy, decentralization, and attack economics. 2. Explain how BFT consensus operates and discuss its assumptions and limitations in consortium networks. 3. Analyse the relationship between block rewards, fees, issuance, and a blockchain’s security budget. 4. Discuss how staking concentration, delegation, and liquid markets can affect Proof of Stake governance. 5. Develop a consensus-selection framework for an enterprise blockchain and justify each evaluation criterion. Analytical / Application Questions1. A network has high throughput but only five organizations control all validators. Analyse its safety, liveness, decentralization, and governance risks. 2. A PoS attacker can borrow a large quantity of tokens for one hour but cannot lock them for the protocol’s unbonding period. Explain which attacks may remain feasible and what defenses are relevant. 3. A public blockchain experiences declining issuance, falling fees, and validator exits. Use network economics to explain the likely security consequences and propose possible responses. 22. Multiple Choice Questions with AnswersQuestion 1Which property ensures that honest blockchain nodes do not accept conflicting histories? A. Liveness B. Safety C. Delegation D. Throughput Correct Answer: B. Safety Question 2What primarily provides Sybil resistance in Proof of Work? A. Legal identity checks B. Token delegation C. Computational expenditure D. Governance voting Correct Answer: C. Computational expenditure Question 3A major advantage of a classical BFT protocol with a known validator set is: A. Unlimited anonymous participation B. Deterministic finality after quorum approval C. Elimination of membership governance D. No communication overhead Correct Answer: B. Deterministic finality after quorum approval Question 4Which situation most directly creates a Proof of Stake long-range attack risk? A. A temporary increase in electricity prices B. Use of historical keys to construct an alternative chain history C. A reduction in block size D. A validator using energy-efficient hardware Correct Answer: B. Use of historical keys to construct an alternative chain history Question 5Why might a high nominal validator count fail to demonstrate effective decentralization? A. Validators always have identical hardware B. Many validators may be controlled by one entity or service C. More validators necessarily reduce security D. Validator identities cannot use cryptography Correct Answer: B. Many validators may be controlled by one entity or service Question 6Which expression best represents a validator’s simplified expected net return? A. Rewards plus fees plus penalties B. Rewards minus all transaction volume C. Rewards and fees minus costs, expected penalties, and opportunity cost D. Token price multiplied by validator count only Correct Answer: C. Rewards and fees minus costs, expected penalties, and opportunity cost Question 7What is a principal concern associated with maximal extractable value? A. It prevents all transaction ordering B. It may encourage ordering manipulation and private transaction channels C. It eliminates arbitrage opportunities D. It makes signatures unnecessary Correct Answer: B. It may encourage ordering manipulation and private transaction channels Question 8A consortium of identified organizations requires fast finality and moderate validator scale. Which model is generally the closest fit? A. Classical BFT B. Unrestricted Proof of Work C. A purely anonymous lottery with no membership controls D. A system with no validation process Correct Answer: A. Classical BFT Question 9Why does token market capitalization alone not reliably measure attack cost? A. Market capitalization never changes B. Attackers may need to acquire only liquid or controllable voting power C. Consensus ignores economic incentives D. Tokens cannot be borrowed Correct Answer: B. Attackers may need to acquire only liquid or controllable voting power Question 10What was the main reason for adding public-chain anchoring in the illustrative trade-network case? A. To replace all consortium validators B. To provide external evidence against retrospective alteration C. To create continuous mining rewards D. To make off-chain inspections automatically truthful Correct Answer: B. To provide external evidence against retrospective alteration
|