feat: inital support for Boojum format #48
Conversation
Introduces structs and calldata parsing for blocks formatted with the newer format.
zeapoz
force-pushed
the
feat/boojum-support
branch
from
0566611 to
18e725e
Compare
| struct Contracts { | ||
| v1: Contract, | ||
| v2: Contract, | ||
| } |
There was a problem hiding this comment.
I'm not a huge fan of this sort of structure, but it was the easiest to implement without merging the two ABI-files. If you have any thoughts/ideas, do let me know
There was a problem hiding this comment.
I think this is a good middle-ground solution. I have related notes below where I elaborate on this.
| struct Contracts { | ||
| v1: Contract, | ||
| v2: Contract, | ||
| } |
There was a problem hiding this comment.
I think this is a good middle-ground solution. I have related notes below where I elaborate on this.
| @@ -237,7 +244,7 @@ impl L1Fetcher { | |||
| disable_polling: bool, | |||
| ) -> Result<tokio::task::JoinHandle<()>> { | |||
| let metrics = self.metrics.clone(); | |||
| let event = self.contract.events_by_name("BlockCommit")?[0].clone(); | |||
| let event = self.contracts.v1.events_by_name("BlockCommit")?[0].clone(); | |||
There was a problem hiding this comment.
e.g. this reads quite well for me and I like this structure.
| } | ||
| let block_info = { | ||
| if use_new_format { | ||
| CommitBlockInfo::V2(v2::CommitBlockInfo::try_from(d)?) |
There was a problem hiding this comment.
Here I was thinking that maybe there could be some kind of a generic structure where the CommitBlockInfo could be built in a way that this could be written like CommitBlockInfo::<V2>::try_from(d)? - maybe?
I cannot figure out a concrete suggestion how the type would specifically look like in this case, but this is just an intuitive gut feeling.
There was a problem hiding this comment.
Good idea! I pushed a new commit that abstracts away the whole enum. So, it's now only used internally when creating the type.
| V2(v2::CommitBlockInfo), | ||
| } | ||
|
|
||
| // TODO: Do we need this? |
There was a problem hiding this comment.
Most probably not. If there is a need in the future, git would have the code so therefore I guess this can be zapped.
| /// NOTE: Does this make sense? | ||
| is_reapeated_write: bool, |
There was a problem hiding this comment.
I'd say yes in this case, when it works, but there is a slight typo though 😛 is_reapeated_write -> is_repeated_write 😉
| repeated_storage_changes: block.repeated_storage_changes, | ||
| factory_deps: block.factory_deps, | ||
| }, | ||
| CommitBlockInfo::V2(_block) => todo!(), |
There was a problem hiding this comment.
Is this todo!() on purpose?
There was a problem hiding this comment.
Yes, this will come later in the PR that fully implements the state reconstruction from these blocks. Figured it was easier to do split the functionality, rather than one PR with 3k LOC or so.
Co-authored-by: Tuomas Mäkinen <[email protected]>
Introduces structs and calldata-parsing for blocks formatted with the newer format.