erigontech / erigontech/erigon
Consolidate Mining Execution
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.5k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 432
Description
At the moment `SpawnMiningExecStage` executes all transactions twice:
Once when it initially builds the block here:
https://github.com/erigontech/erigon/blob/260425731da39cd165e62cae2c4d0d637effd0f1/execution/stagedsync/stage_mining_exec.go#L135
and a second time when it has a complete block here:
https://github.com/erigontech/erigon/blob/260425731da39cd165e62cae2c4d0d637effd0f1/execution/stagedsync/stage_mining_exec.go#L244
This has 2 unfortunate side effects:
1. Performance: we're executing the block twice when we only need to do it once
2. Cosistency: As we never check the contents of the block we finalize and seal we don't actually know if its valid. See https://github.com/erigontech/erigon/issues/17363 for a practical example if the implications of this.
I think the reason for this double execution is the fact that https://github.com/erigontech/erigon/blob/260425731da39cd165e62cae2c4d0d637effd0f1/execution/state/rw_v3.go#L182 was only practically accessable withing the Exec3 function: https://github.com/erigontech/erigon/blob/260425731da39cd165e62cae2c4d0d637effd0f1/execution/stagedsync/exec3.go#L122
Once we have finished the BAL & Parallel execution development we can extract this so it can be called directly from block building. Once we have done this we can just call Apply and then compute the state trie.
Note we will also need to call post execution validation to ensure we have a valid block before publishing as we do in the execution flow: https://github.com/erigontech/erigon/blob/260425731da39cd165e62cae2c4d0d637effd0f1/execution/stagedsync/exec3_serial.go#L442
Contributor guide
Assessment
This issue has not been assessed yet.