This PR separates ENGINE from Ethbackend. It makes it so:
1) EthBackend not a god class
2) We can abstract away engine API so that we can make it CL-like and
enable Consensus-Execution driven design
3) Objective is Json-RPC -> Engine Consensus Module -> Execution module.
types.NewMessage now expects maxFeePerDataGas param, which will be used
in transaction verification (preCheck). GetPayloadV3 method added to
EngineAPI. Some cosmetic changes applied.
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.
If I'm not mistaken, some CLs in some circumstances can send duplicate
requests to build a block. This is a protection against throwing away
progress in case block building has already started.
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.
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.
This is a fix for
[withdrawal-devnet-3](https://forkmon.withdrawal-devnet-3.ethpandaops.io/).
The problem was that CL calls `NewPayloadV2` for pre-Shanghai blocks
with `nil` withdrawals, which is OK, but that `nil` was erroneously
converted into an empty array, causing block hash mismatch.
BaseFee is required in AuRa headers when
[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) is activated.
Also:
- Basic AuRa header verification
- Extract some common RLP methods
- Tiny log clean-up
Revert to older batch size logic to keep memory usage down during
execution phase and closer to the --batchSize flag size.
Spotted a "leak" in key generation as well. The unsafe pointer keeps the
byte slice around for as long as the batch is not committed, takes up a
fair chunk of memory surprisingly doing that so removed the unsafe
pointer usage giving the GC some chance to clean up along the way.
Moved the batch rollback into a defer func call rather than allowing
them to stack in the for loop. If this isn't going to work just let me
know and can change it back.
the root cause is that when `inMemoryExecution` lambda gets created in
the `eth/backend.go`, it captures the reference of
`backend.notifications`, and so the execution of side-forks actually
adds notifications to there, and it all gets sent out to tx pool (and
RPC daemon) at the end of the stage loop (regardless of whether there
was forkchoice update or not)
so we can create a separate notification, but then somehow flush it to
the "main" nofitications when the in-memory exec state is flushed
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro.local>
