The execution model gives us an understanding of state transition given the right elements i.e a series of bytecode instructions and a tuple of environment data such as msg.sender, transaction origin, call value, input data, executing contract address, gas related data, block level data, this process is carried out through the EVM. The EVM is quasi-turing complete which makes it bounded by the amount of gas available for computation.

The EVM is a simple stack-based architecture with a word size of 256 bits, this was chosen to facilitate the Keccak 256 scheme and elliptic-curve computation because both Keccak hashing and elliptic-curve cryptography natively operate on 256-bit values, making cryptographic operations simple, efficient, and secure. The EVM has an independent storage model which is non-volatile as compared to memory.

The EVM is made up of two different data areas which are separate from each other - Memory and Storage they are not the same thing and tend to behave differently, memory is temporary, exist only during a transaction, think of it as RAM during a single function call, storage on the other hand is is persistent, becomes part of the ethereum's global state, its word addressable- this means storage is indexed in slot numbers and each slot holds exactly 256 bits, memory resets to zero after each function call while storage persists across transactions and every node must agree on that transaction. All locations (memory bytes & storage slots) starts at zero, this is crucial for deterministic execution, consensus and security.

The EVM does not follow the standard von Neumann architecture - the operation of the EVM is outside the normal computer where code and data live in the same memory, programs can modify themselves and instructions are just data. The EVM uses a harvard-like architecture where code is stored in a virtual ROM, its immutable after deployment and not accessible like memory and storage. Data is stored in memory or storage, can be read or written. Contract bytecode is immutable - you cannot write to it, overwrite it, treat it as data, that means once the code is deployed the code becomes law and can be interacted with through special instructions called opcodes.

The machine is prone to having "exceptional execution" which returns an error states, some of the reasons can be stack overflow, trying to pop more items than exists or invalid instructions which can be executing an opcode that is either invalid, does not exist or isn't allowed in that context, other causes if exeptional execution can out-of-gas. When the exceptional executions occur all state changes are reverted this includes storage writes, balance transfers, contract creation, logs(events), when these happen the machine halts no more instructions are executed, if it is a top-level transaction the ethereum client receives the error.

Fees (gas fees) are charged before executing steps and the EVM charges gas in three different ways :- The first is intrinsic operation cost, each opcode has a fixed base cost

The pricing prevents infinite loops, reflects real computation effort, makes execution deterministic

The second way gas is paid to sub-calls (CALL/CREATE) when a contract calls another contract (CALL/DELEGATECALL), also when a new contract is created (CREATE/ CREATE2) it must explicitly forward gas.

The third was gas is paid due to memory usage, this is because memory grows in chunks of 32 bytes, if you want to access memory at an address you pay for how far memory has expanded, not how much you used, so if the highest accessed memory index is n, memory must be expanded to cover it.

Storage is the most expensive resource and that is because storage is stored forever, it is replicated across all nodes and it increases the global state size

The ethereum execution is modeled as a pure function such that: - Given the current world state σ, some gas g, and an execution context I - compute a new world state σ, remaining gas g′, side effects A and return data o (σ′,g′,A,o)=Ξ(σ,g,I) The execution environment is the full read-only context the EVM needs to execute bytecode correctly, it can be seen as everything the virtual machine must know before it starts executing Breaking down the elements in the environment

• Ia — address of the executing account - the address of the account which owns the code being executed, address(this) determines which storage to read/write, which balance is affected
• Io — original transaction sender - this is the tx.origin, the EOA that started everything
• Ip — gas price - this is the gas price, tx.gasprice, price per unit of gas(in wei), this is used to compute transaction fee
• Id — input data - this is the msg.data, the input data to this execution, for transaction, it is the function selector and arguments, for contract call it is the call data passed by the caller
• Is — immediate caller - this is the msg.sender, this is the direct caller, changes on every call depth
• Iv — call value - this is the msg.value, the amount of ETH sent with the call, default to zero unless it is explicitly sent
• Ib — bytecode to execute - this is the contract runtime bytecode, it is stored in the account code field, read-only
• IH — block header - block.number block.timestamp, block.coinbase, block.basefee, block.chainid - this is fixed during execution.