In this PR Header's ExcessDataGas is set to the actual value, but it's
still unused. It will be used to compute data fee for eip-4844 data
blobs, logic of which will be added in later PRs. Also eip-4844 header
verification logic added.
`excessDataGas` has been partially made eip-4844 ready, so instead of
passing nils to functions, now it actually assigned to some value (it is
expected to be nil until cancun update).
New transaction type added. This transaction differs from previous
transactions in a network encoding. Network encoding of a new
transaction wraps "regular" transaction with additional data: blobs and
kzgs. The network wrapper will be verified by execution layer using this
extra data.
Separate:
- new tasks coming by channel with limited capacity (touching the limit
will block - like sync.Cond.Wait() does, but composable). as a result -
don't need track queue size (it will not increase conflict-rate).
- re-exec tasks are going to priority-queue (which is also higher
priority than 1-st `chan`).
@shyba hi, seems this lib doesn't work with
ghcr.io/goreleaser/goreleaser-cross (which producing release binaries)
removing it for now, feel free to add it in future - if can make it work
with goreleaser-cross
see: https://github.com/ledgerwatch/erigon/issues/7210
Small change in core.NewEVMBlockContext and now it expects
excessDataGas. This will be used in state transition to compute data fee
for eip-4844 data blobs. The logic that computes it will be added in the
next PRs.
This PR contains very small EIP-4844 additions. GasPool is modified and
now it is a struct with 2 fields "gas" and "dataGas" (blobs are priced
in dataGas). ExcessDataGas block header field added. ExcessDataGas
needed to compute the data gas price. EIP-4844 helper functions are
added as well.
Hi,
I'm syncing Gnosis on a Celeron N5100 to get familiar with the codebase.
In the process I managed to optimize some things from profiling.
Since I'm not yet on the project Discord, I decided to open this PR as a
suggestion. This pass all tests here and gave me a nice boost for that
platform, although I didn't have time to benchmark it yet.
* reuse VM Memory objects with sync.Pool. It starts with 4k as `evmone`
[code
suggested](0897edb001/lib/evmone/execution_state.hpp (L49))
as a good value.
* set32 simplification: mostly cosmetic
* sha256-simd: Celeron has SHA instructions. We should probably do the
same for torrent later, but this already helped as it is very CPU bound
on such a low end processor. Maybe that helps ARM as well.
This PR adds missing tests for eth_getProof and does some mild
refactoring with switching from strings to more strict types. It's
likely best/most easily reviewed commit by commit.
Note, the tests include quite a number of helper types and functions for
doing the proof validation. This is largely because unlike Geth,
Erigon's approach to trie computations only requires serializing the
trie nodes, not deserializing them. Consequently, it wasn't obvious how
to leverage the existing trie code for doing deserialization and proof
checks. I checked on Discord, but, there were no suggestions. Of course,
any feedback is welcome and I'd be happy to remove this code if it can
be avoided.
Additionally, I've opted to change the interface type for `GetProof` to
use a `common.Hash` for the storage keys instead of a `string`. I
_think_ this should be fairly safe, as until very recently it was
unimplemented. That being said, since it's an interface, it has the
potential to break other consumers, anyone who was generating mocks
against it etc. There's additionally a `GetStorageAt` that follows the
same parameter. I'd be happy to submit a PR modifying this one as well
if desired.
Also, as a small note, there is test code for checking storage proofs,
but, storage proofs aren't currently supported by the implementation. My
hope is to add storage proofs and historic proofs in a followup PR.
---------
Co-authored-by: Jason Yellick <jason@enya.ai>
This is a partial implementation of eth_getProof (see issue #1349),
supporting only a request for the latest block and an empty list of
storage keys (i.e. Account proof only). I don't know if there's a better
way of implementing this, but this was what I could come up with.
Posting it here in case it's useful.
Example output:
```
> eth.getProof("0x67b1d87101671b127f5f8714789C7192f7ad340e", [], 'latest')
{
accountProof: ["0xf90131a0252c9d4ed347b4cf3fdccaea3ccef0a507e6bd4dbe4dcd98609b7195347c4062a0ab8cdb808c8303bb61fb48e276217be9770fa83ecf3f90f2234d558885f5abf18080a01a697e814758281972fcd13bc9707dbcd2f195986b05463d7b78426508445a04a0b5d7a91be5ee273cce27e2ad9a160d2faadd5a6ba518d384019b68728a4f62f4a0c2c799b60a0cd6acd42c1015512872e86c186bcf196e85061e76842f3b7cf86080a0e73919d9f472eec11f6da95518503f5527a98b9428f7a02c4f55bf51854214e480a06301b39b2ea8a44df8b0356120db64b788e71f52e1d7a6309d0d2e5b86fee7cb8080a01b7779e149cadf24d4ffb77ca7e11314b8db7097e4d70b2a173493153ca2e5a0a066a7662811491b3d352e969506b420d269e8b51a224f574b3b38b3463f43f0098080", "0xf8518080808080a0a00135c9ec2655cb6a47ab7ad27d6fc150d9cba8b3d4a702e879179116a68a60808080808080a02fb46956347985b9870156b5747712899d213b1636ad4fe553c63e33521d567a80808080", "0xf873a02056274a27dd7524955417c11ecd917251cc7c4c8310f4c7e4bd3c304d3d9a79b850f84e808a021e19e0c9bab2400000a056e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421a0c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"],
address: "0x67b1d87101671b127f5f8714789c7192f7ad340e",
balance: "0x21e19e0c9bab2400000",
codeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
nonce: "0x0",
storageHash: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
storageProof: []
}
> eth.getBlock('latest').stateRoot
"0x6a0673c691edfa4c4528323986bb43c579316f436ff6f8b4ac70854bbd95340b"
```
Passing consensus-specs tests for Capella. Processing of withdrawals and
ExecutionChanges. efficient non-validation implemented. Refactored:
ExecutionPayload/ExecutionPayloadHeader.
**Current Problem**
When X transactions are created, with M transactions out of them having
`gasFeeCap` greater than the current `baseFeePerGas` for the block, and
N transactions having `gasFeeCap` lower, all X transactions get added to
the yellow pool (baseFee) in the txpool and they never get mined.
However when X transactions all having `gasFeeCap` higher than the
`baseFeePerGas` are created, they all get added to the green pool
(pending) in the txpool and thus get mined.
This phenomenon can be inspected in the
`signEIP1559TxsLowerAndHigherThanBaseFee2` function where the number of
transactions that should have `gasFeeCap` higher than and lower than the
current `baseFeePerGas` is specified in its parameter - `func
signEIP1559TxsLowerAndHigherThanBaseFee2(amountLower, amountHigher
int...`.
When `amountLower` is set as `0`, all transactions created from
`amountHigher` will be mined because they have `gasFeeCap` >
`baseFeePerGas`. When `amountLower` has a value > `0`, all the
transactions created (including transactions created with
`amountHigher`) will go to the yellow pool (baseFee) and thus do not get
mined.
To fix#6798
Follows the same pattern as other temporary fixes for BSC.
Tested locally and the transaction in question shows the same behaviour
as nethermind, coming to the same gas used and reverted behaviour by the
end. Tracing the block also works as expected now.
Tracing a transaction after the fork at 21735000 loads up the new
contract as expected as well.
Fees going to the gas fee recipient should be based on the actual gas
used (available in the receipt) rather than the gas limit in a
transaction. This fixes Hive test "GetPayloadV2 Block Value".
Also `engine_getPayloadBodiesByRangeV1` params should be encoded as hex
strings.
Solidity 0.8.0 breaks the current use of `payable` in these test
contracts, resulting in errors like
```
Error: Type address is not implicitly convertible to expected type address payable.
--> selfDestructor.sol:10:9:
|
10 | address payable nil = address(0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Related to #6680
In v2.36.0 we correctly trace this transaction, however due to a code
ordering issue in previous releases, there was an 'out of gas' response,
because we fell through to the code here where
ErrContractAddressCollision will be returned as such. This change isn't
the fix, but ensures the actual error is returned.
Cherry-pick https://github.com/ethereum/go-ethereum/pull/24017.
* core/vm: Define 0xfe opcode as INVALID
* core/vm: Remove opInvalid as opUndefined handles it
Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
Co-authored-by: Andrei Maiboroda <andrei@ethereum.org>
Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
Cherry-pick https://github.com/ethereum/go-ethereum/pull/22766.
Do not keep separate flag for "max code size exceeded" case, but instead
assign appropriate error for it sooner.
Co-authored-by: Paweł Bylica <chfast@gmail.com>
Run tests from a new repo
https://github.com/ethereum/execution-spec-tests.
Also introduce `HashCheck()` function that checks correctness of block's
uncle, transaction, and withdrawals hashes.
Moved some of the tracers to `eth/tracers/logger` to make it more
similar to go-ethereum.
Removed Erigon-specific `Capture-` functions
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
Remove `callType` argument from `CaptureStart`, and change `callType
vm.CallType` to `typ vm.OpCode` in `CaptureEnter` and move to the first
position (as it is in geth)
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
Splitting function `CaptureStart` into `CaptureStart` (when depth == 0)
and `CaptureEnter` (when depth > 0), while removing argument `depth`.
Same with splitting `CaptureEnd` into `CaptureEnd` and `CaptureExit`
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
In this first step, the new functions `CaptureTxStart` and
`CaptureTxEnd` are introduced to all tracers
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro-2.local>
Works around a flaw in the upgrade logic of the system contracts. Since
they are updated directly, without first being self-destructed and then
re-created, the usual incarnation logic does not get activated, and all
historical records of the code of these contracts are retrieved as the
most recent version. This problem will not exist in erigon3, but until
then, a workaround will be used to access code of such contracts through
a special structure, `SystemContractCodeLookup`
Fixes https://github.com/ledgerwatch/erigon/issues/5865
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
So there is an issue with tracing certain blocks/transactions on
Polygon, for example:
```
> '{"method": "trace_transaction","params":["0xb198d93f640343a98f90d93aa2b74b4fc5c64f3a649f1608d2bfd1004f9dee0e"],"id":1,"jsonrpc":"2.0"}'
```
gives the error `first run for txIndex 1 error: insufficient funds for
gas * price + value: address 0x10AD27A96CDBffC90ab3b83bF695911426A69f5E
have 16927727762862809 want 17594166808296934`
The reason is that this transaction is from the author of the block,
which doesn't have enough ETH to pay for the gas fee + tx value if he's
not the block author receiving transactions fees.
The issue is that currently the APIs are using `ethash.NewFaker()`
Engine for running traces, etc. which doesn't know how to get the author
for a specific block (which is consensus dependant); as it was noting in
several TODO comments.
The fix is to pass the Engine to the BaseAPI, which can then be used to
create the right Block Context. I chose to split the current Engine
interface in 2, with Reader and Writer, so that the BaseAPI only
receives the Reader one, which might be safer (even though it's only
used for getting the block Author).
feat:
1. `erigon_getLatestLogs` doesn't have to match the exact position of
the topics. It will match logs that contain the topics regardless of the
topics' position with original bloom filter. And it accepts `blockCount`
& `crit.ToBlock` params for better pagination.
One simple change to send the header in rather than the body allowing
re-use in a loop which saves the copy call when looping.
The other one for a reusable evm seems potentially dangerous so feedback
more than welcome on that one, local testing shows it gains me around
6k±rps so if it's safe is a good win, but I feel it will need more work.
I could only validate against goerli chain which seems to always return
the same value for eth_estimateGas so if anybody could validate it
against another chain that would be awesome.
