Need to update op-program to correctly invalidate blocks containing executing messages which originally had dependencies satisfied, but then had those dependencies removed when another chain had a deposit-only block inserted instead.
TestInteropFaultProofs_CascadeInvalidBlock from #14266 covers this case.
We need to consider performance impact when doing this. The naive approach is to re-evaluate all blocks from scratch after one is replaced with a deposit only block. That may be ok with only two chains (needs benchmarking) because it means evaluating at most 3 block dependencies (A = ok, B = invalid, recheck A) but will quickly be too expensive when adding more chains as it grows exponentially. A more efficient algorithm is to check the dependencies of each chain and record a more specific result than just valid/invalid - it would be one of:
- Invalid
- Valid without depending on non-deposit messages from any other block in this consolidation step
- Valid only if the block being consolidated from chain X remains valid (ie depends on a non-deposit transaction in the latest block from another chain)
The first two cases will never change regardless of what other blocks change. The third may change but clearly identifies which chains need to be valid for this block to remain valid. That way we only need to check the dependencies once, and can then cheaply identify which chains need to be replaced with a deposit-only block.
Need to update op-program to correctly invalidate blocks containing executing messages which originally had dependencies satisfied, but then had those dependencies removed when another chain had a deposit-only block inserted instead.
TestInteropFaultProofs_CascadeInvalidBlockfrom #14266 covers this case.We need to consider performance impact when doing this. The naive approach is to re-evaluate all blocks from scratch after one is replaced with a deposit only block. That may be ok with only two chains (needs benchmarking) because it means evaluating at most 3 block dependencies (A = ok, B = invalid, recheck A) but will quickly be too expensive when adding more chains as it grows exponentially. A more efficient algorithm is to check the dependencies of each chain and record a more specific result than just valid/invalid - it would be one of:
The first two cases will never change regardless of what other blocks change. The third may change but clearly identifies which chains need to be valid for this block to remain valid. That way we only need to check the dependencies once, and can then cheaply identify which chains need to be replaced with a deposit-only block.