A resilient system or network is fundamentally uncompromised by an isolated failure or network split. The system is malleable, adaptable to different conditions and capable of evolving to meet new requirements over time. That said, resilience here identifies also as a characteristic against changing system or network conditions, i.e., the system's core operating principles adjust so that performance remains when the system scales up to serve increasing demand from more users. Building resilience into foundational infrastructure is the key in building a computing and networking fabric for human knowledge.
Welcome to the ResNetLab public repository. In this place, you will be able to find information about our Open Problems, RFPs, Open Positions, Research Areas, Research Projects and much more. You can also consult the version on the Protocol Labs Research website
- The ResNetLab
- Research
- Collab projects tracking threads
- Publications, Talks & Trainings
- Team
- Contact
The Resilient Networks Lab mission is to build resilient distributed systems, by creating and operating a platform where researchers can collaborate openly and asynchronously on deep technical work.
The lab's genesis comes from a need present in the IPFS and libp2p projects to amp their research efforts to tackle the critical challenges of scaling up networks to planet scale and beyond. The Lab is designed to take ownership of the earlier stages on the research pipeline, from ideas to specs and to code.
| Research Area | Open Problem(s) | Short Description |
|---|---|---|
| Networks Observability | NEEDs OPEN PROBLEM | |
| Resilliency in Adversarial Networks | NEEDs OPEN PROBLEM | |
| Heterogeneous Runtimes | General open problem | Making libp2p / IPFS modules and protocols the de-facto distributed substrate for connected devices in the near-future Internet. Enable the execution of libp2p nodes and its underlying protocols anywhere (any device and any runtime). Allow global connectivity between devices. Enable “offline-first” applications. |
| Content Addressing | Routing at Scale (1M, 10M, 100M, 1B.. nodes) | Content-addressable networks face the challenge of routing scalability, as the amount of addressable elements in the network rises by several orders of magnitude compared to the host-addressable Internet of today. |
| Preseve full users' privacy when providing and fetching Content | How to ensure that the user's of the IPFS network can collect and provide information while mainting their full anonymity. | |
| Mutability | Mutable Data (Naming, Real-Time, Guarantees) | Enabling a multitude of different patterns of interactions between users, machines and both. In other words, what are the essential primitives that must be provided for dynamic applications to exist, what are the guarantees they require (consistency, availability, persistancy, authenticity, etc) from the underlying layer in order create powerful and complete applications in the Distributed Web. |
| Human Readable Naming | You can only have two of three properties for a name: Human-meaningful, Secure and/or Decentralized. This is Zooko's Trilemma. Can we have all 3, or even more? Can context related to some data help solve this problem? | |
| PubSub at Scale (1M, 10M, 100M, 1B.. nodes) | As the IPFS system is evolving and growing, communicating new entries to the IPNS is becoming an issue due to the increased network and node load requirements. The expected growth of the system to multiple millions of nodes is going to create significant performance issues, which might render the system unusable. Despite the significant amount of related literature on the topic of pub/sub, very few systems have been tested to that level of scalability, while those that have been are mostly cloud-based, managed and structured infrastructures. | |
| Data Exchange | Enhanced Bitswap/GraphSync with more Network Smarts | Bitswap is a simple protocol and it generally works. However, we feel that its performance can be substantially improved. One of the main factors that hold performance back is the fact that a node cannot request a subgraph of the DAG and results in many round-trips in order to “walk down” the DAG. The current operation of bitswap is also very often linked to duplicate transmission and receipt of content which overloads both the end nodes and the network. |
| Distributed Type Systems | Improved layouts to represent data in hash-linked graphs (using IPLD) | Future™ ⚙️ |
- Hydra Booster
- Gossipsub v1.1
- drand
- Beyond Bitswap
- P2P Observatory
- ACTIVE
- n/a
- PAST
- PulsarCast
- DClaims
- 2019, Jul -
WorkshopA Brief History of Information-Centric Networks - 2019, Sep -
WorkshopACM ICN Tutorial: The InterPlanetary File System (IPFS) - 2019, Dec -
PaperDClaims: A Censorship Resistant Web Annotations System using IPFS and Ethereum- zkcapital - paper of the week
- This paper will be presented http://www.sigapp.org/sac/sac2020/
- 2020, Feb - The effective Distributed Systems developer curriculum, with Golang
- David Dias - Research Engineer & ResNetLab Lead (PI)
- Yiannis Psaras - Research Scientist
- Alfonso de la Rocha - Research Engineer
- Vasilis Giotsas - Research Engineer
You can reach out to us anytime with your question and interest in these projects by emailing resnetlab@protocol.ai