The Latest EVM: “Ethereum Is A Trust-Free Closure System”

The Evolution of Ethereum: A Trust-Free Closure System

The Ethereum community has been abuzz with excitement in recent weeks, as our lead C++ developer, Gavin Wood, and I have been meeting with local Ethereum enthusiasts in San Francisco and Silicon Valley. The interest in our project has been palpable, with a meetup group forming every week, just like the Bitcoin meetup, and over thirty people attending each time. The community is taking it upon themselves to create educational videos, organize events, and experiment with contracts, with one person even independently starting to write an implementation of Ethereum in node.js.

Transactions as Closures

In the early days of Ethereum, the MKTX opcode allowed contracts to send transactions triggering other contracts. However, this opcode had a non-intuitive feature: instead of processing the entire transaction immediately, it deferred execution until the end of the transaction stack. This led to some unexpected behavior, as seen in the example below:

x = array()
x[0] = "george"
x[1] = MYPUBKEY

mktx(NAMECOIN,10^20,x,2)

if contract.storage(NAMECOIN)["george"] == MYPUBKEY:
    registration_successful = 1
else:
    registration_successful = 0

This code seems like it should work, but in reality, it doesn't. With the new EVM3, we've fixed this problem by introducing the concept of "message calls." A message call is an operation executed from inside a contract that takes a destination address, an ether value, and some data as input and calls the contract with that ether value and data, but also returns data as an output.

Ether and Gas

Another important change in EVM3 is the way contracts pay for execution. Instead of paying for contract execution, transactions now pay for execution. When you send a transaction, you need to include a BASEFEE and a maximum number of steps that you're willing to pay for. At the start of transaction execution, the BASEFEE multiplied by the maxsteps is immediately subtracted from your balance. A new counter is then instantiated, called GAS, that starts off with the number of steps that you have left.

The New Terminology Guide

With the introduction of new concepts in EVM3, we've standardized on a few new terms to help clear up discussion on the various topics.

External Actor: A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum.
Address: A 160-bit code used for identifying Accounts.
Account: Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state.
Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object.
Autonomous Object: A virtual object existant only within the hypothetical state of Ethereum.
Storage State: The information particular to a given Autonomous Object that is maintained between the times that it runs.
Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts in a perfectly trusted way.
Message Call: The act of passing a message from one Account to another.
Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-3.5), which is converted freely to and from Gas as required.

Long Term View

In the long term, we plan to release a full formal spec of the changes, including a new version of the whitepaper that takes into account all of these modifications, as well as a new version of the client that implements it. Later on, further changes to the EVM will likely be made, but the ETH-HLL will be changed as little as possible; thus, it is perfectly safe to write contracts in ETH-HLL now and they will continue to work even if the language changes.

Attack the Last Two "Intrinsic" Parts of the System

In the long term, maybe even beyond Ethereum 1.0, perhaps the holy grail is to attack the last two "intrinsic" parts of the system, and see if we can turn them too into contracts: ether and ECDSA. In such a system, ether would still be the privileged currency in the system; the current thinking is that we will premine the ether contract into the index "1" so it takes nineteen fewer bytes to use it. However, the execution engine would become simpler since there would no longer be any concept of a currency – instead, it would all be about contracts and message calls. Another interesting benefit is that this would allow ether and ECDSA to be decoupled, making ether optionally quantum-proof; if you want, you could make an ether account using an NTRU or Lamport contract instead. A detriment, however, is that proof of stake would not be possible without a currency that is intrinsic at the protocol level; that may be a good reason not to go in this direction.

Source: https://blog.ethereum.org/en/2014/03/20/the-latest-evm-ethereum-is-a-trust-free-closure-system