Many people acquainting themselves with the Ethereum ecosystem tend to overlook the Ethereum Virtual Machine, yet it provides really interesting tidbits into how the Ethereum ecosystem works.
The Ethereum Virtual Machine (EVM) is the core innovation of Ethereum. It is a Turing complete software that enables anyone to run any program, provided they have enough memory space. The EVM helps developers build blockchain applications faster, more easily, and more efficiently. It provides the platform for creating countless blockchain applications in one single place, instead of having to create a new blockchain for every new application.
The EVM also prevents denial of service attacks – which are attacks targeted at making a network unavailable to users. It also ensures programs running on the blockchain do not have access to each other’s state, thus eliminating any potential interference.
Turing Complete
EVM is a quasi-Turing complete software. Turing complete is named after Alan Turing, the innovator of the Turing machine. A Turing complete machine can solve any problem fed into it, as long as there are enough time and memory space.
EVM is quasi-Turing complete because its computations are bound by gas – which in effect limits the number of calculations that it can solve.
Gas and EVM Bytecode
On Ethereum, transactions are powered by ‘gas,’ which in essence is the fee that users pay. The concept of gas can be seen in two ways: gas and gas price.
Gas is the measuring tool of how much fee is needed for a particular transaction, while gas price is how much Ether you’re willing to spend to purchase a unit of gas. Gas price is measured in ‘Wei.’
A Wei is the smallest unit of Ether – with one Ether comprising 10^18 Wei.
If an individual wishes to conduct a transaction on Ethereum, they must set the gas limit and gas price attached to that transaction. If they don’t possess the required gas for that transaction, it will ‘run out of gas’ and hence be invalid.
Gas can limit the number of transactions on the EVM, in this way:
- Blocks on the Ethereum blockchain have a gas limit, meaning the gas spend on any transaction cannot exceed a particular amount
- The gas is attached to the gas price, even if the gas limit was removed, it would be impractical to solve just any problem fed into it.
EVM has its own programming language called the ‘EVM bytecode.’ When a code is written in a higher-concept programming language like Ethereum’s own Solidity, it is compiled in the bytecode so that EVM can interpret it.
Transaction-based State Machine
The EVM is a crucial part of the Ethereum infrastructure since it handles internal state and computations, account information pertaining to addresses, balances, gas price, and so on. The EVM must always keep track of the numerous network components so it can support transactions.
A state machine is a term in computer science that refers to a machine that can read inputs fed into it and then, upon interpreting those inputs, produce certain outputs. This is how transactions on the EVM are carried out. At the start, there is a blank slate. When transactions are occurring, any point in that duration describes the current state of Ethereum. For a state transaction to occur, the ‘inputs’ entered must be valid. A transaction is validated once it successfully goes through the mining process.
This mining process is referred to as proof-of-work (PoW) and takes place when certain network participants expend computing power so as to verify a block of transactions and add those transactions on the blockchain. Successfully completing a block gets a miner rewarded with Ether – the native token of the Ethereum blockchain.
Now, onto the components that the EVM must continually keep track of: the Account State, World State, Storage State, Block Information, and Runtime Environment Information.
Account State
The Ethereum platform comprises many small accounts that can interact with each other, thanks to its message-passing infrastructure. These accounts can be divided into two types: externally owned accounts and contract accounts. Externally owned accounts are controlled by their owners via private keys, while contract accounts are controlled by the contract code.
An externally owned account can send messages to other externally owned accounts and also contract accounts via the use of a private key. Communication between these types of accounts can be considered as just value transfer.
However, passing between an externally owned account and a contract account triggers the execution of the contract account code. This causes the contract account to execute the instructions in the code, for example, transferring or creating new tokens.
Unlike externally owned accounts, contract accounts cannot initiate new transactions by themselves.
Instead, they are reactive – meaning they can only engage in transactions in response to other transactions that have been passed to them either from externally owned accounts or other contract accounts.
Three elements characterize the account state, and these are as below:
Nonce – For externally owned accounts, this is the value of how many transactions were sent from the account’s address. For contract accounts, this is how many contracts were created by the account.
Balance – This is how many Weis are owned by the account address
CodeHash – This is the immutable hash value of the EVM code for the corresponding account.
World State
This is a ‘global’ state that comprises a mapping between 160-bit address identifiers and the account state. The mapping is maintained in a data framework called the Merkle Patricia Tree – which in turn consists of nodes with:
- Numerous leaf nodes at the bottom of the tree that houses the underlying data
- A set of intermediate nodes with each node consisting of two child nodes
- A single root hash born from the hash of the previous child nodes, representing the top of the tree structure
Storage State
The storage state is state information for specific accounts. This information is maintained on the EVM at runtime.
Block Information
These are state values that enable transactions to take place, and they comprise:
- Block hash – which is the hash of the youngest validated block
- Coinbase – the recipient’s address
- Timestamp – the current block’s timestamp
- Number – the number or position of the current block
- Difficulty – the difficulty value of the current block
- Gas limit – the maximum gas that can be spent on the current block
Runtime Environment Information
This is information that allows for transactions to be executed. It includes the following:
- Gas Price – Current gas attached to a transaction
- Codesize – The size of transactions’ source code
- Caller – The address of the account that is conducting the transaction
- Origin – The address of the transaction’s initiator
Outside the Network
The EVM is situated outside the main Ethereum network, making it a perfect testing environment. Individuals and companies that wish to create smart contracts can do so on the platform, and this will not any way affect normal blockchain operations. They can also use the platform to hone their smart contract creation skills so they can eventually create more robust and applicable smart contracts.
Closing Thoughts
Smart contracts are central to a decentralized world – and the EVM is an excellent platform for developers to curate smart contracts that will make the world a better place. Being a free and highly developed tool for this process, we can’t think of a better platform where people can perfect – and ultimately showcase their coding smarts.