-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Include p2p into fuel core #492
Conversation
@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 |
fuel-core/src/cli/run/p2p.rs
Outdated
match args.keypair { | ||
Some(path) => { | ||
let mut bytes = std::fs::read(path)?; | ||
Keypair::secp256k1_from_der(&mut bytes)? |
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 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.
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.
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
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.
Seems like we should migrate some of the mnemonics logic to fuel-crypto, to avoid requiring the whole SDK for key parsing.
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.
Makes sense to me.
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.
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 ?
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.
@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!
…beak/include_p2p_into_fuel_core
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 |
…beak/include_p2p_into_fuel_core
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.
LGTM, nothing block on my end, just some questions.
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 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. |
fuel-core/src/cli/run/p2p.rs
Outdated
let mut bytes = std::fs::read(path)?; | ||
Keypair::secp256k1_from_der(&mut bytes)? |
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 use the new fuel-crypto mnemonics to load/generate the secret key.
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 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
ok, now the last thing is to added the service into optional features |
added |
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.
Resolves #480
I have included both things in a single PR since once I included p2p into fuel-core and added
p2p
field toconfig
the cli part of the codebase was complaining.For clarity, there is:
Service
to keep in line with other modules that had top levelService
)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()
andstop()
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 aNetworkOrchestrator
field into a simplevariable
withinrun()
method, so oncerun()
ended (iestop()
was called) thep2p_service
would go out of scope and get removed completely.And if
start()
was called again, a newp2p_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()
andstop()
I have discovered a bug in our NetworkOrchestrator.It's field
outbound_responses
which was of typeonce called
next()
on it, it would returnNone
so in ourloop { tokio::select!...
pattern it was constantly returningNone
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.