Introduction to Smart Contracts

3.1 — Introduction to Smart Contracts

Recall first. Two strangers want to exchange an asset without trusting one another. What must be encoded so that the exchange can happen without a human intermediary? Write: conditions, trigger, and outcome in your own words before reading.

The core idea

A smart contract is a computer program on a blockchain whose rules determine how parties interact. When its predefined conditions are met, the program executes the specified action. It is therefore an automated, machine-readable agreement—not a magical replacement for every legal contract.¹

The useful chain is:

agreement → rules in code → deployment → address on blockchain
          → input/trigger → validation → state change recorded on-chain

The book describes a contract as a set of digitally specified promises and protocol procedures. After compilation and migration, the contract receives an address; its application and state are recorded through blockchain transactions and distributed to nodes.¹

What “smart” contributes

A normal agreement often needs an intermediary to verify conditions and enforce settlement. A smart contract moves the specified, checkable part of that work into code:

1. Reach an agreement: define conditions, rights, and obligations.
2. Formalise it: express those rules in machine-readable form.
3. Enforce it: execute the programmed result when the conditions are satisfied.¹

This can reduce intermediary dependence, delay, and transaction cost. It does not make the underlying facts true. If the contract receives false data, it can execute false logic perfectly.

How a smart contract works

A contract usually has:

A transaction from an external account triggers the contract. Nodes execute the same deterministic rules, and the resulting state is recorded by the blockchain. Writing/updating state costs resources, so Ethereum charges gas; reading state is generally cheaper because it does not create a state-changing transaction.¹

Important boundary. A browser front end is not the smart contract. A DApp combines a user-facing application with one or more contracts and often other services. The contract is the on-chain rule engine; the browser is a client.¹

Structure of a smart contract

At a conceptual level, a Solidity contract contains:

pragma/version choice
contract name {
    state variables
    events
    modifiers
    constructor
    functions
}

The constructor runs during deployment to initialise state. Functions expose permitted reads or state-changing actions. Modifiers package reusable checks such as “only the owner may perform this action.” Events write logs that an external application can listen for. These language elements are developed in note 3.2.²

Smart-contract approaches

The book presents smart contracts along a spectrum from natural-language agreement to machine automation. The exam-safe distinction is:

• Code entirely: the operative rules are directly encoded in program logic.
• Split approach: natural-language terms explain the agreement while code automates the parts that can be checked.
• Encoded performance: code evaluates conditions and performs the agreed action.
• Encoded payment: the contract also controls a payment or asset-transfer mechanism.¹

The more execution is delegated to code, the more important precise specifications, deterministic execution, testing, and dispute handling become.

Types of smart contracts

The book groups application-oriented smart contracts into four types:¹

1. Smart legal contracts — legal templates whose terms are executed according to their coded form.
2. Decentralized applications (DApps) — end-to-end applications with a blockchain-connected smart-contract back end and a front end. A DApp may use several contracts and external systems.
3. Decentralized autonomous organizations (DAOs) — transparent program logic and financial records governed by stakeholders rather than one central authority. Proposals and stakeholder voting are examples of governance actions.
4. Smart-contracting devices — blockchain-connected IoT devices that use coded rules to coordinate data or actions.

DAO and voting

A DAO can use proposals, stakeholder consensus, and voting to decide whether funds move or contractors are appointed. The book mentions this governance pattern, but it does not provide the complete voting-contract application required by syllabus topic 3.3. That application is built as an explicit syllabus bridge in note 3.3, not presented as a book example.¹³

Oracles: the off-chain boundary

A smart contract cannot directly observe the physical world or arbitrary web services. An oracle is an agent or service that verifies an off-chain occurrence and submits usable data on-chain.¹

The book identifies several oracle categories:

An oracle extends a contract’s usefulness but also introduces a trust surface. The blockchain can make the submitted value tamper-evident; it cannot independently prove that the oracle reported the real-world event correctly.

Limitations and failure modes

“Automatic” does not mean “unlimited.” The important limitations are:

1. Bad input and oracle dependence

A contract is deterministic with respect to its inputs. It cannot repair incorrect human data or a manipulated oracle. This is the classic garbage in, garbage out problem. External facts, legal identity, and physical delivery may still require trusted institutions or multiple data sources.¹⁴

2. Immutability and mistakes

Deployed code and recorded state are difficult to alter. That supports auditability, but a bug or wrongly specified rule may also be preserved. “Immutable” means the network will not accept an ordinary unauthorised rewrite; it does not mean the code is correct, legally complete, or impossible to supersede through a new contract and governance process.

3. Sequential execution and denial of service

The book notes a design risk in which transactions are committed and executed in order. A deliberately expensive or long-running contract can delay subsequent work and reduce throughput, creating a denial-of-service vector. Resource limits, bounded loops, and careful gas-aware design are therefore essential.⁴

4. Determinism and language design

Every validating node must reach the same result. Nondeterministic behaviour—such as relying on unstable iteration order—can produce inconsistent state or forks. A contract language and execution environment must constrain behaviour so that equivalent inputs lead to the same output.⁴

5. State synchronisation and consensus

Contract execution changes shared state. Nodes must obtain the same result and propagate or verify that state. Faulty or malicious nodes, execution backlogs, and consensus assumptions affect reliability. State-machine replication is one approach discussed in the book for running execution on a subset of nodes and broadcasting the result.⁴

6. Formal verification is difficult

Testing demonstrates behaviour for selected inputs; formal verification attempts to prove that a program satisfies a specification. The book treats formal verification of smart contracts as a major unsolved challenge because the specification and proof themselves are difficult.⁵

7. Resource, energy, and scalability cost

Distributed execution adds signature verification, redundancy, communication, and consensus overhead. A central database can be faster where there is already one trusted operator. Blockchain use must justify the cost of shared verification.⁴⁵

8. Human and legal limits

A chain can preserve the record of a submitted fact, but it cannot guarantee that the original fact was honest. Nor does code alone settle every legal exception, dispute, identity question, or physical obligation. Smart contracts automate defined rules; they do not remove governance, law, or human responsibility.

Worked example — conditional land sale

Scenario: Parker wants to buy land from Michael. The rule is: transfer ownership and release payment only if identity, ownership, tax, and other required conditions are valid.

Reasoning:

1. The parties and authorities agree on the conditions.
2. The contract records the relevant state and the permitted transition.
3. Parker submits the purchase transaction.
4. The network executes the same checks.
5. If all conditions pass, the contract records the transfer and releases the payment; otherwise, the state transition fails.
6. An oracle may be needed for facts that are not already represented on-chain.

What this demonstrates: conditional execution, reduced dependence on an intermediary, traceability, and the on-chain/off-chain boundary. What it does not demonstrate: that an oracle’s data or the legal ownership claim is automatically true.¹

Exercise

1. Distinguish a smart contract from a DApp in two sentences.
2. Classify each as a smart legal contract, DApp, DAO, or smart-contracting device:
   • (a) A sensor releases a shipment-payment signal after a temperature condition is met.
   • (b) A browser application lets token holders approve a proposal.
   • (c) A coded insurance template pays when an agreed event is verified.
3. Why can a smart contract be tamper-resistant yet still produce a wrong result?
4. Name two limitations that arise specifically from distributed execution.

Exam lens

Definition: A smart contract is a blockchain-resident computer program that encodes conditions and executes a specified agreement or state transition when those conditions are met.

Five-mark answer structure:

1. Define it as code plus rules on a blockchain.
2. Explain deployment, address, trigger, validation, and state change.
3. State benefits: automation, auditability, reduced intermediary dependence, and lower delay/cost in suitable cases.
4. Name types: smart legal contracts, DApps, DAOs, and smart-contracting devices.
5. State limitations: oracle/input trust, bugs and immutability, gas/scalability, determinism, and legal/off-chain limits.

Common traps:

• A smart contract is not automatically a legally complete contract.
• A DApp is not identical to its smart contract.
• An oracle is not proof that an off-chain fact is true.
• Immutability is not correctness.
• A blockchain does not remove every trusted party; permissioned systems still have administrators.

Rapid revision

• Can I define a smart contract without saying “self-executing” alone?
• Can I trace agreement → code → deployment → trigger → state change?
• Can I list the four book categories of smart contracts?
• Can I explain the oracle problem in one example?
• Can I name four technical or organisational limitations?

Key takeaways

• A smart contract is code on a blockchain that automates specified rules and state transitions.
• Deployment gives the contract an address; transactions trigger state changes and consume gas.
• DApps combine front ends and contracts; DAOs add transparent, stakeholder-driven governance.
• Oracles connect off-chain facts to on-chain code but introduce a trust boundary.
• Determinism, resource limits, bad inputs, bugs, formal verification, and legal context limit what smart contracts can safely automate.

Sources