Skip to content
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

feat(rpc): Add ots_ namespace and trait bindings for Otterscan Endpoints #3778

Merged
merged 9 commits into from
Jul 19, 2023

Conversation

ZePedroResende
Copy link
Contributor

Motivation

This tackles the first step for #3726 by adding the namespace and trait bindings for the Otterscan RPC endpoints.

Solution

  • Add ots_ namespace
  • Add the Otterscan trait to rpc-api
  • Add necessary custom types for responses to rpc-types
  • Add a placeholder implementation of the trait to rpc

@ZePedroResende ZePedroResende marked this pull request as draft July 14, 2023 10:28
@ZePedroResende
Copy link
Contributor Author

Hey @mattsse !
If you have any feedback we would love to hear about it !

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet!

I left a few suggestions, once addressed we can already include this and tackle the actual impl separately

crates/rpc/rpc/src/otterscan.rs Outdated Show resolved Hide resolved
crates/rpc/rpc/src/otterscan.rs Outdated Show resolved Hide resolved
#[async_trait]
impl<Eth> OtterscanServer for OtterscanApi<Eth>
where
Eth: EthApiServer,
Copy link
Collaborator

@mattsse mattsse Jul 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might not be enough to fully support the otterscan API, but it is sufficient for now,

but can reevaluate later, see TraceApiImpl for example

@ZePedroResende ZePedroResende requested a review from mattsse July 14, 2023 14:49
Copy link
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main Q/concern here is: What new tables are needed to support these APIs?

Could we scope them very clearly, as well as understand 1) what stages (if any) we need to add to generate these new tables, 2) how much DB overhead they incur?

@codecov
Copy link

codecov bot commented Jul 15, 2023

Codecov Report

Merging #3778 (9babe78) into main (314e561) will decrease coverage by 0.03%.
The diff coverage is 1.25%.

Impacted file tree graph

Impacted Files Coverage Δ
crates/rpc/rpc-api/src/otterscan.rs 0.00% <0.00%> (ø)
crates/rpc/rpc-types/src/otterscan.rs 0.00% <0.00%> (ø)
crates/rpc/rpc/src/otterscan.rs 0.00% <0.00%> (ø)
crates/rpc/rpc-builder/src/lib.rs 65.16% <14.28%> (-0.37%) ⬇️

... and 10 files with indirect coverage changes

Flag Coverage Δ
integration-tests 15.55% <0.00%> (+<0.01%) ⬆️
unit-tests 64.16% <1.25%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
reth binary 26.48% <ø> (ø)
blockchain tree 83.02% <ø> (ø)
pipeline 89.60% <ø> (ø)
storage (db) 74.26% <ø> (ø)
trie 94.65% <ø> (ø)
txpool 46.55% <ø> (+0.56%) ⬆️
networking 77.70% <ø> (+0.05%) ⬆️
rpc 57.55% <1.25%> (-0.38%) ⬇️
consensus 65.61% <ø> (ø)
revm 33.73% <ø> (ø)
payload builder 6.61% <ø> (ø)
primitives 88.07% <ø> (+<0.01%) ⬆️

@naps62
Copy link
Contributor

naps62 commented Jul 15, 2023

👍🏼 moving that discussion to #3726 since it seems more on-topic there

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

q re types.

this is a great first step,
good to merge @ZePedroResende ?

Comment on lines 42 to 44
block_reward: String,
uncle_reward: String,
issuance: String,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are likely U256 I believe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question ! Well to get this one i had to read the Go code ,

type internalIssuance struct {
	BlockReward string `json:"blockReward,omitempty"`
	UncleReward string `json:"uncleReward,omitempty"`
	Issuance    string `json:"issuance,omitempty"`
}

this is the Go struct , and the values are the result of EncodeBig

	ret.BlockReward = hexutil.EncodeBig(minerReward.ToBig())
	ret.Issuance = hexutil.EncodeBig(issuance.ToBig())
	...
	ret.UncleReward = hexutil.EncodeBig(issuance.ToBig())

that from the documentation we get

// EncodeBig encodes bigint as a hex string with 0x prefix.

I took the easy route of just reusing the Go type but i would love to know if it still makes sense to use a U256 and have a custom serializer or if the default U256 serializer behaviour is similar to the EncodeBig output !

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EncodeBig encodes bigint as a hex string with 0x prefix.

This is the same behaviour

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great ! I'll change it over to U256 then , thanks for catching this !

@mattsse mattsse added the A-rpc Related to the RPC implementation label Jul 16, 2023
@mattsse mattsse marked this pull request as ready for review July 16, 2023 09:03
#[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct BlockDetails {
block: Block,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't notice this at first, but we need a custom serializer (or an entirely different struct even) for this block

e.g.: ots_getBlockDetails does not want the transactions attribute, and instead wants a transactionCount (inside the Block, not as another BlockDetails attribute, as I had understood initially)

#[serde(rename_all = "camelCase")]
pub struct TransactionsWithReceipts {
txs: Vec<Transaction>,
receipts: TransactionReceipt,
Copy link
Contributor

@naps62 naps62 Jul 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a Vec

but more importantly, I'm finding now (while working on anvil) that the response otterscan expects doesn't quite match what their spec says,

e.g. for ots_getBlockTransactions, they apparently expect something like:

{
fullblock: { transactions: [ ... ], transactionCount: xx, ... /* all the other usual fields */ },
receipts: [ ... ]
}

which is not what the spec says.

overall, maybe it's better to hold off on these structs and instead add them 1 by 1 as we figure out these inconsistencies
wdyt @mattsse ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad ! Should have doubled checked this.
We really need to write some tests , with some request responses then check that the serializations and deserializations matches up.

async fn search_transactions_after(
&self,
address: Address,
block_number: U256,
Copy link
Contributor

@naps62 naps62 Jul 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattsse do these deserialize from integers in reth?
I had problems doing the equivalent in anvil (foundry-rs/foundry#5414)
Otterscan sends 1, but the deserializer expected only "1". had to switch to u64 over there

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they don't only hex strings, blocknumber should be U64, and there's also U64HexOrNumber

Copy link
Contributor Author

@ZePedroResende ZePedroResende Jul 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used BlockNumberOrTag that is also used on the engine RCP endpoints is that ok or should we use the explicit u64 ?
If that is ok , i think on our side it's ready to merge.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
great start!

@mattsse mattsse enabled auto-merge July 18, 2023 14:02
@mattsse mattsse added this pull request to the merge queue Jul 18, 2023
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 18, 2023
@mattsse mattsse added this pull request to the merge queue Jul 18, 2023
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 18, 2023
@mattsse mattsse enabled auto-merge July 18, 2023 22:44
@mattsse mattsse added this pull request to the merge queue Jul 18, 2023
Merged via the queue into paradigmxyz:main with commit 170e6f2 Jul 19, 2023
merklefruit pushed a commit to anton-rs/op-reth that referenced this pull request Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc Related to the RPC implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants