fix: loosen bounds on CheckpointContext so we can override it

[akundaz]

The restriction introduced in #97 meant that we can't define our own custom checkpoint context when using the optimism platform functions.

See flashbots/unichain-builder#55

[julio4]

I see the issue but we still want to make context accessible in build_payload (as introduced in #97).
If we loosen bounds here we should find a way to still pass extra context info to build payload, maybe not as CheckpointContext?

[akundaz]

I see the issue but we still want to make context accessible in build_payload (as introduced in #97). If we loosen bounds here we should find a way to still pass extra context info to build payload, maybe not as CheckpointContext?

What is the use case for passing extra context info build payload?

[julio4]

I see the issue but we still want to make context accessible in build_payload (as introduced in #97). If we loosen bounds here we should find a way to still pass extra context info to build payload, maybe not as CheckpointContext?

What is the use case for passing extra context info build payload?

Being able to reuse some already computed infos to construct final payload (such as receipts). Atleast that's the idea

[akundaz]

I see the issue but we still want to make context accessible in build_payload (as introduced in #97). If we loosen bounds here we should find a way to still pass extra context info to build payload, maybe not as CheckpointContext?

What is the use case for passing extra context info build payload?

Being able to reuse some already computed infos to construct final payload (such as receipts). Atleast that's the idea

Honestly this is pretty vague to me... do you have a code reference to us doing this anywhere or a doc detailing this requirement? unichain-builder being able to compile from the latest rblib commit is a top priority

[julio4]

Honestly this is pretty vague to me... do you have a code reference to us doing this anywhere or a doc detailing this requirement? unichain-builder being able to compile from the latest rblib commit is a top priority

This is a feature we want because right now the build_payload implementation has no way to reuse the incremental computation artifacts of orders with checkpoints, such as execution results, receipts etc... This is the "re-execution for Payload Building" mentioned in the two significant bottlenecks doc (even though this doc focus on the traversal overhead and don't go in depth for the build payload one).

=> Having a way to share parts of the computation artifacts of checkpoints to the build payload function will allows platforms to implement performant final payload building.

But I agree for unichain-builder close feedback loop on last main commit, we can revert the changes after confirming how it is currently used and find a similar way that don't reduce platform flexibility too much.

[julio4]

let's merge it for now and revisit with an alternative solution