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>
This commit is contained in:
parent
df29b98079
commit
6ef9bfd21b
|
@ -21,15 +21,15 @@ proc accountExists(p: evmc_host_context, address: var evmc_address): c99bool {.c
|
|||
|
||||
proc getStorage(p: evmc_host_context, address: var evmc_address,
|
||||
key: var evmc_bytes32): evmc_bytes32 {.cdecl.} =
|
||||
toHost(p).getStorage(address.fromEvmc, key.fromEvmc).toEvmc
|
||||
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.} =
|
||||
toHost(p).setStorage(address.fromEvmc, key.fromEvmc, value.fromEvmc)
|
||||
toHost(p).setStorage(address.fromEvmc, key.flip256.fromEvmc, value.flip256.fromEvmc)
|
||||
|
||||
proc getBalance(p: evmc_host_context,
|
||||
address: var evmc_address): evmc_uint256be {.cdecl.} =
|
||||
toHost(p).getBalance(address.fromEvmc).toEvmc
|
||||
toHost(p).getBalance(address.fromEvmc).toEvmc.flip256
|
||||
|
||||
proc getCodeSize(p: evmc_host_context,
|
||||
address: var evmc_address): csize_t {.cdecl.} =
|
||||
|
@ -48,9 +48,14 @@ proc selfDestruct(p: evmc_host_context, address,
|
|||
toHost(p).selfDestruct(address.fromEvmc, beneficiary.fromEvmc)
|
||||
|
||||
proc call(p: evmc_host_context, msg: var evmc_message): evmc_result {.cdecl.} =
|
||||
# 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.} =
|
||||
# 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.} =
|
||||
|
@ -70,7 +75,7 @@ proc accessAccount(p: evmc_host_context,
|
|||
|
||||
proc accessStorage(p: evmc_host_context, address: var evmc_address,
|
||||
key: var evmc_bytes32): evmc_access_status {.cdecl.} =
|
||||
toHost(p).accessStorage(address.fromEvmc, key.fromEvmc)
|
||||
toHost(p).accessStorage(address.fromEvmc, key.flip256.fromEvmc)
|
||||
|
||||
let hostInterface = evmc_host_interface(
|
||||
account_exists: accountExists,
|
||||
|
|
|
@ -111,6 +111,13 @@ 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.} =
|
||||
# `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)
|
||||
|
@ -138,9 +145,12 @@ proc afterExecEvmcNested(host: TransactionHost, child: Computation,
|
|||
host.showCallReturn(result, kind.isCreate)
|
||||
|
||||
template callEvmcNested*(host: TransactionHost, msg: EvmcMessage): EvmcResult =
|
||||
# This function must be declared `template` to ensure it is inlined at Nim
|
||||
# level to its caller across `import`. C level `{.inline.}` won't do this.
|
||||
# Note that template parameters `host` and `msg` are multiple-evaluated.
|
||||
# `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)
|
||||
|
|
|
@ -65,6 +65,15 @@ proc setupTxContext(host: TransactionHost) =
|
|||
host.txContext.chain_id = vmState.chaindb.config.chainId.uint.u256.toEvmc
|
||||
host.txContext.block_base_fee = vmState.blockHeader.baseFee.toEvmc
|
||||
|
||||
# Most host functions do `flip256` in `evmc_host_glue`, but due to this
|
||||
# result being cached, it's better to do `flip256` when filling the cache.
|
||||
host.txContext.tx_gas_price = flip256(host.txContext.tx_gas_price)
|
||||
host.txContext.block_difficulty = flip256(host.txContext.block_difficulty)
|
||||
host.txContext.chain_id = flip256(host.txContext.chain_id)
|
||||
host.txContext.block_base_fee = flip256(host.txContext.block_base_fee)
|
||||
|
||||
host.cachedTxContext = true
|
||||
|
||||
const use_evmc_glue = defined(evmc_enabled)
|
||||
|
||||
# When using the EVMC binary interface, each of the functions below is wrapped
|
||||
|
@ -243,7 +252,6 @@ template call(host: TransactionHost, msg: EvmcMessage): EvmcResult =
|
|||
proc getTxContext(host: TransactionHost): EvmcTxContext {.show.} =
|
||||
if not host.cachedTxContext:
|
||||
host.setupTxContext()
|
||||
host.cachedTxContext = true
|
||||
return host.txContext
|
||||
|
||||
proc getBlockHash(host: TransactionHost, number: HostBlockNumber): HostHash {.show.} =
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
import eth/common, stint, evmc/evmc, ../utils
|
||||
|
||||
const
|
||||
evmc_native* {.booldefine.} = true
|
||||
evmc_native* {.booldefine.} = false
|
||||
|
||||
func toEvmc*(a: EthAddress): evmc_address {.inline.} =
|
||||
cast[evmc_address](a)
|
||||
|
|
Loading…
Reference in New Issue