The Ethereum Virtual Machine (EVM) is the heart of the Ethereum blockchain, responsible for executing smart contracts and processing transactions. The EVM has some fascinating and lesser-known features that make it unique and interesting. In this article, we’ll explore 7 facts you didn’t know about the EVM - Interesting history lesson at No. 7.

In the context of the Ethereum Virtual Machine (EVM), determinism refers to the idea that every time the same transaction is executed, it will produce the same result, as long as the state of the blockchain is the same. This is a crucial feature of the EVM because it ensures consistency and reliability across all Ethereum nodes, no matter where or when the transaction is processed.

Determinism guarantees that when a transaction or smart contract is processed by one node, the result of that transaction will be the same when it is processed by another node, no matter where or when the transaction is processed. This is important because Ethereum is a decentralized network, and for the network to reach a consensus, all nodes must agree on the same state changes.

While this is crucial for network consistency and security, it also introduces some unique quirks and constraints that developers must account for when building decentralized applications (dApps) or writing smart contracts. Let’s explore some of these quirks:

• No Randomness: Since the EVM must behave deterministically, randomness cannot be introduced naturally during smart contract execution. If each node must compute the same result, anything involving random number generation would lead to inconsistencies, as nodes would calculate different "random" values. To implement randomness, developers typically rely on external sources or oracles that introduce randomness from off-chain sources. One popular method involves using events like the block hash of a previous block or utilizing a Verifiable Random Function (VRF) from external providers (such as Chainlink VRF).

• External Data (Oracles) Dependency: Smart contracts in Ethereum cannot access external data directly because the EVM execution environment is isolated and deterministic. This means they cannot, for example, query data from a website or access real-time price feeds or other off-chain data unless they are provided by an external source. To introduce off-chain data into a contract, developers use oracles—trusted services that provide external data to Ethereum smart contracts. These oracles feed information such as the current price of assets, weather data, sports scores, and more. Oracles play a critical role in enabling decentralized finance (DeFi) applications, prediction markets, and other smart contracts that rely on real-world data.

The EVM is often described as a quasi-Turing-complete machine. But what does that mean, and why is it important?

A Turing-complete system can perform any computation given enough time and resources. In theory, such a system can solve any problem that is computable. Traditional programming languages like Python or Java are Turing-complete because they can express any algorithm.

The EVM is considered quasi-Turing-complete because, while it can theoretically perform any computation, it is constrained by gas. Gas is the unit of measurement for the computational effort required to execute operations on the Ethereum network. Every operation, from simple arithmetic to complex cryptographic functions, consumes gas. If a transaction runs out of gas, execution halts immediately.

In a truly Turing-complete system, an infinite loop could run forever. On the EVM, however, an infinite loop would eventually consume all available gas, causing the transaction to fail. This prevents denial-of-service attacks where malicious actors could clog the network with endless computations.

The quasi-Turing-complete nature of the EVM allows developers to write powerful smart contracts while ensuring that operations remain economically feasible and secure.

When a transaction is initiated on Ethereum, whether it’s a simple ETH transfer or the invocation of a complex smart contract, it goes through a series of steps before it’s finalized and included in a block. Here’s a comprehensive breakdown of the process from start to finish.

• Step 1: Transaction Creation: A user (like Emma) creates a transaction. This transaction could be sending ETH to another address or interacting with a smart contract. The Transaction includes

  • Sender Address: Emma’s wallet address.

  • Recipient Address: The address receiving the transaction (or a smart contract address).

  • Value: The amount of ETH to send (if applicable).

  • Data: For smart contracts, this includes the function to call and its arguments.

  • Gas Limit: The maximum computational work Emma is willing to pay for.

  • Gas Price: The fee Emma is willing to pay per unit of gas.

  • Nonce: A unique number to ensure transactions are processed in order.

• Step 2: Transaction Broadcast: Emma signs the transaction with her private key, proving her identity. The signed transaction is then sent to the Ethereum network.

• Step 3: Transaction Validation
  Ethereum nodes validate the transaction by checking:

  • Signature: Is the transaction signed by Emma?

  • Balance: Does Emma have enough ETH to cover the transaction and gas fees?

  • Nonce: Is the transaction in the correct order?

• Step 4: Execution on the EVM: The transaction is executed on the EVM. If it’s a simple ETH transfer, the balances are updated. If it’s a smart contract call, the contract’s code is executed. If the transaction runs out of gas, it’s reverted, and Emma only loses the gas used up to that point.

• Step 5: State Update: The blockchain's state is updated, including balances and smart contract storage.

• Step 6: Block Inclusion: Miners or validators package the transaction into a block, which is then added to the blockchain after consensus is reached.

• Step 7: Confirmation and Finalization: Once the block is added to the blockchain, the transaction is confirmed. Users often wait for multiple confirmations (e.g., 12 blocks) for added security.

The EVM is a stack-based machine, utilizing a last-in, first-out (LIFO) data structure to manage operations. What sets it apart is its 256-bit word size.

Every piece of data processed by the EVM—whether it’s a number, address, or cryptographic hash—is 256 bits (32 bytes) wide. This choice aligns with Ethereum’s cryptographic foundations, particularly the Keccak-256 hash function and elliptic-curve computations used for digital signatures.

This architecture allows the EVM to handle large numbers efficiently, particularly in cryptographic operations like verifying digital signatures or computing hashes.

The 256-bit word size ensures the EVM can handle cryptographic demands efficiently while simplifying smart contract design, as developers don’t need to manage smaller data types.

Unlike traditional computers, where code and data are stored in the same memory space, the EVM stores code in virtual ROM (Read-Only Memory). This ensures that the bytecode of smart contracts is immutable during execution, preventing modification while the contract runs.

By isolating code from data, the EVM prevents self-modifying code, enhancing the security and predictability of smart contracts.

Gas fees on the EVM are not only tied to computation but also to memory usage. Memory-intensive operations incur higher costs.

Memory fees are charged based on the smallest multiple of 32 bytes required to cover all accessed memory indices. For example:

• If a contract accesses indices 0 to 31, it pays for 32 bytes.

• If it accesses indices 0 to 63, it pays for 64 bytes.

This ensures efficient memory usage and prevents abuse.

Memory fees encourage developers to optimize their code for gas efficiency, preventing unnecessary strain on the network.

In 2016, one of the most infamous hacks in Ethereum's history occurred with a DAO (Decentralized Autonomous Organization) known as The DAO. This venture raised $150 million by selling tokens to investors, who believed in its vision of a decentralized investment fund. However, just three months after its creation, The DAO was exploited through a reentrancy attack, draining millions of ETH.

The attack targeted a vulnerability in the withdraw() function of The DAO’s smart contract, where the hacker used a malicious contract to repeatedly call the function before the balance was updated, allowing them to withdraw more than their share of funds. This attack highlighted the importance of carefully managing the order of operations in smart contracts. In this case, the vulnerability arose because The DAO’s contract transferred ETH before updating the user's balance, enabling the attacker’s contract to recursively call the withdraw function, thus draining The DAO's funds.

The hack caused a deep ideological debate within the Ethereum community—whether to intervene and correct the hack by forking the blockchain or uphold the immutability of smart contracts. Ultimately, the Ethereum community decided to hard fork the blockchain, resulting in the creation of two separate chains: Ethereum (ETH) and Ethereum Classic (ETC).

The event brought forward critical lessons on smart contract security and the importance of properly handling reentrancy attacks, especially ensuring that state changes (like updating balances) happen before sending funds to avoid exploitative loops.

The Ethereum Virtual Machine is a marvel of engineering, combining flexibility, security, and efficiency to support decentralized applications and smart contracts. By understanding these facts, you can appreciate the depth and sophistication of the EVM’s design. Whether you’re a developer, researcher, or blockchain enthusiast, the EVM offers endless opportunities for innovation and exploration.