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

Introduce Symphony chains replacing Eth chain structures from ethers #26

Open
wants to merge 9 commits into
base: symphony-dev
Choose a base branch
from

Conversation

dereksione
Copy link

@dereksione dereksione commented Jun 29, 2023

Closes #7

This PR naively just substitutes all instances of goerli with the symphony devnet chain and seppolia with testnet.

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

@dereksione dereksione changed the title 8 new primitive crate Introduce Symphony chains replacing Eth chain structures from ethers Jun 29, 2023
@dereksione dereksione self-assigned this Jun 29, 2023
@dereksione dereksione marked this pull request as ready for review June 29, 2023 14:38
@dereksione
Copy link
Author

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}")
}
}
Copy link
Member

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;
Copy link
Member

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};
Copy link
Member

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),
Copy link
Member

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?

Copy link
Author

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

Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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.

Copy link
Member

@SuperFluffy SuperFluffy left a 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.

Cargo.toml Outdated Show resolved Hide resolved
bin/reth/Cargo.toml Outdated Show resolved Hide resolved
@@ -9,6 +9,9 @@ repository.workspace = true
description = "Commonly used types in reth."

[dependencies]
#symphony
symphony-primitives = { workspace = true }
Copy link
Member

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 {
Copy link
Member

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";
Copy link
Member

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?
Copy link
Member

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.
Copy link
Member

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!()
Copy link
Member

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?

Copy link
Author

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!()
Copy link
Member

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),
Copy link
Member

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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants