The purpose of this document is to progress a design originally proposed by @protolambda and contributed to by Hamdi here. The goal is to reduce resource usage by the derivation pipeline when invalid blocks are proposed. This is helpful for ensuring that the fault proof program cannot be denial of service attacked as well as reducing the latency of reorgs, which is especially important in the context of interop.
New derivation pipeline invariants are introduced that are meant to reduce large resets of the derivation pipeline when handling invalid batches.
The derivation pipeline is set up as a series of stages. It takes work to progress from one stage to the next. Sometimes this work involves many remote HTTP requests, other times it requires in memory manipulation of data structures. It's not ideal when there is an error in a later stage that causes a lot of additional work to be done in an earlier stage to recover. In practice, this looks like some sort of invalid batch was deserialized and errors during its processing.
The
DerivationPipelinehas aStep()function that is called over and over again to derive the chain, which ultimately looks like mapping raw batch data intoExecutionPayloads.DerivationPipeline.Step()wraps a call toEngineQueue.Step()which wraps a call toAttributesQueue.NextAttributes().
Examples of types of errors:
- Invalid transaction in block
- Invalid Execution Payload
- Invalid batch timestamp
- Batch contains deposit tx
The following 2 invariants are introduced to ensure timely progression of the derivation pipeline. In both cases, either a batch is correctly progressed or it is mapped into a deposits only batch.
If the batch data makes it
to the BatchQueue, then the batch is either properly deserialized and validated or is mapped into a "deposits only" batch.
This specifically describes the BatchDrop cases returned from CheckBatch.
If the Execution API on the EL returns INVALID, then the batch that produced the ExecutionPayload is mapped into a deposits only batch before
being attempted again as an ExecutionPayload. This particular check captures things like invalid nonces on transactions included
in a block.
With the launch of interop, an additional invariant will be added which involves mapping any batches that contain invalid executing messages into a deposits only batch.
It is possible to only enforce one of the two invariants, where we would want to drop the EL INVALID invariant in favor of
the batch queue invariant.
- This adds risk around unsafe head reorgs. To date, there has not been an unsafe head reorg. Cases where batches would be dropped and then there is another chance to progress the safe head via submitting another batch would be turned into unsafe reorgs. The software and ops have been hardened after running it in production for some time.