2021-04-08 14:52:10 +00:00
|
|
|
# Nimbus
|
|
|
|
|
# Copyright (c) 2018 Status Research & Development GmbH
|
|
|
|
|
# Licensed under either of
|
2021-04-22 18:12:16 +00:00
|
|
|
# * 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.
|
2021-04-08 14:52:10 +00:00
|
|
|
|
|
|
|
|
import
|
2021-09-11 14:58:01 +00:00
|
|
|
../chain_config,
|
2021-04-26 12:03:20 +00:00
|
|
|
../constants,
|
2021-06-01 11:27:05 +00:00
|
|
|
../forks,
|
2021-04-26 12:03:20 +00:00
|
|
|
../db/accounts_cache,
|
2021-04-08 14:52:10 +00:00
|
|
|
../transaction,
|
2021-04-26 12:03:20 +00:00
|
|
|
./computation,
|
2021-04-26 16:00:46 +00:00
|
|
|
./interpreter_dispatch,
|
2021-06-01 11:27:05 +00:00
|
|
|
./interpreter/[gas_costs, gas_meter],
|
2021-04-26 14:08:17 +00:00
|
|
|
./message,
|
2021-04-26 12:03:20 +00:00
|
|
|
./state,
|
|
|
|
|
./types,
|
2021-04-22 18:12:16 +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,
|
2021-04-26 12:03:20 +00:00
|
|
|
eth/common,
|
2021-04-22 18:12:16 +00:00
|
|
|
eth/common/eth_types,
|
|
|
|
|
options,
|
|
|
|
|
sets
|
|
|
|
|
|
2021-04-21 10:12:46 +00:00
|
|
|
proc setupTxContext*(vmState: BaseVMState, origin: EthAddress, gasPrice: GasInt, forkOverride=none(Fork)) =
|
|
|
|
|
## this proc will be called each time a new transaction
|
|
|
|
|
## is going to be executed
|
|
|
|
|
vmState.txOrigin = origin
|
|
|
|
|
vmState.txGasPrice = gasPrice
|
|
|
|
|
vmState.fork =
|
|
|
|
|
if forkOverride.isSome:
|
|
|
|
|
forkOverride.get
|
|
|
|
|
else:
|
2022-01-18 16:19:32 +00:00
|
|
|
vmState.chainDB.config.toFork(vmState.blockNumber)
|
2021-04-21 10:12:46 +00:00
|
|
|
vmState.gasCosts = vmState.fork.forkToSchedule
|
|
|
|
|
|
|
|
|
|
|
2021-04-26 12:03:20 +00:00
|
|
|
proc refundGas*(c: Computation, tx: Transaction, sender: EthAddress) =
|
|
|
|
|
let maxRefund = (tx.gasLimit - c.gasMeter.gasRemaining) div 2
|
|
|
|
|
c.gasMeter.returnGas min(c.getGasRefund(), maxRefund)
|
|
|
|
|
c.vmState.mutateStateDB:
|
|
|
|
|
db.addBalance(sender, c.gasMeter.gasRemaining.u256 * tx.gasPrice.u256)
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
# FIXME-awkwardFactoring: the factoring out of the pre and
|
|
|
|
|
# post parts feels awkward to me, but for now I'd really like
|
|
|
|
|
# not to have too much duplicated code between sync and async.
|
|
|
|
|
# --Adam
|
|
|
|
|
|
|
|
|
|
proc preExecComputation(c: Computation) =
|
2021-04-08 14:52:10 +00:00
|
|
|
if not c.msg.isCreate:
|
|
|
|
|
c.vmState.mutateStateDB:
|
|
|
|
|
db.incNonce(c.msg.sender)
|
|
|
|
|
|
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
|
|
|
proc postExecComputation(c: Computation) =
|
2021-04-08 14:52:10 +00:00
|
|
|
if c.isSuccess:
|
2021-06-28 13:03:50 +00:00
|
|
|
if c.fork < FkLondon:
|
|
|
|
|
# EIP-3529: Reduction in refunds
|
|
|
|
|
c.refundSelfDestruct()
|
2021-05-11 09:05:58 +00:00
|
|
|
shallowCopy(c.vmState.selfDestructs, c.selfDestructs)
|
2021-04-08 14:52:10 +00:00
|
|
|
shallowCopy(c.vmState.logEntries, c.logEntries)
|
|
|
|
|
c.vmState.touchedAccounts.incl c.touchedAccounts
|
|
|
|
|
|
2022-04-08 04:54:11 +00:00
|
|
|
c.vmState.status = c.isSuccess
|
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
|
|
|
|
|
|
|
|
proc execComputation*(c: Computation) =
|
|
|
|
|
c.preExecComputation()
|
|
|
|
|
c.execCallOrCreate()
|
|
|
|
|
c.postExecComputation()
|
|
|
|
|
|
|
|
|
|
# FIXME-duplicatedForAsync
|
|
|
|
|
proc asyncExecComputation*(c: Computation): Future[void] {.async.} =
|
|
|
|
|
c.preExecComputation()
|
|
|
|
|
await c.asyncExecCallOrCreate()
|
|
|
|
|
c.postExecComputation()
|
