nimbus-eth1/nimbus/transaction/host_call_nested.nim

159 lines
6.7 KiB
Nim
Raw Normal View History

# 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: [].}
import
eth/common/eth_types,
stew/ptrops,
stint,
2022-12-02 04:39:12 +00:00
".."/[vm_types, vm_computation],
../utils/utils,
"."/[host_types, host_trace]
proc evmcResultRelease(res: var EvmcResult) {.cdecl, gcsafe.} =
dealloc(res.output_data)
proc beforeExecCreateEvmcNested(host: TransactionHost,
m: EvmcMessage): Computation =
# TODO: use evmc_message to avoid copy
let childMsg = Message(
kind: CallKind(m.kind.ord),
depth: m.depth,
gas: m.gas,
sender: m.sender.fromEvmc,
value: m.value.fromEvmc,
data: @(makeOpenArray(m.inputData, m.inputSize.int))
)
return newComputation(host.vmState, false, childMsg,
Transaction: EVMC fix, `CREATE2` salt is a 256-bit blob not a number This changes fixes a bug in `CREATE2` ops when used with EVMC. Because it changes the salt type, it affects non-EVMC code as well. The salt was passed through EVMC with the wrong byte order, although this went unnoticed as the Nimbus host flipped the byte order before using it. This was found when running Nimbus with third-party EVM, ["evmone"](https://github.com/ethereum/evmone). There are different ways to remedy this. If treated as a number, Nimbus EVM would byte-flip the value when calling EVMC, then Nimbus host would flip the received value. Finally, it would be flipped a third time when generating the address in `generateSafeAddress`. The first two flips can be eliminated by negotiation (like other numbers), but there would always be one flip. As a bit pattern, Nimbus EVM would flip the same way it does when dealing with hashes on the stack (e.g. with `getBlockHash`). Nimbus host wouldn't flip at all - and when using third-party EVMs there would be no flips in Nimbus. Because this value is not for arithmetic, any bit pattern is valid, and there shouldn't be any flips when using a third-party EVM, the bit-pattern interpretation is favoured. The only flip is done in Nimbus EVM (and might be eliminated in an optimised version). As suggested, we'll define a new "opaque 256 bits" type to hold this value. (Similar to `Hash256`, but the salt isn't necessarily a hash.) Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-06-09 22:32:42 +00:00
cast[ContractSalt](m.create2_salt))
proc afterExecCreateEvmcNested(host: TransactionHost, child: Computation,
res: var EvmcResult) {.inline.} =
if not child.shouldBurnGas:
res.gas_left = child.gasMeter.gasRemaining
if child.isSuccess:
host.computation.merge(child)
res.status_code = EVMC_SUCCESS
res.create_address = child.msg.contractAddress.toEvmc
else:
res.status_code = child.statusCode
if child.output.len > 0:
# TODO: can we move the ownership of seq to raw pointer?
res.output_size = child.output.len.uint
res.output_data = cast[ptr byte](alloc(child.output.len))
copyMem(res.output_data, child.output[0].addr, child.output.len)
res.release = evmcResultRelease
proc beforeExecCallEvmcNested(host: TransactionHost,
m: EvmcMessage): Computation {.inline.} =
let childMsg = Message(
kind: CallKind(m.kind.ord),
depth: m.depth,
gas: m.gas,
sender: m.sender.fromEvmc,
codeAddress: m.code_address.fromEvmc,
contractAddress: if m.kind == EVMC_CALL:
m.recipient.fromEvmc
else:
host.computation.msg.contractAddress,
value: m.value.fromEvmc,
data: @(makeOpenArray(m.inputData, m.inputSize.int)),
flags: m.flags,
)
return newComputation(host.vmState, false, childMsg)
proc afterExecCallEvmcNested(host: TransactionHost, child: Computation,
res: var EvmcResult) {.inline.} =
if not child.shouldBurnGas:
res.gas_left = child.gasMeter.gasRemaining
if child.isSuccess:
host.computation.merge(child)
res.status_code = EVMC_SUCCESS
else:
res.status_code = child.statusCode
if child.output.len > 0:
# TODO: can we move the ownership of seq to raw pointer?
res.output_size = child.output.len.uint
res.output_data = cast[ptr byte](alloc(child.output.len))
copyMem(res.output_data, child.output[0].addr, child.output.len)
res.release = evmcResultRelease
# The next three functions are designed so `callEvmcNested` uses very small C
# stack usage for each level of nested EVM calls.
#
# To keep the C stack usage small when there are deeply nested EVM calls,
# `callEvmcNested` must use as little stack as possible, going from the EVM
# which calls it to the nested EVM which it calls.
#
# First, `callEvmcNested` itself is `template` so it is inlined to the caller
# at Nim level, not C level. Only at Nim level is inlining guaranteed across
# `import`. This saves a C stack frame, which matters because some C compilers
# reserve space for 1-3 copies of the large `EvmcResult` return value.
#
# Second, the complicated parts of preparation and return are done in
# out-of-line functions `beforeExecEvmcNested` and `afterExecEvmcNested`. They
# are annotated with `{.noinline.}` to make sure they are out-of-line. The
# annotation ensures they don't contribute to the stack frame of
# `callEvmcNested`, because otherwise the compiler can optimistically inline.
# (Even across modules when using `-flto`).
#
# The functions `beforeExecEvmcNested` and `afterExecEvmcNested` can use as
# much stack as they like.
proc beforeExecEvmcNested(host: TransactionHost, msg: EvmcMessage): Computation
# This function must be declared with `{.noinline.}` to make sure it doesn't
# contribute to the stack frame of `callEvmcNested` below.
{.noinline, gcsafe, raises: [ValueError].} =
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
# `call` is special. Most host functions do `flip256` in `evmc_host_glue`
# and `show` in `host_services`, but `call` needs to minimise C stack used
# by nested EVM calls. Just `flip256` in glue's `call` adds a lot of
# stack: +65% in tests, enough to blow our 750kiB test stack target and
# crash. Easily avoided by doing `flip256` and `show` out-of-line here.
var msg = msg # Make a local copy that's ok to modify.
msg.value = flip256(msg.value)
host.showCallEntry(msg)
let c = if msg.kind == EVMC_CREATE or msg.kind == EVMC_CREATE2:
beforeExecCreateEvmcNested(host, msg)
else:
beforeExecCallEvmcNested(host, msg)
when defined(evmc_enabled):
c.host.init(cast[ptr nimbus_host_interface](host.hostInterface),
cast[typeof(c.host.context)](host))
host.saveComputation.add(host.computation)
host.computation = c
return c
proc afterExecEvmcNested(host: TransactionHost, child: Computation,
kind: EvmcCallKind): EvmcResult
# This function must be declared with `{.noinline.}` to make sure it doesn't
# contribute to the stack frame of `callEvmcNested` below.
{.noinline, gcsafe, raises: [ValueError].} =
host.computation = host.saveComputation[^1]
host.saveComputation[^1] = nil
host.saveComputation.setLen(host.saveComputation.len - 1)
if kind == EVMC_CREATE or kind == EVMC_CREATE2:
afterExecCreateEvmcNested(host, child, result)
else:
afterExecCallEvmcNested(host, child, result)
host.showCallReturn(result, kind.isCreate)
template callEvmcNested*(host: TransactionHost, msg: EvmcMessage): EvmcResult =
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
# `call` is special. The C stack usage must be kept small for deeply nested
# EVM calls. To ensure small stack, this function must use `template` to
# inline at Nim level (same for `host.call(msg)`). `{.inline.}` is not good
# enough. Due to object return it ends up using a lot more stack. (Note
# that template parameters `host` and `msg` are multiple-evaluated here;
# simple expressions must be used when calling.)
let child = beforeExecEvmcNested(host, msg)
child.execCallOrCreate()
afterExecEvmcNested(host, child, msg.kind)