-
Notifications
You must be signed in to change notification settings - Fork 256
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: add initial EIP-7547 engine types #287
Conversation
procedural question, should in-progress EIPs be homed in |
For this one it could be, since it would not cause any circular deps. But if an in progress eip needed a transaction type for example, it would cause problems. IMO despite this one not causing circular issues, it seems best to just have it as a draft PR to the place where it will eventually live (rpc-engine-types). |
another option would be to have a specific crate alloy-eipXXXX for these while they're in progress and not accepted |
that makes sense! |
This is now in the eip7547 crate |
@@ -20,6 +20,7 @@ rustdoc-args = ["--cfg", "docsrs"] | |||
alloy-consensus = { version = "0.1.0", default-features = false, path = "crates/consensus" } | |||
alloy-contract = { version = "0.1.0", default-features = false, path = "crates/contract" } | |||
alloy-eips = { version = "0.1.0", default-features = false, path = "crates/eips" } | |||
alloy-eip7547 = { version = "0.1.0", default-features = false, path = "crates/eip7547" } |
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.
key here doesn't match package name. different hyphenation. standardize on eip7547
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.
whoops, just fixed
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.
UTACK. I have not reviewed these types for conformance, but given this is a pre-finalization EIP i don't think that matters much
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.
quantity should be hex
https://ethereum.org/en/developers/docs/apis/json-rpc/#quantities-encoding
crates/eip7547/src/summary.rs
Outdated
/// The nonce of the inclusion list entry. | ||
pub nonce: u64, |
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 hex serde?
crates/eip7547/src/summary.rs
Outdated
/// The slot of the inclusion list summary. | ||
pub slot: u64, | ||
/// The proposer index of the inclusion list summary. | ||
pub proposer_index: u64, |
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 be hex?
crates/eip7547/src/summary.rs
Outdated
@@ -82,7 +82,7 @@ pub struct InclusionListSummaryEntryV1 { | |||
/// The address of the inclusion list entry. | |||
pub address: Address, | |||
/// The nonce of the inclusion list entry. | |||
pub nonce: u64, | |||
pub nonce: U64, |
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.
can we use u64 and serde_with alloy_serde::u64_hex for all U64?
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.
whoops, yeah
Motivation
Inclusion lists are being implemented by clients for a poc:
ethereum/go-ethereum@3fd8199
To do this for reth, we'll need to get the proper rpc types, so we can implement the calls in reth.
Solution
Implemented the types defined in michaelneuder/execution-apis#1
PR Checklist