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:
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:
00
raw string
No interpretation - used in oracles
01
Sophia_AEVM_01
For Sophia 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.
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
, andInt.to_bytes
Last updated