ethereum / ethereum/execution-specs
`uv run execute remote` with `--engine-endpoint` driver FCUs + getPayload too fast for big txs
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 505
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 116
Description
I'm using the `--engine-endpoint` to drive the chain! This ethereum/execution-spec-tests#2070 PR is very exciting! However, for big txs which take a long time to execute (e.g. XEN) the default `get_payload_wait_time` is too short. The problem is, that the tx will never get included, because each time that EEST FCUs (with PayloadAttributes so it starts block building) then while the block is currently building (the heavy tx is being executed), it queries getPayload and this will return the empty block (or at least: it will not include the heavy tx). This also stops the building process.
I tried in CLI to edit the wait time `--get-payload-wait-time 10` (this option should be added to the help docs as well!) and this works. However, this would stall all the fast setup phases, we only need it for heavy txs.
I'd think that in this pending txs loop to see if they are mined https://github.com/ethereum/execution-spec-tests/blob/10b02048237f917c8ae33b827ba92fca39d48c4a/src/pytest_plugins/execute/rpc/chain_builder_eth_rpc.py#L379-L388
If we see that a certain pending_tx is not included, then exponentially increase `self.get_payload_wait_time` (so keep doubling it for instance). Once the tx is included, however, reset it back to the original value. This will give the block builder more time to include these txs and at some point it will include it - but only for "heavy" txs, for others it will just use the normal wait time. If this is not done, EEST will (correctly) error with the case that the tx is not included.
Contributor guide
Assessment
This issue has not been assessed yet.