Smart contracts: fundamentals and limits

A concrete case

A cocoa cooperative in Bafoussam wants a register of lots whose rules cannot be secretly modified by a single person: who may register a lot, and a lot number can never be used twice. A smart contract is a program, with its data, stored at an address on a chain with a programmable virtual machine (Ethereum-style chains, for example). Users call it by sending transactions; every node executes the call and must arrive at the same new state.

A clarification up front: the most widespread language for these chains is Solidity, but this course does not teach its syntax. The examples below are in pseudo-code, readable without knowing any language.

contract LotRegistry:
  storage owner                     // set at creation
  storage lots: map lotId -> (holder, weightKg)

  function register(lotId, weightKg):
    require caller == owner         // access control
    require lots[lotId] does not exist
    lots[lotId] = (caller, weightKg)
    emit Registered(lotId)

require means: if the condition is false, the whole call is undone and the state stays as before. caller is the address that signed the transaction (or the contract calling it). You saw in the transactions topic that this signature is checked by the protocol; the contract decides what it allows.

Four properties that define the craft

1. Determinism. All nodes must get the same result from the same state and the same transaction. So a contract cannot draw a "truly random" number, nor call a web page (two nodes would ask at different moments and get different answers). A block timestamp exists, but it is a value set by the block producer within bounds, not a trusted clock.

2. Gas. Each operation costs a number of units of gas, and execution is metered: the sender sets a gas limit and a price per unit, and the fee paid is gas consumed × price (as in the fees workshop). If the limit is reached before the end, execution is undone, but the work performed is still paid for. This keeps infinite loops from blocking the network.

Example with a fictitious schedule: writing a new storage slot costs 20,000 units, reading a slot 200, and each transaction has a base cost of 21,000. The register call reads two slots (owner and the lot's existence) and writes one: 21,000 + 200 + 200 + 20,000 = 41,400 units (in this fictitious schedule the pair (holder, weightKg) fits in a single slot and the emit event is ignored; with two separate writes the total would be 61,400). With a limit of 40,000, the call runs out of gas: everything is undone, and the 40,000 units are paid anyway. With a limit of 45,000 it passes and only the gas actually consumed (41,400) is billed. Real schedules differ; the idea stays.

Design consequence: a function that loops over a list that grows with users eventually exceeds a block's gas limit and becomes unusable. Avoid unbounded loops.

3. Publicity. A contract's state is readable by everyone. A language's "private" keywords only stop other contracts from accessing it simply; anyone reading the storage sees the values. No secret in a contract.

4. Immutability. Once deployed, a contract's code cannot be modified in the current scheme. A bug there is permanent. One can plan a "proxy" contract that redirects to a new version, but then whoever holds the right to switch version holds an enormous power, and your users must trust them. Immutable is an advantage (the rules do not move) and a risk (neither do the errors).

What this does NOT guarantee

• The contract guarantees that its rules are applied, not that the facts are true: if the owner records "500 kg" for a lot that weighs 50, the chain faithfully preserves a lie.
• A contract never runs by itself: a transaction must call it. It cannot "act at midnight".
• Deployed does not mean correct.

Recap: code and state at an address, deterministic result, execution metered in gas, public state, frozen code.

Why specific flaws

Because code is public, immutable and handles value, a defect is found and exploited by strangers, often within hours, with no possible fix afterwards. Three families come up again and again (see also the OWASP Smart Contract Top 10).

1. Broken access control

Every function that modifies state must answer the question: who may call it? A faulty example:

function setOwner(newOwner):
  owner = newOwner          // no check on caller

Anyone becomes the owner. The fix is a single line (require caller == owner), but you must remember to add it. Rule: deny by default, allow explicitly, and test every sensitive function from an unauthorised account.

2. Integer overflow

A contract's integers have a fixed size. Illustration on 8 bits (values 0 to 255):

• 250 + 10 = 260, which does not fit: the result "wraps" to 260 − 256 = 4.
• 3 − 5 = −2, impossible without a sign: the result becomes 256 − 2 = 254.

A balance of 3 that spends 5 and ends at 254 is a catastrophe. In real contracts the integers are much larger (256 bits on Ethereum-style machines), but the principle is the same. In Solidity, since version 0.8, arithmetic cancels the call on overflow by default; before that it wrapped silently, and today the check can be turned off in a block marked unchecked. Overflow therefore remains possible in old code or deliberately unchecked code.

3. Reentrancy

This is the most famous flaw, to be understood as a concept. A contract that sends value to an address that is itself a contract hands over control: the recipient address's code runs before the starting function has finished. If that code calls the same function again, it re-enters it.

A faulty vault in pseudo-code:

function withdraw():
  amount = balances[caller]
  require amount > 0
  send(caller, amount)       // (1) hands control to the caller's code
  balances[caller] = 0       // (2) too late

A worked example. The vault holds 10 coins: 9 belong to other users, 1 to the attacker, whose recorded balance is 1. The attacker calls withdraw.

The attacker received 10 coins for one deposited: 9 coins stolen from others. In reality the number of re-entries is bounded by gas and call depth, but the idea holds. The 2016 incident of The DAO is the most cited example of this pattern.

Two remedies fix the flaw, often combined, and a third habit is useful without fixing it alone:

1. Checks, effects, interactions: update the state before the external call. Here, put balances[caller] = 0 before send (in pseudo-code, if the send fails the whole call is undone; in Solidity, a send by call returns a boolean and you must write require(ok) to get that cancellation).
2. Lock: a flag set to true on entering the function and refused if already true.
3. Pull payment: the contract records what is owed, each party comes to withdraw it, and nothing is ever sent in bulk. It is not a remedy for reentrancy: the faulty vault above is already a pull withdrawal. The pull model mainly keeps a failing recipient from blocking everyone else; the withdrawal function itself must update state before sending (remedy 1) or be locked (remedy 2).

function withdraw():
  amount = balances[caller]
  require amount > 0
  balances[caller] = 0       // effect first
  send(caller, amount)       // interaction after

Reentrancy depends on the virtual machine: some platforms limit it by design. The general principle (an external call can hand control back before your state is consistent) remains a good reflex.

What this does NOT guarantee

• Knowing these three flaws does not make you an auditor: there are many others.
• A passing test does not prove the absence of a flaw; only a test written against the attack demonstrates or refutes it.
• A patch applied in the wrong place can seem to work: for example, limiting the gas given to the caller is not a reliable protection, since costs change from one protocol to another.

Recap: who may call? ; integer size is finite ; state first, external call after.

Who guarantees what?

When something goes wrong, the first question is: is it the contract's matter, the protocol's, or neither's? Confusing them leads to false promises.

Frequent mistaken expectations:

• Expecting a contract to cancel an already finalised transaction: that is a protocol (or governance) decision, not code.
• Expecting it to trigger itself on a date: a transaction is needed (from a human or from a service called a "keeper").
• Expecting it to read another chain or a web page: it has no way to without an intermediary.
• Expecting it to keep a secret: state is public.
• Expecting a fair ordering of transactions: the block producer chooses the order, hence the risk that someone who sees a pending transaction jumps ahead (often grouped under the acronym MEV, for maximal extractable value). This is a property of the protocol and the network.

The oracle problem

A contract sees only the chain. To react to an outside fact (the price of cocoa, the weight read by a scale, the weather), someone must write it onto the chain: that intermediary is an oracle. The problem: the chain checks that the data was written by the right address, not that it is true. The contract is therefore no more reliable than its oracle.

A worked example with three independent reporters of the price of a kilo (fictitious units): 100, 102 and 160. The mean is (100 + 102 + 160) / 3 ≈ 120.67: one faulty or corrupted reporter pulls the result. The median (the middle value once sorted) is 102: an outlier has no influence. With n reporters, the median withstands fewer than half faulty reporters: 1 of 3, 2 of 5. If 2 of the 3 are corrupted, the median is wrong too.

Other mitigations: require several independent sources, bound the changes accepted per hour, introduce a delay before acting, require a stake that the reporter loses on fault. They reduce risk; none removes the trust in the original data.

Applying this to our registry

The lot registry proves that a record was not modified afterwards and that it was made by an authorised address. It does not prove that the bag really holds 500 kg. If a sensor or an agent enters the weight, that is the oracle, and off-chain controls are needed: contradictory weighings, several agents, audit. Honest traceability says: "the chain fixes what was declared, and by whom".

What this does NOT guarantee

• A decentralised oracle is not automatically honest: several reporters can collude or read the same faulty source.
• The price on a very thin market can be manipulated for a few moments; taking it as truth is a classic attack.
• Separating the layers is not an excuse: it is what lets you promise only what you can keep.

Recap: the protocol guarantees the mechanics, the contract guarantees its rules, nobody guarantees outside facts without trusting an oracle.

What the browser does not do, and what you will do elsewhere

This workshop's objectives include writing, testing and deploying a contract on a test network. These three acts require a compiler and a node, which do not run in this page. This lesson gives you the method; the independent lab has you practise with Solidity (official documentation) and Foundry (Foundry Book). Note your tools' versions in the README: they change, and this course fixes none. To make the method concrete, the lesson shows the same registry in Solidity, a Foundry test file and deployment commands. These are outlines written from memory and not run here: check them against the official documentation and the version installed before relying on them.

Write small

A short contract is easier to review, test and audit. Principles: little state, few functions, one rule per function, clear names, events (emit) for every important change so applications can follow them. Reusing proven code beats reinventing, provided you know what you import.

The same registry in Solidity

Here is the lesson 1 pseudo-code translated into Solidity (outline). The correspondences: require becomes require(condition, "message"), caller becomes msg.sender, and the owner is set in the constructor, code that runs exactly once, at deployment.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract LotRegistry {
    address public owner;
    mapping(uint256 => address) public holder;
    mapping(uint256 => uint256) public weightKg;

    event Registered(uint256 indexed lotId, uint256 weight);

    constructor() {
        owner = msg.sender;           // the deploying address becomes the owner
    }

    function register(uint256 lotId, uint256 weight) external {
        require(msg.sender == owner, "not owner");
        require(weight > 0, "weight is zero");
        require(holder[lotId] == address(0), "lot exists");
        holder[lotId] = msg.sender;
        weightKg[lotId] = weight;
        emit Registered(lotId, weight);
    }
}

Two details to remember. First, owner = msg.sender in the constructor means the owner is the account that sends the deployment transaction: using the wrong key at deployment means the wrong owner, permanently. Second, the pseudo-code stored a pair in one slot; here two separate tables make the code simpler to read, at the price of one more write (which changes the gas cost, see lesson 1).

Test first what must fail

A test is a small program that calls your contract and checks the result. For the lot registry, the minimal list:

Add property tests: for example "whatever the calls, a registered lot never changes weight". Fuzzing tools generate many random inputs to look for a violation. For a known flaw (reentrancy), first write a test that plays the attack: it must fail on the faulty code and pass on the fixed code. That is the proof of the fix.

With Foundry, tests are written in Solidity, in a contract that inherits from Test. Outline for the first three rows of the table:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {LotRegistry} from "../src/LotRegistry.sol";

contract LotRegistryTest is Test {
    LotRegistry registry;
    address other = address(0xBEEF);

    function setUp() public {
        registry = new LotRegistry();     // the test deploys, so it is the owner
    }

    function test_OwnerRegisters() public {
        registry.register(7, 500);
        assertEq(registry.weightKg(7), 500);
    }

    function test_NonOwnerReverts() public {
        vm.prank(other);                  // the next call comes from "other"
        vm.expectRevert("not owner");     // we expect this precise cancellation
        registry.register(8, 100);
    }

    function test_DuplicateReverts() public {
        registry.register(7, 500);
        vm.expectRevert("lot exists");
        registry.register(7, 600);
    }
}

vm.prank and vm.expectRevert are Foundry "cheatcodes": the first makes the next call come from another address, the second requires that call to be cancelled with the given message. Tests run with forge test. An access test that checks the refusal is worth as much as the one that checks success.

Deploy on a test network

A test network (testnet) is a chain that imitates the real one, whose tokens have no value and are obtained free from a faucet. On Ethereum-style chains, deploying is a special transaction: with no recipient, carrying the compiled code; the chain then assigns an address to the contract. It costs gas, growing with the code size. The new contract's address appears in the deployment transaction's receipt.

With Foundry, deployment is done with a command along these lines (outline: options change by version, check with forge create --help):

cast wallet import testdeployer --interactive      # stores an encrypted TEST key (keystore)
forge create src/LotRegistry.sol:LotRegistry \
  --rpc-url <TESTNET-RPC-URL> --account testdeployer --broadcast

The encrypted keystore keeps the key out of terminal history and environment variables, which is better than passing it in clear on the command line. For a reproducible deployment you rather write a versioned script (forge script) that does the same job. After deployment, two simple checks: read the contract's owner() and verify it is the intended address; call register from that account.

Habits to adopt:

1. Rehearse the deployment on a testnet before any other network, with a versioned, reproducible script.
2. Use a deployment key reserved for testing, never in the repository (see the Git workshop) nor in the image (see the Docker workshop).
3. Check the constructor parameters (notably the owner address) before sending.
4. Publish the source code on the network's explorer so everyone can compare.
5. For a contract carrying real value: peer review, external audit, admin rights held by a multi-signer mechanism, monitoring, an incident plan.

The limits of assurance

• Tests show the presence of defects, never their absence.
• An audit is sampling done by humans in limited time.
• Formal verification proves properties against a specification; if the specification is wrong, the proof does not protect.
• A pause function or an emergency key can save funds, but it gives its holder a power your users must accept. Decide and say so.

Why the rest of the curriculum goes one layer down

What you have just seen (gas, determinism, immutability, dependence on oracles) explains why some projects choose to build their own chain or protocol module rather than a contract: more control over the rules, at the price of more responsibility. You will meet these choices again in the following workshops.

What this does NOT guarantee

• A successful testnet deployment does not imply it will succeed on the main network: parameters, fees and addresses differ.
• A contract verified on the explorer is readable, not thereby safe.
• The case list above is a minimum, not a guarantee of coverage.

Recap: small, tested against failure, rehearsed on testnet, with a test key, and aware of the limits of assurance.