Extended Block Metadata #350
Description
Block builders and executors can inspect each transaction's final read and write set for valuable metadata that
improves downstream execution speed.
-
Transaction Dependency Graph: Syncing nodes can fork-join block execution according to a transaction
dependency graph. Each parallel fork executes a chain of dependent transactions sequentially. All forks join at the end
for post-processing. This optimal process yields no state conflict and re-execution. A single full-block validation at
the end confirms the execution result. -
Read Memory Locations: Syncing nodes can concurrently preload to-be-read memory locations to avoid blocking
I/O during transaction execution. -
Blacklisting: Malicious metadata like enormous read memory locations can significantly slow down or even crash
syncing nodes. Therefore, syncing nodes must have strict bounds while parsing and blacklist nodes that provide bad
metadata, either to not receive more blocks or to not process extended metadata from them. Sensitive nodes can go
further by only whitelisting trusted nodes. Nevertheless, if the full-block validation fails after executing with a dependency graph, the syncing node can still fall back to optimistic execution.
Before committing to a full implementation & RISE Stack integration, we should do a quick PoC and benchmark how much speedup we gain when executing blocks with a pre-provided dependency graph.