Smart Contract Foundations

Introduction and Context

A smart contract is a computer program that executes agreed rules and produces results when specified conditions are met. In a blockchain environment, the program is usually stored, replicated, and executed by many independent computers. Its operation is therefore not based solely on the promise of a company, bank, or government. Instead, participants rely on a combination of cryptography, distributed data storage, consensus procedures, software rules, and economic incentives.

The expression smart contract was introduced by computer scientist Nick Szabo in the 1990s to describe computerized transaction protocols that enforce the terms of an agreement. Szabo used the example of a vending machine: when a customer inserts the required money, the machine automatically releases the selected product. Modern blockchain smart contracts extend this idea by allowing more complex rules, assets, identities, and interactions to be represented digitally.

A blockchain is not automatically a smart-contract platform. Some blockchains primarily record transfers of value, whereas programmable blockchains provide an execution environment in which users can deploy and call programs. Understanding this distinction is essential for analysing blockchain applications, risks, and design choices.

Learning Objectives

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

1. Define smart contracts and distinguish them from traditional legal contracts.
2. Explain distributed ledgers, decentralization, and consensus.
3. Describe transactions, digital signatures, hashes, and immutability.
4. Explain why deterministic execution is necessary in replicated blockchains.
5. Identify the trust assumptions and limitations of smart-contract systems.
6. Summarize the historical development of programmable blockchains.
7. Apply these concepts to a practical smart-contract scenario.

From Centralized Records to Distributed Ledgers

A conventional database is normally controlled by an administrator or organization. The administrator determines who may write data, which version is authoritative, and how errors are corrected. This arrangement can be efficient, but users must trust the administrator and the organization’s operational controls.

A distributed ledger is a record maintained by multiple network participants, often called nodes. Each node may hold a copy of the ledger or enough information to verify it. A valid update is accepted according to network rules rather than according to the unilateral decision of one database owner.

A blockchain is a type of distributed ledger in which transactions are grouped into blocks. Each block normally contains a reference to the preceding block, commonly produced using a cryptographic hash. If earlier data changes, the resulting hash changes, making unauthorized alteration detectable. A blockchain therefore provides an auditable history, although it does not make every piece of information permanently correct.

Decentralization

Decentralization describes the distribution of control, authority, data, and decision-making across participants. It is not a single condition. A system may be decentralized in one dimension and centralized in another. For example, transaction validation may be distributed while software development, token ownership, or access to user interfaces remains concentrated.

Important dimensions include:

Decentralization can reduce dependence on a single operator, but it may increase costs, slow decision-making, and make accountability more difficult. A decentralized system still depends on software developers, infrastructure providers, wallet operators, users, and governance institutions.

Consensus: Agreeing on the Ledger State

In a distributed network, nodes must agree on which transactions are valid and in what order they should be applied. This coordination problem is addressed through a consensus mechanism.

Consensus is not simply a vote about truth. It is a protocol for selecting an accepted state despite delays, failures, conflicting messages, or dishonest participants. Different mechanisms make different assumptions and impose different costs.

Proof of Work

In proof-of-work systems, specialized participants compete to solve a computational puzzle. The winning participant proposes a block, and the network verifies it. Security is connected to the cost of obtaining computational power and electricity. The major limitations are energy consumption, specialized hardware, and probabilistic finality.

Proof of Stake

In proof-of-stake systems, participants lock or delegate economic value and may be selected to propose or attest to blocks. Dishonest behavior can lead to penalties, often called slashing. Security therefore depends partly on the economic value at risk, validator distribution, protocol design, and governance.

Permissioned Consensus

A permissioned network restricts participation to approved organizations or identities. Such systems may use voting, Byzantine fault-tolerant protocols, or other controlled procedures. They can offer faster confirmation and greater privacy, but they require trust in the membership and governance arrangements.

Consensus does not guarantee that an input is factually correct. If a smart contract receives an incorrect price from an oracle, consensus may faithfully preserve and execute the incorrect input. Consensus establishes agreement about the state according to protocol rules; it does not independently establish real-world truth.

Transactions, State, and Execution

A blockchain transaction is a digitally authorized request to change the ledger state. Depending on the platform, it may transfer tokens, deploy a contract, call a contract function, or perform another protocol-defined operation.

A useful abstract model is:

Here, S_t is the current system state, T_t is a valid transaction or ordered set of transactions, F is the protocol’s state-transition function, and S_t+1 is the resulting state. The model assumes that all honest nodes apply the same rules to the same ordered inputs.

A smart contract usually maintains state variables such as balances, ownership records, permissions, or voting status. A transaction invokes a function that reads existing state and may produce a new state. The transaction may succeed, fail, or consume execution resources without producing the intended state change.

Transactions commonly include:

• the destination address or contract address;
• the requested operation and its arguments;
• a fee or resource limit;
• a sequence number or nonce to prevent unintended replay;
• the sender’s digital signature; and
• protocol-specific metadata.

A transaction is not the same as a contract. The contract is persistent code and state; the transaction is an authorized request that may invoke that code.

Digital Signatures and Identity

Digital signatures allow a participant to demonstrate control of a private key without revealing that private key. A simplified process is:

1. The sender constructs a transaction.
2. The transaction is hashed.
3. The sender signs the hash using a private key.
4. Network nodes use the corresponding public key to verify the signature.
5. If the signature and other protocol conditions are valid, the transaction may be accepted.

A signature provides authorization and integrity. It does not prove that the person controlling a key is legally entitled to act, nor does it guarantee that the transaction’s contents are economically wise. If a private key is stolen, the protocol may treat the thief’s validly signed transaction as authorized.

Public-key systems are commonly represented by a key pair:

Key management is therefore a central operational risk. Hardware wallets, multisignature controls, role separation, transaction simulation, and carefully protected recovery procedures reduce—but do not eliminate—this risk.

Hashes and Immutability

A cryptographic hash function maps input data to a fixed-length output. A secure hash is designed so that it is computationally difficult to find two different inputs with the same output, to reconstruct the input from the output, or to create a chosen input with a specified output.

Blocks commonly contain the hash of the previous block. This creates a linked history. If an attacker changes a transaction in an earlier block, the hash of that block changes and the links to later blocks no longer match. The attacker would then need to overcome the relevant consensus and network security conditions.

Immutability should be understood carefully. Blockchain records are often tamper-evident and difficult to reverse, not metaphysically impossible to change. Changes may occur through protocol upgrades, reorganizations, governance decisions, administrative intervention in permissioned networks, or social agreement to adopt a new chain. Immutability also does not correct false data entered by an authorized user.

Deterministic Execution

A replicated smart-contract platform requires nodes to compute the same result. For a given initial state and ordered transaction, honest nodes should reach the same next state. This requirement is called deterministic execution.

A contract should generally avoid uncontrolled dependence on:

• local system time;
• random values generated independently by each node;
• local file systems or network responses;
• processor-specific behavior;
• nondeterministic iteration order; and
• external information not committed through a protocol mechanism.

If one node calculates that a payment succeeded while another calculates that it failed, the ledger cannot converge reliably. Platforms therefore provide controlled execution environments, resource limits, and deterministic instruction sets. Many platforms charge execution fees because computation and storage consume scarce network resources.

Randomness and external data require special mechanisms. A blockchain oracle can deliver information such as an exchange rate or weather reading, but the oracle becomes a trust and security dependency. A decentralized oracle network may reduce reliance on one source, yet it introduces questions about data selection, aggregation, incentives, and manipulation.

Smart Contracts and Traditional Contracts

A traditional legal contract is an agreement whose interpretation and enforcement may involve parties, courts, regulators, and professional advisers. A blockchain smart contract is executable code whose behavior is constrained by technical rules. The two can support each other, but they are not identical.

Code can execute exactly as written while still producing an unfair or legally unacceptable result. Legal design, user disclosure, consumer protection, and governance remain important.

Historical Development of Programmable Blockchains

The development of smart contracts can be viewed as a progression rather than a single invention.

Early Conceptual Foundations

In the 1990s, Nick Szabo described smart contracts as computerized transaction protocols. Earlier developments in cryptography, public-key infrastructure, digital cash, and secure computing provided essential technical foundations.

Bitcoin and Scripted Transactions

Bitcoin, launched in 2009, demonstrated that a distributed network could maintain a digital monetary ledger without a central clearing institution. Bitcoin transactions use a constrained scripting system. This supports conditions such as signatures and multisignature authorization, but it was intentionally limited compared with a general-purpose application platform.

General-Purpose Programmable Platforms

Later platforms introduced more expressive execution environments in which developers could deploy persistent programs. Ethereum, proposed in 2013 and launched in 2015, made general-purpose smart contracts a central feature of a public blockchain. Its account-and-state model allowed applications involving tokens, exchanges, lending, games, organizational governance, and digital collectibles.

Scaling and Alternative Architectures

As usage increased, limitations involving transaction capacity, fees, latency, and energy use encouraged new designs. These include proof-of-stake systems, layer-two networks, sidechains, application-specific chains, and permissioned platforms. Each approach changes the trade-off among security, decentralization, performance, cost, and interoperability.

Figure: A simplified historical timeline of programmable blockchain development.

Trust Assumptions and System Boundaries

Blockchain systems do not eliminate trust; they redistribute it. Users may trust:

• the cryptographic algorithms and implementation;
• the consensus mechanism and validator incentives;
• the deployed contract code;
• the compiler and development tools;
• wallet and key-management software;
• data oracles and bridges;
• governance and upgrade administrators;
• the availability of network infrastructure; and
• the legal and regulatory environment.

A useful professional question is: Which actor or mechanism can change the result, and under what conditions? For example, a contract may appear decentralized but contain an administrator key capable of pausing transfers or changing critical parameters. Such a control may be appropriate, but it must be disclosed and governed.

The phrase “trustless” is therefore misleading when interpreted literally. Smart contracts can reduce the need to trust a particular intermediary for a narrowly defined operation. They replace some institutional trust with trust in code, cryptography, protocol incentives, and operational processes.

Applied Case: A Token-Based Escrow Contract

The following is an illustrative case, not a report of a specific deployed system.

Background

A small exporter sells equipment to an overseas buyer. Both parties want protection: the buyer wants payment released only after delivery, while the seller wants evidence that funds are reserved before shipping. A traditional bank escrow service is slow and expensive for small transactions.

Problem

The parties must coordinate payment, delivery evidence, dispute handling, and refunds. Shipping information is generated outside the blockchain, so the contract cannot independently observe delivery.

Analysis

A smart contract could hold the buyer’s deposited tokens and define states such as funded, awaiting confirmation, released, and disputed. The contract could require signatures from the buyer, seller, and an approved logistics oracle. However, the oracle and dispute authority become important trust dependencies.

Approach and Solution

A carefully designed system might include:

1. A deposit function that accepts payment only before a deadline.
2. A state variable recording the escrow status.
3. Separate roles for buyer, seller, and arbitrator.
4. A release function requiring the appropriate authorization.
5. A dispute function that pauses automatic release.
6. A refund rule if the deadline expires without shipment.
7. Event logs for operational and audit purposes.
8. A security review, test deployment, and emergency procedure.

The contract should follow the checks-effects-interactions principle: validate conditions first, update internal state before external calls, and minimize re-entrant or unexpected interactions. Sensitive permissions should use multisignature control rather than one unprotected administrator key.

Outcome

The contract can reduce reliance on a bank for custody and rule execution, but it cannot determine whether goods are genuinely damaged or whether a delivery photograph is authentic. Human arbitration, reliable oracle design, and legal agreements remain necessary.

Learning Points

The case illustrates that automation is strongest where conditions are objective and digitally verifiable. It is weaker where performance depends on physical facts, judgment, identity, or legal interpretation. The main design task is not merely writing code; it is defining trustworthy boundaries between on-chain logic and the external world.

Benefits, Limitations, and Risks

Potential benefits include transparent audit trails, automated settlement, reduced reconciliation, programmable permissions, continuous availability, and composability between applications. Smart contracts can support decentralized finance, tokenization, supply-chain records, digital identity, insurance, and organizational governance.

Major limitations include:

• Code defects: A programming error may allow unauthorized transfers or permanently lock assets.
• Irreversibility: Mistaken transactions may be difficult or impossible to undo.
• Scalability constraints: Shared execution and storage can create congestion and high fees.
• Oracle dependence: External facts require trusted data-delivery mechanisms.
• Privacy limits: Public ledgers may expose transaction patterns and sensitive relationships.
• Governance risk: Upgrades, emergency powers, or concentrated voting can undermine decentralization.
• Interoperability risk: Bridges connecting networks have historically created complex attack surfaces.
• Legal uncertainty: The legal status of tokens, automated agreements, and decentralized organizations varies across jurisdictions.
• User-experience risk: Key recovery, transaction signing, and fee management can be difficult for non-specialists.

Ethical, Governance, and Regulatory Considerations

Smart-contract designers should consider fairness, accessibility, privacy, consumer protection, and the consequences of failure. A technically valid transaction may still cause serious harm if users do not understand the code or if an application exploits information asymmetry.

Governance should specify who can upgrade contracts, pause operations, change fees, add trusted data sources, or resolve disputes. These powers should be minimized, documented, auditable, and protected by appropriate approval thresholds. Privacy-by-design is also important: information that does not need to be public should not be placed directly on a transparent ledger.

Regulatory obligations may involve financial services, anti-money-laundering controls, securities law, data protection, taxation, consumer law, and electronic transactions legislation. Technical decentralization does not automatically remove legal responsibility. Organizations should obtain jurisdiction-specific advice before deployment.

Best Practices for Foundation-Level Design

A professional smart-contract project should:

1. Define the business problem before selecting a blockchain.
2. Specify actors, permissions, state transitions, and failure conditions.
3. Keep code simple and minimize unnecessary on-chain data.
4. Use established libraries and tested design patterns.
5. Test normal, boundary, failure, and adversarial cases.
6. Conduct independent security review and, where justified, formal verification.
7. Protect administrative keys with hardware security and multisignature approval.
8. Explain fees, risks, upgrade powers, and data visibility to users.
9. Monitor deployed systems and prepare incident-response procedures.
10. Treat oracles, bridges, wallets, and front-end applications as part of the security boundary.

Chapter Summary

Smart contracts are executable rules deployed in a blockchain or related distributed execution environment. They depend on distributed ledgers, cryptographic authorization, consensus, deterministic state transitions, and resource accounting. Transactions request state changes; digital signatures demonstrate control of private keys; hashes link records and make unauthorized alteration detectable; and consensus enables independent nodes to converge on an accepted ledger state.

Decentralization distributes control but does not remove all trust. Users continue to rely on code, cryptography, validators, developers, governance, oracles, infrastructure, and legal institutions. Smart contracts can automate clear and digitally verifiable conditions, but they cannot independently establish the truth of external events. Their history developed from cryptographic and digital-cash research through Bitcoin’s constrained scripts to general-purpose programmable platforms and newer scaling architectures.

Effective professional practice requires attention to security, privacy, governance, legal obligations, usability, and the boundary between on-chain code and the physical or institutional world.

Key Terms

Smart contract: Executable software that applies predefined rules, usually in a blockchain environment.

Distributed ledger: A record replicated or maintained across multiple network participants.

Blockchain: A distributed ledger that organizes records into linked blocks.

Decentralization: Distribution of control, data, validation, or governance among multiple participants.

Consensus: A protocol for agreeing on valid ledger updates and state.

Node: A computer or software participant in a distributed network.

Transaction: A digitally authorized request to change ledger state.

State: The current data configuration maintained by a protocol or contract.

State-transition function: The rule that maps a current state and valid transaction to a new state.

Private key: Secret cryptographic value used to authorize actions.

Public key: Cryptographic value used to verify signatures.

Digital signature: Cryptographic evidence that a transaction was authorized by a private key.

Hash: A fixed-length cryptographic representation of input data.

Immutability: Resistance to alteration, reversal, or deletion after recording.

Deterministic execution: Producing the same result from the same state and ordered inputs.

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

Gas or execution fee: A charge for computational or storage resources.

Validator: A participant that proposes, verifies, or attests to ledger updates.

Multisignature: An authorization scheme requiring approval from multiple keys.

Governance: Processes for changing rules, parameters, permissions, or protocol direction.

Review Questions

Short Answer Questions

1. What is a smart contract, and how does it differ from a traditional legal contract?
2. Why is consensus necessary in a distributed ledger?
3. What role does a digital signature play in a blockchain transaction?
4. Explain why smart-contract execution must be deterministic.
5. Why should blockchain immutability be described as tamper-evidence rather than absolute permanence?

Long Answer Questions

1. Compare centralized databases and distributed ledgers, including their advantages and limitations.
2. Explain how transactions, state, hashes, signatures, and consensus work together to update a blockchain.
3. Compare proof of work, proof of stake, and permissioned consensus.
4. Discuss the trust assumptions involved in a smart-contract application that uses an oracle.
5. Trace the historical development from smart-contract concepts to modern programmable blockchain platforms.

Analytical / Application Questions

1. A contract automatically releases payment when a logistics oracle reports delivery. Identify at least four technical, governance, or legal risks and propose controls for each.
2. A decentralized application has 10,000 token holders but one administrator key can upgrade the contract instantly. Analyse whether the application is decentralized and explain what additional disclosures or controls are appropriate.
3. Design the principal states, roles, authorization rules, and failure conditions for a blockchain-based equipment escrow system. Explain which conditions should remain subject to human or institutional judgment.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a smart contract?

A. A paper agreement stored in a database

B. Executable code that applies predefined rules

C. A mining device used to validate blocks

D. A private key used to access a wallet

Correct Answer: B. Executable code that applies predefined rules

Question 2

What is the primary purpose of consensus in a distributed ledger?

A. To guarantee that all external data is truthful

B. To hide all transactions from network participants

C. To help participants agree on valid ledger updates

D. To replace digital signatures

Correct Answer: C. To help participants agree on valid ledger updates

Question 3

What does a digital signature primarily demonstrate?

A. That the transaction was authorized by the relevant private key

B. That the transaction is legally enforceable in every jurisdiction

C. That the recipient is a government-verified person

D. That the transaction contains accurate real-world information

Correct Answer: A. That the transaction was authorized by the relevant private key

Question 4

Why must replicated smart-contract execution be deterministic?

A. So nodes using the same inputs reach the same result

B. So contracts can access unrestricted external websites

C. So transaction fees are always zero

D. So private keys can be published safely

Correct Answer: A. So nodes using the same inputs reach the same result

Question 5

Which statement about blockchain immutability is most accurate?

A. Recorded information can never be changed under any circumstances

B. Immutability makes incorrectly entered data automatically correct

C. Records are generally difficult to alter, but protocol or governance changes may occur

D. Only centralized databases can provide tamper evidence

Correct Answer: C. Records are generally difficult to alter, but protocol or governance changes may occur

Question 6

What is an oracle in a smart-contract system?

A. A mechanism that supplies external information to the blockchain

B. A device that generates private keys

C. A consensus algorithm based only on electricity use

D. A replacement for all network validators

Correct Answer: A. A mechanism that supplies external information to the blockchain

Question 7

Which item is normally kept secret by an account holder?

A. Block number

B. Public address

C. Private key

D. Transaction hash

Correct Answer: C. Private key

Question 8

What is a major limitation of a blockchain consensus mechanism?

A. It can prove that every real-world input is factually correct

B. It may preserve and execute an incorrect oracle input

C. It prevents any software from being deployed

D. It eliminates the need for governance

Correct Answer: B. It may preserve and execute an incorrect oracle input

Question 9

Which development is associated with Ethereum’s significance?

A. It introduced general-purpose smart-contract execution as a central feature

B. It eliminated the need for cryptography

C. It restricted all transactions to physical cash

D. It made distributed ledgers dependent on one database administrator

Correct Answer: A. It introduced general-purpose smart-contract execution as a central feature

Question 10

Which control best reduces the risk of one compromised administrator key changing a contract?

A. Publishing the administrator’s private key

B. Using multisignature approval and clearly governed upgrade procedures

C. Removing all transaction records

D. Allowing unrestricted external calls

Correct Answer: B. Using multisignature approval and clearly governed upgrade procedures