Smart contracts

In brief

Nick Szabo used “smart contract” in the mid-1990s for computerized protocols that carry out contractual terms. On today’s blockchains the phrase usually means deployed program code plus the data it stores, executed deterministically when a transaction or another program calls it. Ethereum-style contracts are accounts with bytecode. Solana programs are executable accounts whose mutable state lives in separate data accounts. Bitcoin Script is a limited, non-Turing-complete language for spending conditions, not a general application platform. Code is not automatically legally binding. A deployed program does not run continuously. What it can do, who can change it, and what happens when it is wrong all depend on the specific chain and on how the program was written.

The term is older than Ethereum

In a 1994 note, Nick Szabo defined a smart contract as “a computerized transaction protocol that executes the terms of a contract.” The design goals he listed were ordinary contractual ones: payment terms, liens, confidentiality, enforcement, fewer accidental or malicious exceptions, and less need for trusted intermediaries.

In 1996 he expanded the idea. A smart contract, he wrote, is “a set of promises, specified in digital form, including protocols within which the parties perform on these promises.” The word “smart” meant more functional than paper, not artificial intelligence. His stock example is the vending machine: within a limited potential loss, it takes coins and dispenses product by mechanism rather than by a clerk’s judgment. He also described “smart property” — embedding those protocols in objects, such as a car that will not start without the right cryptographic handshake, or a loan that can transfer control of the keys if payments stop.

That writing is about embedding contractual performance in hardware, software and cryptography. It is not a specification of the Ethereum Virtual Machine, and it does not claim that running code in public is the same thing as winning a lawsuit.

Ethereum later reused the phrase for on-chain programs. ethereum.org’s introduction still points back to Szabo’s 1994 and 1996 texts. The historical term and the blockchain implementation overlap; they are not identical.

What a blockchain smart contract actually is

On Ethereum, official developer documentation defines a smart contract as a program that runs on the Ethereum blockchain: a collection of code (functions) and data (state) at a specific address. It is a type of account. It can hold a balance and be the target of transactions. It is not controlled by a user’s private key in the way an ordinary key-controlled account is. Users interact by submitting transactions that execute a function. Interactions are generally irreversible, and the bytecode is not deleted by default.

That is a useful picture for Ethereum. It is not the only picture.

• Ethereum / EVM. The contract account stores code and persistent storage. A transaction from a key-controlled account, or a call from another contract, starts execution. Every full node re-executes the same bytecode so that applying the block produces the same new state. The original Ethereum whitepaper compared contracts to autonomous agents that act when poked.
• Solana. A program is an account that holds executable sBPF bytecode and has its executable flag set. Official Solana documentation is explicit: programs are stateless. Mutable state lives in separate data accounts passed in by instructions. The program can be upgradeable if it was deployed with an upgrade authority; revoking that authority makes it immutable. This is not “an ERC-20-style contract that keeps its own balances in a mapping.”
• Bitcoin. Bitcoin Script is a Forth-like stack language used to express spending conditions on transaction outputs. Bitcoin’s developer documentation describes it as deliberately stateless and not Turing complete. There are no loops. The usual job is to check signatures and hashes so that an output can be spent. Pay-to-script-hash and later output types allow more elaborate conditions, including multisignature spends. That is programmable authorization, not a general-purpose application server.

Other systems sit somewhere in between: constrained scripting, native assets with ledger-level rules, or virtual machines that are neither the EVM nor sBPF. Calling every on-chain program a “smart contract” is common speech. For this article, the precise object is the program-plus-state model of the chain in question.

Deterministic execution, not a background process

A blockchain program is not a server that keeps running. It sits in storage until something invokes it.

On Ethereum, that something is a transaction or an internal message from another contract. The Ethereum Virtual Machine steps through opcodes. Operations cost gas. If the call runs out of gas or hits an error, its state changes revert; the fee for work already attempted is still paid. Given the same starting state and the same inputs, every honest node must compute the same result. That determinism is why the network can agree.

The same “idle until called” rule applies on Solana. A transaction lists accounts and instructions. The runtime loads those accounts and invokes the named program. Parallel execution is possible when transactions do not write the same accounts, which is a runtime property, not a claim that programs loop in the background.

Deterministic execution is also why contracts cannot freely fetch the weather, a stock price, or the result of a football match. Those facts are not already in the chain’s state. If two nodes asked the open internet, they might see different answers and disagree. That limitation is by design on Ethereum and on similar systems.

Deployment, state and calls

Deploying an Ethereum contract is itself a transaction. It costs gas because the bytecode occupies storage. After deployment, the contract has an address. Users and other contracts call functions. Persistent storage survives from call to call; memory used during a call does not.

On Solana, deploying a program stores executable bytecode in a program account. Application data is created as separate accounts owned by that program. Only the owner program may change an account’s data or debit its lamports. Addresses can be ordinary Ed25519 public keys or program-derived addresses (PDAs) that have no private key.

Permissions are whatever the program encodes. An Ethereum contract can restrict a function to msg.sender == owner. It can require several signatures (a multisig). It can have no special owner at all. Solana programs similarly check account owners, signers and PDA seeds. Nothing in the word “smart contract” implies that the code is ownerless.

Upgradeability

“Immutable” is a property of a particular deployment, not of the idea.

Ethereum bytecode at a given address is not casually edited. Many applications nevertheless change behavior by keeping state and a stable address in a proxy that delegates calls to replaceable logic. Separately, a protocol-level hard fork can exceptionally alter chain state, as Ethereum’s 2016 response to The DAO did; that was a community and protocol decision, not an upgrade function built into the application. Solana’s upgradeable loader lets an upgrade authority replace program bytecode until that authority is revoked.

An upgrade path is a feature and a risk. Users who thought they were interacting with frozen rules may later be interacting with different rules. Admin keys, multisigs and timelocks are design choices, not decorations.

Composability

On a shared virtual machine, one program can call another in the same transaction. Ethereum documentation describes public contracts as resembling open APIs: a lending market can read an oracle, a vault can deposit into a market, and a new contract can deploy further contracts.

That composability is powerful and brittle. A bug or an unexpected assumption in one program can become a bug in everything that calls it. At the top level, an uncaught failure reverts the transaction’s state changes; contracts can deliberately catch some failed subcalls and continue. “Flash” operations enforce repayment before the overall transaction completes or else revert — they are not magic, but a same-transaction constraint encoded by the contracts involved.

Solana composition is cross-program invocation: one program calls another and, if needed, signs for a PDA it derived. Bitcoin composition is much narrower. Scripts do not call other scripts as general APIs.

Common uses

Uses follow from “code plus state, run when called”:

• token ledgers and authorization (on Ethereum, interfaces such as ERC-20; on Solana, mint and token accounts under a Token Program);
• non-custodial trading and automated market makers;
• lending, borrowing and collateral accounting;
• treasuries, multisigs and on-chain governance hooks;
• registries: names, unique token identifiers, attestations;
• escrows and time locks.

A use case is not a guarantee. A lending contract still depends on its collateral rules, its oracle, its admin powers and the absence of a fatal bug.

Not a legal contract

Szabo’s original project was to make some contractual performance cheaper to observe, verify and enforce. Blockchain programs automate state transitions. They do not, by themselves, create a meeting of minds, assign legal capacity, or bind a court.

A person can owe money under law and have no on-chain program. A program can move tokens without necessarily forming a valid sale. Whether code creates, records or merely performs a legally binding agreement depends on the governing law and the facts. The Law Commission of England and Wales, for example, distinguishes an ordinary smart-contract program from a smart legal contract, in which some or all legally binding obligations are defined in or performed by code.

“Code is law” is a slogan. In practice, code is what the virtual machine will do, and law is what institutions will enforce. They can coincide, conflict, or ignore each other.

Oracles: reaching off-chain facts

ethereum.org’s contract documentation states the limitation plainly: smart contracts alone cannot retrieve data from off-chain sources. The usual workaround is an oracle — a mechanism that posts external data on-chain so that later calls can read it.

An oracle reintroduces trust along a new axis. The contract will deterministically consume whatever the oracle wrote. If the feed is late, wrong, thinly traded, or captured, the contract will be faithfully wrong. Designs differ: a single operator, a committee, a median of several publishers, or a delayed time-weighted price from a pool. None of those is “the contract looked out the window.”

Bugs and irreversible consequences

Because honest nodes replay the same code, they will all honor a mistake.

In June 2016, Vitalik Buterin posted on the Ethereum Foundation blog that an attacker was draining The DAO by a recursive-calling vulnerability in that application’s split function. The post treated Ethereum itself as uncompromised and The DAO as a specific contract with a specific bug. The later hard fork moved the affected funds to a withdrawal contract so holders could recover them; that was a social and protocol decision, not a feature of the original program. The episode is a warning about reentrancy, about putting very large value in unaudited code, and about the difference between “the virtual machine did what the bytecode said” and “the community accepted the result.”

Failed calls can still cost fees. Successful calls that do the wrong thing generally cannot be undone by asking the chain nicely. Pause switches, upgrade keys and legal recovery processes exist in some systems precisely because immutability is a double-edged property.

Ethereum mainnet directly enforces EIP-170’s deployed runtime-code limit: MAX_CODE_SIZE is 0x6000, or 24,576 bytes (24 KiB). If contract creation returns more code than that, creation fails with an out-of-gas error. This is a runtime-code limit, distinct from later rules for creation/initcode. Splitting logic or using proxies can work around the design constraint, but adds complexity and trust considerations.

Different chains, different models

Do not generalize one architecture.

| System | What “the program” is | Where state lives | How it is invoked | | --- | --- | --- | --- | | Ethereum | Contract account with EVM bytecode | In the contract’s storage (and transient storage during a call) | Transaction or internal call | | Solana | Executable program account (sBPF) | Separate data accounts owned by the program | Transaction instructions listing accounts | | Bitcoin | Script attached to an output | No persistent contract storage; UTXOs are created and spent | A later input that satisfies the locking script |

Tokens follow the same split. An Ethereum ERC-20 is usually its own contract. A Solana token is a mint account plus token accounts under a shared Token Program. Bitcoin has no ERC-20 equivalent as a native standard.

Wallets are not the program. An address is not the program. A website that talks to the program is not the program. Connecting a wallet is not, by itself, authorization to move funds; authorization is whatever signature, session key or account rule the chain and the program require.

What this article is not saying

A deployed program does not run continuously. Code is not automatically legally binding. “Smart contract” is not a synonym for “trustless,” “decentralized,” or “cannot be changed.” Those are claims about a particular deployment, its permissions, its dependencies and the chain it lives on.