Smart Contracts and Blockchain Foundations

Introduction

Blockchain systems combine distributed computing, cryptography, economic incentives, and software engineering. Their central innovation is not simply the storage of data in blocks; it is the ability of independent participants to maintain a shared state without relying on one central operator. Smart contracts extend this capability by allowing rules to be expressed as executable programs whose results are recorded and enforced by a blockchain network.

For Solidity developers, these foundations are essential. A contract is not an ordinary server application. It executes in a replicated environment, where many nodes independently process the same transaction and must reach the same result. Code is usually public, execution is persistent, and errors may be difficult or impossible to reverse. Sound contract development therefore requires understanding both programming and the underlying trust model.

Learning Objectives

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

• distinguish centralized, decentralized, and distributed systems;
• explain blocks, transactions, state, and distributed ledgers;
• describe hashing, digital signatures, public-key cryptography, and Merkle trees;
• compare major consensus approaches and their trust assumptions;
• explain why blockchain execution must be deterministic;
• describe the lifecycle of a smart contract;
• identify major smart-contract use cases and their limitations;
• evaluate governance, security, legal, and ethical implications of blockchain applications.

1. Centralized, Distributed, and Decentralized Systems

A centralized system has a dominant authority that controls infrastructure, data, and decision-making. A bank database is a typical example: the bank determines which records are valid, processes transactions, and resolves disputes. Centralization can provide speed, accountability, privacy, and efficient correction of errors, but it also creates a single point of control and failure.

A distributed system consists of multiple computers that communicate over a network. Distribution does not necessarily imply decentralization. A company may operate a distributed database across several data centres while retaining complete administrative control.

A decentralized system distributes authority among multiple participants. No single participant is expected to control the complete system. Blockchain networks are generally distributed and may be decentralized, although the degree of decentralization varies with validator concentration, software control, governance, and ownership of infrastructure.

This distinction is important because blockchain is not automatically superior to a conventional database. If one trusted organization controls all participants and data, a conventional database may be faster, cheaper, and easier to govern. Blockchain becomes more valuable when several parties need a shared record but do not wish to place complete control in one organization.

2. Distributed Ledgers and Blockchain Structure

A distributed ledger is a replicated record maintained by multiple network participants. Each participant may hold a complete or partial copy of the ledger. The ledger records transactions and, depending on the platform, the resulting state of accounts, assets, permissions, or contract storage.

A blockchain organizes ledger history into blocks. A simplified block contains:

• a reference to the preceding block;
• a timestamp or protocol-defined time value;
• an ordered set of transactions or a transaction commitment;
• a state or transaction root, commonly represented by a Merkle-tree root;
• consensus-related metadata.

The previous-block reference is typically a cryptographic hash. If the contents of an earlier block change, its hash changes, causing subsequent references to become inconsistent. This creates tamper evidence. It does not, by itself, make data mathematically impossible to alter: an attacker would also need to overcome the network’s consensus and economic or operational protections.

A blockchain ledger can be understood through two related concepts:

1. History: the ordered sequence of accepted transactions.
2. State: the current result of applying those transactions according to protocol rules.

For an account-based blockchain, state may include account balances, contract code, nonces, and contract storage. A transaction changes state only if it is valid and is included according to consensus rules.

A useful abstract model is:

Here, S_t is the state before a transaction or transaction set, T_t is the input transaction or ordered transaction set, F is the protocol’s state-transition function, and S_t+1 is the resulting state. The model assumes that all honest nodes use the same protocol rules and transaction ordering. It is not a prediction formula; it is a conceptual description of state transition.

Transactions

A transaction is a signed instruction submitted to the network. Depending on the blockchain, it may transfer value, deploy contract code, invoke a contract function, or modify permissions. A transaction commonly contains a sender identifier, recipient or contract address, input data, a fee limit, a fee price, a nonce or sequence number, and a digital signature.

A transaction is not the same as a contract execution result. It is an authenticated request for execution. Nodes validate the request, execute it according to protocol rules, and record the result if the transaction is accepted into the canonical chain.

Fees and resource use

Smart-contract execution consumes computational and storage resources. Public networks charge fees to discourage spam and compensate validators or block producers. In Ethereum-like systems, execution is measured in gas. A simplified fee relationship is:

Gas used is measured in gas units, while gas price is commonly denominated in the smallest unit of the native currency per gas unit. The formula assumes the transaction is executed under the relevant network’s fee rules. Actual fee mechanisms may include base fees, priority fees, fee caps, refunds, or separate data charges.

3. Cryptographic Foundations

Cryptography provides integrity, authentication, and controlled ownership. It does not replace governance or solve every social problem.

Hash functions

A cryptographic hash function maps an input of arbitrary length to a fixed-length output. A secure hash is expected to provide:

• preimage resistance: given a hash, finding an input that produces it is computationally difficult;
• second-preimage resistance: given one input, finding a different input with the same hash is difficult;
• collision resistance: finding any two different inputs with the same hash is difficult;
• avalanche behaviour: a small input change generally produces a substantially different output.

If H is a hash function and m is a message, the digest is h = H(m). The output length is fixed by the chosen algorithm, while the input length may vary. Hashes are used for block references, transaction identifiers, commitments, and Merkle trees.

A hash is not encryption. Encryption is designed to be reversible by an authorized party using a key; a cryptographic hash is normally designed as a one-way digest.

Public-key cryptography and signatures

Public-key systems use a key pair: a private key and a corresponding public key. The private key must remain secret. The public key may be shared. A digital signature demonstrates control of the private key associated with a public key and provides integrity for the signed message.

A simplified signing process is:

1. The sender constructs a transaction.
2. The transaction is encoded according to protocol rules.
3. The sender signs the transaction using the private key.
4. Network nodes verify the signature using the public key or an address derived from it.
5. Nodes reject the transaction if the signature is invalid or the transaction violates other rules.

A signature proves authorization under the cryptographic scheme; it does not prove that the signer is a legitimate real-world person, that the transaction is wise, or that an external fact is true. Private-key compromise can allow unauthorized transactions, while private-key loss can make assets inaccessible.

Merkle trees

A Merkle tree summarizes many records with one root hash. Leaf nodes represent transaction hashes. Pairs of hashes are repeatedly combined and hashed until one root remains. A Merkle proof can demonstrate that a transaction belongs to a committed set without transmitting every transaction.

If a tree contains n leaves and is approximately balanced, a membership proof generally contains about log₂(n) sibling hashes. This logarithmic proof size is useful for light clients. The exact structure depends on the protocol, including treatment of odd numbers of leaves and transaction ordering.

4. Consensus and Trust Models

Consensus is the process by which network participants agree on the valid ordering and state of transactions. It must address conflicting transactions, faulty nodes, network delays, and potentially malicious participants.

Proof of Work

Proof-of-Work systems require participants to perform computational work to propose blocks. Security is connected to the cost of acquiring and operating sufficient computational power. Participants compete to satisfy a protocol-defined condition, and the chain-selection rule favours the chain representing the greatest accepted work or equivalent measure.

Advantages include an open participation model and a long operational history. Limitations include energy consumption, specialized hardware, probabilistic finality, and possible concentration of mining power.

Proof of Stake

Proof-of-Stake systems select or weight validators according to staked assets and protocol rules. Validators may be penalized for specified misbehaviour, often through slashing or loss of rewards. Stake-based systems can reduce energy use and support faster finality mechanisms, but they introduce risks involving wealth concentration, validator cartels, governance power, and complex incentive design.

Permissioned consensus

In a permissioned network, an authorized group operates validators. Protocols may use Byzantine fault-tolerant voting, leader rotation, or other mechanisms. These networks can provide high throughput and identifiable governance, but trust is placed in the consortium and its admission, operational, and dispute-resolution procedures.

No consensus mechanism eliminates trust. It changes where trust is placed: in computing power, economic stake, an appointed validator group, software governance, legal institutions, or combinations of these.

Safety and liveness

Consensus protocols commonly distinguish:

• Safety: honest participants do not finalize conflicting states.
• Liveness: valid transactions eventually receive progress or inclusion, assuming protocol conditions hold.
• Finality: the degree to which an accepted transaction is considered irreversible.

Some systems provide probabilistic finality, where confidence increases as additional blocks are added. Others provide explicit or economic finality after a voting threshold. Users and applications must understand which type applies before treating a transaction as irreversible.

5. Deterministic Execution

A blockchain virtual machine executes the same transaction on many independent nodes. Determinism requires that every honest node, starting from the same prior state and valid transaction, obtains the same result.

Contract code must therefore avoid uncontrolled dependence on:

• local computer time;
• random numbers generated from local state;
• operating-system files;
• network responses;
• local database contents;
• nondeterministic thread scheduling;
• floating-point behaviour where exact reproducibility is required.

Block timestamps, block numbers, and other block metadata may be available, but they are protocol values and should not be treated as precise real-world time or secure randomness. If a contract requires external information such as an exchange rate or delivery event, it generally uses an oracle. The oracle introduces a new trust and governance dependency.

Determinism does not mean that execution is automatically fair. Transaction ordering can affect outcomes. A validator or block producer may observe pending transactions and reorder, delay, or exclude them within the limits of protocol rules. This creates concerns such as front-running, sandwich attacks, and maximal extractable value.

6. Smart Contracts

A smart contract is a program deployed to a blockchain address. It contains executable logic and persistent state. Users interact with it by submitting transactions, while other applications may read its publicly available state through node interfaces.

The term “smart contract” can be misleading. A blockchain contract is not necessarily legally enforceable by itself, and it is not intelligent in the human sense. It is an automated rule system whose execution is constrained by code and consensus. Legal enforceability depends on jurisdiction, agreement, consumer-protection law, evidence, and the relationship between code and legal documents.

Core properties

• Automation: valid calls execute according to programmed rules.
• Transparency: code, transactions, and state may be publicly inspectable.
• Persistence: deployed code and stored state remain available under protocol rules.
• Composability: contracts can call other contracts and use shared standards.
• Limited reversibility: correcting an error may require an upgrade, migration, governance decision, or compensating transaction.

Smart-contract lifecycle

The lifecycle normally includes the following stages:

1. Requirements and threat modelling: define assets, actors, assumptions, failure modes, and legal constraints.
2. Design: specify state variables, permissions, invariants, events, interfaces, and upgrade policy.
3. Implementation: write Solidity or another supported language and compile it into bytecode and an application binary interface (ABI).
4. Testing: use unit, integration, property-based, fuzz, and adversarial tests.
5. Review and audit: conduct peer review, static analysis, and, for high-value systems, independent security assessment.
6. Deployment: submit creation transaction, record the resulting address, verify source where appropriate, and configure operational controls.
7. Operation: monitor events, balances, failures, upgrades, and privileged actions.
8. Maintenance or retirement: apply governed upgrades, migrate state, pause functions when justified, or decommission the application.

Deployment is itself a transaction. A contract address is not necessarily a person or organization; it is an address controlled by protocol execution. Contract-to-contract calls may trigger complex chains of effects, so developers must analyse external calls, reentrancy, access control, and failure propagation.

Solidity relevance

Solidity is a statically typed, contract-oriented language commonly used for Ethereum-compatible virtual machines. It provides functions, events, modifiers, mappings, structs, inheritance, interfaces, and visibility controls. Solidity code is compiled into bytecode executed by the virtual machine, while the ABI describes how external software encodes calls and decodes results.

A Solidity developer must distinguish:

• storage, persistent and comparatively expensive state;
• memory, temporary data during execution;
• calldata, read-only input supplied with an external call;
• events, logs intended for off-chain consumers rather than contract-readable storage.

The language is only one part of security. Compiler versions, libraries, deployment scripts, key management, oracle design, governance, and monitoring also affect system safety.

7. Major Use Cases

Digital assets and tokenization

Contracts can represent transferable units, ownership records, rights, or claims. Fungible-token standards support interchangeable units, while non-fungible-token standards represent individually identifiable items. Tokenization does not automatically transfer legal title: the connection between a token and an off-chain asset must be defined and enforceable.

Decentralized finance

Lending, exchanges, derivatives, stable-value instruments, and automated market makers use contracts to manage collateral and settlement. Risks include oracle failure, liquidity loss, smart-contract exploits, governance capture, and cascading liquidations.

Supply chains

A shared ledger can record handoffs, certifications, and provenance across organizations. Its value depends on the quality of data entered at the physical boundary. Blockchain can preserve a record of what was submitted; it cannot guarantee that a submitted claim was true.

Decentralized identity and credentials

Users may hold verifiable credentials and selectively disclose information. Good design minimizes unnecessary publication of personal data. Public blockchains are generally inappropriate for storing immutable plaintext personal information because deletion and consent requirements may conflict with permanence.

Royalties, licensing, and automated settlement

Contracts can distribute payments according to programmed rules. However, reliable performance requires clear definitions of sales, ownership, permitted use, taxes, dispute handling, and external data.

Governance and collective coordination

Decentralized autonomous organizations use contracts, voting systems, and treasury controls to coordinate participants. Formal voting does not guarantee informed or equitable governance; token concentration, voter apathy, delegated power, and legal uncertainty remain significant issues.

8. Illustrative Case: Agricultural Provenance Network

This is a fictional illustrative case.

Background

A cooperative of coffee producers sells certified beans to international buyers. Producers, transporters, warehouses, auditors, and buyers maintain separate records. Disputes about certification and custody delay payment.

Problem

The cooperative wants a shared history of batch creation, inspection, shipment, and receipt. It also wants payment to be released automatically when defined delivery evidence is recorded.

Analysis

A permissioned blockchain is selected because the participants are known organizations and the cooperative requires controlled access. A public chain would provide stronger public verifiability but could expose commercially sensitive information and create unpredictable fees. The design uses off-chain documents, hashed references, and a contract recording batch identifiers, authorized inspectors, custody events, and payment status.

The system does not assume that a blockchain proves physical reality. Inspectors remain responsible for the accuracy of certification. An oracle or authorized data gateway submits inspection results, creating an explicit trust point.

Approach

The contract includes role-based permissions, unique batch identifiers, event logs, a payment escrow mechanism, and a dispute or pause function. Payments are released only when the required events are recorded in the prescribed order. The cooperative establishes a governance policy for adding inspectors, correcting erroneous records, handling compromised credentials, and upgrading the contract.

Security testing includes unauthorized-call tests, duplicate-batch tests, invalid-state-transition tests, failure of payment calls, and tests for reentrancy and denial-of-service conditions.

Outcome

The network improves shared visibility and reduces reconciliation work. It does not eliminate disputes, because participants may still disagree about inspection quality or data accuracy. The main benefit is a common, auditable workflow rather than a claim that code has made trust unnecessary.

Learning points

1. Permission design should reflect the actual business trust model.
2. Oracles are part of the system’s security boundary.
3. A blockchain record preserves submissions, not necessarily truth.
4. Governance and recovery procedures must be designed before deployment.
5. A conventional database may be preferable if one organization already has legitimate authority and no multi-party reconciliation problem exists.

9. Limitations, Governance, and Ethics

Blockchain systems face scalability constraints, transaction fees, latency, privacy challenges, key-management risks, and software vulnerabilities. Public transparency can conflict with confidentiality. Immutability can conflict with correction, deletion, and consumer rights. Automated execution can magnify mistakes and make redress difficult.

Governance must address protocol upgrades, validator admission, emergency response, treasury management, voting rights, and conflicts of interest. A technical “admin key” may be necessary for safety, but it creates concentrated authority that users must understand.

Legal and regulatory analysis may involve securities law, payments regulation, anti-money-laundering requirements, consumer protection, taxation, data protection, and licensing. The classification of a token or service depends on facts and jurisdiction; technical labels alone are insufficient.

Ethically, designers should consider accessibility, environmental effects, financial harm, surveillance, discrimination, and unequal exposure to irreversible errors. Responsible practice includes clear disclosures, least-privilege permissions, privacy minimization, independent review, incident response, and mechanisms for human intervention where appropriate.

Artificial intelligence may assist with code review, anomaly detection, documentation, and test generation. It must not be treated as an authority: generated code can contain subtle vulnerabilities, and confidential keys or sensitive data should never be exposed to an unapproved tool.

Best-Practice Framework

Before deploying a smart-contract system, ask:

1. Is a blockchain actually needed?
2. Who are the participants, and what must they trust?
3. Which facts are on-chain, and which depend on oracles?
4. What assets and failure modes are in scope?
5. Are permissions, upgrades, pauses, and recovery explicit?
6. Are state transitions and invariants formally specified?
7. Has the code been tested against adversarial behaviour?
8. Are private keys protected by suitable operational controls?
9. Can users understand fees, risks, and irreversibility?
10. Is there a monitored incident-response and governance process?

Chapter Summary

Blockchain is a distributed ledger technology in which network participants maintain a shared history and state under common protocol rules. Blocks, hashes, signatures, Merkle trees, and consensus mechanisms provide integrity and coordination, but each addresses a different problem. Consensus determines which transactions are accepted and in what order; cryptography authenticates and commits data; deterministic execution ensures that honest nodes compute the same result.

Smart contracts are persistent programs executed by a blockchain virtual machine. Their lifecycle extends from requirements and threat modelling through design, implementation, testing, audit, deployment, monitoring, governance, and retirement. Solidity development therefore requires more than language syntax: it requires analysis of state, authorization, external calls, resource consumption, oracles, upgrades, and human institutions.

Blockchain applications can support tokenization, finance, provenance, identity, settlement, and collective governance. Their benefits are conditional. They do not guarantee truthful inputs, legal enforceability, privacy, scalability, or fairness. Professional practice places the blockchain within a broader socio-technical system of people, data, law, incentives, and operational controls.

Key Terms

Distributed ledger: A replicated record maintained by multiple network participants.

Blockchain: A ledger that organizes data into linked, ordered blocks.

State: The current values and ownership conditions resulting from accepted transactions.

Transaction: A signed request to transfer value, deploy code, or invoke a program.

Hash function: A function that maps input data to a fixed-length cryptographic digest.

Digital signature: Cryptographic evidence that a private key authorized a message.

Private key: Secret cryptographic material used to sign transactions.

Public key: A shareable key used to verify signatures or derive an address.

Merkle tree: A hash-based structure that summarizes a set of records.

Consensus: Rules and processes for agreeing on valid transaction history and state.

Proof of Work: Consensus based partly on expending computational resources.

Proof of Stake: Consensus based partly on economically committed stake.

Finality: The degree to which a transaction is considered irreversible.

Smart contract: A blockchain-resident program with executable logic and persistent state.

Determinism: The property that identical valid inputs produce identical execution results.

Oracle: A mechanism that supplies external information to a blockchain application.

Gas: A protocol measure of computational or storage work used by execution.

ABI: An interface specification for encoding contract calls and decoding results.

Reentrancy: An execution risk in which control returns to a contract before an earlier operation is complete.

Governance: Processes for making and enforcing decisions about a blockchain system.

Review Questions

Short Answer Questions

1. What is the difference between a distributed system and a decentralized system?
2. Why is a blockchain hash not the same as encryption?
3. What does deterministic execution require from blockchain nodes?
4. What is the purpose of a digital signature in a transaction?
5. Why do smart-contract systems often require oracles?

Long Answer Questions

1. Explain how blocks, transactions, state, hashes, and consensus interact in a blockchain system.
2. Compare Proof of Work, Proof of Stake, and permissioned consensus, including their trust assumptions and limitations.
3. Describe the complete lifecycle of a smart contract from requirements analysis to retirement.
4. Discuss why immutability can be both an advantage and a risk in smart-contract applications.
5. Evaluate the claim that smart contracts eliminate the need for trust.

Analytical / Application Questions

1. A consortium of banks already operates a jointly governed database and requires confidential, high-throughput settlement. Analyse whether a permissioned blockchain is justified, and identify the decision criteria.
2. Design a trust and security boundary for a supply-chain contract that receives inspection results from an external oracle. Identify at least four failure modes and corresponding controls.
3. A public contract automatically releases funds when a delivery timestamp is submitted. Analyse the risks of relying on timestamps and propose a safer design using explicit business events, permissions, and dispute handling.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a distributed system from a decentralized system?

A. A distributed system always uses a blockchain.

B. A distributed system has multiple computers, while decentralization concerns the distribution of authority.

C. A decentralized system must have one controlling administrator.

D. The terms are technically identical.

Correct Answer: B. A distributed system has multiple computers, while decentralization concerns the distribution of authority.

Question 2

What is the primary purpose of a cryptographic hash in a blockchain?

A. To provide reversible encryption for private data

B. To authenticate a person’s legal identity

C. To create a tamper-evident digest of data

D. To guarantee that external data is truthful

Correct Answer: C. To create a tamper-evident digest of data

Question 3

Why must blockchain smart-contract execution be deterministic?

A. So every honest node can obtain the same state transition

B. So contracts can access each node’s local files

C. So transaction fees are eliminated

D. So private keys can be published safely

Correct Answer: A. So every honest node can obtain the same state transition

Question 4

Which item must normally remain secret to authorize transactions?

A. Contract address

B. Public key

C. Block number

D. Private key

Correct Answer: D. Private key

Question 5

A transaction uses 21,000 gas and the gas price is 20 units per gas. Under the simplified fee formula, what is the fee?

A. 1,050 units

B. 21,020 units

C. 420,000 units

D. 4,200,000 units

Correct Answer: C. 420,000 units

Question 6

What does a Merkle proof primarily allow a participant to demonstrate?

A. That a transaction belongs to a committed set of records

B. That a private key has never been copied

C. That an oracle’s external fact is true

D. That a blockchain has unlimited capacity

Correct Answer: A. That a transaction belongs to a committed set of records

Question 7

Which statement about an oracle is most accurate?

A. It removes all trust assumptions from a contract.

B. It supplies external information and introduces an additional trust and governance dependency.

C. It is the same as a private key.

D. It guarantees that physical events occurred as reported.

Correct Answer: B. It supplies external information and introduces an additional trust and governance dependency.

Question 8

Which is a characteristic of Proof of Stake?

A. Validators are selected only by physical location.

B. Block production depends exclusively on encryption.

C. Participants may commit economic stake and face protocol penalties for specified misconduct.

D. It requires every user to store every historical file.

Correct Answer: C. Participants may commit economic stake and face protocol penalties for specified misconduct.

Question 9

Which activity belongs earliest in a professional smart-contract lifecycle?

A. Threat modelling and requirements analysis

B. Publishing the contract address

C. Retiring the contract

D. Distributing audit findings after deployment

Correct Answer: A. Threat modelling and requirements analysis

Question 10

What limitation is illustrated by recording a supply-chain claim on a blockchain?

A. The blockchain automatically verifies the physical product.

B. The blockchain preserves the submitted record but cannot by itself prove that the input was truthful.

C. The blockchain prevents all disputes between participants.

D. The blockchain makes governance unnecessary.

Correct Answer: B. The blockchain preserves the submitted record but cannot by itself prove that the input was truthful.