2021-04-30 09:33:14 +00:00
|
|
|
# Nimbus - Various ways of calling the EVM
|
|
|
|
#
|
2024-02-15 02:57:05 +00:00
|
|
|
# Copyright (c) 2018-2024 Status Research & Development GmbH
|
2021-04-30 09:33:14 +00:00
|
|
|
# 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.
|
|
|
|
|
2023-02-14 20:27:17 +00:00
|
|
|
{.push raises: [].}
|
|
|
|
|
2021-04-30 09:33:14 +00:00
|
|
|
import
|
2022-05-09 14:04:48 +00:00
|
|
|
chronicles,
|
Added basic async capabilities for vm2. (#1260)
* Added basic async capabilities for vm2.
This is a whole new Git branch, not the same one as last time
(https://github.com/status-im/nimbus-eth1/pull/1250) - there wasn't
much worth salvaging. Main differences:
I didn't do the "each opcode has to specify an async handler" junk
that I put in last time. Instead, in oph_memory.nim you can see
sloadOp calling asyncChainTo and passing in an async operation.
That async operation is then run by the execCallOrCreate (or
asyncExecCallOrCreate) code in interpreter_dispatch.nim.
In the test code, the (previously existing) macro called "assembler"
now allows you to add a section called "initialStorage", specifying
fake data to be used by the EVM computation run by that test. (In
the long run we'll obviously want to write tests that for-real use
the JSON-RPC API to asynchronously fetch data; for now, this was
just an expedient way to write a basic unit test that exercises the
async-EVM code pathway.)
There's also a new macro called "concurrentAssemblers" that allows
you to write a test that runs multiple assemblers concurrently (and
then waits for them all to finish). There's one example test using
this, in test_op_memory_lazy.nim, though you can't actually see it
doing so unless you uncomment some echo statements in
async_operations.nim (in which case you can see the two concurrently
running EVM computations each printing out what they're doing, and
you'll see that they interleave).
A question: is it possible to make EVMC work asynchronously? (For
now, this code compiles and "make test" passes even if ENABLE_EVMC
is turned on, but it doesn't actually work asynchronously, it just
falls back on doing the usual synchronous EVMC thing. See
FIXME-asyncAndEvmc.)
* Moved the AsyncOperationFactory to the BaseVMState object.
* Made the AsyncOperationFactory into a table of fn pointers.
Also ditched the plain-data Vm2AsyncOperation type; it wasn't
really serving much purpose. Instead, the pendingAsyncOperation
field directly contains the Future.
* Removed the hasStorage idea.
It's not the right solution to the "how do we know whether we
still need to fetch the storage value or not?" problem. I
haven't implemented the right solution yet, but at least
we're better off not putting in a wrong one.
* Added/modified/removed some comments.
(Based on feedback on the PR.)
* Removed the waitFor from execCallOrCreate.
There was some back-and-forth in the PR regarding whether nested
waitFor calls are acceptable:
https://github.com/status-im/nimbus-eth1/pull/1260#discussion_r998587449
The eventual decision was to just change the waitFor to a doAssert
(since we probably won't want this extra functionality when running
synchronously anyway) to make sure that the Future is already
finished.
2022-11-01 15:35:46 +00:00
|
|
|
chronos,
|
2023-08-04 11:10:09 +00:00
|
|
|
eth/common/eth_types_rlp,
|
2024-06-17 07:56:39 +00:00
|
|
|
../evm/[types, state, internals],
|
2023-12-12 19:12:56 +00:00
|
|
|
../db/ledger,
|
2022-12-02 04:39:12 +00:00
|
|
|
../common/common,
|
2024-06-07 08:24:32 +00:00
|
|
|
../evm/evm_errors,
|
2024-04-16 12:52:07 +00:00
|
|
|
../rpc/params,
|
2021-05-17 11:39:52 +00:00
|
|
|
./call_common
|
2021-04-30 09:33:14 +00:00
|
|
|
|
2023-10-31 05:54:57 +00:00
|
|
|
export
|
|
|
|
call_common
|
|
|
|
|
2024-06-07 08:24:32 +00:00
|
|
|
proc rpcCallEvm*(args: TransactionArgs,
|
|
|
|
header: common.BlockHeader,
|
|
|
|
com: CommonRef): EvmResult[CallResult] =
|
2021-10-26 15:18:08 +00:00
|
|
|
const globalGasCap = 0 # TODO: globalGasCap should configurable by user
|
2024-04-16 12:52:07 +00:00
|
|
|
let topHeader = common.BlockHeader(
|
2022-01-18 16:19:32 +00:00
|
|
|
parentHash: header.blockHash,
|
2023-10-18 02:16:11 +00:00
|
|
|
timestamp: EthTime.now(),
|
2024-06-14 07:31:08 +00:00
|
|
|
gasLimit: 0.GasInt, ## ???
|
|
|
|
baseFeePerGas: Opt.none UInt256, ## ???
|
|
|
|
)
|
2024-06-07 08:24:32 +00:00
|
|
|
let vmState = ? BaseVMState.new(topHeader, com)
|
2024-06-14 07:31:08 +00:00
|
|
|
let params = ? toCallParams(vmState, args, globalGasCap, header.baseFeePerGas)
|
2021-10-26 15:18:08 +00:00
|
|
|
|
2024-06-05 20:52:04 +00:00
|
|
|
var dbTx = com.db.newTransaction()
|
2021-10-26 15:18:08 +00:00
|
|
|
defer: dbTx.dispose() # always dispose state changes
|
|
|
|
|
2024-06-07 08:24:32 +00:00
|
|
|
ok(runComputation(params))
|
2021-10-26 15:18:08 +00:00
|
|
|
|
2024-04-16 12:52:07 +00:00
|
|
|
proc rpcCallEvm*(args: TransactionArgs,
|
|
|
|
header: common.BlockHeader,
|
2024-03-21 11:24:32 +00:00
|
|
|
com: CommonRef,
|
2024-06-07 08:24:32 +00:00
|
|
|
vmState: BaseVMState): EvmResult[CallResult] =
|
2024-03-21 11:24:32 +00:00
|
|
|
const globalGasCap = 0 # TODO: globalGasCap should configurable by user
|
2024-06-14 07:31:08 +00:00
|
|
|
let params = ? toCallParams(vmState, args, globalGasCap, header.baseFeePerGas)
|
2024-03-21 11:24:32 +00:00
|
|
|
|
2024-06-05 20:52:04 +00:00
|
|
|
var dbTx = com.db.newTransaction()
|
2024-03-21 11:24:32 +00:00
|
|
|
defer: dbTx.dispose() # always dispose state changes
|
|
|
|
|
2024-06-07 08:24:32 +00:00
|
|
|
ok(runComputation(params))
|
2024-04-16 12:52:07 +00:00
|
|
|
|
|
|
|
proc rpcEstimateGas*(args: TransactionArgs,
|
|
|
|
header: common.BlockHeader,
|
2024-06-07 08:24:32 +00:00
|
|
|
com: CommonRef, gasCap: GasInt): EvmResult[GasInt] =
|
2021-10-26 15:18:08 +00:00
|
|
|
# Binary search the gas requirement, as it may be higher than the amount used
|
2024-04-16 12:52:07 +00:00
|
|
|
let topHeader = common.BlockHeader(
|
2022-01-18 16:19:32 +00:00
|
|
|
parentHash: header.blockHash,
|
2023-10-18 02:16:11 +00:00
|
|
|
timestamp: EthTime.now(),
|
2024-06-14 07:31:08 +00:00
|
|
|
gasLimit: 0.GasInt, ## ???
|
|
|
|
baseFeePerGas: Opt.none UInt256, ## ???
|
|
|
|
)
|
2024-06-07 08:24:32 +00:00
|
|
|
let vmState = ? BaseVMState.new(topHeader, com)
|
2024-07-04 13:48:36 +00:00
|
|
|
let fork = vmState.fork
|
2021-10-26 15:18:08 +00:00
|
|
|
let txGas = gasFees[fork][GasTransaction] # txGas always 21000, use constants?
|
2024-06-14 07:31:08 +00:00
|
|
|
var params = ? toCallParams(vmState, args, gasCap, header.baseFeePerGas)
|
2021-10-26 15:18:08 +00:00
|
|
|
|
2021-05-03 08:08:11 +00:00
|
|
|
var
|
2021-10-26 15:18:08 +00:00
|
|
|
lo : GasInt = txGas - 1
|
2024-04-16 12:52:07 +00:00
|
|
|
hi : GasInt = GasInt args.gas.get(0.Quantity)
|
2021-10-26 15:18:08 +00:00
|
|
|
cap: GasInt
|
|
|
|
|
2024-06-05 20:52:04 +00:00
|
|
|
var dbTx = com.db.newTransaction()
|
2021-10-26 15:18:08 +00:00
|
|
|
defer: dbTx.dispose() # always dispose state changes
|
|
|
|
|
|
|
|
# Determine the highest gas limit can be used during the estimation.
|
|
|
|
if hi < txGas:
|
|
|
|
# block's gasLimit act as the gas ceiling
|
|
|
|
hi = header.gasLimit
|
|
|
|
|
|
|
|
# Normalize the max fee per gas the call is willing to spend.
|
2024-04-16 12:52:07 +00:00
|
|
|
var feeCap = GasInt args.gasPrice.get(0.Quantity)
|
|
|
|
if args.gasPrice.isSome and
|
|
|
|
(args.maxFeePerGas.isSome or args.maxPriorityFeePerGas.isSome):
|
2024-06-07 08:24:32 +00:00
|
|
|
return err(evmErr(EvmInvalidParam))
|
2024-04-16 12:52:07 +00:00
|
|
|
elif args.maxFeePerGas.isSome:
|
|
|
|
feeCap = GasInt args.maxFeePerGas.get
|
2021-10-26 15:18:08 +00:00
|
|
|
|
|
|
|
# Recap the highest gas limit with account's available balance.
|
|
|
|
if feeCap > 0:
|
2024-04-16 12:52:07 +00:00
|
|
|
if args.source.isNone:
|
2024-06-07 08:24:32 +00:00
|
|
|
return err(evmErr(EvmInvalidParam))
|
2021-10-26 15:18:08 +00:00
|
|
|
|
2024-04-16 12:52:07 +00:00
|
|
|
let balance = vmState.readOnlyStateDB.getBalance(ethAddr args.source.get)
|
2021-10-26 15:18:08 +00:00
|
|
|
var available = balance
|
2024-04-16 12:52:07 +00:00
|
|
|
if args.value.isSome:
|
|
|
|
let value = args.value.get
|
2021-10-26 15:18:08 +00:00
|
|
|
if value > available:
|
2024-06-07 08:24:32 +00:00
|
|
|
return err(evmErr(EvmInvalidParam))
|
2021-10-26 15:18:08 +00:00
|
|
|
available -= value
|
|
|
|
|
|
|
|
let allowance = available div feeCap.u256
|
|
|
|
# If the allowance is larger than maximum GasInt, skip checking
|
|
|
|
if allowance < high(GasInt).u256 and hi > allowance.truncate(GasInt):
|
2024-04-16 12:52:07 +00:00
|
|
|
let transfer = args.value.get(0.u256)
|
2021-10-26 15:18:08 +00:00
|
|
|
warn "Gas estimation capped by limited funds", original=hi, balance,
|
|
|
|
sent=transfer, maxFeePerGas=feeCap, fundable=allowance
|
|
|
|
hi = allowance.truncate(GasInt)
|
|
|
|
|
|
|
|
# Recap the highest gas allowance with specified gasCap.
|
|
|
|
if gasCap != 0 and hi > gasCap:
|
|
|
|
warn "Caller gas above allowance, capping", requested=hi, cap=gasCap
|
|
|
|
hi = gasCap
|
|
|
|
|
|
|
|
cap = hi
|
2023-06-24 13:56:44 +00:00
|
|
|
let intrinsicGas = intrinsicGas(params, vmState)
|
2021-10-26 15:18:08 +00:00
|
|
|
|
|
|
|
# Create a helper to check if a gas allowance results in an executable transaction
|
2024-06-07 08:24:32 +00:00
|
|
|
proc executable(gasLimit: GasInt): EvmResult[bool] =
|
2021-10-26 15:18:08 +00:00
|
|
|
if intrinsicGas > gasLimit:
|
|
|
|
# Special case, raise gas limit
|
2024-06-07 08:24:32 +00:00
|
|
|
return ok(true)
|
2021-10-26 15:18:08 +00:00
|
|
|
|
|
|
|
params.gasLimit = gasLimit
|
|
|
|
# TODO: bail out on consensus error similar to validateTransaction
|
2024-06-07 08:24:32 +00:00
|
|
|
let res = runComputation(params)
|
|
|
|
ok(res.isError)
|
2021-10-26 15:18:08 +00:00
|
|
|
|
|
|
|
# Execute the binary search and hone in on an executable gas limit
|
|
|
|
while lo+1 < hi:
|
|
|
|
let mid = (hi + lo) div 2
|
2024-06-07 08:24:32 +00:00
|
|
|
let failed = ? executable(mid)
|
2021-10-26 15:18:08 +00:00
|
|
|
if failed:
|
|
|
|
lo = mid
|
|
|
|
else:
|
|
|
|
hi = mid
|
|
|
|
|
|
|
|
# Reject the transaction as invalid if it still fails at the highest allowance
|
|
|
|
if hi == cap:
|
2024-06-07 08:24:32 +00:00
|
|
|
let failed = ? executable(hi)
|
2021-10-26 15:18:08 +00:00
|
|
|
if failed:
|
|
|
|
# TODO: provide more descriptive EVM error beside out of gas
|
|
|
|
# e.g. revert and other EVM errors
|
2024-06-07 08:24:32 +00:00
|
|
|
return err(evmErr(EvmInvalidParam))
|
2021-10-26 15:18:08 +00:00
|
|
|
|
2024-06-07 08:24:32 +00:00
|
|
|
ok(hi)
|
2021-05-03 16:50:47 +00:00
|
|
|
|
2024-07-04 13:48:36 +00:00
|
|
|
proc callParamsForTx(tx: Transaction, sender: EthAddress, vmState: BaseVMState): CallParams =
|
Added basic async capabilities for vm2. (#1260)
* Added basic async capabilities for vm2.
This is a whole new Git branch, not the same one as last time
(https://github.com/status-im/nimbus-eth1/pull/1250) - there wasn't
much worth salvaging. Main differences:
I didn't do the "each opcode has to specify an async handler" junk
that I put in last time. Instead, in oph_memory.nim you can see
sloadOp calling asyncChainTo and passing in an async operation.
That async operation is then run by the execCallOrCreate (or
asyncExecCallOrCreate) code in interpreter_dispatch.nim.
In the test code, the (previously existing) macro called "assembler"
now allows you to add a section called "initialStorage", specifying
fake data to be used by the EVM computation run by that test. (In
the long run we'll obviously want to write tests that for-real use
the JSON-RPC API to asynchronously fetch data; for now, this was
just an expedient way to write a basic unit test that exercises the
async-EVM code pathway.)
There's also a new macro called "concurrentAssemblers" that allows
you to write a test that runs multiple assemblers concurrently (and
then waits for them all to finish). There's one example test using
this, in test_op_memory_lazy.nim, though you can't actually see it
doing so unless you uncomment some echo statements in
async_operations.nim (in which case you can see the two concurrently
running EVM computations each printing out what they're doing, and
you'll see that they interleave).
A question: is it possible to make EVMC work asynchronously? (For
now, this code compiles and "make test" passes even if ENABLE_EVMC
is turned on, but it doesn't actually work asynchronously, it just
falls back on doing the usual synchronous EVMC thing. See
FIXME-asyncAndEvmc.)
* Moved the AsyncOperationFactory to the BaseVMState object.
* Made the AsyncOperationFactory into a table of fn pointers.
Also ditched the plain-data Vm2AsyncOperation type; it wasn't
really serving much purpose. Instead, the pendingAsyncOperation
field directly contains the Future.
* Removed the hasStorage idea.
It's not the right solution to the "how do we know whether we
still need to fetch the storage value or not?" problem. I
haven't implemented the right solution yet, but at least
we're better off not putting in a wrong one.
* Added/modified/removed some comments.
(Based on feedback on the PR.)
* Removed the waitFor from execCallOrCreate.
There was some back-and-forth in the PR regarding whether nested
waitFor calls are acceptable:
https://github.com/status-im/nimbus-eth1/pull/1260#discussion_r998587449
The eventual decision was to just change the waitFor to a doAssert
(since we probably won't want this extra functionality when running
synchronously anyway) to make sure that the Future is already
finished.
2022-11-01 15:35:46 +00:00
|
|
|
# Is there a nice idiom for this kind of thing? Should I
|
|
|
|
# just be writing this as a bunch of assignment statements?
|
|
|
|
result = CallParams(
|
2021-05-17 09:36:34 +00:00
|
|
|
vmState: vmState,
|
|
|
|
gasPrice: tx.gasPrice,
|
2021-05-17 13:01:41 +00:00
|
|
|
gasLimit: tx.gasLimit,
|
2021-05-17 09:36:34 +00:00
|
|
|
sender: sender,
|
2021-06-27 04:19:43 +00:00
|
|
|
to: tx.destination,
|
|
|
|
isCreate: tx.contractCreation,
|
2021-05-17 09:36:34 +00:00
|
|
|
value: tx.value,
|
|
|
|
input: tx.payload
|
2021-05-17 13:01:41 +00:00
|
|
|
)
|
2021-06-27 04:19:43 +00:00
|
|
|
if tx.txType > TxLegacy:
|
2024-02-15 02:57:05 +00:00
|
|
|
result.accessList = tx.accessList
|
2021-05-03 19:35:29 +00:00
|
|
|
|
2023-06-24 13:56:44 +00:00
|
|
|
if tx.txType >= TxEip4844:
|
|
|
|
result.versionedHashes = tx.versionedHashes
|
|
|
|
|
2024-07-04 13:48:36 +00:00
|
|
|
proc callParamsForTest(tx: Transaction, sender: EthAddress, vmState: BaseVMState): CallParams =
|
Added basic async capabilities for vm2. (#1260)
* Added basic async capabilities for vm2.
This is a whole new Git branch, not the same one as last time
(https://github.com/status-im/nimbus-eth1/pull/1250) - there wasn't
much worth salvaging. Main differences:
I didn't do the "each opcode has to specify an async handler" junk
that I put in last time. Instead, in oph_memory.nim you can see
sloadOp calling asyncChainTo and passing in an async operation.
That async operation is then run by the execCallOrCreate (or
asyncExecCallOrCreate) code in interpreter_dispatch.nim.
In the test code, the (previously existing) macro called "assembler"
now allows you to add a section called "initialStorage", specifying
fake data to be used by the EVM computation run by that test. (In
the long run we'll obviously want to write tests that for-real use
the JSON-RPC API to asynchronously fetch data; for now, this was
just an expedient way to write a basic unit test that exercises the
async-EVM code pathway.)
There's also a new macro called "concurrentAssemblers" that allows
you to write a test that runs multiple assemblers concurrently (and
then waits for them all to finish). There's one example test using
this, in test_op_memory_lazy.nim, though you can't actually see it
doing so unless you uncomment some echo statements in
async_operations.nim (in which case you can see the two concurrently
running EVM computations each printing out what they're doing, and
you'll see that they interleave).
A question: is it possible to make EVMC work asynchronously? (For
now, this code compiles and "make test" passes even if ENABLE_EVMC
is turned on, but it doesn't actually work asynchronously, it just
falls back on doing the usual synchronous EVMC thing. See
FIXME-asyncAndEvmc.)
* Moved the AsyncOperationFactory to the BaseVMState object.
* Made the AsyncOperationFactory into a table of fn pointers.
Also ditched the plain-data Vm2AsyncOperation type; it wasn't
really serving much purpose. Instead, the pendingAsyncOperation
field directly contains the Future.
* Removed the hasStorage idea.
It's not the right solution to the "how do we know whether we
still need to fetch the storage value or not?" problem. I
haven't implemented the right solution yet, but at least
we're better off not putting in a wrong one.
* Added/modified/removed some comments.
(Based on feedback on the PR.)
* Removed the waitFor from execCallOrCreate.
There was some back-and-forth in the PR regarding whether nested
waitFor calls are acceptable:
https://github.com/status-im/nimbus-eth1/pull/1260#discussion_r998587449
The eventual decision was to just change the waitFor to a doAssert
(since we probably won't want this extra functionality when running
synchronously anyway) to make sure that the Future is already
finished.
2022-11-01 15:35:46 +00:00
|
|
|
result = CallParams(
|
2021-05-17 16:27:20 +00:00
|
|
|
vmState: vmState,
|
2021-10-14 06:08:40 +00:00
|
|
|
gasPrice: tx.gasPrice,
|
|
|
|
gasLimit: tx.gasLimit,
|
|
|
|
sender: sender,
|
|
|
|
to: tx.destination,
|
|
|
|
isCreate: tx.contractCreation,
|
|
|
|
value: tx.value,
|
|
|
|
input: tx.payload,
|
2021-05-04 14:02:16 +00:00
|
|
|
|
2021-10-14 06:08:40 +00:00
|
|
|
noIntrinsic: true, # Don't charge intrinsic gas.
|
|
|
|
noRefund: true, # Don't apply gas refund/burn rule.
|
|
|
|
)
|
|
|
|
if tx.txType > TxLegacy:
|
2024-02-15 02:57:05 +00:00
|
|
|
result.accessList = tx.accessList
|
Added basic async capabilities for vm2. (#1260)
* Added basic async capabilities for vm2.
This is a whole new Git branch, not the same one as last time
(https://github.com/status-im/nimbus-eth1/pull/1250) - there wasn't
much worth salvaging. Main differences:
I didn't do the "each opcode has to specify an async handler" junk
that I put in last time. Instead, in oph_memory.nim you can see
sloadOp calling asyncChainTo and passing in an async operation.
That async operation is then run by the execCallOrCreate (or
asyncExecCallOrCreate) code in interpreter_dispatch.nim.
In the test code, the (previously existing) macro called "assembler"
now allows you to add a section called "initialStorage", specifying
fake data to be used by the EVM computation run by that test. (In
the long run we'll obviously want to write tests that for-real use
the JSON-RPC API to asynchronously fetch data; for now, this was
just an expedient way to write a basic unit test that exercises the
async-EVM code pathway.)
There's also a new macro called "concurrentAssemblers" that allows
you to write a test that runs multiple assemblers concurrently (and
then waits for them all to finish). There's one example test using
this, in test_op_memory_lazy.nim, though you can't actually see it
doing so unless you uncomment some echo statements in
async_operations.nim (in which case you can see the two concurrently
running EVM computations each printing out what they're doing, and
you'll see that they interleave).
A question: is it possible to make EVMC work asynchronously? (For
now, this code compiles and "make test" passes even if ENABLE_EVMC
is turned on, but it doesn't actually work asynchronously, it just
falls back on doing the usual synchronous EVMC thing. See
FIXME-asyncAndEvmc.)
* Moved the AsyncOperationFactory to the BaseVMState object.
* Made the AsyncOperationFactory into a table of fn pointers.
Also ditched the plain-data Vm2AsyncOperation type; it wasn't
really serving much purpose. Instead, the pendingAsyncOperation
field directly contains the Future.
* Removed the hasStorage idea.
It's not the right solution to the "how do we know whether we
still need to fetch the storage value or not?" problem. I
haven't implemented the right solution yet, but at least
we're better off not putting in a wrong one.
* Added/modified/removed some comments.
(Based on feedback on the PR.)
* Removed the waitFor from execCallOrCreate.
There was some back-and-forth in the PR regarding whether nested
waitFor calls are acceptable:
https://github.com/status-im/nimbus-eth1/pull/1260#discussion_r998587449
The eventual decision was to just change the waitFor to a doAssert
(since we probably won't want this extra functionality when running
synchronously anyway) to make sure that the Future is already
finished.
2022-11-01 15:35:46 +00:00
|
|
|
|
2023-06-24 13:56:44 +00:00
|
|
|
if tx.txType >= TxEip4844:
|
|
|
|
result.versionedHashes = tx.versionedHashes
|
|
|
|
|
2024-06-07 08:24:32 +00:00
|
|
|
proc txCallEvm*(tx: Transaction,
|
|
|
|
sender: EthAddress,
|
2024-07-04 13:48:36 +00:00
|
|
|
vmState: BaseVMState): GasInt =
|
2024-06-07 08:24:32 +00:00
|
|
|
let
|
2024-07-04 13:48:36 +00:00
|
|
|
call = callParamsForTx(tx, sender, vmState)
|
2024-06-07 08:24:32 +00:00
|
|
|
res = runComputation(call)
|
|
|
|
res.gasUsed
|
|
|
|
|
|
|
|
proc testCallEvm*(tx: Transaction,
|
|
|
|
sender: EthAddress,
|
2024-07-04 13:48:36 +00:00
|
|
|
vmState: BaseVMState): CallResult =
|
|
|
|
let call = callParamsForTest(tx, sender, vmState)
|
2021-10-14 06:08:40 +00:00
|
|
|
runComputation(call)
|