1. Blockchain Foundations and Terminology

Introduction and Context

Blockchain technology is often described as a new form of database, but that description is incomplete. A blockchain is better understood as a coordination technology for recording transactions and maintaining agreement among parties that may not fully trust one another. It combines distributed computing, cryptography, peer-to-peer networking, consensus mechanisms, and economic incentives into a single system.

The significance of blockchain lies not simply in storing data. Conventional information systems already store, retrieve, and protect data effectively. Blockchain becomes valuable when several independent organizations need to share a common record, when no single participant should have unilateral control, or when participants require evidence that previously recorded events have not been altered. In such settings, blockchain can reduce reconciliation, improve auditability, automate conditional transactions, and support digital assets.

However, blockchain is not universally superior to a conventional database. It normally introduces additional computational cost, governance complexity, latency, and operational responsibility. A sound professional decision therefore begins with a clear understanding of the problem being solved rather than with enthusiasm for the technology itself.

This chapter establishes the conceptual foundation for later study of smart contracts, blockchain architecture, consensus, platforms, security, applications, and regulation.

Learning Objectives

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

1. Explain the historical and technological evolution that led to blockchain.

2. Define the principal terms used in blockchain systems.

3. Describe how blocks, hashes, digital signatures, peer-to-peer networks, and consensus work together.

4. Distinguish a blockchain from a centralized database, a distributed database, and a distributed ledger.

5. Explain the value proposition and limitations of blockchain in organizational settings.

6. Identify suitable applications, governance concerns, and professional risks.

7. Evaluate whether a business problem genuinely requires blockchain.

From Digital Cash to Shared Ledgers

The intellectual roots of blockchain extend beyond Bitcoin. In the 1980s and 1990s, researchers investigated digital cash, public-key cryptography, electronic signatures, timestamping, and methods for reaching agreement in distributed systems. A persistent problem was the prevention of double spending: digital information can be copied, so a digital token cannot be treated like a physical coin without a reliable method of determining which transaction is valid.

Traditional electronic payment systems solve this problem through trusted intermediaries such as banks and payment processors. These institutions maintain authoritative ledgers and validate transactions. Earlier digital-cash proposals explored ways to reduce dependence on intermediaries, but many faced difficulties involving trust, scalability, privacy, or the prevention of double spending.

A major conceptual step was the use of cryptographic timestamping. If records are linked to earlier records through cryptographic hashes, later alteration becomes detectable. Research on distributed consensus also addressed how computers could agree on a common state despite communication failures or malicious participants.

In 2008, the Bitcoin protocol was proposed under the pseudonym Satoshi Nakamoto, and the network became operational in 2009. Bitcoin combined a peer-to-peer network, a chain of hash-linked blocks, a public transaction history, digital signatures, and proof-of-work consensus. Its important contribution was not the invention of every individual component, but the integration of these components into an open system without a central transaction administrator.

Subsequent blockchain platforms expanded the design space. Some introduced programmable smart contracts, allowing code to control digital assets and execute predefined rules. Others emphasized permissioned participation, privacy, high throughput, or enterprise governance. Blockchain therefore refers to a family of architectures rather than one single technology.

The Core Idea: A Shared, Tamper-Evident Record

A ledger is a record of economic or operational events. In a blockchain, transactions are digitally signed statements that request a change to the ledger state. A network of nodes receives transactions, checks them against protocol rules, and orders valid transactions into blocks. Each block contains a reference to the preceding block, usually represented by a cryptographic hash.

A cryptographic hash function accepts input of arbitrary length and produces a fixed-length output. A suitable hash function has several properties:

• The same input produces the same output.
• A small change in the input produces a substantially different output.
• It is computationally infeasible to recover the input from the hash alone.
• It is computationally infeasible to find two different inputs with the same hash in practical circumstances.

Because a block contains the hash of its predecessor, changing an old transaction changes the old block’s hash and invalidates the references of later blocks. This creates tamper evidence. It does not make alteration metaphysically impossible; rather, it makes unauthorized alteration detectable and, under appropriate consensus assumptions, economically or computationally impractical.

A blockchain should therefore be described carefully as tamper-evident, append-oriented, and replicated. The terms “immutable” or “unchangeable” are useful shorthand only when their limits are understood. Protocol upgrades, governance decisions, administrative interventions, or a successful attack can change what users regard as the valid history.

How a Blockchain Transaction Becomes Part of the Ledger

The detailed process differs among platforms, but a general transaction lifecycle contains the following stages.

First, a user or application creates a transaction. The transaction may transfer a digital asset, record an event, invoke a smart contract, or update an account balance. The transaction is signed using the sender’s private key. The corresponding public key or address allows others to verify the signature without learning the private key.

Second, the transaction is broadcast through the peer-to-peer network. Nodes validate basic conditions, such as signature correctness, format, authorization, and whether the proposed action violates current ledger rules. Invalid transactions are rejected or ignored.

Third, an authorized block producer, miner, validator, or ordering service selects valid transactions and forms a candidate block. The block normally contains a header, metadata, a reference to the previous block, and a collection of transactions. Transactions may also be summarized using a Merkle tree, allowing efficient verification that a transaction belongs to a block without transmitting every transaction.

Fourth, the network applies a consensus procedure. Depending on the blockchain, participants may compete through proof of work, be selected through proof of stake, or follow an agreement protocol among known organizations. Consensus determines which block or sequence of blocks becomes accepted.

Finally, nodes update their local copy of the ledger. In some systems, a transaction is considered increasingly final as additional blocks are added. In others, especially systems with Byzantine fault-tolerant consensus, finality may be explicit once the required participants approve a block.

These stages show that blockchain is not merely a data structure. It is a coordinated system involving identity, authorization, networking, validation, ordering, replication, and governance.

Essential Terminology

Blocks, chains, and state

A block is a structured collection of transactions and metadata accepted by the network. A blockchain is an ordered sequence of blocks linked by cryptographic references. The ledger state is the condition represented by the accepted history—for example, current account balances, ownership records, or smart-contract variables.

The term genesis block refers to the first block in a blockchain. It has no ordinary predecessor and establishes the starting point of the chain. A node is a computer participating in the network. Nodes may store the entire ledger, validate transactions, relay messages, or perform specialized functions.

Keys, addresses, and signatures

Public-key cryptography uses a mathematically related private key and public key. The private key must be kept secret and is used to create digital signatures. The public key can be shared and is used to verify signatures. An address is generally a shorter or transformed representation used to identify a destination or account.

Ownership in many blockchain systems is not established by a person’s name in a central register. It is established by control of the private key associated with an address. This creates both autonomy and risk: loss or theft of a private key can mean loss or unauthorized transfer of assets.

A digital signature provides authentication and integrity. It demonstrates that a transaction was authorized by the holder of the relevant private key and that the signed content has not been modified. It does not, by itself, prove that the person using the key is legally entitled to act.

Consensus and finality

Consensus is the mechanism by which network participants agree on the valid ordering or state of transactions. It is not simply a vote on whether a transaction is desirable. It is a protocol for resolving conflicting proposals and maintaining a common ledger under specified assumptions.

Proof of work requires participants to perform computational work in competition to propose blocks. Its security is associated with the cost of computation and energy. Proof of stake assigns influence according to staked value and uses penalties or other mechanisms to discourage dishonest behavior. Permissioned systems may use Byzantine fault-tolerant protocols in which identified validators exchange messages and approve blocks.

Finality is the point at which a transaction is considered irreversible under the protocol. Probabilistic finality means confidence increases as more blocks follow a transaction. Deterministic or economic finality provides a stronger protocol or incentive-based guarantee after a specified decision.

Tokens and smart contracts

A token is a digital representation of value, entitlement, access, or another asset recorded on a blockchain. Tokens may be fungible, meaning each unit is interchangeable with another unit of the same type, or non-fungible, meaning each unit has a distinct identity or metadata.

A smart contract is a program deployed to a blockchain that executes according to encoded rules. It is not necessarily a legally enforceable contract, nor is it inherently intelligent. Smart contracts can enforce certain digital conditions, but they may require trusted external data, known as oracles, for facts originating outside the blockchain.

A wallet is software or hardware that manages cryptographic keys and creates transactions. Strictly speaking, assets remain recorded on the ledger; a wallet stores the credentials that authorize actions involving those assets.

Permission models

A public, or permissionless, blockchain generally allows broad participation in reading data, submitting transactions, and sometimes validating blocks. Bitcoin and many public smart-contract networks are examples of this model.

A private blockchain is controlled by one organization, while a consortium or federated blockchain is governed by several identified organizations. The broader term permissioned blockchain describes a system in which participation in particular activities is restricted. Permissioned systems may provide stronger privacy, predictable performance, and identifiable accountability, but they rely more heavily on institutional governance and may offer less decentralization.

Blockchain, Databases, and Distributed Ledgers: A Necessary Distinction

A conventional centralized database is usually administered by one organization or a clearly dominant authority. It can provide excellent performance, fine-grained access control, mature backup facilities, and efficient querying. A bank’s internal transaction database is a typical example. The database operator determines which records are valid and may correct or delete records under authorized procedures.

A distributed database stores data across multiple computers, often to improve availability, scalability, or performance. Replication does not automatically make it a blockchain. The participating computers may still operate under one administrative authority and may trust a central controller or a conventional coordination service.

A distributed ledger is a ledger replicated among multiple participants. The term is broader than blockchain. A distributed ledger may use a blockchain structure, a directed acyclic graph, or another data model. It may be permissionless or permissioned, and it may use various consensus methods.

Blockchain is therefore a particular approach to distributed ledger design, characterized commonly by cryptographically linked blocks, replicated validation, and a consensus process for ordering records. Not every distributed ledger is a blockchain, and not every multi-site database needs blockchain.

The key distinctions are authority, trust, data structure, and governance. A centralized database assumes or deliberately creates a trusted administrator. A blockchain distributes validation and makes the shared history verifiable among participants. A conventional database usually supports modification and deletion as ordinary administrative operations, whereas a blockchain emphasizes append-oriented history and controlled state transitions.

These differences should not be reduced to the simplistic claim that blockchain eliminates trust. Blockchain shifts trust. Participants may trust cryptographic rules, software, validators, incentives, governance procedures, and the accuracy of data supplied to the system. Human and institutional trust remain relevant.

A Decision Framework for Blockchain Suitability

A practical evaluation can begin with six questions.

1. Do multiple independent organizations need to write to and share the same record?

2. Is there limited willingness to give one participant complete control?

3. Is a common history, rather than merely a current database state, important?

4. Can transactions be represented digitally and governed by clear rules?

5. Is the required performance compatible with distributed validation and replication?

6. Can the participants agree on governance, privacy, identity, and dispute resolution?

If one trusted organization can efficiently operate the system, a conventional database is often preferable. If several parties need shared control and auditability, a permissioned distributed ledger may be appropriate. If open participation and censorship resistance are central requirements, a public blockchain may be considered.

This framework prevents technology-first decision-making. Blockchain is most defensible when it addresses a coordination problem, not merely when it offers an alternative storage mechanism.

Value Proposition in Organizational Practice

Blockchain can create value in several ways. A shared ledger may reduce reconciliation between organizations that maintain separate records. A tamper-evident history can strengthen audit trails and provenance. Digitally represented assets can be transferred according to transparent rules. Smart contracts can automate settlement, escrow, royalties, or compliance checks. Public networks can enable participation without a central platform operator.

The value is conditional. A blockchain does not guarantee that a physical product is genuine, that a sensor is accurate, or that an input supplied by an authorized user is truthful. It preserves and shares submitted information; it does not automatically verify reality. This is the “garbage in, garbage out” problem in a new technical setting.

Blockchain also changes organizational responsibilities. Key management, protocol upgrades, validator operations, privacy design, incident response, legal compliance, and dispute handling must be assigned explicitly. A decentralized technical architecture may still require centralized or collective governance.

Applications Across Industries

In supply chains, participants can record custody transfers, certifications, and shipping events on a shared ledger. The benefit is strongest when organizations currently reconcile inconsistent records. Blockchain cannot by itself verify whether a shipment was physically stored at the required temperature; sensors, inspection procedures, and trusted data feeds remain necessary.

In finance, blockchain supports digital settlement, tokenized assets, cross-border transfers, collateral management, and programmable payment conditions. Financial applications must address identity, anti-money-laundering obligations, privacy, operational resilience, and legal ownership.

In healthcare, distributed records may support consent management, data-sharing permissions, and audit trails. Storing sensitive medical data directly on a public blockchain is generally inappropriate because public visibility, persistence, and deletion requirements may conflict with privacy obligations. A more suitable architecture may store hashes, permissions, or references on-chain while keeping clinical data in controlled systems.

In public administration, blockchain may support credential verification, land records, benefit distribution, and procurement transparency. These applications depend on legal recognition, inclusive access, institutional accountability, and mechanisms for correcting errors.

In education and employment, verifiable credentials can allow institutions to issue digitally signed qualifications that employers or other institutions can verify. The design must still address identity binding, revocation, privacy, and the possibility that a credential was issued in error.

Illustrative Case Study: Shared Food-Traceability Ledger

Background

Consider a fictional consortium consisting of farmers, a food processor, logistics providers, retailers, and a public health authority. Each organization maintains its own records. When a contamination concern arises, tracing a product batch takes several days because participants exchange spreadsheets and reconcile different identifiers.

Situation and Problem

The consortium wants faster traceability without giving one commercial participant complete control of the shared record. It also needs to distinguish authorized entries, preserve an auditable history, and restrict commercially sensitive information.

Analysis

The problem is not simply data storage. It is a coordination problem involving independent organizations with partially aligned interests. A shared ledger could reduce reconciliation and make custody events visible to authorized participants. However, blockchain would not prove that a farmer entered a truthful harvest date or that a temperature sensor was calibrated. Governance and data-quality procedures are therefore as important as the ledger.

Approach

The consortium adopts a permissioned distributed ledger. Each organization receives an authenticated identity and defined permissions. The ledger records batch identifiers, custody transfers, inspection attestations, and references to laboratory documents. Large documents remain in controlled repositories; cryptographic hashes are recorded on the ledger to reveal later alteration.

A consensus protocol among recognized validator organizations orders transactions. Smart-contract logic checks that a transfer is authorized, that a batch has not already been assigned inconsistently, and that required inspection records exist before shipment. A governance committee defines onboarding, validator responsibilities, correction procedures, privacy rules, and incident response.

Outcome

The system reduces manual reconciliation and allows authorized participants to trace the recorded history of a batch more quickly. It does not eliminate the need for inspections or legal enforcement. When a sensor provider is found to have supplied inaccurate data, the consortium must investigate the external evidence and record an appropriate correction or qualification.

Learning Points

The case demonstrates that blockchain’s value arises from shared governance and verifiable history. A permissioned design may be more appropriate than a public blockchain where participants are known and commercial confidentiality matters. It also demonstrates that on-chain integrity cannot compensate for inaccurate off-chain data.

Risks, Limitations, and Common Mistakes

Scalability is a central limitation. Replication and consensus can reduce throughput or increase latency compared with a centralized database. Public networks may also experience variable transaction fees.

Privacy requires careful treatment. A record may be technically pseudonymous rather than anonymous. Publicly visible transaction patterns can reveal relationships, and permanent storage may conflict with data-protection requirements. Encryption does not automatically solve all privacy problems because keys may be lost, compromised, or subject to lawful disclosure.

Security risks include private-key theft, smart-contract defects, compromised interfaces, malicious validators, governance attacks, and social engineering. The blockchain protocol may function correctly while an exchange, wallet, oracle, or application fails.

Governance is frequently underestimated. Participants must decide who may join, who may validate, how software changes are approved, how disputes are resolved, and what happens when legal requirements conflict with historical records. A technically decentralized system can fail through unclear institutional responsibility.

Common mistakes include putting unnecessary personal data on-chain, assuming immutability guarantees truth, choosing a public blockchain for a problem requiring confidentiality, ignoring user experience and key recovery, and treating a token as equivalent to legal ownership without legal analysis.

Ethical, Legal, and Professional Considerations

Blockchain projects affect control over identity, assets, and information. Ethical design should consider inclusion, accessibility, unequal technical capacity, and the consequences of irreversible errors. Users should understand what they are authorizing and what data may remain permanently observable.

Regulatory obligations may include financial licensing, consumer protection, securities law, taxation, anti-money-laundering requirements, data protection, cybersecurity, and records-management rules. The legal status of a token or smart-contract transaction depends on jurisdiction and context; technical implementation does not settle legal interpretation.

Professionals should apply privacy by design, data minimization, least-privilege access, strong key-management practices, independent code review, documented governance, and clear accountability. Sustainability should also be evaluated, especially where consensus involves substantial energy consumption. The correct assessment depends on the protocol, infrastructure, use case, and alternatives rather than on general labels.

Current Developments and Emerging Directions

Blockchain development is moving toward more efficient consensus, layer-two scaling, interoperability, tokenization of real-world assets, verifiable credentials, decentralized identity, and privacy-enhancing technologies. Zero-knowledge proofs can allow a party to demonstrate that a statement is valid without revealing all underlying information. Interoperability protocols seek to move information or assets across networks, although bridges introduce significant security and governance risks.

Artificial intelligence and blockchain may complement one another in limited ways. Blockchain can provide provenance records for datasets, model artifacts, or automated decisions, while AI can analyze blockchain transactions for fraud, anomalies, and network behavior. Neither technology automatically establishes the truth of the other’s outputs. A reliable system still requires data governance, validation, explainability, and human accountability.

The broader trend is toward modular architectures in which on-chain components handle settlement, verification, or shared state while off-chain systems provide storage, computation, privacy, and user interfaces. This approach can improve practicality but increases integration and governance complexity.

Best-Practice Principles

A responsible blockchain initiative should:

• Begin with a clearly defined coordination or trust problem.
• Compare blockchain with databases and other distributed systems.
• Select public, private, or consortium governance deliberately.
• Minimize on-chain personal and confidential data.
• Define identity, permissions, key recovery, and accountability.
• Validate external data sources and oracle assumptions.
• Test performance, privacy, security, and failure recovery.
• Establish upgrade, dispute, and legal-compliance procedures.
• Design for accessibility and understandable user consent.
• Measure operational value rather than technological novelty.

Chapter Summary

Blockchain is a coordinated system for maintaining a shared, cryptographically verifiable record among participants. Its evolution combined digital signatures, hashing, timestamping, peer-to-peer networking, distributed consensus, and incentive mechanisms. Blocks link transactions into an append-oriented history, while keys and signatures support authorization and integrity.

Blockchain differs from a centralized database because control and validation are distributed, and from a distributed database because replication alone does not imply blockchain-style consensus or governance. A distributed ledger is the broader category; blockchain is one important ledger architecture. Public, private, and consortium systems make different trade-offs among openness, privacy, performance, and accountability.

Blockchain can reduce reconciliation, improve provenance, automate rule-based transactions, and support digital assets. It cannot guarantee the truth of external data, eliminate governance, or replace every database. Professional evaluation must consider scalability, privacy, key management, legal requirements, data quality, energy use, and institutional responsibility. The most suitable application is one in which multiple parties require a shared history but do not wish to rely entirely on one controlling intermediary.

Key Terms

Blockchain: An ordered, cryptographically linked sequence of transaction blocks maintained through a network consensus process.

Distributed ledger: A ledger replicated and maintained across multiple participants using an agreed coordination mechanism.

Centralized database: A database administered by one dominant authority that controls validation and access.

Distributed database: A database whose data or processing is spread across multiple computers, usually under coordinated administration.

Block: A structured collection of validated transactions and metadata added to a blockchain.

Hash: A fixed-length cryptographic output representing input data and supporting integrity checking.

Genesis block: The first block in a blockchain.

Node: A computer that participates in receiving, validating, storing, relaying, or processing blockchain data.

Consensus: A protocol through which participants agree on valid transactions, ordering, or ledger state.

Finality: The condition in which a transaction is considered settled and not subject to reversal under the protocol.

Private key: A secret cryptographic value used to authorize transactions and create digital signatures.

Public key: A cryptographic value used to verify signatures associated with a private key.

Digital signature: A cryptographic proof of authorization and message integrity.

Smart contract: A blockchain-resident program that executes encoded rules.

Token: A digital representation of value, entitlement, access, or another asset.

Wallet: Software or hardware used to manage blockchain keys and create transactions.

Permissionless blockchain: A blockchain generally open to broad participation without prior institutional approval.

Permissioned blockchain: A blockchain in which participation or specific roles are restricted.

Oracle: A service or mechanism that supplies external information to a blockchain or smart contract.

Immutability: A practical property of resistance to unauthorized alteration, subject to protocol, governance, and security assumptions.

Review Questions

Short Answer Questions

1. What problem does a blockchain address when several organizations need a common transaction history?

2. How does a cryptographic hash help make a blockchain tamper-evident?

3. Distinguish a distributed database from a distributed ledger.

4. What is the relationship between a private key and a digital signature?

5. Why does blockchain not guarantee the truth of off-chain data?

Long Answer Questions

1. Explain the evolution from digital cash research to modern blockchain systems.

2. Describe the general lifecycle of a blockchain transaction from creation to ledger acceptance.

3. Compare centralized databases, distributed databases, distributed ledgers, and blockchains.

4. Discuss the value proposition and limitations of blockchain for organizational collaboration.

5. Explain the governance, privacy, security, and legal issues that must be addressed in a blockchain project.

Analytical / Application Questions

1. A consortium of hospitals needs to share audit records, but patient data must remain confidential and correctable. Should it use a public blockchain, a permissioned ledger, or a conventional database? Justify your answer.

2. A retailer proposes recording every product event on a public blockchain to guarantee authenticity. Analyze the proposal, including the oracle and data-quality problem.

3. An organization already has a highly trusted central database but wants blockchain because it is fashionable. Apply the suitability framework to determine whether blockchain is justified.

22. Multiple Choice Questions with Answers

Question 1

Which combination most directly enables a blockchain to provide an ordered, tamper-evident transaction history?

A. Hash-linked blocks and a consensus mechanism

B. A single administrator and periodic backups

C. Encrypted files stored on one server

D. An offline spreadsheet and manual approvals

Correct Answer: A. Hash-linked blocks and a consensus mechanism

Question 2

What does a digital signature primarily demonstrate in a blockchain transaction?

A. That the real-world event definitely occurred

B. That the transaction was authorized by the relevant private key and was not altered

C. That the transaction has legal validity in every jurisdiction

D. That the sender’s identity is necessarily known

Correct Answer: B. That the transaction was authorized by the relevant private key and was not altered

Question 3

Which statement best distinguishes a distributed database from a blockchain?

A. A distributed database cannot replicate data

B. A blockchain never uses cryptography

C. A distributed database may operate under one authority without blockchain-style consensus

D. A blockchain is always private

Correct Answer: C. A distributed database may operate under one authority without blockchain-style consensus

Question 4

A consortium of known companies requires shared records, controlled access, and predictable performance. Which design is generally most appropriate?

A. A permissioned consortium blockchain

B. An entirely anonymous public network in all cases

C. A single unencrypted personal computer

D. A system with no participant authentication

Correct Answer: A. A permissioned consortium blockchain

Question 5

Why does blockchain not automatically prove that a temperature recorded for a shipment is accurate?

A. Hashes cannot be calculated for numbers

B. Consensus only confirms the accepted record, not necessarily the truth of the external input

C. Blocks cannot contain sensor data

D. Digital signatures prevent sensor use

Correct Answer: B. Consensus only confirms the accepted record, not necessarily the truth of the external input

Question 6

What is the principal function of a blockchain wallet?

A. To store physical copies of all assets

B. To manage cryptographic keys and create authorized transactions

C. To replace the consensus mechanism

D. To guarantee recovery from every private-key loss

Correct Answer: B. To manage cryptographic keys and create authorized transactions

Question 7

Which situation most strongly supports considering blockchain rather than a conventional database?

A. One trusted department needs a fast internal reporting system

B. Several independent organizations need a shared history without giving one party complete control

C. A company needs temporary spreadsheet calculations

D. A researcher needs a private local data file

Correct Answer: B. Several independent organizations need a shared history without giving one party complete control

Question 8

What is a major privacy concern associated with public blockchains?

A. All transactions are automatically deleted after validation

B. Transaction patterns and recorded information may remain publicly observable and persistent

C. Public blockchains cannot use addresses

D. Permissioned validators always see less information

Correct Answer: B. Transaction patterns and recorded information may remain publicly observable and persistent

Question 9

Which statement about smart contracts is most accurate?

A. They are always legally enforceable contracts

B. They are programs that execute encoded rules, often requiring external data for off-chain facts

C. They eliminate the need for governance

D. They can reverse any transaction without protocol rules

Correct Answer: B. They are programs that execute encoded rules, often requiring external data for off-chain facts

Question 10

A firm chooses blockchain solely because it wants to use a fashionable technology, although one trusted administrator already operates an efficient database. What is the strongest evaluation?

A. Blockchain is automatically superior because it is newer

B. The firm should first identify a coordination or trust problem and compare alternatives

C. The firm must use a permissionless network

D. The database should be removed before requirements are analyzed

Correct Answer: B. The firm should first identify a coordination or trust problem and compare alternatives