Report: A study of libp2p and ETH2

Ecosystem and Community
1

The MolochDAO commissioned Matthew Slipper from Kyokan to produce an assessment of the state of affairs on the ETH2.0 >< libp2p collaboration.

Matthew interviewed:

  • four ETH2.0 implementation teams.
  • the libp2p project leads here at Protocol Labs.

to collect impressions, perspectives and suggestions in a neutral, unbiased fashion.

The report is out. It’s concise, eloquent, and well-founded. Read it here:

This document will help grease the wheels of an unprecedented collaboration in the space of P2P networking. After all, the decentralised web is built atop unstoppable networks. Why reinvent the wheel at every project out there? Fragmentation is involution, not evolution. Why not unite communities to build a modular, rock-solid OSS library that any project can rely on?

My key takeaways from this report are:

  1. Co-funding libp2p work with the Ethereum Foundation: we need to establish a public pathway for talented teams/engineers to acquire funds to hack on libp2p.
    • We’ve long talked about formalising a DevRFP programme that encourages experimentation and heterogeneity, and we need to expedite this.
    • So far, we’ve issued (or pre-approved) a series of discretionary grants for teams that have approached us directly, examples being jvm-libp2p (Harmony) and nim-libp2p (Status.im).
  2. The libp2p team at Protocol Labs needs to scale. We need to HIRE MORE TALENT, FASTER.
    • We need to onboard a brilliant, full-time, multi-lingual (Go, Rust, JS, Java, etc.) go-getter within the next weeks/month to act as a forward-deployed engineer for ETH2.0 teams.
    • They’ll engage hands-on with them to advise, hack, debug, optimise and iron things out, informing into the libp2p community and engineering efforts to help us improve the technology.
    • Interested in working full-time on libp2p and ETH2.0? Fit the description? Apply below, or ping me via DM on Twitter:
  3. Forward conversations to structured, collaborative discussion channels. The hub-and-spoke model of me serving as a point-person via Gitter, Twitter, Telegram, Email, etc. scales poorly. It fulfilled the goal of jumpstarting this collaboration, but it’s turned inefficient now that efforts have matured, and the need for more structure has manifested.
    • The libp2p team/community at large are fully/better qualified to answer many questions.
    • There’s a person tasked with monitoring these forums, and watching that posts get answered promptly and accurately: @yusef. Refer to the forum operation protocol.
    • Discussing here – rather than privately or across venues – creates a running, public indexable knowledge base that (a) seeds future searches, (b), serves as publicly referenceable material, (c) enables people to lurk and level up their knowledge by observing.
    • There’s enough libp2p expertise in the world for users to answer other users’ questions, and we should leverage that by transforming this community into a collaborative vortex – which is also the hallmark of successful OSS ecosystems like the Apache Software Foundation.
  4. Begin to norm on community alignment and governance processes. Challenges we’ve identified include: keeping implementations in sync as specs evolve, conformance test kits, efficient and expeditious RFC/spec’ing process, addressing compatibility issues, continuous interoperability testing, conflicts of interest between implementations, unified/single-point-of-entry documentation site, etc.
  5. Encourage folks to report concrete issues: the more concrete you get with voicing out issues or concerns, the more readily people will help you. It’s in your best interest. If you can lend a hand to fix whatever is broken, plus points! Remember: libp2p is an OSS project, not a monetised product with customer support.
    • When reporting technical issues, attach log outputs, CPU profiles, heap dumps, etc. Specify the environment and explain steps for reproduction are. Be available for follow-up questions.
    • When suggesting improvements, remove the frustration and emotion out of the discourse. State how the dysfunction impacts you objectively, and propose the solutions you can think of. We’re building this community together. We’re not perfect, but we’re friends, and we want to make things rock’n’roll for everyone.
3 Likes
2

This is a really positive response to the Kyokan report!.

When I’ve assessed libp2p for Tendermint/Cosmos, I’ve come to similar conclusions about the state of project and advocated to keep resources on our own connection and peer discovery layer.

It would be great to share more resources with other projects at this layer. I’m watching closely and would love to update my recommendations but I don’t want to jump into solving yet another multi project coordination problem. I’m already doing so many of those.

1 Like
3

Thanks for kicking this off Raul.

At the risk of sounding like a broken record, I think it might be interesting to coordinate cross-organizational grants around libp2p tooling and client dev through a libp2p specific deployment of a MolochDAO, with the EF and PL providing the bulk of the funds (and thus getting the most decision making power) but also accepting smaller contributions from Cosmos, Web3F, and others so we can reduce redundant work. The DAO could use any ERC20, so if the members prefer, we could use DAI.

This organization could help act as a signal for libp2p talent discovery as well—Moloch has been fairly successful thus far at accelerating the DevRFP process for various Ethereum initiatives.

1 Like
4

Hi @raul and @ameensol - reaching out by request of my colleagues at Golem building our networking stack on libp2p -Rust .
We are interested in learning more and possibly taking part. This is a very important subject and a priority for us.
Could we arrange a call with my tech team?

1 Like