-
Notifications
You must be signed in to change notification settings - Fork 0
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
Introduce Symphony chains replacing Eth chain structures from ethers
#26
base: symphony-dev
Are you sure you want to change the base?
Conversation
…o 8-new-primitive-crate
ethers
Meta: I realized that the massive PR approach that I was taking was just not working out, so I'm splitting those up into more atomic PRs, and even though the interim code is a little ugly sometimes to make it compile, it will be more manageable in terms of requesting reviews and making consistent and transparent progress |
|
||
write!(f, "symphony-{chain_name}") | ||
} | ||
} |
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.
nit: new line
|
||
pub const MAINNET_ID: u64 = 70047; | ||
pub const DEVNET_ID: u64 = 70048; | ||
pub const TESTNET_ID: u64 = 70049; |
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.
nit: new line
pub mod constants; | ||
pub mod chains; | ||
|
||
pub use chains::{SymphonyChains, SymphonyChainError}; |
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.
nit: new line
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize)] | ||
pub enum Chain { | ||
/// Contains a known chain | ||
Named(ethers_core::types::Chain), | ||
Named(SymphonyChains), |
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.
Could we fork ethers potentially instead and update as others have. This might solve the test issues above. We could also then potentially reuse goerli and sepolia names but point at OUR named in ethers devnet and testnet chains. Would likely negate most of the changes here?
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.
We could, but I have a suspicion that they are going to replace this with an alloy implementation soon, so maybe we can hold off on that? Open to suggestions
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.
It looks like there will "soon" be an alloy-rs/chains
repo.
It seems either way there is likely a refactor of this work, if alloy-rs/chains
is very different we need to redo, and it might make more sense to push our chain definition into there than here.
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.
@joroshiba Do you think it's a bad idea to temporarily park it here and then upstream it when they move to alloy?
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 first thought when looking at the primitives and the uncommented changes was also: "this will be annoying to rebase on top of reth changes".
If ethers/alloy have done something akin to introducing new chains, maybe we can follow in their footsteps? Even if they will soon replace ethers will alloy this means that we can profit from their well worn path.
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.
On first glance the changes look reasonable.
If however this symphony fork is happening at the wrong level (re @joroshiba's comments further down) I would ask to consider introducing our fork in a similar way that ethers/alloy are doing.
Forking is a big commitment if we want to stay up-to-date with upstream and forking the wrong thing can lead to a lot of work down the road.
@@ -9,6 +9,9 @@ repository.workspace = true | |||
description = "Commonly used types in reth." | |||
|
|||
[dependencies] | |||
#symphony | |||
symphony-primitives = { workspace = true } |
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 realize I have never thought about this too much - but why is this a workspace dependency rather than a path dependency? I.e.:
symphony-primitives = { path = "../symphony-primitives" }
} | ||
|
||
#[derive(Debug)] | ||
pub enum SymphonyChainError { |
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.
IMO the errors need not be grouped but can be 2 separate error types (I made them wrap ()
so they cannot be constructed outside this crate):
pub struct UnrecognizedChainId(());
// Clearer name for the second error
pub struct UnrecognizedChainName(());
Also, please add doc comments on the errors, but especially implement std::error::Error
.
@@ -0,0 +1,7 @@ | |||
pub const MAINNET_NAME: &str = "MAINNET"; |
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.
Could they be lower-cased by default if they are only displated as to_lowercase()
in their display impl?
|
||
type Strategy = BoxedStrategy<Chain>; | ||
} | ||
// FIXME: what does this do? |
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 stuff is relevant to set up the proptest further down (which you probably know 😄; but the FIXME was here, so I am answering the question here ^^ ).
} | ||
|
||
/// Returns bootnodes for the given chain. | ||
/// Returns bootnodes for the given chain. |
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.
redundant space at the end
Sepolia => Some(sepolia_nodes()), | ||
_ => None, | ||
} | ||
todo!() |
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.
probably remove the todo!
before 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.
Need to keep the todo because this function is used in other places
/// Returns the address of the public DNS node list for the given chain. | ||
/// | ||
/// See also <https://github.com/ethereum/discv4-dns-lists> | ||
pub fn public_dns_network_protocol(self) -> Option<String> { | ||
use ethers_core::types::Chain::*; | ||
const DNS_PREFIX: &str = "enrtree://AKA3AM6LPBYEUDMVNU3BSVQJ5AD45Y7YPOHJLEF6W26QOE4VTUDPE@"; | ||
todo!() |
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.
remove todo!
before merge?
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize)] | ||
pub enum Chain { | ||
/// Contains a known chain | ||
Named(ethers_core::types::Chain), | ||
Named(SymphonyChains), |
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 first thought when looking at the primitives and the uncommented changes was also: "this will be annoying to rebase on top of reth changes".
If ethers/alloy have done something akin to introducing new chains, maybe we can follow in their footsteps? Even if they will soon replace ethers will alloy this means that we can profit from their well worn path.
Co-authored-by: Richard Janis Goldschmidt <[email protected]>
Closes #7
This PR naively just substitutes all instances of goerli with the symphony
devnet
chain and seppolia withtestnet
.This does not address any of the work highlighted in #13, #14, #17, #19, #24, #25
Those are going to be future improvements based off of this PR