-
Notifications
You must be signed in to change notification settings - Fork 245
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
refactor: add network-primitives #1101
Conversation
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, one nit
as dicussed we need this split so we can avoid cyclic dependencies for network/consensus/rpc
This also removes BlockTransactionHashesMut
this is reasonable I believe, I don't think we want to support this
crates/rpc-types-eth/src/block.rs
Outdated
@@ -14,7 +15,7 @@ pub use alloy_eips::{ | |||
/// Block representation | |||
#[derive(Clone, Debug, Default, PartialEq, Eq, Serialize, Deserialize)] | |||
#[serde(rename_all = "camelCase")] | |||
pub struct Block<T = Transaction> { | |||
pub struct 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.
hmm, can we keep this generic? otherwise we can't reuse that block type?
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.
right, this could be useful in some cases, though I think for most of the rollups entire Block
would be different as there'll be no withdrawals
for example, so we'd likely want to just add more reusable generic components for custom blocks (like BlockTransactions<T>
)
added generic back as it doesn't hurt anyway
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.
yep I also think this will be the case but this can be useful for rollups that only have 1 additional tx type 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.
ah now I get why we can't reuse the BlocktransactionsMut
lgtm
not sure what's up with the clippy error...
* refactor: add network-primitives * fix tests * fix docs * add re-exports * Block<T>
Motivation
alloy-rpc-types-eth
are supposed to be concrete, thus having generics on types defined in it is not helpful and makes it hard to define implementations based on traits from other crates.Solution
ReceiptResponse
andTransactionResponse
fromalloy-network
to new cratealloy-network-primitives
, allowing their usage without depending onalloy-network
BlockTransactions<T>
intonetwork-primitives
and provide implementations forT: TransactionResponse
instead of concreterpc_types_eth::Transaction
This sets us up for block response abstraction, making it possible to add getters for
BlockTransactions
generic overN::TransactionResponse
ref #267Note: This changed
Iterator::Item
forBlockTransactionHashes
from&B256
toB256
as this is whatTransactionResponse::tx_hash
returns. Is it fine or should I update the trait instead? It seems that it's OK to expectTransactionResponse
to own a hash.This also removes
BlockTransactionHashesMut
PR Checklist