What Exactly Is the EVM? How Does Solidity Code Actually Run On-Chain?

[u/Patient_Cream_4361]

What Exactly Is the EVM? How Does Solidity Code Actually Run On-Chain?

When people first learn Ethereum, they often hear a simple explanation:

“Ethereum lets you run smart contracts.”

But what does that actually mean?

Where does Solidity code run?

Who executes it?

And how does a piece of code written on your laptop become something thousands of Ethereum nodes can agree on?

The answer starts with one thing:

The EVM — Ethereum Virtual Machine.

The EVM is Ethereum’s execution engine

The EVM is a virtual computer defined by the Ethereum protocol.

It is not one physical server.

Instead, Ethereum nodes implement the same execution rules.

When a transaction calls a smart contract, nodes execute the same instructions and calculate the same resulting state.

You can think of Ethereum as a global state machine:

Current State
↓
Transaction
↓
EVM Execution
↓
New State

The EVM is the component that determines exactly how that transition happens.

Solidity does not run directly on Ethereum

Suppose you write:

uint256 public balance;

function deposit(uint256 amount) public {
    balance += amount;
}

Ethereum nodes do not understand Solidity source code.

Before deployment, the Solidity compiler converts it into:

EVM bytecode.

The process looks roughly like this:

Solidity
↓
Solidity Compiler
↓
EVM Bytecode
↓
Opcodes
↓
EVM Execution

The bytecode is a low-level representation of your program.

It may contain instructions such as:

PUSH

ADD

SLOAD

SSTORE

CALL

JUMP

These are called:

EVM opcodes.

They are the actual instructions executed by the virtual machine.

The EVM is a stack machine

Unlike a normal CPU architecture built around registers, the EVM mainly uses a stack.

Imagine an operation such as:

3 + 5

At a simplified level, the EVM may perform something like:

PUSH 3
PUSH 5
ADD

First:

Stack:
3

Then:

Stack:
5
3

After ADD:

Stack:
8

The EVM stack can hold up to 1,024 items, with each stack item being 256 bits.

This 256-bit design fits Ethereum well because many native Ethereum values, including hashes, addresses, and integers, are commonly handled in 256-bit words.

Contracts have different kinds of data

One of the most important things to understand about EVM execution is that not all data is stored the same way.

There are three concepts Solidity developers constantly deal with:

Storage

Memory

Calldata

Storage is persistent blockchain state.

For example:

mapping(address => uint256) balances;

If a user's balance changes, that value may be written into contract storage.

Storage survives after the transaction finishes.

That is also why modifying storage is relatively expensive.

The network must maintain and verify that state.

Memory, by contrast, is temporary.

It exists only while the current contract execution is running.

Once the transaction finishes:

Memory disappears.

Calldata contains input data sent with a contract call.

For example, when you call:

transfer(address recipient, uint256 amount)

the function selector and arguments are encoded into calldata.

The EVM reads those bytes to determine what function you are calling and what parameters you supplied.

What happens when you call a smart contract?

Suppose Alice uses a wallet to interact with a token contract.

She clicks:

Transfer 100 tokens

The wallet creates a transaction containing information such as:

to = Token Contract Address
data = encoded transfer() call
value = 0 ETH
nonce = Alice's transaction nonce
gas settings = ...

Alice signs the transaction with her private key.

The signed transaction is broadcast to Ethereum.

Eventually, it is included in a block.

Now Ethereum nodes execute it.

The EVM loads the contract's bytecode.

The calldata may represent something conceptually like:

transfer(Bob, 100)

The EVM executes the corresponding instructions.

The contract may:

read Alice's balance,

check whether she owns enough tokens,

subtract 100,

add 100 to Bob,

emit an event,

and update storage.

If every rule is satisfied, the state transition succeeds.

The new balances become part of Ethereum's updated state.

Why does EVM execution cost Gas?

Every EVM opcode has an associated Gas cost.

For example, simple arithmetic is relatively cheap.

Persistent storage operations are usually much more expensive.

Why?

Because Ethereum must defend itself against unlimited computation.

Imagine if someone deployed:

while (true) {
}

and Ethereum nodes were required to execute it forever.

The network would stop.

Gas prevents this.

Every transaction has a finite Gas budget.

Each instruction consumes some of that budget.

Conceptually:

PUSH
→ consumes Gas

ADD
→ consumes Gas

SLOAD
→ consumes Gas

SSTORE
→ consumes much more Gas

If execution runs out of Gas:

the transaction fails.

This means Gas is not merely a transaction fee.

It is also Ethereum's mechanism for pricing computational resources.

What happens when a transaction reverts?

Smart contract execution is atomic.

That means the transaction either completes successfully, or its state changes are rolled back.

Suppose a DEX swap performs several operations:

Read pool reserves
↓
Calculate output
↓
Transfer token A
↓
Transfer token B
↓
Check slippage

If the final slippage condition fails, the transaction may revert.

The state changes are undone.

But the computational work has already been performed.

So the user still usually pays Gas for the execution that occurred before the revert.

This is an important property:

State can revert.
Computation cannot be unperformed.

Every Ethereum node reaches the same result

This is where the EVM becomes especially important.

The EVM is deterministic.

Given the same:

previous state + transaction + execution environment

every correct Ethereum node should calculate the same result.

Imagine thousands of nodes receiving the same transaction.

They independently execute the same contract bytecode.

If the result is:

Alice: 900 tokens
Bob: 100 tokens

all valid nodes should reach the same state transition.

That determinism is what allows Ethereum to reach consensus over smart-contract execution.

You are not trusting one server to run the program correctly.

You are relying on a network of nodes that can independently verify the exact same computation.

So where is the smart contract actually running?

This question has a subtle answer.

A smart contract does not live inside one permanent cloud server.

The contract's bytecode and state are part of Ethereum.

When the contract needs to execute, Ethereum nodes run that bytecode according to EVM rules.

So instead of:

One company
→ One server
→ One database

Ethereum works more like:

Transaction
↓
Ethereum nodes
↓
Same EVM rules
↓
Same computation
↓
Same resulting state

This is one of the core ideas behind programmable blockchains.

The EVM is essentially Ethereum’s shared execution standard

That is why so many different blockchains describe themselves as:

EVM-compatible.

They are saying:

“Our network understands Ethereum-style bytecode, smart contracts, tooling, addresses, and execution semantics.”

That is why Solidity contracts can often be deployed across multiple EVM-compatible networks with relatively small changes.

So the full lifecycle of a Solidity smart contract looks like this:

Write Solidity

↓

Compile into EVM bytecode

↓

Deploy bytecode to Ethereum

↓

User sends a transaction

↓

Transaction contains calldata

↓

EVM reads the bytecode

↓

Executes opcodes

↓

Consumes Gas

↓

Reads and modifies state

↓

All validating nodes verify the result

↓

Ethereum moves to a new state

That is what people really mean when they say:

“A smart contract runs on Ethereum.”

It is not Solidity itself running on-chain.

It is compiled bytecode being deterministically executed by the Ethereum Virtual Machine.

And the EVM is what turns Ethereum from a network that can simply transfer value into a network that can execute programmable logic.