Describe the feature
It currently looks like we issue the following RPC calls per block on a bedrock network with 2 builders:
- 8x
eth_feeHistory
- 2x
eth_call
- 2x
eth_getTransactionCount
- 1x
eth_getLogs
And then 2x eth_getBalance every 10s.
We can reduce this per-block baseline by:
- Moving
eth_getTransactionCount and eth_getBalance, which are used by the builder, into the chain tracking logic. Only issue these calls when a transaction is mined.
- Removing the
isFjord() check from the bedrock sync da logic
- Investigate where
eth_feeHistory is being called, it should be called once per block, and the pool should serve as source of truth.
Ideally we get to:
- 1x
eth_feeHistory - determine base/priority fee
- 1x
eth_getLogs - handle entrypoint events
- 1x
eth_call - DA data updates
- (on transaction mined for tracked address) 1x
eth_getBalance,
Describe the feature
It currently looks like we issue the following RPC calls per block on a bedrock network with 2 builders:
eth_feeHistoryeth_calleth_getTransactionCounteth_getLogsAnd then 2x
eth_getBalanceevery 10s.We can reduce this per-block baseline by:
eth_getTransactionCountandeth_getBalance, which are used by the builder, into the chain tracking logic. Only issue these calls when a transaction is mined.isFjord()check from the bedrock sync da logiceth_feeHistoryis being called, it should be called once per block, and the pool should serve as source of truth.Ideally we get to:
eth_feeHistory- determine base/priority feeeth_getLogs- handle entrypoint eventseth_call- DA data updateseth_getBalance,eth_getTransactionCountisn't needed unless the sender is reset. Pool can stream per address updates to builder [pool/builder] Track builder addresses via chain tracking #887