Splat Self-Asserting Fractal Network Protocol

Introduction

There are many systems today which require self-assembling networks of cooperating computer units: Signal, Telegram, WhatsApp, Jami communications applications, or BitTorrent file-sharing service, or Ethereum distributed crpytocurrency ledger, or Mastodon and Bluesky social networks, are examples. These depend more or less on centralized resources. Of efforts to produce completely free open-source, open-protocol, fully federated systems, two efforts which stand out leverage much of the development that has gone into the other systems: GNUnet and Jami.

These stand at opposite ends of a spectrum with respect to the underlying autonomous network topology: Jami uses a fundamentally linear network, while GNUnet uses a completely ad-hoc network. Typically a distributed hash table is implemented on top of these networks to provide logarithmic-time look-up, e.g. a Kademlia protocol variant.

Here we develop an intermediate type of network: using a global fractal topology the network demands small and constant resource from each node, and has intrinsic logarithmic look-up time without need for another network layer. The upshot is a low-level network layer (sits on top of TCP in the network stack) which makes implementation of modern higher layers, functions and applications such as those mentioned above much simpler.

Figure 1. A network of independent nodes self-assembling one node at a time.

Points to note:

• no node ever has fewer than two connections
• no two nodes are never more than 7 hops apart
• the nodes are all identical, none are special
• the placement of each node in the network is indeterminate
• each node only knows of between 2 and 4 other nodes; resources required of each node are small and absolutely bounded

In general, a network of splat size S (a hard, pre-defined network parameter) containing N nodes (variable, unbounded) will have a fractal depth D=⎡ln_SN⎤, longest path (time for discovery) 2^D-1 = ⎣(N-1)^ln_S2⎦, and every node in the network would need resources to track exactly S other nodes (independent of N).

For example,

• with a splat size of S=8, a full 6-layer fractal network could contain N=262,144 nodes
• each node would know 8 other nodes
• any two nodes would be no more than 63 links apart (most would be fewer)

Use cases

The main selling-point for the new protocol is that higher-level protocols are much easier to implement directly on top of Splat, without adding more layers of complexity. For example

• distributed hash function, a.k.a. telephone directory

  This can be implemented directly within the topology, instead of needing another layer, e.g. Kademlia.

• mixing network, to thwart traffic analysis

  There are many routes equal to the minimum length between any two nodes in the network, so packet streams can be broken across paths and mingled more randomly with packets of other streams, without increasing path lengths.

• resilience against attack

  Most nodes will be connected to S other nodes, so if one goes missing there will still be enough links in the network for the network to sustain itself, possibly after some self-reconfiguration.

State of the project

The project is destined to produce three outcomes

IETF-style specification document

This has not been started. Work will begin when the developments outlined below are in a much more advanced state.

Reference implementation; dynamic library with C linkage

A version which can build-out (but not collapse-in) a splat network is available (soon in the GIT repository). It is implemented in Rust.

The next stages are

• implement distributed hash function on top of the network
• allow for nodes leaving graciously
• allow for nodes leaving suddenly (attack!)
• strengthen the protocol against the actions of rogue nodes

Demonstration program, with visual insight, for research purposes

The animation above is the result of the current effort. It is implemented in Rust, but not currently in a state suitable for general release.

The next stages are

• get the code into a state suitable for dissemination
• indicate communications passing between the nodes
• show nodes joining, leaving, and dying

Specification document

This will appear here once work commences on this part of the project.

GIT code repository

This is currently work in progress.

Contact us