6

I've read What was the reason to invent the EVM? but I feel like it didn't fully answer the question.

So I have a couple of followup questions regarding the EVM:

Why does the EVM ensure perfect determinism (for consensus)? And why is that important? The example made was infinite loop resistance but that is that the only reason for "perfect determinism" (whatever that means).

Why not use a toned down version of an already existing VM like JVM? (and afaik there are open source alternatives so that you don't need to get a license from Sun)

I don't really understand why the developers had to build a EVM from scratch, that sounds overly complicated.

Improve this question
1
  • 1
    Note that even things that seem innocuous can introduce nondeterminism. Floating point arithmetic, for instance
    – Tjaden Hess
    Commented Nov 15, 2017 at 16:16

2 Answers 2

Reset to default
7

It's much better to write a new virtual machine specifically for this task for several reasons:

Determinism

Ethereum, like all blockchains, is a trustless and decentralized network. Each node in the network must be able to validate all transactions and their code execution on their own. They have to do this to determine how much Ether each address owns after each transaction, and to decide whether or not to relay a transaction to other nodes. To accomplish this, all nodes have to agree with eachother what the exact execution flow of a contract execution was and what the state of the blockchain is.

For example, in the JVM you can request a random number, read a file or load data from the internet. These operations can return completely different results depending on which computer is executing them. They are therefore not deterministic. The JVM was not designed with determinism in mind. Most existing virtual machines do not guarantee determinism.

It is less work to write a new virtual machine from scratch than it would be to modify an existing virtual machine to fit the strict and precise requirements of Ethereum.

Execution speed

As mentioned before, something like the JVM comes loaded with lots of features that aren't really useful in the case of Ethereum. This can only serve to slow down the execution of smart contracts. The execution speed of smart contracts is crucial to make the network affordable to use. If a contract executes twice as slowly, it would cost twice the transaction fees to use it.

Security

The Ethereum virtual machine needs perfect security in very specific ways. For example, one contract should not be able to change the state of another contract. Using an existing virtual machine would be dubious because they were not written with Ethereum's special requirements in mind.

Measuring execution effort

In a system like Ethereum, one would like small transactions that take very few CPU cycles to have small transaction fees. Large transactions that do a lot of computation should cost more, proportionally. To accomplish this, you need to measure how much effort it took to execute a contract code. You can't just measure time or CPU cycles, because those are implementation and machine-dependent. We want all the nodes on the network to agree on exactly how much effort it took.

Therefore, Ethereum uses the unit gas to measure the effort it took to execute a transaction. Each opcode in the EVM takes a certain universally agreed-upon amount of gas.

This dynamic transaction fee system provides the necessary economic incentive to senders of transactions and writers of contracts to reduce the use of storage space and CPU time on all nodes.

Pretty much no existing virtual machines come with such a counter.

Binary size

Having less opcodes (only the ones needed for this specific purpose) means programs can be packed more tightly. This reduces blockchain size and transaction fees.

I hope this helps :-)

Improve this answer
2
  • What if instead of agreeing on exactly how much effort it took, they all agreed on the final output state? is it not feasible because it might takes some miners longer to compute than others if it was using a VM like the JVM, and it wouldn't be considered "fair"?
    – Miguel
    Commented Aug 1, 2018 at 18:44
  • @MiguelMota The transaction fees are based on exactly how much effort it took, and the transaction fees are part of the final output state. So how much effort it took is also part of the final state. You can't separate the two under Ethereum's transaction fee system. Of course nodes are free to write their own implementation of the EVM and use different hardware, so one node might still physically take longer than another node. The point of gas is to have at least some deterministic mechanism to measure the effort required to execute a transaction.
    – Jesbus
    Commented Aug 2, 2018 at 10:14
1

Ethereum talks about the first-class-citizen property, where contracts can do anything that external actors can, this includes calling other contracts to perform actions. This exposes the potential problem of infinite recursion. A malicious actor could write contract code in a way that it causes nodes on the network to enter an infinite loop and halt.

Design decisions were made to prevent these events from occurring. It was these design decisions that allowed the EVM to be Turing-complete. There is an inherent constraint on the number of computational steps transactions/messages can perform so why not give the added benefit of Turing-completeness anyway?

For these reasons, Ethereum is often labelled as Quasi-Turing-complete because of the guaranteed finality of all executions.

A new VM, among other things (mentioned in other answers) was needed to accommodate for this new paradigm of redundant computation.

Hope this helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.