What is the EVM?

The Ethereum Virtual Machine (EVM) is a set of shared rules for executing smart contracts. Ethereum nodes implement those rules in their own software, computing over the same transactions and starting state, and so arrive at a result other nodes can recheck.

The EVM is not one physical server, nor the single application a developer sees on their computer. It is more like a precise set of computing instructions: which basic operations code may perform, where data goes, how much computing resource each operation consumes, and how blockchain state is updated when execution succeeds or fails.

From source code to executable bytecode

Developers usually write contracts in a high-level language such as Solidity. Human-readable source code has to be converted by a compiler into bytecode the EVM can execute — a string of machine instructions arranged in a fixed format.

When a contract is deployed, the creating transaction contains the code used to generate it. After successful execution, the network establishes an address for the contract and stores the bytecode to run when it later receives calls. A contract's deployed runtime code is not the same representation as a developer's source files, so published source code still has to be checked against the onchain bytecode before you can say the two correspond.

Compiler version and settings can affect the final bytecode. Two source files that look similar may produce different results; seeing the same contract name is even less of a substitute for checking the network and the contract address.

A call provides a contract's execution input

When a user calls a contract, they send a transaction carrying data to the contract address. That data usually indicates which function to call and attaches parameters in an agreed format. A contract can also call another contract during execution, passing values or data onward.

The EVM starts from the current blockchain state, reads the caller, the target, any attached value, the input data and the information the current block permits it to use, then executes the target contract's bytecode instruction by instruction. Each instruction changes the temporary data within this computation under the rules, or requests a read from or write to the contract's persistent state.

A contract does not start itself just because a certain time has arrived. There must be a transaction or another contract call forming an execution entry point; "automatic execution" on a web page usually still requires some external service to submit a transaction once conditions are met.

Opcodes are the basic actions within bytecode

EVM bytecode consists of individual opcodes. An opcode can be understood as the smallest action the virtual machine recognizes — for example doing arithmetic, comparing values, reading call data, reading from or writing to storage, and calling other contracts.

Different opcodes have defined inputs, outputs and gas consumption rules. A node does not need to understand a contract's business-level names; executing in opcode order is enough to check whether the result another node produced complies with the protocol.

One line in a high-level language may compile into several opcodes. Conversely, looking at a single opcode cannot convey complete business intent, so reviewing a contract usually also means combining source code, compilation settings, call data and the actual deployment address.

Temporary data and persistent state

Not all data used during execution is permanently written to the blockchain. It helps to first distinguish three locations:

• call data is the read-only input brought in by this call;
• memory is a temporary workspace used during this execution and is not retained once it ends;
• storage belongs to a specific contract and, once successfully written, becomes part of blockchain state for later calls to read.

The EVM also uses a last-in-first-out temporary computing structure called the stack. Opcodes take values from the top of the stack and put results back after computing. An ordinary reader does not have to track each step by hand, but does need to know that "a change in memory" and "contract storage has changed" are not the same thing.

Writing to persistent storage usually consumes more gas than doing only temporary computation. Deleting or changing storage is also bound by protocol rules; onchain state is not a local file an ordinary program may overwrite at will.

State changes have to be recomputable

Transactions in the same block have a determined order. Starting from the same pre-block state and executing the same transactions in order, nodes should arrive at the same post-block state; otherwise they cannot agree on a shared ledger.

An EVM contract therefore cannot, during execution, directly reach arbitrary web pages, device time or a random result from some server. When an offchain price, weather reading or other information is needed, an external participant must first bring that data onchain in the form of a transaction. The EVM can check how code uses that input, but it cannot automatically prove that the offchain fact the input represents is true.

Information a block provides, such as time and block number, also comes from the execution environment the protocol defines. Developers may read these under the rules, but should not mistake the values for a precise external clock or a secret source of randomness unaffected by the block proposal process.

Gas limits the work in each execution

Every EVM operation consumes a certain amount of gas. Gas is a unit of measurement for computing and storage work, not a separate token; on Ethereum mainnet, actual execution fees are usually paid in the network's native asset, ETH.

A transaction's sender sets the maximum gas this transaction may consume. During execution, the EVM accumulates gas according to the operations actually run; if the remaining gas is insufficient to complete the next step, execution fails by running out of gas.

Gas prevents infinite loops or unusually complex calls from occupying every node's computing resources at no cost. It also means the same function may consume different amounts depending on input, current state and execution path. A transaction with a large value does not necessarily execute more code than one with a small value.

Success, revert and failure

A contract can end normally and return data, can revert deliberately, or can fail because of an invalid operation, running out of gas or another cause. On failure, state modifications not yet committed along this call path are undone under the rules, but the computing resources the transaction has already consumed may still incur a fee.

One transaction can trigger several layers of contract calls. If an inner call fails, the outer contract may, according to its code, choose to carry on handling the returned result, or may cause the whole transaction to revert. "Some internal step failed" and "the whole transaction ultimately failed" therefore have to be judged together with the call results.

A state revert also does not undo the fact that a transaction was included in a block. A block explorer can display a failed transaction and the gas consumed; it is only the expected contract state modifications that did not take effect.

Reading results and submitting transactions

A wallet or application can have a node simulate a read-only request locally and return the result immediately. Such a read does not reach new consensus across the whole network and does not modify onchain state, so it usually does not require the user to sign and pay an onchain fee.

An operation that needs to change state must instead form a transaction, be signed by an account and broadcast, and be executed jointly by nodes once it enters a block. Simulating before submission can help spot obvious failures, but the final result may still be affected by transaction ordering, state changes, gas settings and the network selected.

An application interface showing "expected to succeed" therefore does not mean a transaction has been confirmed. The real onchain outcome requires checking the transaction's status, execution result and contract state on the correct network.

The EVM and Ethereum are not the same concept

The EVM describes only part of the rules for smart contract execution and state transition. Ethereum also includes account and transaction formats, block propagation, proof of stake consensus, network communication and other protocol components.

Other blockchains can also implement the EVM, or an execution environment highly similar to it, in order to reuse contract tooling and bytecode. They are usually called EVM-compatible networks, but they still have their own block history, validation arrangements, fee asset and security boundary.

So "able to run EVM contracts" does not mean something is Ethereum, and it does not guarantee that the same address has the same code deployed on different networks. When using an application across networks, you still have to check the network and its network number, the contract address and the actual bytecode.

Shared execution does not mean a contract is safe

The EVM's deterministic rules let nodes recheck whether a contract executed according to its code, but they cannot judge whether that code matches the business outcome a user actually wanted. Mistaken permissions, an external contract calling back repeatedly before a previous operation has finished, problems with price inputs, upgrade control or a misleading interface can each make a transaction that fully complies with EVM rules produce an unintended consequence.

Successful compilation, successful onchain execution or published source code likewise cannot each substitute for a security review. Judging a specific contract requires combining the deployed bytecode, the initialization state, administrative permissions, external dependencies and the real call path.

FAQ

Is the EVM a cloud server?

No. It is a set of execution rules implemented jointly by node software, and does not correspond to any one fixed machine.

Does the EVM execute Solidity code directly?

Usually not. Solidity source code is first converted by a compiler into EVM bytecode, and what nodes execute is the deployed bytecode.

Does reading a contract always require paying a gas fee?

A local read-only request usually does not form an onchain transaction, so it does not directly incur an onchain fee. If a read is part of the execution of another onchain transaction, the related operations still count towards that transaction's gas.

Can the EVM read internet data directly?

No. External data has to be brought onchain by some participant or service through a transaction; the EVM can only process input already provided, under the rules.

Does EVM compatibility mean a contract can migrate without modification?

Not guaranteed. The degree of compatibility, protocol version, available opcodes, fee rules, system contracts and external dependencies may all differ, so verification and testing on the target network are still needed.

Related concepts

Continue with Ethereum, smart contract, gas fee and blockchain, or return to the Crypto Glossary.

Sources

• Ethereum.org: Ethereum Virtual Machine — the EVM, state transitions, the execution environment, the stack, memory and storage.
• Ethereum.org: smart contract anatomy — source code, compilation, deployed code and the structure of contract calls.
• Ethereum.org: EVM opcodes — opcodes, parameters and gas rules.
• Ethereum.org: gas and fees — gas measurement, gas limits, execution fees and the result of running out of gas.