Welcome back to part 2 of our series on Qtum’s design. In the previous part, we talked about the UTXO model championed by Bitcoin. Today, we will be looking at Ethereum’s side of the equation — the Ethereum Virtual Machine.
What Is the Ethereum Virtual Machine?
Let us take a look at Java as an example, in Java, developers write the codes and compile them into bytecodes. These bytecodes are then loaded into the Java Virtual Machine (JVM) and executed in the JVM. The JVM specification ensures the interoperability of the programs across different implementations. Ethereum takes a similar approach, where developers code smart contracts in Solidity. These contracts are then converted into bytecodes and uploaded on the blockchain for execution on the EVM (Ethereum Virtual Machine) running on various hardware platforms.
The Ethereum Virtual Machine is a “quasi-Turing” complete machine. A Turing complete machine is mathematically able to solve any problem given to it. So why is the Ethereum Virtual Machine seen only as quasi-Turing complete? The reason is that the calculations performed by the machine are limited by Gas, which acts as a safety limit when it comes to the number of computations the machine can perform.
We mentioned earlier that the Ethereum Virtual Machine is at the heart of the Ethereum ecosystem. It handles the deployment and the execution of smart contracts. Simple transactions do not need the involvement of the EVM. However, other operations will require a state update by the EVM. The Ethereum Virtual Machine contains millions of executable objects, with each object having its data store.
The Ethereum Virtual Machine utilizes a stack-based architecture, storing the in-memory values on a stack. All operations are performed as defined in the EVM code or the bytecode. It also has several data components such as
● Immutable program code ROM, The ROM is loaded ...
To keep reading, please go to the original article at:
Stories by Qtum on Medium