-
Virtual Machine (Virtualbox, QEMU, cloud computing)
-
Java VM
Virtual Machine technologies such as Virtualbox and QEMU/KVM differ from the EVM in that their purpose is to provide hypervisor functionality, or a software abstraction that handles system calls, task scheduling, and resource management between a guest OS and the underlying host OS and hardware.
Certain aspects of the Java VM (JVM) specification however, do contain similarities to the EVM. From a high-level overview, the JVM is designed to provide a runtime environment that is irrespective of the underlying host OS or hardware, enabling compatibility across a wide variety of systems. High level program languages such as Java or Scala that run on the JVM are compiled into the respective instruction set bytecode. This is comparable to compiling a Solidity source file to run on the EVM.
The EVM Machine Language is divided into specific instruction set groups, such as arithmetic operations, logical and comparison operations, control flow, system calls, stack operations, and memory operations. In addition to the typical bytecode operations, the EVM must also manage account information (i.e. address and balance), current gas price, and block information.
As with any computating system, the concept of state is an important one. Just like a CPU keeping track of a process in execution, the EVM must keep track of the status of various components in order to support a transaction. The status or state of these components ultimately drives the level of change in the overarching blockchain. This aspect leads to the description of Ethereum as a transaction-based state machine containing the following components:
- World State
-
A mapping between 160-bit address identifiers and account state, maintained in an immutable Merkle Patricia Tree data structure.
- Account State
-
Contains the following four components:
-
nonce: A value representing either the number of transactions sent or the number of contracts created from this respective account.
-
balance: The number of Wei owned by the account address.
-
storageRoot: A 256-bit hash of the Merkle Patricia Tree’s root node.
-
codeHash:: An immutable hash value of the EVM code for the respective account.
-
State transitions are calculated with the following functions:
- Ethereum State Transition Function
-
Used to calculate a valid state transition.
- Block Finalization State Transition Function
-
Used to determine the state of a finalized block as part of the mining process, including block reward.
- Block Level State Transition Function
-
The resulting state of the Block Finalization State Transition Function when applied to a transaction state.
Compiling a Solidity source file to EVM bytecode can be accomplished via the command line. For a list of additional compile options, simply run the following command:
$ solc --help
Generating the raw opcode of a Solidity source file is easily achieved with the --opcodes command line option. For example, compiling an example Solidity file Example.sol and populating the opcode output into a directory named BytecodeDir is accomplished with the following command:
$ solc -o BytecodeOutputDir --opcodes Example.sol
The output opcode files generated will depend on the specific contracts contained within the Solidity source file. Our simple Solidity file Example.sol has only one contract named "example".
pragma solidity ^0.4.19;
contract example {
address contractOwner;
function example() {
contractOwner = msg.sender;
}
}
If you look in the BytecodeDir directory, you will see the opcode file example.opcode which contains the EVM machine language instructions of the "example" contract. Opening up the example.opcode file in a text editor will show the following:
PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH2 0xF JUMPI PUSH1 0x0 DUP1 /*snip*/
Let’s examine the first two instructions:
PUSH1 0x60 PUSH1 0x40
Here we have the mnemonic "PUSH1" with a value of "0x60". This corresponds to the EVM instruction of pushing a 1-byte item onto the stack. This operation is capable of pushing a 32-byte item on the stack with the following opcode:
PUSH32 0x7f
The second push opcode value "0x40" indicates the hash value of a complete block.