Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
# Nimbus - Services available to EVM code that is run for a transaction
|
|
|
|
#
|
|
|
|
# Copyright (c) 2019-2021 Status Research & Development GmbH
|
|
|
|
# Licensed under either of
|
|
|
|
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
|
|
|
|
# * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
|
|
|
|
# at your option. This file may not be copied, modified, or distributed except according to those terms.
|
|
|
|
|
|
|
|
#{.push raises: [Defect].}
|
|
|
|
|
|
|
|
import
|
2021-05-21 05:24:09 +00:00
|
|
|
sets, times, stint, chronicles,
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
eth/common/eth_types, ../db/accounts_cache, ../forks,
|
|
|
|
".."/[vm_types, vm_state, vm_computation, vm_internals],
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
./host_types, ./host_trace
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
|
|
|
|
proc setupTxContext(host: TransactionHost) =
|
|
|
|
# Conversion issues:
|
|
|
|
#
|
|
|
|
# `txContext.tx_gas_price` is 256-bit, but `vmState.txGasPrice` is 64-bit
|
|
|
|
# signed (`GasInt`), and in reality it tends to be a fairly small integer,
|
|
|
|
# usually < 16 bits. Our EVM truncates whatever it gets blindly to 64-bit
|
|
|
|
# anyway. Largest ever so far may be 100,000,000.
|
|
|
|
# https://medium.com/amberdata/most-expensive-transaction-in-ethereum-blockchain-history-99d9a30d8e02
|
|
|
|
#
|
|
|
|
# `txContext.block_number` is 64-bit signed. This is actually too small for
|
|
|
|
# the Nimbus `BlockNumber` type which is 256-bit (for now), so we truncate
|
|
|
|
# the other way.
|
|
|
|
#
|
|
|
|
# `txContext.chain_id` is 256-bit, but `vmState.chaindb.config.chainId` is
|
|
|
|
# 64-bit or 32-bit depending on the target CPU architecture (Nim `uint`).
|
|
|
|
# Our EVM truncates whatever it gets blindly to 64-bit or 32-bit.
|
|
|
|
#
|
|
|
|
# No conversion required with the other fields:
|
|
|
|
#
|
|
|
|
# `txContext.tx_origin` and `txContext.block_coinbase` are 20-byte Ethereum
|
|
|
|
# addresses, no issues with these.
|
|
|
|
#
|
|
|
|
# `txContext.block_timestamp` is 64-bit signed. `vmState.timestamp.toUnix`
|
|
|
|
# is from Nim `std/times` and returns `int64` so this matches. (It's
|
|
|
|
# overkill that we store a full seconds and nanoseconds object in
|
|
|
|
# `vmState.timestamp` though.)
|
|
|
|
#
|
|
|
|
# `txContext.block_gas_limit` is 64-bit signed (EVMC assumes
|
|
|
|
# [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985) although it's not
|
|
|
|
# officially accepted), and `vmState.gasLimit` is too (`GasInt`).
|
|
|
|
#
|
|
|
|
# `txContext.block_difficulty` is 256-bit, and this one can genuinely take
|
|
|
|
# values over much of the 256-bit range.
|
|
|
|
|
|
|
|
let vmState = host.vmState
|
|
|
|
host.txContext.tx_gas_price = vmState.txGasPrice.u256.toEvmc
|
|
|
|
host.txContext.tx_origin = vmState.txOrigin.toEvmc
|
|
|
|
# vmState.coinbase now unused
|
|
|
|
host.txContext.block_coinbase = vmState.minerAddress.toEvmc
|
|
|
|
# vmState.blockNumber now unused
|
|
|
|
host.txContext.block_number = (vmState.blockHeader.blockNumber
|
|
|
|
.truncate(typeof(host.txContext.block_number)))
|
|
|
|
# vmState.timestamp now unused
|
|
|
|
host.txContext.block_timestamp = vmState.blockHeader.timestamp.toUnix
|
|
|
|
# vmState.gasLimit now unused
|
|
|
|
host.txContext.block_gas_limit = vmState.blockHeader.gasLimit
|
|
|
|
# vmState.difficulty now unused
|
|
|
|
host.txContext.block_difficulty = vmState.blockHeader.difficulty.toEvmc
|
|
|
|
host.txContext.chain_id = vmState.chaindb.config.chainId.uint.u256.toEvmc
|
|
|
|
|
2021-05-20 09:15:00 +00:00
|
|
|
const use_evmc_glue = defined(evmc_enabled)
|
|
|
|
|
|
|
|
# When using the EVMC binary interface, each of the functions below is wrapped
|
|
|
|
# in another function that converts types to be compatible with the binary
|
|
|
|
# interface, and the functions below are not called directly. The conversions
|
|
|
|
# mostly just cast between byte-compatible types, so to avoid a redundant call
|
|
|
|
# layer, make the functions below `{.inline.}` when wrapped in this way.
|
|
|
|
when use_evmc_glue:
|
|
|
|
{.push inline.}
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc accountExists(host: TransactionHost, address: HostAddress): bool {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
if host.vmState.fork >= FkSpurious:
|
|
|
|
not host.vmState.readOnlyStateDB.isDeadAccount(address)
|
|
|
|
else:
|
|
|
|
host.vmState.readOnlyStateDB.accountExists(address)
|
|
|
|
|
|
|
|
# TODO: Why is `address` an argument in `getStorage`, `setStorage` and
|
|
|
|
# `selfDestruct`, if an EVM is only allowed to do these things to its own
|
|
|
|
# contract account and the host always knows which account?
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getStorage(host: TransactionHost, address: HostAddress, key: HostKey): HostValue {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
host.vmState.readOnlyStateDB.getStorage(address, key)
|
|
|
|
|
Transaction: Calculate EIP-1283/2200/2929 gas refund in `setStorage`
Make the host service `setStorage` calculate the gas refund itself, instead of
depending on EVM internals.
In EVMC, host `setStorage` is responsible for adding the gas refund using the
rules of EIP-1283 (Constantinople), EIP-2200 (Istanbul) or EIP-2929 (Berlin).
It is not obvious that the host must do it from EVMC documentation, but it's
how it has to be. Note, this is very different from the gas _cost_, which the
host does not calculate.
Gas refund doesn't affect computation. It is applied after the whole
transaction is complete, so it can be tracked on the host or EVM side. But
`setStorage` doesn't return enough information for the EVM to calculate the
refund, so the host must do it when `setStorage` is used.
For now, this continues using Nimbus `Computation` just to hold the gas refund,
to fit around existing structures and get new EVMC working. But the host can't
keep using `Computation`, so gas refund will be moved out of it in due course.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-24 08:53:53 +00:00
|
|
|
const
|
|
|
|
# EIP-1283
|
|
|
|
SLOAD_GAS_CONSTANTINOPLE = 200
|
|
|
|
# EIP-2200
|
|
|
|
SSTORE_SET_GAS = 20000
|
|
|
|
SSTORE_RESET_GAS = 5000
|
|
|
|
SSTORE_CLEARS_SCHEDULE = 15000
|
|
|
|
SLOAD_GAS_ISTANBUL = 800
|
|
|
|
# EIP-2929
|
|
|
|
WARM_STORAGE_READ_COST = 100
|
|
|
|
COLD_SLOAD_COST = 2100
|
|
|
|
COLD_ACCOUNT_ACCESS_COST = 2600
|
|
|
|
|
|
|
|
func storageModifiedAgainRefund(originalValue, oldValue, value: HostValue,
|
|
|
|
fork: Fork): int {.inline.} =
|
|
|
|
# Calculate `SSTORE` refund according to EIP-2929 (Berlin),
|
|
|
|
# EIP-2200 (Istanbul) or EIP-1283 (Constantinople only).
|
|
|
|
result = 0
|
|
|
|
if value == originalValue:
|
|
|
|
result = if value.isZero: SSTORE_SET_GAS
|
|
|
|
elif fork >= FkBerlin: SSTORE_RESET_GAS - COLD_SLOAD_COST
|
|
|
|
else: SSTORE_RESET_GAS
|
|
|
|
let SLOAD_GAS = if fork >= FkBerlin: WARM_STORAGE_READ_COST
|
|
|
|
elif fork >= FkIstanbul: SLOAD_GAS_ISTANBUL
|
|
|
|
else: SLOAD_GAS_CONSTANTINOPLE
|
|
|
|
result -= SLOAD_GAS
|
|
|
|
if not originalValue.isZero:
|
|
|
|
if value.isZero:
|
|
|
|
result += SSTORE_CLEARS_SCHEDULE
|
|
|
|
elif oldValue.isZero:
|
|
|
|
result -= SSTORE_CLEARS_SCHEDULE
|
|
|
|
|
|
|
|
proc setStorage(host: TransactionHost, address: HostAddress,
|
|
|
|
key: HostKey, value: HostValue): EvmcStorageStatus {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
let db = host.vmState.readOnlyStateDB
|
|
|
|
let oldValue = db.getStorage(address, key)
|
|
|
|
|
|
|
|
if oldValue == value:
|
|
|
|
return EVMC_STORAGE_UNCHANGED
|
|
|
|
|
|
|
|
host.vmState.mutateStateDB:
|
|
|
|
db.setStorage(address, key, value)
|
|
|
|
|
|
|
|
if host.vmState.fork >= FkIstanbul or host.vmState.fork == FkConstantinople:
|
|
|
|
let originalValue = db.getCommittedStorage(address, key)
|
|
|
|
if oldValue != originalValue:
|
Transaction: Calculate EIP-1283/2200/2929 gas refund in `setStorage`
Make the host service `setStorage` calculate the gas refund itself, instead of
depending on EVM internals.
In EVMC, host `setStorage` is responsible for adding the gas refund using the
rules of EIP-1283 (Constantinople), EIP-2200 (Istanbul) or EIP-2929 (Berlin).
It is not obvious that the host must do it from EVMC documentation, but it's
how it has to be. Note, this is very different from the gas _cost_, which the
host does not calculate.
Gas refund doesn't affect computation. It is applied after the whole
transaction is complete, so it can be tracked on the host or EVM side. But
`setStorage` doesn't return enough information for the EVM to calculate the
refund, so the host must do it when `setStorage` is used.
For now, this continues using Nimbus `Computation` just to hold the gas refund,
to fit around existing structures and get new EVMC working. But the host can't
keep using `Computation`, so gas refund will be moved out of it in due course.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-24 08:53:53 +00:00
|
|
|
# Gas refund for `MODIFIED_AGAIN` (EIP-1283/2200/2929 only).
|
|
|
|
let refund = storageModifiedAgainRefund(originalValue, oldValue, value,
|
|
|
|
host.vmState.fork)
|
|
|
|
# TODO: Refund depends on `Computation` at the moment.
|
|
|
|
if refund != 0:
|
|
|
|
host.computation.gasMeter.refundGas(refund)
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
return EVMC_STORAGE_MODIFIED_AGAIN
|
|
|
|
|
|
|
|
if oldValue.isZero:
|
|
|
|
return EVMC_STORAGE_ADDED
|
|
|
|
elif value.isZero:
|
Transaction: Calculate EIP-1283/2200/2929 gas refund in `setStorage`
Make the host service `setStorage` calculate the gas refund itself, instead of
depending on EVM internals.
In EVMC, host `setStorage` is responsible for adding the gas refund using the
rules of EIP-1283 (Constantinople), EIP-2200 (Istanbul) or EIP-2929 (Berlin).
It is not obvious that the host must do it from EVMC documentation, but it's
how it has to be. Note, this is very different from the gas _cost_, which the
host does not calculate.
Gas refund doesn't affect computation. It is applied after the whole
transaction is complete, so it can be tracked on the host or EVM side. But
`setStorage` doesn't return enough information for the EVM to calculate the
refund, so the host must do it when `setStorage` is used.
For now, this continues using Nimbus `Computation` just to hold the gas refund,
to fit around existing structures and get new EVMC working. But the host can't
keep using `Computation`, so gas refund will be moved out of it in due course.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-24 08:53:53 +00:00
|
|
|
# Gas refund for `DELETED` (all forks).
|
|
|
|
# TODO: Refund depends on `Computation` at the moment.
|
|
|
|
host.computation.gasMeter.refundGas(SSTORE_CLEARS_SCHEDULE)
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
return EVMC_STORAGE_DELETED
|
|
|
|
else:
|
|
|
|
return EVMC_STORAGE_MODIFIED
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getBalance(host: TransactionHost, address: HostAddress): HostBalance {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
host.vmState.readOnlyStateDB.getBalance(address)
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getCodeSize(host: TransactionHost, address: HostAddress): HostSize {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
# TODO: Check this `HostSize`, it was copied as `uint` from other code.
|
|
|
|
# Note: Old `evmc_host` uses `getCode(address).len` instead.
|
|
|
|
host.vmState.readOnlyStateDB.getCodeSize(address).HostSize
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getCodeHash(host: TransactionHost, address: HostAddress): HostHash {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
let db = host.vmState.readOnlyStateDB
|
|
|
|
# TODO: Copied from `Computation`, but check if that code is wrong with
|
|
|
|
# `FkSpurious`, as it has different calls from `accountExists` above.
|
|
|
|
if not db.accountExists(address) or db.isEmptyAccount(address):
|
|
|
|
default(HostHash)
|
|
|
|
else:
|
|
|
|
db.getCodeHash(address)
|
|
|
|
|
|
|
|
proc copyCode(host: TransactionHost, address: HostAddress,
|
|
|
|
code_offset: HostSize, buffer_data: ptr byte,
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
buffer_size: HostSize): HostSize {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
# We must handle edge cases carefully to prevent overflows. `len` is signed
|
|
|
|
# type `int`, but `code_offset` and `buffer_size` are _unsigned_, and may
|
|
|
|
# have large values (deliberately if attacked) that exceed the range of `int`.
|
|
|
|
#
|
|
|
|
# Comparing signed and unsigned types is _unsafe_: A type-conversion will
|
|
|
|
# take place which breaks the comparison for some values. So here we use
|
|
|
|
# explicit type-conversions, always compare the same types, and always
|
|
|
|
# convert towards the type that cannot truncate because preceding checks have
|
|
|
|
# been used to reduce the possible value range.
|
|
|
|
#
|
|
|
|
# Note, when there is no code, `getCode` result is empty `seq`. It was `nil`
|
|
|
|
# when the DB was first implemented, due to Nim language changes since then.
|
|
|
|
var code: seq[byte] = host.vmState.readOnlyStateDB.getCode(address)
|
|
|
|
var safe_len: int = code.len # It's safe to assume >= 0.
|
|
|
|
|
|
|
|
if code_offset >= safe_len.HostSize:
|
|
|
|
return 0
|
|
|
|
let safe_offset = code_offset.int
|
|
|
|
safe_len = safe_len - safe_offset
|
|
|
|
|
|
|
|
if buffer_size < safe_len.HostSize:
|
|
|
|
safe_len = buffer_size.int
|
|
|
|
|
|
|
|
if safe_len > 0:
|
|
|
|
copyMem(buffer_data, code[safe_offset].addr, safe_len)
|
|
|
|
return safe_len.HostSize
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc selfDestruct(host: TransactionHost, address, beneficiary: HostAddress) {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
host.vmState.mutateStateDB:
|
|
|
|
let closingBalance = db.getBalance(address)
|
|
|
|
let beneficiaryBalance = db.getBalance(beneficiary)
|
|
|
|
|
|
|
|
# Transfer to beneficiary
|
|
|
|
db.setBalance(beneficiary, beneficiaryBalance + closingBalance)
|
|
|
|
|
|
|
|
# Zero balance of account being deleted.
|
|
|
|
# This must come after sending to the beneficiary in case the
|
|
|
|
# contract named itself as the beneficiary.
|
|
|
|
db.setBalance(address, 0.u256)
|
|
|
|
|
2021-05-24 08:53:53 +00:00
|
|
|
# TODO: Calling via `computation` is necessary to make some tests pass.
|
|
|
|
# Here's one that passes only with this:
|
|
|
|
# tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest487.json
|
|
|
|
# We can't keep using `computation` though.
|
|
|
|
host.computation.touchedAccounts.incl(beneficiary)
|
|
|
|
host.computation.selfDestructs.incl(address)
|
|
|
|
#host.touchedAccounts.incl(beneficiary)
|
|
|
|
#host.selfDestructs.incl(address)
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc call(host: TransactionHost, msg: EvmcMessage): EvmcResult {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
echo "**** Nested call not implemented ****"
|
|
|
|
return EvmcResult(status_code: EVMC_REJECTED)
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getTxContext(host: TransactionHost): EvmcTxContext {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
if not host.cachedTxContext:
|
|
|
|
host.setupTxContext()
|
|
|
|
host.cachedTxContext = true
|
|
|
|
return host.txContext
|
|
|
|
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
proc getBlockHash(host: TransactionHost, number: HostBlockNumber): HostHash {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
# TODO: Clean up the different messy block number types.
|
|
|
|
host.vmState.getAncestorHash(number.toBlockNumber)
|
|
|
|
|
|
|
|
proc emitLog(host: TransactionHost, address: HostAddress,
|
|
|
|
data: ptr byte, data_size: HostSize,
|
EVMC: Using `{.show.}` trace all calls from EVM to host services
When `show_tx_calls` is manually set to true, show all the calls from the EVM
to the host, including name, arguments and results.
For example this shows each call to `setStorage`, the key, value and storage
result. This output allows the externally-visible activity of an EVM to be
seen, and it's been useful for guessing what went wrong when a test fails.
In theory, if two EVMs show the same activity in this log, they should have the
same effect on account states, gas, etc. and the same final `roothash`
(which is the only value some tests check).
ps. Ideally we'd use `{.push show.}`...`{.pop.}`, just like with `inline`.
But we can't: https://github.com/nim-lang/Nim/issues/12867
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-21 05:24:09 +00:00
|
|
|
topics: ptr HostTopic, topics_count: HostSize) {.show.} =
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
var log: Log
|
|
|
|
# Note, this assumes the EVM ensures `data_size` and `topics_count` cannot be
|
|
|
|
# unreasonably large values. Largest `topics_count` should be 4 according to
|
|
|
|
# EVMC documentation, but we won't restrict it here.
|
|
|
|
if topics_count > 0:
|
|
|
|
let topicsArray = cast[ptr UncheckedArray[HostTopic]](topics)
|
|
|
|
let count = topics_count.int
|
|
|
|
log.topics = newSeq[Topic](count)
|
|
|
|
for i in 0 ..< count:
|
|
|
|
log.topics[i] = topicsArray[i]
|
|
|
|
|
2021-05-24 08:53:53 +00:00
|
|
|
if (data_size > 0):
|
|
|
|
log.data = newSeq[byte](data_size.int)
|
|
|
|
copyMem(log.data[0].addr, data, data_size.int)
|
|
|
|
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
log.address = address
|
2021-06-08 08:03:29 +00:00
|
|
|
|
|
|
|
# TODO: Calling via `computation` is necessary to makes some tests pass.
|
|
|
|
# Here's one that passes only with this:
|
|
|
|
# tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest583.json
|
|
|
|
# We can't keep using `computation` though.
|
|
|
|
host.computation.logEntries.add(log)
|
|
|
|
#host.logEntries.add(log)
|
Transaction: Add "host services", accessors to host state from EVM
This provides "host services", functions provided by the application to an EVM.
They are a key part of EVMC compatibility, but we will switch to using these
with "native" EVM as well.
These are functions like `getStorage`, `setStorage` and `emitLog` for accessing
the account state, because the EVM is not allowed direct access to the database.
This code is adapted from `nimbus/vm/evmc_host.nim` and other places, but there
is more emphasis on being host-side only, no dependency on the EVM or
`Computation` type. It uses `TransactionHost` and types in `host_types`.
These host services have two goals: To be compatible with EVMC, and to be a
good way for the Nimbus EVM to access the data it needs. In our new Nimbus
internal architecture, the EVM will only access the databases and other
application state via these host service functions.
The reason for containing the EVM like this, even "native" EVM, is that having
one good interface to the data makes it a lot easier to change how the database
works, which is on the roadmap.
These functions almost have EVMC signatures, but they are not binary compatible
with EVMC. (Binary compatibility is provided by another module). It would be
fine for Nimbus EVM to call these functions directly when linked directly.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-05-20 19:08:36 +00:00
|
|
|
|
2021-05-20 09:15:00 +00:00
|
|
|
when use_evmc_glue:
|
|
|
|
{.pop: inline.}
|
|
|
|
const included_from_host_services = true
|
|
|
|
include ./evmc_host_glue
|
|
|
|
else:
|
|
|
|
export
|
|
|
|
accountExists, getStorage, storage, getBalance, getCodeSize, getCodeHash,
|
|
|
|
copyCode, selfDestruct, getTxContext, call, getBlockHash, emitLog
|