ProbeLab Fundraising Roadmap - 2024H1 (Tentative)

[yiannisbot]

Description

This is the tentative roadmap with which the ProbeLab team will be fundraising for H1 of 2024. A fourth item might be added, subject to sponsorship and effort needed.

• The roadmap will be finalised once the fundraising period is over.
• This issue exists as a place to foster discussion around the selected roadmap items. Anyone should feel free to comment on these items and/or suggest new ones.
• The roadmap items are not stack ranked, meaning that they won't necessarily be dealt with in this order.
• A document will be shared here in the next few days with more details on the fundraising process.

IPNS Performance Measurement and Protocol Improvement

• Effort Estimate: 3 dev months

• Summary: Investigate the protocol design choices of the InterPlanetary Name System and identify space for performance improvement. We will investigate whether the InterPlanetary Name System is as fast as can be and ideate towards an IPNS-v2 design.

• Description: We hypothesize that some design choices of IPNS are slowing down performance (e.g., quorum size). We also expect that alternative, smart designs, such as Optimistic Provide, which is now integrated into kubo can improve IPNS performance significantly. We will develop tools and orchestrate the right infrastructure to investigate those alternative directions and propose improvements as needed.

  Tasks for this milestone include:

  • Impact of quorum on performance - measure the performance of getting IPNS records from the network with different quorum values.
  • Quantify usage of IPNS in the ENS ecosystem and improvement directions in terms of performance and adoption by the ENS ecosystem.
  • Investigate option to use proximity estimation (like in Optimistic Provide) to terminate the query early.
  • Use Optimistic Provide to put IPNS records into the network (as it’s currently done for provider records).
  • Beyond performance: how would IPNS-v2 look like, what would it be able to solve that cannot be solved today? Which early design decisions could be improved with the knowledge of today?

• Outcomes: Report, Continuous Performance Measurement at https://probelab.io/ and Spec Draft (not implementation) for IPNS-v2

• Impact: IPNS is very central in the operation of IPFS, but also critical for other platforms and ecosystems, such as ENS. It is the sole enabler protocol for a decentralised Web and Naming infrastructure. IPFS will only be able to host the next billion websites if IPNS operates efficiently.

Gossipsub Performance and Security Guarantees

• Effort Estimate: 4 dev months

• Summary: Verify that Gossipsub performs according to its spec when it comes to transporting messages in the Filecoin and Ethereum blockchains.

• Description: Gossipsub’s design is complex and based on a score function in order to maintain connections to well-behaving peers and disconnect from peers that look malicious. We will investigate the stability (or instability) that this score function provides to the network, i.e., how often do nodes alter their peerings). We will also investigate the scalability of the protocol when a large number of topics is required, such as the situation expected for Ethereum Danksharding developments.

  Tasks for this milestone include:

  • Stability (or lack thereof) of peer connections due to the frequency of GRAFTs and PRUNEs.
  • Message propagation latency estimation through passive node participation. Active participation (through extension of an existing node’s software) will be investigated and planned, but not executed as part of this milestone.
  • (Tentative) Impact of large numbers of topics on performance and protocol scalability.

• Outcomes: Report and Continuous Performance Measurement at: https://probelab.io/

• Impact: Gossipsub is critical for the performance of blockchains such as Filecoin and Ethereum. Malfunctioning of the protocol is likely to cost millions of dollars. A thorough investigation on its performance and operating principles will increase confidence of thousands of applications and businesses.

libp2p bandwidth baseline in different networks

• Effort Estimate: 2 dev months

• Summary: We will quantify what are the bandwidth requirements for an idle node when participating in networks such as IPFS, Polkadot, Ethereum and Filecoin. We will identify improvement directions in case of excess bandwidth consumption.

• Description: We will investigate if libp2p is operating according to expectations on several different networks and across different implementations. We will identify the potential sources of overhead in those different networks and propose improvements, as and where needed.

  Tasks for this milestone include:

  • Measure bandwidth requirements of an idle node in the IPFS, Filecoin, Ethereum and Polkadot network and compare the outcomes.
  • Compare different implementations of libp2p when operating on those networks.
  • Identify and stack rank the sources of overhead (per libp2p protocol involved in the handshake)
  • How does smart dialing affect the handshake overhead?
  • How does the handshake process affect other components/protocols of the system, such as a DHT

• Outcomes: Report and (if applicable) Continuous Performance Measurement at: https://probelab.io/

• Impact: libp2p is the core building block of several billion dollar networks. It is responsible for starting, maintaining and terminating connections to millions of nodes on a daily basis. Efficient operation of libp2p’s core properties, e.g., in terms of overhead can save significant amounts of bandwidth and expedite performance of peer connections.