The concept of Ethereum was conceived in 2013 by Vitalik Buterin . Ethereum is firmly grounded on Ethereum Virtual Machine as a code for execution and known to be as heart of Ethereum. Before we start, I want to enlighten the concept of virtual machine, VM.
A virtual machine (VM) is a program running on host hardware that provides an isolated environment with its operating system (OS) and applications. The most common example is using Kali Linux as a VM in a windows based system. VM provides a secure sandboxed environment with portability. Portability means it can be easily moved from one server to another or on-premises to the cloud as per requirement. An Ethereum virtual machine is a software platform, or “virtual computer,” used by developers to create decentralized applications (DApps) and execute and deploy smart contracts on the Ethereum system.
Smart Contract is mostly developed in a programming language called Solidity. Then it is compiled to bytecode, a machine-readable format, and sent to Ethereum nodes on the Ethereum Network, which is spread worldwide. Every Ethereum node has a copy of its EVM, where this bytecode of the smart Contract is deployed and executed.
EVM as a ‘World Computer’
The Ethereum Network is a decentralized network of nodes all working together to run programs called Smart Contracts. Many companies are building applications on top of Ethereum as a base layer. In that way, it became the “world computer,” which aims to implement a globally decentralized, un-ownable digital computer for executing peer-to-peer contracts.
EVM is a quasi–Turing-complete state machine
The EVM is a quasi–Turing-complete state machine; “quasi” because all execution processes are limited to a finite number of computational steps by the amount of gas available for any given smart contract execution. EVM can run any program you feed into it, but only if it terminates within a particular amount of computation. This makes EVM a quasi-Turing complete machine.
EVM has a stack-based architecture
EVM has a stack-based architecture with a depth of 1024 items. Each item is a 256 bit word. This stack is used for hashing and elliptic curve operations.
Figure 1: EVM operation
There are three main types of storage available in the architecture of EVM:
Main Memory : The first type is called main memory or volatile memory, which is a word-addressed byte array. When a contract finishes its code execution, the memory is cleared. Memory is unlimited but constrained by gas fee requirements.
Storage : The other type is called storage, a key-value store permanently persisted on the blockchain. Keys and values are each 256 bits wide. It is allocated to all accounts on the blockchain. As a security measure, storage is only accessible by its respective CAs. It can be thought of as hard disk storage. The program code is stored in virtual read-only memory (virtual ROM) that is accessible using the CODECOPY instruction. The CODECOPY instruction copies the program code into the main memory. The EVM reads the main memory by referring to the program counter and executes step-by-step instructions.
Stack : EVM is a stack-based machine and thus performs all computations in a data area called the stack. All in-memory values are also stored in the stack. It has a maximum depth of 1024 elements and supports a word size of 256 bits. It supports Push – inserting the item into the stack and Pop- removing an item from the stack.
EVM Opcodes
An opcode is the portion of a machine language instruction that specifies the operation to be performed. In EVM, there are seven types of opcodes available, as described in the table below:
Table: The EVM opcodes
For detailed information on EVM opcode, please visit: GitHub - crytic/evm-opcodes: Ethereum opcodes and instruction reference
Ethereum State
The EVM behaves as a mathematical function: Given an input, it produces a deterministic output. Therefore, it is quite helpful to describe Ethereum more formally as having a state transition function:
Y(s,t)=s’
Given an old valid state (s) and a new set of valid transactions (T), the Ethereum state transition function Y (s, t) produces a new valid output state s.’
So, we begin with a genesis state and incrementally execute transactions to morph it into some final state. The EVM defines the specific rules of changing state from block to block.
At the top level, we have the Ethereum world state. The world state maps address (accounts) and account states. Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree or trie. The trie requires a simple database backend that maintains a mapping of byte arrays to byte arrays; we name this underlying database the state database.
At the lower level, each Ethereum address represents - an account state that includes an ether balance, a nonce, the account’s storage, and the account’s program code.
Figure 2: World state trie and Account storage
Gas Accounting in EVM
Each opcode that is executed in EVM incurs a cost in gas. Before each operation is executed, the EVM checks the gas balance to determine whether it is enough to pay for its execution. If there isn’t enough gas, execution is halted, and the transaction is reverted.
If the EVM reaches the end of execution successfully, without running out of gas, the gas cost used is paid to the miner as a transaction fee, converted to ether based on the gas price specified in the transaction.
miner fee = gas cost * gas price
The gas remaining in the gas supply is refunded to the sender, again converted to ether based on the gas price specified in the transaction:
remaining gas = gas limit - gas cost
refunded ether = remaining gas * gas price
where
- Gas cost is a measure of computation and storage used in the EVM - the number of units of gas required to perform a particular operation.
- Gas price is the amount of ether you are willing to pay per unit of gas when you send your transaction to the Ethereum network.
- Miner fee - The miners are only paid for the computations they perform.
- Gas limit is the limit of Gas usage- a transaction’s sender will set higher than or equal to the amount of gas expected to be used. If the gas limit is set higher than the amount consumed, the sender will receive a refund of the excess amount.
- Block Gas Limit - The block gas limit is the maximum amount of gas that all the transactions in a block may consume and constrains how many transactions can fit into a block. The miners on the network collectively decide the block gas limit. The miner of a block can vote to adjust the block gas limit.
Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain 
Appendix H depicts the details of the Gas fee according to opcodes available in Ethereum.
The Bottom Line
In this article, I discussed the architecture and working model of EVM. This may open up many new thoughts and vision regarding scalability in the form of Layer 2 and Layer 3 protocols.
Reference
[1] Ethereum Virtual Machine (EVM) | ethereum.org
[2] Ethereum White Paper - A NEXT GENERATION SMART CONTRACT & DECENTRALIZED APPLICATION PLATFORM, By Vitalik Buterin published in ethereum.org
[3] Mastering Ethereum by Andreas M. Antonopoulos, Gavin Wood, Publisher- O’Reilly Media
[4] https://www.datasciencecentral.com/the-ethereum-virtual-machine-evm/