Skip to content

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}")
}
} No newline at end of file
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; No newline at end of file
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

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?

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

@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.


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

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 {

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";

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?

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.

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!()

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

pub fn public_dns_network_protocol(self) -> Option<String> {
use ethers_core::types::Chain::*;
const DNS_PREFIX: &str = "enrtree://AKA3AM6LPBYEUDMVNU3BSVQJ5AD45Y7YPOHJLEF6W26QOE4VTUDPE@";
todo!()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove todo! before merge?

pub enum Chain {
/// Contains a known chain
Named(ethers_core::types::Chain),
Named(SymphonyChains),

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.

5 participants