5. Major Blockchain Platforms and Ecosystems

Introduction and Context

Blockchain platforms are not interchangeable databases. They embody different assumptions about trust, participation, transaction ordering, programmability, governance, performance, and legal responsibility. Bitcoin was designed primarily as a permissionless monetary network. Ethereum extended the idea by providing a general-purpose execution environment for decentralised applications. Enterprise platforms such as Hyperledger Fabric and R3 Corda were designed for identifiable organisations that require privacy, controlled membership, and legally meaningful governance. Newer platforms, including Solana, Polkadot, and Avalanche, attempt to improve throughput, interoperability, developer flexibility, or scalability while preserving selected properties of decentralisation.

For cybersecurity professionals, platform selection is not simply a question of transaction speed. The relevant questions include: Who may participate? Who validates transactions? What is the trust model? How are software defects handled? Can confidential data be protected? What happens when governance disputes occur? How are keys managed, and what is the consequence of compromise? A technically impressive platform may be unsuitable if its governance, privacy model, regulatory position, or operational controls conflict with the organisation's requirements.

This chapter compares major blockchain ecosystems through an architectural and risk-oriented lens. It treats a blockchain as a socio-technical system: protocol rules, software clients, validators, developers, users, custodians, regulators, and commercial incentives all influence its behaviour.

Learning Objectives

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

1. Explain the architectural purpose and operating model of Bitcoin, Ethereum, enterprise ledgers, and selected next-generation platforms.

2. Compare consensus, programmability, privacy, governance, scalability, and security across blockchain ecosystems.

3. Distinguish permissionless, permissioned, and hybrid deployment models.

4. Select a suitable platform for a use case by analysing technical, organisational, legal, and cybersecurity requirements.

5. Evaluate platform-specific risks, including smart-contract vulnerabilities, validator concentration, governance failure, privacy leakage, and key compromise.

6. Apply a structured framework to a realistic blockchain platform decision.

A Comparative Lens for Blockchain Platforms

A useful comparison begins with six dimensions. Participation asks whether anyone can read data, submit transactions, or validate blocks. Consensus concerns how the network agrees on the next valid state. Execution describes whether the platform merely transfers native assets or supports general-purpose programs. Data visibility ranges from fully public records to selectively disclosed information. Governance includes both formal protocol mechanisms and informal influence exercised by developers, validators, token holders, companies, and users. Finally, operational assurance considers identity, key management, monitoring, upgrade procedures, recovery, and compliance.

These dimensions are related. A permissionless network can obtain broad participation but may sacrifice transaction privacy and predictable identity assurance. A permissioned ledger can provide stronger access control and confidentiality but requires trust in a defined group of operators. High programmability increases the range of applications, but it also expands the attack surface. Greater throughput may be achieved through hardware requirements or validator concentration, potentially affecting decentralisation.

A platform should therefore be evaluated against a threat model rather than a marketing claim. A supply-chain consortium, a public cryptocurrency, a central-bank settlement experiment, and a decentralised finance application have different security and governance requirements.

Bitcoin: A Narrow but Robust Settlement System

Bitcoin's central design objective is permissionless digital value transfer without a central monetary authority. Participants maintain a replicated ledger of transactions, and miners compete under a proof-of-work mechanism to append blocks. The longest valid chain, more precisely the chain representing the greatest accumulated work, provides the practical ordering of transactions.

Bitcoin uses an account-like unspent transaction output model. Transactions consume earlier outputs and create new outputs controlled by scripts. Bitcoin Script is intentionally constrained and not a general-purpose programming language. This limitation reduces expressive flexibility but also restricts certain classes of computational and programming errors. Most Bitcoin transactions use digital signatures to demonstrate control of private keys, while more advanced script constructions support multisignature arrangements, time locks, and conditional spending.

Bitcoin's principal security property is the economic cost of rewriting history. An attacker seeking to reverse sufficiently confirmed transactions must acquire substantial computational power and bear significant energy and infrastructure costs. This does not make Bitcoin invulnerable. Exchanges, wallets, mining pools, software clients, and users remain attack targets. A private-key theft can result in irreversible loss, while a compromised exchange can create extensive financial and reputational damage without the Bitcoin consensus protocol itself being compromised.

Bitcoin's trade-offs are deliberate. Settlement is comparatively slow and throughput is limited relative to conventional payment networks. On-chain data is publicly visible, although identities are represented by pseudonymous addresses rather than legal names. Transaction graph analysis can often link addresses to individuals or organisations. Second-layer systems and sidechain approaches can improve payment speed or functionality, but they introduce additional trust, liquidity, software, or availability assumptions.

Bitcoin is appropriate where censorship resistance, monetary scarcity, public verifiability, and a relatively conservative scripting model are more important than high throughput, complex application logic, or confidential transactions. It is generally less suitable as the primary platform for business workflows involving private data, rapid reversibility, or complex inter-organisational permissions.

Ethereum: A Programmable Public State Machine

Ethereum generalised the blockchain model by providing a public execution environment for smart contracts. Rather than recording only transfers of a native asset, Ethereum maintains a state containing accounts, balances, contract storage, and code. Users submit transactions that cause the Ethereum Virtual Machine to execute operations and update state.

Ethereum supports externally owned accounts controlled by private keys and contract accounts controlled by code. Smart contracts can issue tokens, manage collateral, implement exchanges, represent digital assets, coordinate decentralised organisations, and provide financial services. This programmability is its defining strength and its defining risk. A contract may execute exactly as written even when the result is economically undesirable or contrary to the user's intention.

Ethereum's transition to proof of stake changed the validator model. Validators commit capital and are subject to rewards and penalties according to protocol rules. Proof of stake reduces dependence on energy-intensive computation, but it creates different concerns, including stake concentration, validator outsourcing, correlated failures, governance influence, and the complexity of staking infrastructure. The security of a decentralised application depends not only on the base protocol but also on oracles, bridges, wallets, front-end interfaces, libraries, and off-chain services.

Ethereum's public execution model creates important privacy challenges. Contract state and transaction histories are generally observable. Encryption can protect data before it is placed on-chain, but encrypted data may still reveal timing, relationships, values, or interaction patterns. Applications requiring confidentiality may use zero-knowledge methods, private execution environments, or permissioned deployments, each with additional complexity and assumptions.

Scalability has been addressed through a layered ecosystem. Layer-2 networks execute or batch transactions away from the base chain and use Ethereum for settlement or security, although their exact trust and data-availability models differ. Sidechains and application-specific networks may offer other performance characteristics but should not automatically be treated as equivalent to Ethereum's base-layer security. Bridges between networks are especially sensitive because they often control pooled assets through complex verification mechanisms.

Ethereum is suitable for open applications requiring composability, programmable assets, transparent settlement, and broad developer access. It is less suitable when legal identity, confidential records, deterministic performance, or simple operational governance are primary requirements.

Enterprise Ledgers: Controlled Membership and Business Privacy

Enterprise ledgers respond to a different problem: several known organisations want to share a consistent record without giving one participant unilateral control. Participants may need contractual accountability, selective disclosure, predictable performance, and integration with existing identity systems.

Hyperledger Fabric

Hyperledger Fabric is a permissioned, modular platform commonly organised around identified organisations, membership services, peers, ordering services, and channels. A transaction normally follows an endorsement, ordering, validation, and commitment process. Endorsement policies specify which organisations must approve a proposed transaction. Ordering services establish transaction sequence but do not necessarily determine whether the transaction satisfies business rules; validation occurs when peers check endorsements, versions, and policy requirements.

Channels can provide separate ledgers for subsets of participants, while private data collections allow authorised peers to hold private values with hashes or related evidence shared more broadly. This design supports business confidentiality, but privacy is not automatic. Metadata, transaction timing, endorsement patterns, and poorly designed access policies can still reveal information. Network governance must specify membership approval, certificate issuance, peer operation, software upgrades, dispute resolution, and data retention.

Fabric is well suited to supply-chain records, trade documentation, inter-organisational workflows, and regulated consortia where participants are known. Its performance is generally more predictable than that of a large permissionless network, but its trust is concentrated in the consortium and its identity infrastructure.

R3 Corda

Corda uses a different conceptual model. It is designed for business agreements and transactions shared only with parties that need to know. A network may use notaries to provide uniqueness and, depending on configuration, transaction finality. Participants exchange states and signed transactions rather than broadcasting every transaction to every node.

This selective-disclosure approach can reduce unnecessary data exposure and align with legal and commercial workflows. It also means that system-wide visibility is not the default, and the overall architecture depends heavily on identity, notary configuration, contractual interpretation, and integration with institutional processes. Corda is particularly relevant to finance, insurance, trade, and other settings where bilateral or multilateral agreements require controlled disclosure.

Enterprise Platforms and the Question of Trust

Permissioned systems are not automatically centralised databases, nor are they automatically decentralised. Their governance may distribute control among several firms, but participants remain identifiable and admission is controlled. Their security model includes conventional controls such as certificate authorities, hardware security modules, privileged administration, backup, incident response, and legal agreements. A consensus failure may be less likely than in an open network, but insider collusion, certificate compromise, administrator abuse, or consortium exclusion remain significant threats.

Selected Next-Generation Platforms

Solana

Solana combines proof of stake with a protocol mechanism commonly described as proof of history, which provides a cryptographic sequencing reference. Its design targets high throughput and low transaction latency through parallel execution and substantial hardware and bandwidth requirements. This can benefit applications such as high-volume trading or consumer-scale services.

The trade-off is operational and decentralisation risk. Running validators may require more capable infrastructure, and performance-oriented designs can increase the consequences of software defects, outages, or validator concentration. Solana supports smart contracts, but application security remains dependent on program audits, account validation, arithmetic safety, authority management, and careful handling of upgrade permissions.

Polkadot

Polkadot is designed around a relay chain and application-specific parachains. Its architecture seeks interoperability and shared security while allowing specialised chains to define their own execution environments. This can reduce the need for every application to build an independent validator set, but it introduces complexity in shared security, cross-chain messaging, governance, and parachain configuration.

The security of a cross-chain application depends on message verification, asset representation, replay protection, execution assumptions, and the security of each connected environment. Interoperability increases utility but also increases the number of boundaries that must be defended.

Avalanche

Avalanche uses a family of consensus protocols and supports multiple interoperable networks or subnets. Its architecture enables application-specific environments with different validator, compliance, and execution requirements. This flexibility is valuable for institutions that need custom rules, but it can fragment liquidity, tooling, monitoring, and security expertise. A subnet's security cannot be inferred solely from the reputation of the wider ecosystem; its own validator set, software, governance, and bridge arrangements must be assessed.

Cross-Platform Comparison

Bitcoin prioritises robust, permissionless settlement and conservative scripting. Ethereum prioritises open programmability and composability. Fabric prioritises organisational identity, endorsement policies, and modular consortium governance. Corda prioritises bilateral privacy and legally structured transactions. Solana prioritises performance, while Polkadot and Avalanche emphasise interoperability and application-specific environments.

No platform simultaneously maximises decentralisation, confidentiality, throughput, simplicity, and regulatory controllability. This is not merely an engineering inconvenience. It reflects conflicting objectives. Public verifiability may conflict with confidentiality; rapid upgrades may conflict with predictability; broad participation may conflict with identity assurance; specialised performance may conflict with hardware diversity.

A practical decision matrix should score at least the following factors:

| Criterion | Questions for evaluation |

|---|---|

| Trust model | Are participants anonymous, identified, or mixed? Who can validate? |

| Execution | Are simple transfers sufficient, or are complex contracts required? |

| Privacy | Must data be public, selectively disclosed, encrypted, or kept off-chain? |

| Performance | What throughput, latency, finality, and availability are required? |

| Governance | Who approves upgrades, resolves disputes, and controls emergency actions? |

| Security | What are the threats to keys, validators, contracts, bridges, and administrators? |

| Compliance | How are identity, audit, retention, consumer protection, and jurisdiction handled? |

| Ecosystem | Are suitable tools, developers, auditors, custodians, and integrations available? |

A platform should not be selected before defining which data belongs on-chain. Personal information, secrets, large documents, and frequently changing operational data are often better held off-chain, with hashes, commitments, or references recorded on-chain. Immutability does not eliminate the need for data governance; it can make mistakes more difficult to correct.

Application Domains

In digital assets and decentralised finance, Ethereum and comparable programmable public platforms offer composability and open access. Security teams must assess contract logic, oracle manipulation, flash-loan-enabled attacks, governance capture, wallet permissions, and bridge exposure.

For payments and monetary settlement, Bitcoin may be appropriate where censorship resistance and independent validation are central. A permissioned ledger may be more appropriate for institutional settlement requiring identity, privacy, and contractual controls.

Supply-chain applications often benefit from permissioned ledgers because participants are known and commercial data is sensitive. Yet a blockchain cannot prove that a physical shipment was honestly measured or that a sensor was not tampered with. The system can preserve submitted evidence, not guarantee the truth of every external event.

Digital identity requires particular care. Public blockchains can provide verifiable credentials or revocation evidence, but personal data should generally not be placed in an immutable public record. Selective disclosure and off-chain credential storage reduce exposure.

Central-bank and regulated financial experiments often use permissioned or hybrid architectures. They require clear settlement finality, operational resilience, privacy controls, legal enforceability, and mechanisms for authorised intervention. These requirements differ substantially from those of an open cryptocurrency.

Illustrative Case Study: Selecting a Platform for a Pharmaceutical Consortium

Background

Five pharmaceutical manufacturers, two logistics providers, and a national distributor seek to improve the traceability of temperature-sensitive medicines. They want to detect duplicate serial numbers, record custody changes, and provide regulators with an auditable history.

Situation and Problem

The consortium initially proposes a public smart-contract platform because it offers immutability and broad auditability. However, manufacturers are unwilling to expose shipment volumes, supplier relationships, and commercial prices. The members also require identified participants, contractual liability, and the ability to suspend a compromised organisation's credentials.

Analysis

The core requirements are controlled membership, selective disclosure, high availability, integration with enterprise identity, and evidence of custody changes. A public chain would provide strong external transparency but would expose metadata and create difficulties concerning personal and commercial information. It would also make credential revocation and governance more complex. A permissioned consortium ledger better matches the trust model, provided that governance prevents one member from unilaterally rewriting records.

The consortium must also recognise an oracle problem. A ledger can record a sensor report, but it cannot independently establish whether the sensor was calibrated, physically attached, or compromised. Therefore, sensor identity, secure firmware, signed measurements, tamper evidence, calibration records, and exception handling are required.

Approach and Solution

The consortium selects a permissioned architecture using identified organisations, endorsement policies requiring multiple parties for critical events, private data collections for commercial details, and an ordering service governed jointly by the members. Product identifiers and custody events are recorded on the ledger; detailed invoices and personally identifiable information remain in controlled off-chain systems. Regulators receive a dedicated read access arrangement or cryptographic proofs rather than unrestricted access to all commercial data.

Security controls include hardware-backed organisational keys, certificate revocation, separate administrative roles, continuous monitoring, software supply-chain review, incident-response procedures, and a governance agreement covering upgrades and disputes. The design also includes periodic reconciliation with warehouse systems and independent audits of sensor processes.

Outcome

The architecture provides a shared audit trail without treating the blockchain as a universal repository. It improves accountability among consortium members, but it does not eliminate counterfeit risk or guarantee the accuracy of sensor data. Those risks are addressed through physical controls, assurance procedures, and independent verification.

Learning Points

The case demonstrates that platform selection begins with governance and data requirements, not with a preference for a particular brand. It also shows that permissioned systems require strong cybersecurity and institutional accountability. Finally, blockchain integrity protects recorded state; it does not automatically guarantee the integrity of inputs.

Security, Governance, and Professional Risk

Smart-contract defects are a major risk in programmable platforms. Reentrancy, incorrect access control, unsafe upgrade mechanisms, price-oracle manipulation, denial of service, integer or precision errors, and flawed economic assumptions can all cause losses. Testing should include code review, static and dynamic analysis, property-based testing, formal methods where appropriate, independent audits, staged deployment, monitoring, and carefully designed emergency controls.

Key management is foundational across all platforms. Private keys may be stolen through malware, phishing, insider abuse, cloud compromise, or inadequate backups. Organisations should use role separation, hardware-backed storage, multisignature or threshold approval, transaction policy engines, address allow-listing where suitable, recovery procedures, and continuous anomaly detection. A secure protocol cannot compensate for an exposed signing key.

Governance creates another attack surface. Token voting may be dominated by large holders; enterprise governance may be captured by a powerful consortium member; informal developer influence may exceed formal voting rules. Upgrade keys, emergency pauses, validator admission, treasury control, and dispute resolution require explicit accountability. Governance procedures should be documented, auditable, tested, and consistent with legal obligations.

Regulatory and ethical issues include financial licensing, sanctions compliance, consumer protection, data protection, tax treatment, market manipulation, environmental impact, and the rights of individuals affected by immutable records. Security professionals should avoid assuming that decentralisation removes responsibility. Operators, developers, custodians, and deploying organisations may each carry distinct duties.

Current Developments and Emerging Directions

Blockchain ecosystems increasingly use modular architectures in which execution, settlement, consensus, and data availability are separated. This can improve specialisation but creates additional interfaces and dependencies. Layer-2 networks, application-specific chains, interoperability protocols, and zero-knowledge systems are expanding the design space. Zero-knowledge proofs can demonstrate knowledge or correctness without revealing all underlying data, although their cryptographic assumptions, implementation quality, and operational complexity require careful evaluation.

Institutional adoption is also moving toward hybrid systems: regulated entities may use public networks for settlement while keeping identity and sensitive records off-chain, or they may use permissioned networks that interoperate with public ecosystems. Artificial intelligence can assist with smart-contract vulnerability detection, transaction anomaly analysis, and governance monitoring, but AI-generated code and automated decisions require human review, reproducible testing, and controls against poisoned data or false positives.

Interoperability remains both an opportunity and a persistent security challenge. Every bridge or messaging layer expands the trust boundary. Future platform evaluation will therefore place greater emphasis on formal verification, transparent validator operations, resilient key management, privacy-preserving identity, and evidence-based security claims.

Best Practices for Platform Selection and Deployment

A professional selection process should:

• define business objectives, legal constraints, participants, assets, and threat actors before choosing a platform;
• distinguish data that must be public, shared selectively, encrypted, or retained off-chain;
• document consensus, finality, validator, identity, and governance assumptions;
• assess the security of wallets, contracts, bridges, APIs, oracles, administrators, and third-party dependencies;
• use independent testing and security review before production deployment;
• design key custody, recovery, revocation, monitoring, and incident response in advance;
• establish upgrade, rollback, dispute, and emergency procedures;
• measure real performance under representative workloads rather than relying on advertised throughput;
• review decentralisation and concentration risks periodically; and
• treat the blockchain as one component of a wider socio-technical control system.

Chapter Summary

Bitcoin, Ethereum, enterprise ledgers, and newer platforms represent different solutions to different coordination problems. Bitcoin provides permissionless settlement with conservative scripting and proof-of-work security. Ethereum offers a programmable public state machine whose flexibility supports extensive application ecosystems but creates significant smart-contract and composability risks. Hyperledger Fabric and Corda use identified participants, controlled disclosure, and institutional governance for enterprise workflows. Solana, Polkadot, and Avalanche explore performance, interoperability, and application-specific architectures, while introducing additional assumptions about hardware, cross-chain communication, validator sets, and governance.

Platform selection should be based on trust model, privacy, execution requirements, performance, governance, compliance, security, and ecosystem maturity. No architecture removes the need for key management, secure software development, reliable data inputs, monitoring, or accountability. The most appropriate platform is the one whose technical and institutional assumptions match the actual use case.

Key Terms

Permissionless blockchain: A network in which participation is generally open and users need not obtain institutional approval.

Permissioned ledger: A ledger in which participation, validation, or data access is controlled by recognised authorities.

Consensus: The mechanism by which distributed participants agree on transaction order and ledger state.

Proof of work: A consensus approach that uses computational expenditure to make chain rewriting costly.

Proof of stake: A consensus approach in which participants commit stake and may receive rewards or penalties.

Smart contract: Program code deployed on a blockchain that executes according to platform rules.

State machine: A computational model in which inputs cause transitions from one valid system state to another.

UTXO: An unspent transaction output that represents value available for consumption by a later transaction.

Ethereum Virtual Machine: The execution environment that processes Ethereum smart-contract operations.

Finality: The degree of assurance that a confirmed transaction will not be reversed.

Permissioned channel: A selectively shared ledger or communication domain within an enterprise network.

Endorsement policy: A rule specifying which organisations or peers must approve a transaction proposal.

Oracle: A service or mechanism that supplies external data to a blockchain application.

Layer-2 network: A system that processes transactions away from a base blockchain while using it in some manner for settlement or security.

Bridge: Infrastructure that transfers assets or messages between distinct blockchain environments.

Interoperability: The ability of separate blockchain networks or applications to exchange information or value.

Validator: A participant responsible for checking transactions and contributing to consensus.

Governance capture: A condition in which a participant or coalition obtains disproportionate control over decisions.

Selective disclosure: Sharing information only with parties authorised or required to receive it.

Threshold approval: A control requiring a specified number or proportion of authorised parties to approve an action.

Review Questions

Short Answer Questions

1. Why is Bitcoin's scripting model intentionally less expressive than Ethereum's smart-contract environment?

2. What is the role of an endorsement policy in Hyperledger Fabric?

3. Explain the difference between public verifiability and data confidentiality.

4. Why are bridges considered important security boundaries?

5. What is meant by the oracle problem?

Long Answer Questions

1. Compare Bitcoin and Ethereum in terms of architecture, programmability, consensus, security, and suitable applications.

2. Explain how Hyperledger Fabric and Corda address privacy and organisational identity in different ways.

3. Discuss the principal trade-offs involved in selecting a high-throughput platform such as Solana.

4. Analyse how governance and key management affect the security of blockchain ecosystems.

5. Explain why a blockchain platform should be selected using a threat model rather than throughput claims alone.

Analytical / Application Questions

1. A consortium of banks requires identified participants, confidential bilateral transactions, shared auditability, and legally governed upgrades. Which platform characteristics should guide the choice between a public programmable chain and an enterprise ledger?

2. A decentralised application uses a bridge, an external price oracle, and an upgradeable smart contract. Construct a threat model identifying at least five attack surfaces and propose controls.

3. A public health organisation wants to place patient records directly on a public blockchain. Evaluate the proposal and design a safer architecture using on-chain and off-chain components.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes Bitcoin from Ethereum?

A. Bitcoin uses cryptographic signatures

B. Bitcoin is primarily designed for permissionless value settlement with constrained scripting

C. Bitcoin has no consensus mechanism

D. Bitcoin requires all users to be identified

Correct Answer: B. Bitcoin is primarily designed for permissionless value settlement with constrained scripting

Question 2

In Ethereum, a smart contract is best understood as:

A. A legal document stored outside the network

B. A mining pool operated by validators

C. Program code that changes blockchain state when executed

D. A private key recovery service

Correct Answer: C. Program code that changes blockchain state when executed

Question 3

What is the main purpose of an endorsement policy in Hyperledger Fabric?

A. To determine which organisations must approve a transaction proposal

B. To hide all transaction metadata from administrators

C. To replace the membership service provider

D. To convert a permissioned network into a permissionless one

Correct Answer: A. To determine which organisations must approve a transaction proposal

Question 4

Why may Corda be suitable for transactions involving sensitive bilateral agreements?

A. It broadcasts every transaction to every participant

B. It uses selective sharing so only relevant parties receive transaction information

C. It does not use digital signatures

D. It prevents organisations from identifying one another

Correct Answer: B. It uses selective sharing so only relevant parties receive transaction information

Question 5

A company chooses a public blockchain for a confidential supply-chain system. Which issue is most likely to undermine the design?

A. Public transaction data may reveal commercial relationships and activity patterns

B. Public chains cannot record timestamps

C. Digital signatures cannot be used on public chains

D. Public chains always require a central administrator

Correct Answer: A. Public transaction data may reveal commercial relationships and activity patterns

Question 6

Which statement best describes the oracle problem?

A. A blockchain cannot execute any program without an oracle

B. A blockchain may preserve an external data submission without proving that the input was truthful

C. An oracle permanently replaces the consensus mechanism

D. An oracle automatically encrypts all ledger data

Correct Answer: B. A blockchain may preserve an external data submission without proving that the input was truthful

Question 7

Why can interoperability increase security risk?

A. It eliminates the need for validators

B. It creates additional messaging, verification, asset-representation, and trust boundaries

C. It guarantees identical governance across networks

D. It prevents applications from using smart contracts

Correct Answer: B. It creates additional messaging, verification, asset-representation, and trust boundaries

Question 8

Which control most directly reduces the impact of a single compromised signing key?

A. Publishing the key publicly

B. Using threshold or multisignature approval with hardware-backed custody

C. Removing transaction monitoring

D. Storing the key in an unencrypted text file

Correct Answer: B. Using threshold or multisignature approval with hardware-backed custody

Question 9

A consortium needs identified members, selective disclosure, and predictable business workflows. Which deployment model is generally the best initial fit?

A. A permissioned enterprise ledger

B. A proof-of-work cryptocurrency only

C. An anonymous public ledger with no access controls

D. A system without cryptographic authentication

Correct Answer: A. A permissioned enterprise ledger

Question 10

What is a central trade-off of high-throughput blockchain designs that require substantial validator hardware?

A. They may increase validator concentration and reduce accessibility of participation

B. They cannot support programmable applications

C. They eliminate all software vulnerabilities

D. They necessarily provide complete transaction confidentiality

Correct Answer: A. They may increase validator concentration and reduce accessibility of participation