feat: allow for user defined checkpoint metadata #78
Conversation
akundaz
force-pushed
the
ak-checkpoint-state
branch
from
bf0e1ed to
de7f40f
Compare
|
|
||
| impl Platform for Ethereum { | ||
| type Bundle = FlashbotsBundle<Self>; | ||
| type CheckpointMetadata = EmptyMetadata; |
There was a problem hiding this comment.
How about we make rust unit type () the empty metadata type?
There was a problem hiding this comment.
That doesn't impl Display, so I had to make a new type, unless we're fine with using the Debug formatting in the checkpoint display
There was a problem hiding this comment.
It's ok to not have Display. Display on the metadata type would actually be too strict of a trait bound for this scenario imo.
| #[derive(Debug, derive_more::Display, Default, Clone)] | ||
| pub struct EmptyMetadata; |
There was a problem hiding this comment.
impl<P: Platform> CheckpointMetadata<P> for () {}
|
Looks great! Let's just tweak the public API a little bit. |
julio4
left a comment
julio4
left a comment
There was a problem hiding this comment.
This is good!
I generally think that we should be careful about changing API and that moving to a builder pattern should be discussed separately.
Also, we should try to not overload too much method and try to extract metadata from within checkpoint when possible.
And lastly, we attach metadata to checkpoint but this is basically a state that is passed across checkpoint to give more context required by some platform. I think maybe metadata is not exactly the correct name, maybe something like BuildingContext could be more relevant if I understood this correctly.
What do you think?
| let metadata = payload.metadata().clone(); | ||
| let mut orders = self | ||
| .order_pool | ||
| .best_orders_for_block(ctx.block(), &metadata); |
There was a problem hiding this comment.
Is the clone necessary, can't we just take the metadata reference from payload directly?
| db: &DB, | ||
| metadata: &P::CheckpointMetadata, |
There was a problem hiding this comment.
technically we pass checkpoint as db here, so maybe we can slightly change this to extract metadata without having to add metadata arg.
|
Now that we will have |
3 participants
Add an associated type to
Platformto hold state that is passed around with checkpoints. This makes it easier to write features like flashblocks, since multiple steps need to access the flashblock number and so we currently define state outside the pipeline and share it with those steps. This PR also makes it possible to access this state during bundle filtering, so we will can filter on flashblock numbers.Checkpoint metadata can be accessed via
checkpoint.metadata()and can be updated likecheckpoint.execute(tx).metadata(new_metadata).apply(). If metadata isn't set for the next checkpoint then the current checkpoint's metadata is cloned to the next checkpoint.I refactored the checkpoint construction api because we want to be able to optionally set tags and/or metadata. Instead of
apply(tx)orbarrier()returning the next checkpoint, theexecute(tx)andbarrier()methods now returnCheckpointBuilderinstances which has anapply()method to create the next checkpoint, along withtagandmetadatasetter functions. This results in more verbose code but it seems like the clearest way to enable metadata and tags.