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

Include p2p into fuel core #492

Merged
merged 36 commits into from
Aug 24, 2022

Conversation

leviathanbeak
Copy link
Contributor

Resolves #480

I have included both things in a single PR since once I included p2p into fuel-core and added p2p field to config the cli part of the codebase was complaining.

For clarity, there is:

  • P2pService
  • NetworkOrchestrator which contains P2pService
  • Service which wraps the NetworkOrchestrator (I have named it Service to keep in line with other modules that had top level Service)

Creating the top level Service

I have went and implemented a similar pattern for the network as our other Services have done, by adding start() and stop() methods.

I have achieved that by wrapping the NetworkOrchestrator into a Service but I had to change some things:

P2P Service and Network needed to shut down

Unlike some other simpler Services, once network Service was stopped, we needed to shut down the whole p2p network.
I have achieved that by moving p2p_service from a NetworkOrchestrator field into a simple variable within run() method, so once run() ended (ie stop() was called) the p2p_service would go out of scope and get removed completely.

And if start() was called again, a new p2p_service would be instantiated - I had to keep the p2p_config within the NetworkOrchestrator for this case.

FuturesUnordered and their blocking of the executor

While testing out start() and stop() I have discovered a bug in our NetworkOrchestrator.

It's field outbound_responses which was of type

type ResponseFuture = Pin<Box<dyn Future<Output = Option<(OutboundResponse, RequestId)>>>>;
FuturesUnordered<ResponseFuture>

once called next() on it, it would return None so in our loop { tokio::select!... pattern it was constantly returning None
without letting any other items to be polled, basically it was blocking the executor. I discovered this while adding tokio's sleep within a test, and it never got to finish! So I have changed this part of the code slightly by using tokio's channels instead of FuturesUnordered.

There were few other changes and clean ups.

@leviathanbeak
Copy link
Contributor Author

@rakita I have just passed some of the p2p channels into other services and removed the placeholders, please review and let me know if they are correct

match args.keypair {
Some(path) => {
let mut bytes = std::fs::read(path)?;
Keypair::secp256k1_from_der(&mut bytes)?
Copy link
Member

@Voxelot Voxelot Jul 20, 2022

Choose a reason for hiding this comment

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

Should we also include a cli command for randomly generating libp2p keyfiles? Otherwise it will be hard to configure a multinode deployment if the keys are generated on the fly, since we won't know the bootnode peer id in advance.

Also this might be something we want to check with @digorithm about standardizing keyfile formats to use mnemonics instead of binary serialization. If we had a standard mnemonic format it would be a lot easier for users to setup their peering keys without needing additional keygen tools or cli commands.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, the SDK and fuel-crypto have some primitives around keygen/mnemonics. Maybe we should use those here.

SDK documentation for wallets/mnemonics: https://fuellabs.github.io/fuels-rs/v0.19.0/wallets/mnemonic-wallet.html

fuel-crypto documentation for SecretKey generation: https://docs.rs/fuels/latest/fuels/signers/fuel_crypto/struct.SecretKey.html

Copy link
Member

Choose a reason for hiding this comment

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

Seems like we should migrate some of the mnemonics logic to fuel-crypto, to avoid requiring the whole SDK for key parsing.

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

great, should we then create a separate ticket for migrating that logic to fuel-crypto and another for incorporating it in a new cli command ?

Copy link
Member

@digorithm digorithm Aug 2, 2022

Choose a reason for hiding this comment

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

@Voxelot already created one for migrating the logic to fuel-crypto: FuelLabs/fuel-crypto#27

I guess we need another one for the latter as you said!

@bvrooman bvrooman mentioned this pull request Jul 28, 2022
@Voxelot Voxelot removed the request for review from rakita August 2, 2022 00:40
@ControlCplusControlV
Copy link
Contributor

Sorry for re-running clippy showing the rust 1.63 errors, I needed a sanity check against my upstream branch since I wasn't sure if clippy changes had been moved to this branch yet. Once you can finish merge conflicts @leviathanbeak I can re-review and then we can get this moved as git history is starting to get very long

Copy link
Contributor

@ControlCplusControlV ControlCplusControlV left a comment

Choose a reason for hiding this comment

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

LGTM, nothing block on my end, just some questions.

@Voxelot
Copy link
Member

Voxelot commented Aug 17, 2022

I'm starting to get concerned with the weight of all the extra dependencies being linked to fuel-core. Can we put the service under a feature flag, so that libp2p is not compiled or included when --no-default-features is used when building fuel-core? We should also do this for the relayer.

Since the SDK uses fuel-core in it's test harness, it would be much more efficient if contract testing didn't load in big deps like ethers, libp2p and rocksdb.

Comment on lines 99 to 100
let mut bytes = std::fs::read(path)?;
Keypair::secp256k1_from_der(&mut bytes)?
Copy link
Member

Choose a reason for hiding this comment

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

This should use the new fuel-crypto mnemonics to load/generate the secret key.

Copy link
Contributor Author

@leviathanbeak leviathanbeak Aug 18, 2022

Choose a reason for hiding this comment

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

I switched to using fuel-crypto for both loading a mnemonic and generating a random key,

Since libp2p's Keypair struct was needed for p2pConfig I have added a function to convert from fuel-crypto's SecretKey into libp2p's SecretKey -> Keypair

@leviathanbeak
Copy link
Contributor Author

ok, now the last thing is to added the service into optional features

@leviathanbeak
Copy link
Contributor Author

added p2p optional feature to fuel-core

fuel-core/Cargo.toml Outdated Show resolved Hide resolved
Copy link
Contributor

@ControlCplusControlV ControlCplusControlV left a comment

Choose a reason for hiding this comment

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

clippy-ship-it

@leviathanbeak leviathanbeak merged commit e50553a into master Aug 24, 2022
@leviathanbeak leviathanbeak deleted the leviathanbeak/include_p2p_into_fuel_core branch August 24, 2022 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Integrate p2p-orchestrator into fuel-core and expose configuration
5 participants