Virtual machines on the æternity blockchain

A smart contract is associated with a virtual machine for the execution of that contract. The æternity blockchain supports the virtual machine AEVM - A version of the Ethereum VM. The AEVM can also use different ABIs, and it is versioned to ensure that runs on earlier version can still be run to validate the chain in the presence of consensus breaking VM changes.

A Create Contract transaction and the contract state tree contains a 'vm_version' field and an 'abi_version' field. These fields describes the type and version of the virtual machine to use for the contract and the type and version of the application binary interface (ABI) of the contract. (Note that the serialization packs the version into one integer.)

The current meaning of the VM field is:

Value (hex)
Machine
Description

00

none

NO_VM ("Used" in oracles)

01

AEVM_01

For Sophia contracts on the AEVM

02

AEVM_01

For Solidity contracts on the AEVM

03

AEVM_02

Improved AEVM for Sophia, Minerva release

04

AEVM_03

Improved AEVM for Sophia, Fortuna release

05

FATE_01

For Sophia contracts using FATE (Lima release)

06

AEVM_04

Improved AEVM for Sophia, Lima release

07

FATE_02

For Sophia contracts using FATE (Iris release)

08

FATE_03

For Sophia contracts using FATE (Ceres release)

09-FFFF

UNUSED

The current meaning of the ABI field is:

Value (hex)
ABI
Description

00

raw string

No interpretation - used in oracles

01

Sophia_AEVM_01

For Sophia contracts on the AEVM

02

For Solidity contracts on the AEVM

03

Sophia_FATE_01

For Sophia contracts using FATE

04-FFFF

UNUSED

Which VM versions are accepted are different based on consensus protocol versions.

Protocol version
Operation
Accepted VM values
Accepted ABI values

Roma

contract call/create

0x1

0x1

oracle register

(Not applicable.)

0x0, 0x1

Minerva

contract call

0x1, 0x3

0x1

contract create

0x3

0x1

oracle register

(Not applicable.)

0x0, 0x1

Fortuna

contract call

0x1, 0x3, 0x4

0x1

contract create

0x3, 0x4

0x1

oracle register

(Not applicable.)

0x0, 0x1

Lima

contract call

0x1, 0x3, 0x4, 0x5, 0x6

0x1, 0x3

contract create

0x5, 0x6

0x1, 0x3

oracle register

(Not applicable.)

0x0, 0x1, 0x3

Iris

contract call

0x1, 0x3, 0x4, 0x5, 0x6, 0x7

0x1, 0x3

contract create

0x7

0x3

oracle register

(Not applicable.)

0x0, 0x3

Ceres

contract call

0x1, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8

0x1, 0x3

contract create

0x8

0x3

oracle register

(Not applicable.)

0x0, 0x3

The number after the machine name designates the version of the machine. In the future new versions of the machine can be implemented with new instructions, contracts using these machines must use a new vm_version number corresponding to the new machine version.

The ABI name correspond to the supported languages. All Ethereum VM languages uses the same ABI (Solidity_1). The languages can in the future be extended with new functionality and new ABIs reflected by the ABI version number.

For a description of each ABI see the corresponding language description: Sophia, Solidity.

The æternity Ethereum virtual machine AEVM

See The AEVM.

Consensus breaking changes between AEVM versions

AEVM_01 -> AEVM_02

  • Oracle query fee of unknown oracle

    • AEVM_01: Succeeded with bogus value

    • AEVM_02: Fails with exception

  • New crypto/hash primitives

  • New VM instructions (bit shift operations)

AEVM_02 -> AEVM_03

  • New primitive operations (Auth.tx_hash)

  • New crypto primitives

AEVM_03 -> AEVM_04

  • New crypto primitives

  • Memory gas adjustments

  • Updated arguments for AENS-functions

  • Support for payable

Consensus breaking changes between FATE versions

FATE_01 -> FATE_02

  • Added operations

    • Crypto pairing operations (BLS12-381)

    • String functions (to_list, from_list, etc)

    • AENS.update, AENS.lookup, Oracle.expire

    • Chain.create, Chain.clone, Chain.bytecode_hash, Call.fee

  • Bug fixes

  • Gas model adjustments

FATE_02 -> FATE_03

  • Added operations:

    • bitwise operations on integers (band, bor, bxor, bnot, << and >>)

    • Address.to_bytes - converting an address to its binary representation

    • Int.mulmod - a combined multiplication and modulus operation for efficiency

    • Crypto.poseidon - a ZK/SNARK friendly hash function

    • Arbitrary sized binary arrays: Bytes.split_any, Bytes.to_fixed_size, Bytes.size, String.to_bytes, and Int.to_bytes

Last updated