-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
Co-Authored-By: Miguel Palhas <[email protected]>
Hey @mattsse ! |
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.
sweet!
I left a few suggestions, once addressed we can already include this and tackle the actual impl separately
#[async_trait] | ||
impl<Eth> OtterscanServer for OtterscanApi<Eth> | ||
where | ||
Eth: EthApiServer, |
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 might not be enough to fully support the otterscan API, but it is sufficient for now,
but can reevaluate later, see TraceApiImpl for example
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.
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 Report
... and 10 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
👍🏼 moving that discussion to #3726 since it seems more on-topic there |
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.
q re types.
this is a great first step,
good to merge @ZePedroResende ?
block_reward: String, | ||
uncle_reward: String, | ||
issuance: String, |
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.
these are likely U256 I believe?
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.
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 !
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.
EncodeBig encodes bigint as a hex string with 0x prefix.
This is the same behaviour
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.
Great ! I'll change it over to U256 then , thanks for catching this !
#[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize)] | ||
#[serde(rename_all = "camelCase")] | ||
pub struct BlockDetails { | ||
block: Block, |
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 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, |
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 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 ?
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.
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.
crates/rpc/rpc-api/src/otterscan.rs
Outdated
async fn search_transactions_after( | ||
&self, | ||
address: Address, | ||
block_number: U256, |
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.
@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
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.
they don't only hex strings, blocknumber should be U64, and there's also U64HexOrNumber
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 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.
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.
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.
lgtm
great start!
…nts (paradigmxyz#3778) Co-authored-by: Miguel Palhas <[email protected]> Co-authored-by: Matthias Seitz <[email protected]>
Motivation
This tackles the first step for #3726 by adding the namespace and trait bindings for the Otterscan RPC endpoints.
Solution
ots_
namespacerpc-api
rpc-types
rpc