interop: specify conditions on state-transition and safety changes

[protolambda]

Description

Specify the "driver" component of the rollup node.

The "driver" is a concept from bedrock, except it used to be very synchronous, and parts of the functionality were under-specified or merged into derivation.

This replaces the engine-queue, and separates the jobs of the engine queue into encapsulated effects.

The derivation-process itself does not change: the existing derivation-pipeline is reused.

Effects are enacted based on conditions, and apply state-transition and/or block-safety changes.

This spec does not explicitly enshrine locks or threads, but does direct that each effect is meant to be processed asynchronously.

Tech-debt fixes

• The "is last in span-batch" condition applies to safety-changes, and is thus a property that is kept track of along the generated payload-attributes.
• Changes to the head of the chain, like unsafe block processing or sequencing, don't conflict with happy-path safe-block consolidation. If we implement it like this, then we will not see safe-head stalls when the unsafe blocks are processed slowly.
• Payload-attributes forcing (processing as new) and consolidation are separated better, since they do not require the same type of engine access.
• This is a step towards being able to optimistically queue up multiple payload-attributes, for faster processing.

Interop specifics

With interop we introduce the notion of cross-unsafe. This requires its own safety-progression effect, and its own safety-reversal effect.

Payload-attributes, derived from L1, are first just considered unsafe. Only with the emitted initiating messages can we fully resolve intra-block message dependency cycles with other chains. Then, with that data, the block can be promoted to cross-unsafe, and then to safe.

The dependency-checks of the cross-unsafe progression step are encapsulated, and to be specified separate from the driver behavior.

#Additional context

By making it more asynchronous, and by encapsulating the effects better, we can extend it with new long-running effects without direct effects on any processing that would previously have been synchronous and relatively tangled up.

Metadata

Fix https://github.com/ethereum-optimism/protocol-quest/issues/187

[tynes]

nit: typo implementations -> implementation

[tynes]

typo: test -> tests

[tynes]

@protolambda curious how you feel about this spec - what are the next steps with it?