tracking(driver): Refactor

[clabby]

Overview

This ticket serves as a tracking / discussion issue for the topic of refactoring kona-driver.

Right now, the kona-driver crate is a high-level stateful interface over the derivation pipeline (kona-derive) that handles:

1. Executing the pipeline until it produces a PayloadAttributes.
   • Or, if an error that requires a Signal to be sent to the pipeline (i.e. L1 reorg), dispatches the signal to trigger the reset action.
2. Sending the PayloadAttributes to the execution layer.
3. Updating the tracked safe head.

However, the abstractions are leaky. A few examples of this are:

1. The TipCursor keeps track of the output root of the latest block, which is not required for a rollup node. This is a proofs-specific need that leaked into the abstraction - the consumer instead should handle the generation of an output root for a given block, rather than relying on the driver to do this every time it receives a sealed block back from the EL.

kona/crates/driver/src/tip.rs

Lines 38 to 41 in dfed471

	/// Returns the output root of the L2 safe head.
	pub const fn l2_safe_head_output_root(&self) -> &B256 {
	&self.l2_safe_head_output_root
	}

2. The Executor interface doesn't conform well to the EL engine API, which makes it harder to integrate into an eventual rollup node. Also, it contains certain logic for output root generation, which should be external to the engine's interface.

kona/crates/driver/src/executor.rs

Lines 23 to 37 in dfed471

	/// Waits for the executor to be ready.
	async fn wait_until_ready(&mut self);
	/// Updates the safe header.
	fn update_safe_head(&mut self, header: Sealed<Header>);
	/// Execute the gicen [OpPayloadAttributes].
	async fn execute_payload(
	&mut self,
	attributes: OpPayloadAttributes,
	) -> Result<Header, Self::Error>;
	/// Computes the output root.
	/// Expected to be called after the payload has been executed.
	fn compute_output_root(&mut self) -> Result<B256, Self::Error>;

3. The Driver in core.rs is much too proof-specific, advancing to a given L2 block number target and returning just the hash of the block without any side-effects such as updating safety labels, etc. The proofs-specific driver ideally should be separated, and we should offer a concrete implementation that is extensible enough to fit both a rollup node and the proof while also allowing reuse of common functionality.

kona/crates/driver/src/core.rs

Lines 72 to 76 in dfed471

	pub async fn advance_to_target(
	&mut self,
	cfg: &RollupConfig,
	mut target: Option<u64>,
	) -> DriverResult<(u64, B256, B256), E::Error> {

[clabby]

Leaving a few notes here before the week - would like to start thinking about some concrete steps here soon. This crate was initially made for some initial efforts on hilo, but never got too much love. Would like to make sure we're working towards these primitives being useful for upstream consumption :)