Describe the solution you'd like
Currently the BSS keeps track of a fixed number of L2 block ids, where each corresponds to the last L2 block in a response to optimism_getBatchBundle. When querying for the next bundle, the entire list is submitted via RPC (currently 20kb w/ 600 entries). In normal circumstances this is overkill, and we can likely send only the tip of what we know. The bulk of this issue revolves around the rollup node being able to communicate to the BSS that none of the ancestors provided were found in the canonical chain, and for the BSS to reattempt submission with deeper history.
This is not an immediate need, but should be tackled if we observe request latency being a bottleneck specifically in regards to constructing the ancestor list.
Metadata
Describe the solution you'd like
Currently the BSS keeps track of a fixed number of L2 block ids, where each corresponds to the last L2 block in a response to optimism_getBatchBundle. When querying for the next bundle, the entire list is submitted via RPC (currently 20kb w/ 600 entries). In normal circumstances this is overkill, and we can likely send only the tip of what we know. The bulk of this issue revolves around the rollup node being able to communicate to the BSS that none of the ancestors provided were found in the canonical chain, and for the BSS to reattempt submission with deeper history.
This is not an immediate need, but should be tackled if we observe request latency being a bottleneck specifically in regards to constructing the ancestor list.
Metadata