SPIKE: op-program: Determine the maximum age of initiating messages that we can safely handle in fault proofs

[ajsutton]

No description provided.

[ajsutton]

Started with some quick tests, without using the Pectra block history support. Walking back 5000 L2 blocks took about 10 mins on my laptop with local source nodes - based on experience with block processing times on my laptop vs GCP that would be 2-3 hours in GCP.

Walking back a week of L2 blocks (2s block time) is still running after over 15 hours on my laptop.

Pectra should make things about 8000 times faster since we can skip back 8124 blocks at a time (but with more overhead per request as I believe we'll have to walk down the state trie to get the value we need).

However we then need to divide the maximum time window by the number of chains in the dependency set (as we may be forced to walk back the maximum distance on each of those chains).

So even with pectra I think we'd be struggling to support longer than 1 week window. Once we grow the dependency set beyond two chains even one week looks unrealistic.

Will need to do some better benchmarks and pull together a spreadsheet to forecast execution times for different histories and number of chains in the dep set, but this is an initial rough take.

[ajsutton]

Fetching a receipt from a block that's a week old on my laptop took just over 16 hours (without pectra)

[ajsutton]

Created a spreadsheet to play with the numbers a bit more: https://docs.google.com/spreadsheets/d/1rCrFItkOWYG0KNAkkfmu07rH8Lw_Tve4JDogTYvLVsY/edit?usp=sharing (sadly OP Labs only due to sharing restrictions).

Bottom line is that with 2 chains in the dependency set, we could have an expiry window of 30 days (with pectra) and still execute cannon in an estimated 7 hours in GCP. While we have 84 hours on the chess clock to start, I would be very nervous to push execution times much past that as it becomes too easy to overwhelm the honest challenger via multiple claims. Plus we need to leave ourselves time to actually post counter claims, including rerunning parts of the cannon trace to generate claims at specific steps.

With 10 chains in the dependency set we could do 7 days expiry and still execute in 7-8 hours in GCP.

Without pectra, even with just two chains in the dependency set we'd need to set the expiry window to about 5 hours at most.

If we wanted to extend the expiry window we could extend the number of block hashes retained in Pectra's block history contract. Retaining 32768 blocks instead of 8192, would let us handle 30 day expiry with 10 chains in the dependency set and an execution time of about 8 hours which is manageable.

[ajsutton]

Key thing out of this though is Pectra on L2 is a hard requirement for interop being fault provable and we should start tracking it as a dependency.

We need to implement support for leveraging Petra's block hash history and benchmark that to know for sure what speed up it provides. We can also then evaluate how much extra storage is required if we increase the pectra block hash range vs the increase in expiry window it could support.