nimbus-eth1/nimbus/transaction/evmc_host_glue.nim

141 lines
6.0 KiB
Nim
Raw Normal View History

# Nimbus - Binary compatibility on the host side of the EVMC API interface
#
# 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].}
when not declaredInScope(included_from_host_services):
{.error: "Do not import this file directly, import host_services instead".}
import evmc/evmc
template toHost(p: evmc_host_context): TransactionHost =
cast[TransactionHost](p)
proc accountExists(p: evmc_host_context, address: var evmc_address): c99bool {.cdecl.} =
toHost(p).accountExists(address.fromEvmc)
proc getStorage(p: evmc_host_context, address: var evmc_address,
key: var evmc_bytes32): evmc_bytes32 {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
toHost(p).getStorage(address.fromEvmc, key.flip256.fromEvmc).toEvmc.flip256
proc setStorage(p: evmc_host_context, address: var evmc_address,
key, value: var evmc_bytes32): evmc_storage_status {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
toHost(p).setStorage(address.fromEvmc, key.flip256.fromEvmc, value.flip256.fromEvmc)
proc getBalance(p: evmc_host_context,
address: var evmc_address): evmc_uint256be {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
toHost(p).getBalance(address.fromEvmc).toEvmc.flip256
proc getCodeSize(p: evmc_host_context,
address: var evmc_address): csize_t {.cdecl.} =
toHost(p).getCodeSize(address.fromEvmc)
proc getCodeHash(p: evmc_host_context,
address: var evmc_address): evmc_bytes32 {.cdecl.} =
toHost(p).getCodeHash(address.fromEvmc).toEvmc
proc copyCode(p: evmc_host_context, address: var evmc_address, code_offset: csize_t,
buffer_data: ptr byte, buffer_size: csize_t): csize_t {.cdecl.} =
toHost(p).copyCode(address.fromEvmc, code_offset, buffer_data, buffer_size)
proc selfDestruct(p: evmc_host_context, address,
beneficiary: var evmc_address) {.cdecl.} =
toHost(p).selfDestruct(address.fromEvmc, beneficiary.fromEvmc)
proc call(p: evmc_host_context, msg: var evmc_message): evmc_result {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
# This would contain `flip256`, but `call` is special. The C stack usage
# must be kept small for deeply nested EVM calls. To ensure small stack,
# `flip256` must be handled at `host_call_nested`, not here.
toHost(p).call(msg)
proc getTxContext(p: evmc_host_context): evmc_tx_context {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
# This would contain `flip256`, but due to this result being cached in
# `getTxContext`, it's better to do `flip256` when filling the cache.
toHost(p).getTxContext()
proc getBlockHash(p: evmc_host_context, number: int64): evmc_bytes32 {.cdecl.} =
# TODO: `HostBlockNumber` is 256-bit unsigned. It should be changed to match
# EVMC which is more sensible.
toHost(p).getBlockHash(number.uint64.u256).toEvmc
proc emitLog(p: evmc_host_context, address: var evmc_address,
data: ptr byte, data_size: csize_t,
topics: ptr evmc_bytes32, topics_count: csize_t) {.cdecl.} =
toHost(p).emitLog(address.fromEvmc, data, data_size,
cast[ptr HostTopic](topics), topics_count)
proc accessAccount(p: evmc_host_context,
address: var evmc_address): evmc_access_status {.cdecl.} =
toHost(p).accessAccount(address.fromEvmc)
proc accessStorage(p: evmc_host_context, address: var evmc_address,
key: var evmc_bytes32): evmc_access_status {.cdecl.} =
EVMC: Byte-endian conversions for 256-bit numeric values Perform byte-endian conversion for 256-bit numeric values, but not 256-bit hashes. These conversions are necessary for EVMC binary compatibility. In new EVMC, all host-side conversions are explicit, calling `flip256`. These conversions are performed in the EVMC "glue" code, which deals with the binary interface, so the host services aren't aware of conversions. We intend to skip these conversions when Nimbus host calls Nimbus EVM, even when it's a shared library, using a negotiated EVMC extension. But for now we're focused on correctness and cross-validation with third party EVMs. The overhead of endian conversion is not too high because most EVMC host calls access the database anyway. `getTxContext` does not, so the conversions from that are cached here. Also, well-optimised EVMs don't call it often. It is arguable whether endian conversion should occur for storage slots (`key`). In favour of no conversion: Slot keys are 32-byte blobs, and this is clear in the EVMC definition where slot keys are `evmc_bytes32` (not `evmc_uint256be`), meaning treating as a number is _not_ expected by EVMC. Although they are often small numbers, sometimes they are a hash from the contract code plus a number. Slot keys are hashed on the host side with Keccak256 before any database calls, so the host side does not look at them numerically. In favour of conversion: They are often small numbers and it is helpful to log them as such, rather than a long string of zero digits with 1-2 non-zero. The representation in JSON has leading zeros removed, like a number rather than a 32-byte blob. There is also an interesting space optimisation when the keys are used unhashed in storage. Nimbus currently treats slot keys on the host side as numbers, and the tests pass when endian conversion is done. So to remain consistent with other parts of Nimbus we convert slot keys. Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-11-24 15:54:59 +00:00
toHost(p).accessStorage(address.fromEvmc, key.flip256.fromEvmc)
let hostInterface = evmc_host_interface(
account_exists: accountExists,
get_storage: getStorage,
set_storage: setStorage,
get_balance: getBalance,
get_code_size: getCodeSize,
get_code_hash: getCodeHash,
copy_code: copyCode,
selfdestruct: selfDestruct,
call: call,
get_tx_context: getTxContext,
get_block_hash: getBlockHash,
emit_log: emitLog,
access_account: accessAccount,
access_storage: accessStorage,
)
# The built-in Nimbus EVM, via imported C function.
proc evmc_create_nimbus_evm(): ptr evmc_vm {.cdecl, importc.}
# Pull in the definition of the above function because we're not building it as
# a separate library yet.
import ./evmc_vm_glue
proc evmcExecComputation*(host: TransactionHost): EvmcResult {.inline.} =
host.showCallEntry(host.msg)
let vm = evmc_create_nimbus_evm()
if vm.isNil:
echo "Warning: No EVM"
# Nim defaults are fine for all other fields in the result object.
result = EvmcResult(status_code: EVMC_INTERNAL_ERROR)
host.showCallReturn(result)
return
let hostContext = cast[evmc_host_context](host)
host.hostInterface = hostInterface.unsafeAddr
# Without `{.gcsafe.}:` here, the call via `vm.execute` results in a Nim
# compile-time error in a far away function. Starting here, a cascade of
# warnings takes place: "Warning: '...' is not GC-safe as it performs an
# indirect call here [GCUnsafe2]", then a list of "Warning: '...' is not
# GC-safe as it calls '...'" at each function up the call stack, to a high
# level function `persistBlocks` where it terminates compilation as an error
# instead of a warning.
#
# It is tempting to annotate all EVMC API functions with `{.cdecl, gcsafe.}`,
# overriding the function signatures from the Nim EVMC module. Perhaps we
# will do that, though it's conceptually dubious, as the two sides of the
# EVMC ABI live in different GC worlds (when loaded as a shared library with
# its own Nim runtime), very similar to calling between threads.
#
# TODO: But wait: Why does the Nim EVMC test program compile fine without
# any `gcsafe`, even with `--threads:on`?
{.gcsafe.}:
result = vm.execute(vm, hostInterface.unsafeAddr, hostContext,
evmc_revision(host.vmState.fork), host.msg,
if host.code.len > 0: host.code[0].unsafeAddr else: nil,
host.code.len.csize_t)
host.showCallReturn(result)