Most descriptions of smart contracts stop at the analogy: "code that runs automatically when conditions are met." That's technically true but tells you nothing about the mechanism. A vending machine also runs automatically when conditions are met — understanding why smart contracts matter requires understanding what actually happens between "transaction sent" and "state updated."
The mechanism is specific, consequential, and worth getting right.
What a Smart Contract Actually Is
A smart contract isn't a program in the traditional sense. It's bytecode — a sequence of low-level instructions — stored permanently at an address on the blockchain.
The source code (usually written in Solidity or Vyper) is compiled down to EVM bytecode before deployment. Once deployed, the original source code is irrelevant to execution. The network only knows the bytecode. Explorers like Etherscan can display verified source if developers choose to submit it, but that's optional and doesn't affect how the contract runs.
That bytecode lives at a contract address, just like a wallet lives at a wallet address. The difference: send a transaction to a wallet address and the network records a value transfer. Send a transaction to a contract address and the network runs the bytecode.
The EVM as the Execution Environment
Ethereum's Ethereum Virtual Machine (EVM) is the runtime environment that executes smart contract bytecode. Every full node in the Ethereum network runs a local copy. When a transaction triggers a contract, every node runs the same bytecode with the same inputs — and every honest node produces the same output.
That replication is the core property that makes smart contracts trustless. Execution isn't delegated to a single server. It happens simultaneously across thousands of independent nodes.
The EVM is a stack-based machine. Operations push and pop values from a stack rather than working with named registers. Each instruction is called an opcode, and each opcode has a fixed gas cost. ADD costs 3 gas. Loading a value from cold storage (SLOAD) costs 2,100 gas. Deploying new contract code (CREATE) costs 32,000 base plus 200 gas per byte of bytecode.
Gas is how the network meters computation. Without it, a contract with an infinite loop would freeze every node running it. Gas creates a hard ceiling: when execution exhausts the allocated gas, it halts and reverts. Every operation has to be paid for.
Walking Through an Execution
Take a specific example: a user calls a swap() function on a DEX contract.
They construct a transaction containing:
- To: the contract address
- Data: the encoded function call — a function selector plus any arguments
- Gas limit: the maximum gas they're willing to pay
- Value: any ETH being sent alongside the call
The function selector is the first four bytes of the keccak-256 hash of the function signature. transfer(address,uint256) hashes to a specific 4-byte prefix. The EVM uses this to route the call to the correct function in the contract's bytecode. This lookup is deterministic — same function signature, same selector, always.
Once the transaction lands in a block, every node:
- Initializes a fresh execution context — empty stack, temporary memory
- Routes control to the contract bytecode at the function's entry point
- Runs each opcode in sequence, consuming gas
- Reads and writes the contract's persistent storage — a key-value mapping per address
- Can call other contracts, passing along gas for sub-execution
- Either completes and commits all state changes, or reverts and discards them entirely
That last point is the binding constraint: execution is atomic. Either the entire call succeeds and every state change is written, or it fails and nothing changes. There's no partial execution. If a transaction reverts — say a required condition isn't met — the state rolls back completely. The user still pays gas for computation that already ran, but no persistent change occurs.
Cross-Contract Calls and Reentrancy
Smart contracts can call other contracts mid-execution. Contract A can invoke Contract B, pass it gas, and wait for a result. This composability is what makes DeFi protocols stack on top of one another.
It's also where one of the most well-known vulnerability classes lives.
When Contract A calls Contract B, A's execution pauses while B runs. If B is malicious — or simply designed to call back into A — it can trigger A's functions again before A has finished updating its own state. This is reentrancy.
The pattern: Contract A's withdrawal function sends ETH to Contract B's address. B's fallback function immediately calls A's withdrawal function again. A checks the user's balance and — because B triggered the callback before A updated its records — still sees funds available. The cycle repeats until gas runs out or A is drained.
This is how $60 million was extracted from The DAO in 2016. Not a bug in the EVM. A bug in the contract's logic: it sent funds before updating balances.
The standard defense is the checks-effects-interactions pattern: validate all preconditions, update all internal state, and only then interact with external contracts. The EVM gives you no protection against logic errors. It executes exactly what the bytecode says.
What the EVM Can't Read
A smart contract's execution is isolated to on-chain data unless it explicitly receives external input.
During execution, a contract can read: its own persistent storage, the current block's metadata (number, timestamp, base fee), balances and bytecode at other addresses, and the calldata it was sent.
It cannot read: external APIs, real-world prices, off-chain databases, or anything that exists outside the blockchain's current state.
This is why oracles exist as a separate category of infrastructure. Chainlink, Pyth, and similar protocols push external data on-chain as signed transactions — the contract then reads that on-chain data during execution. The oracle is the bridge. The EVM just reads whatever data is in storage at the time of the call.
What's Changing
The EVM's core execution model has been stable for several years, but active development is worth tracking.
EVM Object Format (EOF) is the most significant pending change. It restructures how bytecode is organized — separating code from data, adding deploy-time validation, and enabling safer static analysis. It's been delayed through multiple forks but remains on the Ethereum roadmap, currently targeting Pectra and beyond.
Account abstraction (ERC-4337) doesn't change the EVM's execution semantics but changes what can initiate execution — allowing smart contract wallets to define their own validation logic, pay gas in ERC-20 tokens, and batch operations. The execution environment inside the EVM is unchanged; what changed is the transaction entry point.
On competing architectures: Solana uses a different model entirely (BPF-based programs with Sealevel parallel execution), and zkEVMs prove EVM execution validity with zero-knowledge proofs rather than re-running it on every node. The EVM remains the dominant execution environment by total value locked. It's not the only viable approach, but it's the most battle-tested.
Confirmation and Invalidation
Confirmation signals: Continued growth in contract deployments across EVM-compatible chains. EOF shipping without fragmenting tooling. zkEVM proving times compressing further, increasing L2 throughput without altering execution semantics.
Invalidation signals: A critical vulnerability in the EVM specification itself — distinct from contract-level bugs, which are routine — that forces a breaking change to execution semantics. Or a fundamentally different execution model gaining sufficient security validation and developer adoption to displace EVM compatibility as the primary smart contract standard.
Timing
Now: The EVM is live at scale. Every smart contract on Ethereum, Polygon, Arbitrum, Base, and hundreds of other chains runs inside it. Understanding the execution model is foundational to understanding how any of these systems behave.
Next (2025-2026): EOF, if it ships, changes how contracts are structured and validated. Meaningful for developers, largely invisible to users.
Later: Whether zkEVMs replace re-execution as the primary node model is genuinely open. The economic argument is compelling; the security validation timeline isn't.
This explanation covers the execution mechanism. Smart contract security practices, gas optimization, and the economics of deploying contracts are separate topics that build on this foundation.
The EVM executes exactly what you deploy. Whether what you deploy does what you intend is the harder question.
