From Bitcoin Script to the Ethereum EVM

Recap: The Bridge to Part 2

In Part 1, you built a cryptocurrency from scratch — wallets, transactions, blocks, mining, consensus. You understand how blockchains work. But Bitcoin's blockchain can only do one thing: move coins from address A to address B. What if you wanted the blockchain to execute arbitrary logic?

Bitcoin Script: Powerful but Limited

Every Bitcoin transaction output contains a small program — written in a language called Bitcoin Script — that defines the condition under which that output can be spent. Spending is not just "send coins": it is proving you can satisfy the program. Every full node on the network runs the program during validation, and the rules of the network are the rules of this tiny language. Understanding it deeply is the foundation for understanding why Ethereum had to invent something bigger.

What "Stack-Based" Actually Means

The Mental Model: A Puzzle and Its Solution

The Opcode Families

Bitcoin Script has roughly 100 usable opcodes grouped into a handful of families. You rarely need more than a dozen to read real scripts, but knowing the categories gives you the vocabulary to parse any script you encounter on a block explorer.

Worked Example 1: A Trivial Arithmetic Script

Bitcoin's real-world scripts almost never do arithmetic — they do hash checks and signature verification. But arithmetic is the easiest place to see the stack machine in action. Consider this short script (which is not a valid Bitcoin transaction, just a pedagogical program):

OP_2  OP_3  OP_ADD  OP_5  OP_EQUAL

Read it left to right; the stack is shown with the top on the right.

Notice what the script did not do: it did not declare a variable, it did not name a function, it did not jump. It just pushed, popped, and compared. Every Bitcoin Script on the main network — even the most complex — is the same mechanical shape as this one, with different opcodes doing different work on the stack.

Example: Pay-to-Public-Key-Hash (P2PKH)

The most common Bitcoin transaction type. When Alice pays Bob, the transaction contains two scripts:

• Locking script (scriptPubKey) — set by Alice: "Only someone who can prove they own Bob's public key can spend this."
• Unlocking script (scriptSig) — provided by Bob when he spends: "Here's my public key and my signature."

The node concatenates both scripts — scriptSig first, then scriptPubKey — and executes them on a single stack. The locking script is: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. The unlocking script that Bob provides is just: <sig> <pubKey>. If the final result on the stack is TRUE, the transaction is valid.

Worked Example 2: 2-of-3 Multisig

A real-world pattern. Alice wants three co-signers — herself, her partner, and a lawyer — and wants any two of the three to be able to authorise a spend. The locking script for a 2-of-3 multisig output is:

// Locking script (scriptPubKey), set by Alice:
OP_2 <pubKey_Alice> <pubKey_Partner> <pubKey_Lawyer> OP_3 OP_CHECKMULTISIG

// Unlocking script (scriptSig), later provided by any two of them:
OP_0 <sig_1> <sig_2>

What Bitcoin Script Cannot Do

Bitcoin Script Has Not Stood Still

Course material sometimes implies Bitcoin's scripting is frozen in 2009. That is not accurate — it has evolved through a sequence of soft forks, each making scripts smaller, cheaper, or more private without abandoning the stack-based core.

Ethereum's Big Idea: A World Computer

In 2013, Vitalik Buterin — then 19 years old — published the Ethereum whitepaper. His insight was radical: instead of building a new blockchain for every new application, build a single blockchain that can run any program. A world computer.

Two Types of Accounts

Ethereum = A Global State Machine

This phrase is repeated in every Ethereum explainer, but it is rarely unpacked. It is a precise technical claim, and it is the central idea of the protocol — everything else in Part 2 builds on it. Let us take it apart.

What Is the World State?

At any given moment, the Ethereum world state is a single giant dictionary: it maps every 20-byte address that has ever been touched to a small record — the account state — describing that address. There is exactly one world state across the whole network; every honest node agrees on it byte-for-byte. Storing it naively would be impossible (too large to send between peers, too slow to diff), so Ethereum commits to it with a cryptographic data structure we will meet in a moment. First, the shape of the records it contains.

An Account Has Four Fields — Always

Whether you are an EOA or a contract, your account state is exactly these four fields. The EVM treats them uniformly; the only runtime difference between EOAs and contracts is that an EOA's codeHash points at the empty string while a contract's points at real bytecode.

Committing the State: the Merkle Patricia Trie

A world state with potentially hundreds of millions of accounts cannot be sent over the wire, nor re-hashed in full every time a transaction changes one byte. Ethereum solves both problems with a Merkle Patricia Trie (MPT): a combination of a trie (efficient prefix-based key lookup) with the Merkle idea from Module 2 (every internal node hashes its children).

Where the State Root Lives

Every Ethereum block header contains three such roots — this is what ties the state into consensus:

• stateRoot — world state after all transactions in this block have executed.
• transactionsRoot — an MPT over the transactions included in this block.
• receiptsRoot — an MPT over the receipts produced by those transactions (status, gas used, emitted logs).

When a validator proposes a block, every other validator re-executes the transactions from the parent's stateRoot and checks that they reach the same new stateRoot. If the computed root does not match, the block is rejected. This is the mechanism by which tens of thousands of nodes, run by people who do not know each other, stay bit-for-bit synchronised on a continuously-changing database.

The State Transition Function

Where the State Came From: the Genesis Block

Account Model vs UTXO Model

The Nonce: Ethereum's Replay & Ordering Mechanism

Because Ethereum tracks balances by account (not by UTXO), it faces a problem Bitcoin does not: replay and ordering. If Alice signs a "send 1 ETH to Bob" transaction, what stops Bob from re-broadcasting that same signed transaction ten times and draining Alice's account? And if Alice broadcasts three transactions at once, which one runs first?

A Small But Important Detail: Ethereum Uses Keccak-256

The EVM: Ethereum Virtual Machine

The EVM is the runtime that executes smart contract code on every Ethereum node. Think of it as a global, decentralised CPU — except every node runs the same computation and must get the same result.

What Makes the EVM Special

EVM Architecture

Opcodes: The EVM's Instruction Set

Smart contracts are compiled to bytecode — a sequence of low-level instructions called opcodes. The EVM has ~140 opcodes. Here are the key categories:

* SELFDESTRUCT is effectively deprecated. Since the Cancun upgrade (March 2024, EIP-6780), it no longer deletes a contract's code or storage — it only forwards remaining ETH — except when called in the same transaction that created the contract. Any tutorial that teaches "destroy a contract to refund gas" predates Cancun. Treat SELFDESTRUCT as a legacy opcode you may see in audits, not something to reach for.

CALL vs DELEGATECALL vs STATICCALL

When one contract invokes another, it chooses how with one of three opcodes. The difference is about whose state and whose address the called code sees — this distinction is the foundation of proxy patterns (Module 8) and of a whole class of security bugs (Module 13).

Gas: Paying for Computation

If the EVM is Turing-complete, programs can loop forever. This is the halting problem — you can't know in advance if a program will terminate. Ethereum's solution: make the caller pay for every computational step. That payment is called gas.

First: ETH, Gwei, Wei

Before we can talk about fees, you need the three units Ethereum uses everywhere. ETH is the human-facing unit; Gwei is the unit gas prices are quoted in; Wei is the atomic integer unit the EVM actually works with (there are no floats anywhere in the EVM).

How Gas Works

Gas Costs: What's Expensive?

Smart Contracts: Code on the Blockchain

A smart contract is just a program that lives at an Ethereum address. It has code (immutable) and storage (mutable). When someone sends a transaction to the contract's address, the EVM executes the code.

The Smart Contract Lifecycle

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

contract SimpleStorage {
    uint256 public storedValue;      // state variable (on-chain)

    function set(uint256 _value) external {
        storedValue = _value;         // writes to storage
    }

    function get() external view returns (uint256) {
        return storedValue;           // reads from storage (free if called off-chain)
    }
}

The ABI: How the Outside World Talks to a Contract

Step 2 of the lifecycle mentions that the compiler produces an ABI alongside the bytecode. Bytecode is what the EVM runs; the ABI (Application Binary Interface) is what callers need. It is a JSON description of every public and external function, every event, and every argument type — the contract's public API in machine-readable form. A wallet, a frontend, or another contract uses the ABI to know how to encode a call and decode the response.

0x60fe47b1 // selector = keccak256("set(uint256)")[0:4]
000000000000000000000000000000000000000000000000000000000000002a // 42, padded to 32 bytes

Events and Logs: The Contract's Notification Channel

Smart contracts cannot push data to users — they cannot open a socket or call an API. Instead they emit events, and off-chain code listens. An emit Transfer(from, to, amount) statement writes a log into that transaction's receipt. Logs live in a special low-cost area of the chain: nodes keep them, clients can query them, but smart contracts cannot read them back. They are the blockchain's equivalent of a server-sent event stream.

Putting It All Together: Transaction Lifecycle

Let's trace a complete Ethereum transaction from the moment a user clicks "Send" in their wallet to the final state update on-chain. Before we walk the steps, it helps to know what a transaction actually is — the bytes your wallet signs.

Anatomy of an Ethereum Transaction

A modern (EIP-1559 / type-2) Ethereum transaction is a handful of fields the sender fills in, plus a signature.

Exercise & Self-Check