From Bitcoin Script to the Ethereum EVM
Bitcoin proved that programmable money is possible — but its scripting language was intentionally limited. Ethereum asked: what if the blockchain were a general-purpose computer? This module bridges the two worlds.
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?
Part 1 — What You Know
Hash functions, digital signatures, Merkle trees, UTXO model, proof of work, Nakamoto consensus, gossip protocol, forks, Proof of Stake. You can explain how Bitcoin works from private key to global consensus.
Part 2 — What's Next
Programmable blockchains. Smart contracts. The EVM. Solidity. Tokens. DApps. You'll go from understanding blockchains to building on them.
The Question
Bitcoin can transfer value. But can it enforce a rental agreement? Run an auction? Issue a token? No. And that's by design.
Bitcoin Script: Powerful but Limited
Every Bitcoin transaction contains a small program written in Bitcoin Script — a stack-based, Forth-like language. It's not just "send coins"; there's actual code being executed by every node. But Satoshi deliberately kept it simple.
Stack-Based Execution
Bitcoin Script uses a stack — a last-in, first-out data structure. Instructions either push data onto the stack or pop values off and operate on them. There are no variables, no loops, no functions. Just push, pop, and check.
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 and executes them on the stack. If
the final result is TRUE, the transaction is valid. If not, it's rejected.
OP_DUP — Duplicate the
public key on the stackOP_HASH160 — Hash it
(SHA-256 + RIPEMD-160)OP_EQUALVERIFY — Compare
with the expected hashOP_CHECKSIG — Verify the
signature against the public keyWhat Bitcoin Script Cannot Do
No loops — No for, no
while. Every script terminates in bounded time.
No state — Scripts can't read or write persistent data. No memory between transactions.
No complex conditions — Limited branching. You can't implement an auction, a voting system, or a token.
Not Turing-complete — There are programs you simply cannot write in Bitcoin Script. Intentional — security through simplicity.
Why Satoshi Made It This Way
Security. A Turing-complete language on a global consensus network means any bug could halt the entire network or drain funds. Satoshi chose safety over expressiveness. Every Bitcoin Script is guaranteed to terminate — no infinite loops, no gas, no surprises. This design philosophy is the exact opposite of what Ethereum chose to do.
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.
The Key Insight
"I thought [those in the Bitcoin community] weren't approaching the problem in the right way. I thought they were going after individual applications; they were trying to kind of explicitly support each [use case] in a sort of Swiss Army knife protocol." — Vitalik Buterin, 2014. Ethereum's solution: one general-purpose platform with a Turing-complete programming language.
Two Types of Accounts
EOA (Externally Owned Account)
Controlled by a private key. This is your wallet — like a Bitcoin address. It can send transactions and hold ETH. No code attached.
Contract Account
Controlled by code. Has its own address, can hold ETH, and executes logic when called. Once deployed, the code is immutable — it runs exactly as written, forever.
Ethereum = A Global State Machine
Bitcoin is a transaction ledger: it tracks who paid whom. Ethereum is a state machine: it tracks the entire state of every account — balances, contract code, and contract storage. Every transaction transforms the global state from State(N) to State(N+1). The EVM is the engine that computes this transformation.
Account Model vs UTXO Model
| Property | Bitcoin (UTXO) | Ethereum (Account) |
|---|---|---|
| Balance tracking | Sum of unspent outputs | Single balance field per account |
| State | Stateless — UTXOs consumed/created | Stateful — accounts persist between TXs |
| Smart contracts | Very limited (Bitcoin Script) | Full Turing-complete EVM |
| Parallel processing | Easier — UTXOs are independent | Harder — shared global state |
| Privacy | Better — new address per TX | Worse — address reuse common |
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
Deterministic — Given the same input, every node produces the exact same output. No randomness, no system calls. Pure computation.
Isolated (sandboxed) — Contract code cannot access the file system or other contracts' storage directly. Only message calls.
Metered — Every operation costs gas. Prevents infinite loops and DoS attacks. Gas runs out → state reverts.
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:
| Category | Examples |
|---|---|
| Arithmetic | ADD, MUL, SUB, DIV, MOD, EXP |
| Stack operations | PUSH1…PUSH32, POP, DUP1…DUP16, SWAP1…SWAP16 |
| Memory & Storage | MLOAD, MSTORE, SLOAD, SSTORE |
| Control flow | JUMP, JUMPI, STOP, RETURN, REVERT |
| Environment | CALLER, CALLVALUE, GASPRICE, BLOCKHASH |
| Contract interaction | CALL, DELEGATECALL, CREATE, SELFDESTRUCT |
Bytecode Example: 1 + 2
The Solidity expression 1 + 2 compiles to three
opcodes: PUSH1 0x01 (push 1), PUSH1 0x02 (push 2),
ADD (pop both, push 3). That's it — the EVM is fundamentally simple. The
complexity comes from composing thousands of these tiny operations.
EVM vs Bitcoin Script — The Fundamental Difference
Bitcoin Script asks: "Is this transaction valid?" The EVM asks: "What is the new state of the world after this transaction?" Bitcoin Script is a validator. The EVM is a computer.
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.
Why Gas Exists
Without gas, anyone could deploy a contract with an infinite loop and freeze every node in the network. Gas is both a DoS protection mechanism and an economic incentive: validators are compensated for the computational resources they provide.
How Gas Works
EIP-1559: The Fee Market Revolution
Since August 2021, Ethereum uses a base fee + tip model. The base fee is algorithmically adjusted per block and is burned — destroyed forever. The tip goes to the validator. This makes fees more predictable and makes ETH slightly deflationary.
Gas Costs: What's Expensive?
| Operation | Gas cost | Why |
|---|---|---|
| ADD / SUB | 3 | Simple CPU operation |
| MUL / DIV | 5 | Slightly more complex |
| SLOAD (read storage) | 2,100 | Disk access on every node |
| SSTORE (write storage) | 20,000 | Persists on-chain forever — every node stores it |
| CREATE (deploy contract) | 32,000+ | Allocates new on-chain storage |
| Simple ETH transfer | 21,000 | Base TX cost |
Key Insight: Storage Dominates Cost
Writing to storage costs ~7,000× more than addition. This is why Solidity developers obsess over storage optimisation — and why you'll see patterns like packing multiple values into a single 256-bit slot in Module 8.
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
solc)
converts your source code into bytecode and an ABI.to address. The network assigns the contract a new address.
Immutability: The Double-Edged Sword
Once deployed, a contract's code cannot be changed. If there's a bug, you can't patch it. This is both the greatest strength (trustless) and the greatest risk (The DAO hack lost $60M). In Module 8, you'll learn the proxy pattern.
Solidity Preview: Your First Contract
Don't worry about the syntax yet — Module 7 will cover Solidity
in depth. Just notice the structure: a contract keyword (like a class), a state
variable stored on-chain, and a function that modifies it.
// 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 (20,000 gas)
}
function get() external view returns (uint256) {
return storedValue; // reads from storage (free if called off-chain)
}
}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.
1. Sign
The user's wallet creates a transaction object and signs it with the private key — exactly like Bitcoin (Module 2).
2. Broadcast
The signed transaction is broadcast via gossip protocol. It lands in the mempool of each node.
3. Include
A validator selects the transaction from the mempool and includes it in their proposed block.
4. Execute
The EVM runs the transaction: loads bytecode, sets up context, and processes opcodes one by one.
5. Update State
If execution succeeds: balances change, storage updates, events are emitted. If it fails: all changes roll back, but gas is consumed.
6. Receipt & Logs
A transaction receipt is generated with status, gas used, and event logs. DApps listen for events in real-time.
Etherscan: A Window into the EVM
Block explorers like Etherscan let you inspect every transaction, every contract, every event. You can read contract source code, see internal calls, trace gas usage, and decode function parameters. It's the developer's most important debugging tool — and you'll use it daily in Part 2.
Exercise & Self-Check
Exercises
- Script analysis: Write out the stack state at each step when a P2PKH script executes.
- Account model comparison: Alice has 10 ETH and sends 3 ETH to Bob. Compare Ethereum (Account) vs Bitcoin (UTXO).
- Gas calculation: Calculate the gas for 100 ADDs + 5 SLOADs + 2 SSTOREs. Convert to ETH and USD.
- EVM exploration: Find the USDT contract on Etherscan and examine a transfer event.
- Design thinking: Why can't Bitcoin Script implement an on-chain voting system? How does Ethereum make it possible?
Self-Check Questions
- Why is Bitcoin Script not Turing-complete? What advantage does this give?
- What are the two types of Ethereum accounts? How do they differ?
- Name the four data locations in the EVM and explain when each is used.
- Why does writing to storage cost ~7,000× more gas than an ADD operation?
- What happens when a transaction runs out of gas? Is the fee refunded?
Module Summary
You've crossed the bridge from Bitcoin to Ethereum. You understand why Bitcoin Script is limited by design, how Ethereum introduced a Turing-complete virtual machine (the EVM) with persistent state, why gas exists as both DoS protection and economic mechanism, and how smart contracts go from Solidity source to on-chain execution. In Module 7, you'll write your first Solidity smart contracts.