-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing Otterscan support #5414
Conversation
Adds anvil support for Otterscan's custom RPC endpoints. This is still a work in progress, as I have two endpoints to implement still, but they should be **easy** (famous last words) compared to a lot of the others, so I'm opening this ahead of time to gather feedback. This was a bit tricky for a couple of reasons: * Otterscan's endpoints are inherently hard to compute with existing data (otherwise they wouldn't be needed in the first place). They solve things that the original RPC spec didn't account for (most notably, listing historical transactions by address). For anvil, this is mostly a non-issue, as we can choose to traverse all the blocks & traces in-memory. Would be interesting to test this on an node with a heavy data-set though; * After having gone through the spec, it seems to not be as well though-out as it could, and in some cases outdated compared to their code. Some of the design decisions behind it are a bit awkward to implement (see otterscan/otterscan#1081).
@Evalir couple questions:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey hey! tysm for this—this is awesome.
i have some comments/clarifications so we can keep this going—i tried to check for correctness but the best way to keep testing is probably to keep testing directly with otterscan and see what it likes or doesn't like.
cc @mattsse beefy pr so ideally we'd have two eyes on this
/// Otterscan's `ots_getApiLevel` endpoint | ||
#[cfg(feature = "otterscan")] | ||
#[cfg_attr(feature = "serde", serde(rename = "erigon_getHeaderByNumber"))] | ||
ErigonGetHeaderByNumber( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be called so? If so, can we add a bit of context as to why it has erigon naming? not super familiar with otterscan so just wanna make sure we have this documented 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I documented the impl EthApi
functions, but now that you mention, probably most of those comments belong here instead
As for this particular one, it's otterscan being a bit sneaky and making an erigon-specific call on load to "check if we're connected to an erigon node". In practice I think they could achieve the same result (show a proper error msg when the node isnt' supported) by using ay other ots_ endpoint, but oh well.
Perhaps I'll change that upstream later. for now it's reported here, waiting for input: otterscan/otterscan#1081
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another batch of comments, but this should be real close
@mattsse would love your eyes on this!
anvil/src/eth/api.rs
Outdated
) -> Result<Option<Block<TxHash>>> { | ||
node_info!("ots_getApiLevel"); | ||
|
||
// TODO: probably only return blocks from before the fork? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you determine what this should be? IMO it's fine if it's only post-fork.
Co-authored-by: evalir <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is fantastic.
all of this looks very good already, only have a few needs re organization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is beautiful—I'd just like docs for the things that don't have any.
Will look at solving the last todo as well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
amazing, this will be super useful
haven't reviewed the new handler impls too closely but all they do is add additional features so should be fine
@Evalir I believe everything's now done! (I'll later create an issue on the book repo, and probably work on it as well) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is beautiful. Amazing work @naps62 — it was such a pleasure reviewing this!
Comply w/ foundry-rs/foundry#5414 Co-authored-by: Trajan0x <[email protected]>
adds a local otterscan block explorer for the anvil ethereum mainnet, helps to see what's happening on the base network. (they[ recently added support](foundry-rs/foundry#5414) for otterscan in anvil) the transactions/calls are not decoded, so right now it's primarily useful if we are using portal contracts - hard to tell what the rollup contracts are doing. sets the local otterscan at http://localhost:5100/ https://github.com/AztecProtocol/aztec-packages/assets/142251406/0dd83352-103b-4b75-8fb6-baff5f0eee6b
adds a local otterscan block explorer for the anvil ethereum mainnet, helps to see what's happening on the base network. (they[ recently added support](foundry-rs/foundry#5414) for otterscan in anvil) the transactions/calls are not decoded, so right now it's primarily useful if we are using portal contracts - hard to tell what the rollup contracts are doing. sets the local otterscan at http://localhost:5100/ https://github.com/AztecProtocol/aztec-packages/assets/142251406/0dd83352-103b-4b75-8fb6-baff5f0eee6b
Otterscan works on |
Motivation
The people want Etherscan for their anvil nodes.
Solution
Implements the Otterscan JSON RPC namespace, along with all the quirks that were found to be needed.
Some of the code is a bit messier than I'd like,
This is still a work in progress, as I have two endpoints to implement still, but they should be easy (famous last words) compared to a lot of the others, so I'm opening this ahead of time to gather feedback.
The code is also a bit messier than I'd like, but I was trying to touch as little as possible on
Backend
and other modules. maybe there's some patterns or utility function I missed in the codebase that could have helped, so feedback is much appreciated!This was also a bit tricky for a couple of reasons:
todo list