Very basic implementation for get payload bodies rpc calls. Once we have
Hive tests for these calls I can pick this back up and work through any
issues.
Implementation of https://github.com/ethereum/execution-apis/pull/352.
There are two fixes:
1) the blockNumber in the CreateHistoryStateReader should be blockNumber
+ 1 as in the eth_call, eth_createAccessList:
- eth_call: already use blockNumber + 1 see
CreateStateReaderFromBlockNumber where the blockNumber
- passed to the CreateHistoryStateReader is blockNumber + 1
- eth_createAccessList: call CreateHistoryStateReader directly with
blockNumber + 1
2) The eth_callBudle allows to execute the original transaction (here
the sender nonce is assigned to the tx) on a user defined block; the
original transition could be performed in another block . The sender's
nonce when the original transaction was performed had a value that may
be different to the nonce of the sender when the tx is "executed" on new
block. So during the execution of the eth_callBundle must not be
verified that the nonce is progressive (original nonce of the tx + 1:
see preCheck() in state_transition.go that; if the checkNonce fails an
error is arised, nonce too low or nonce to high)
The eth_call does not check the nonce because is using ToMessage(calls
types.NewMessage with checkNonce = false) with checkNonce disabled;
while the eth_callBundle uses AsMessage object (where is built the
Message with checkNonce = true) where the checkNonce is enabled.
Action: Disable the checkNonce as proposed
Some transactions in replayed blocks do not get reverted, although they
were originally reverted due to out of gas. This causes false balance
calculations for some addresses
erigon_blockNumber returns "latest executed block number" or any block
number requested.
In this last case the rpcBlockNum variable was not initialized
Continuing the work of https://github.com/ledgerwatch/erigon/pull/6381 .
We encountered a problem in blocks with type 2 transactions,
specifically blocks with two transactions with the same `tx.from`. When
the first tx is replayed, a high `gasPrice` is being calculate in
`txn.AsMessage` causing the second replayed tx to fail with the
following error:
```
insufficient funds for gas * price + value: address ...
```
This happens in both `eth_callMany` and `debug_traceCallMany`.
This pull request follows the `debug_traceTransaction` usage of
`tx.AsMessage` in `ComputeTxEnv`
Refactors filters.go such that map+locks are now in their own class
Move logic for safely canceling & draining channel to its own class
changed subscriptions to ask for size of buffer and construct its own
channel
marked as draft b/c need to do live testing.
