Waku as a metastable network

Waku
1

A “stable” network is what we have right now. While seen through a static lens our network may seams stable, the actual experience of it is quite chaotic. Node IPs changes all the times and also churn out. We organize the network into a DHT and maintain bootstrapping nodes but without all this effort it would fragment or become stale and useless.

The idea of metastability is taken from physics but in our case mean something different. The concept is quite simple, when links are self-healing, networks tend towards order. Although, this order would happen at a logical and not network level.

Assuming new nodes can be introduced to the network, remembers links and those links are self-healing, this network could last indefinitely and require low bandwidth and compute from each nodes. The implication is that metastable networks can persists without ANY central components and the birthday paradox teaches us that the threshold for the number of nodes required to achieve metastability is much lower than one would think.

In a libp2p network, we already have most of what is needed to achieve metastability. PeerIDs and multi-addresses are remembered, act as identifiers and links but lack the self-healing properties. If a PeerID is rotated and IP changed, that node cannot be reliably found again, the link is broken. In contrast, the web has DNS to “heal” broken links via name association. Imagine if this wasn’t the case… We can’t use DNS because it’s permissioned but with clever cryptography, a self-healing link system is possible.

Provable provenance logs could be used with our future Kademlia DHT to bind VLADs to multi-addresses. This system can achieve much more than just metastability but that’s another discussion.

WDYT?

edit: more explanation below

Assumimg we have a way to introduce nodes into the network the first time, (boot nodes, QR code, etc…)

  1. Nodes SHOULD store ALL valid routing info gathered via ambient discovery, for later use (even if stale). VLADs, key material, PeerIDs and Multi-addresses.
  2. Nodes, when online, SHOULD continually try to refresh ALL their cached routing info (sync it up!).
  3. Only cryptographically valid routing info MUST be kept.

Birthday paradox and whatnot, we don’t need that many nodes to achieve metastability. This network is not vulnerable to attacks and is actually useful, in contrast to the stable overlay networks we have right now. If individual nodes are attacked then they can use RLN-relay, TOR or a mixnet.

On top of this very simple overlay network many things can be built.

  • Decentralized DB, permissioned via provable provenance logs (p-logs) and synced (RBSR, Waku sync). Store only the data you want from who you want.
  • Distributed hash table for looking up specific VLADs and their associated content (can be encrypted content too). DHT search is very useful but costly to maintain. Nodes only cache p-logs they care about.
  • De-MLS group chat (assuming we can “admin” it somehow). Members can always find latest key materials, multi-addresses and sync messages.

Because of metastability Waku becomes de facto signaling networks for ALL.

2 Likes
2

Currently I work on other way for support stability on an overlay layer, which can based on high dynamic infrastructure.
High mesh dynamic in a p2p networks is a normal situation: relay nodes can go online and offline, id’s and addresses can changing according to configuration, cryptokeys renew epochs, mobile devices can change base stations and even providers, linkage conditions can be changed by DPI, Firewalls, BGP peering policies, physical lines accidents, etc and in any case, if participants of that creazy fluid environment keep just an internet connections and stay online, and able to connect to any node in a mesh, they are should only reconnect back to the VLANs, inside which they are return a stability of full interconnection, independent from base network dynamic
This idea explained and discussed here

3

But!
VLAD is a greate idea too, especially for privide well known code trusted accessibility. Ithink additionally a mechanizm of trust to multisig comunity check also should be provided.
IIUC, permanent multisig is reflect a trust to this multisig participant, right? because VLAD, signed by untrusted comunity can point, for example, to malicious WASM code.
I thin a good idea will be thin about, how we can create a decentralized, anonymous, but absolite trusted multisigs, whith which anyone can trust to content. identified by a VLAD, or it will be a conditionally trusted solution
By the way, VLADs also looks like a good IDs to be stored on a blockchain )

1 Like
4

Interesting, but do we need a history of multiaddress changes to be recorded somewhere? All we would need is the latest entry which is valid that would ensure the connectivity is successful. Ideally some form of a decentralized and censorship-resistant name resolution service is what would be required to solve the problem of changes. Or a fixed location where bootstrap info can be updated.
Or am i missing something here?

Also wouldn’t having a history of multiaddress and IP changes recorded break the whole point of what little privacy/censorship resistance achieved by rotating the peerId and multiaddress.
Although having a name resolution service also causes same issue as someone could just keep running a query to keep track.

5

No matter the system if an observer want to track IPs it can because that is how metastability is achieved. Encrypted provable provenance logs could help but I haven’t thought about the implications.

That already exist it’s call ENS. The problem is you need consensus for naming, so a blockchain must be used, not good.

That’s the status quo, we can do better!

6

I think that is the crux of the problem. Nodes don’t stay online, if they did we wouldn’t need metastability, stability would do just fine.

Yes that is true but it’s still not metastability. A libp2p network already is as stable as a VLAN. Metastabilitty emerge from the logical links between nodes/users not the network links.

1 Like
7

Yea, and agreed that we should definitely look for a non-blockchain based solution as maintaining blockchain based consensus for such small data is too much of an overhead. Maybe we do something like what miden is trying to do as explained here

Well, i was wondering in a fixed location but updatabl, then that is what ENS/IPNS are.

1 Like
8

Imagine a highly dynamic peer-to-peer network serving as a unified transport layer for many cryptographically isolated VLANs, where each packet is an encapsulated Ethernet frame belonging to one of these virtual LANs.

Any VLAN can be accessed from any node, but joining a VLAN requires membership in its TreeKEM (MLS) group. Still, every node can act as a relay for all VLANs, even those it isn’t directly a member of.

All relay nodes continuously exchange network state information and dynamically optimize the global mesh interconnection. As peers go online or offline, as bandwidth fluctuates or connections are lost, the routing layer adapts in real time.

As a result, most VLAN packets reach their destinations through ever-changing paths — yet for users inside the VLAN, this complexity remains invisible. From their perspective, they experience stable, direct connectivity as if they were linked via dedicated fiber.

And the more nodes join the network, the more performant and stable it becomes — benefiting from scale rather than suffering from it.

This isn’t just metastability — it’s a form of resilient megastability.

1 Like
9

Can’t wait to see it built!

10

Currently I’m finish a specification, and work on a development planning, than will start a coding, about updates I will post here or will create a new topic on a forum. I think some MVP will be ready before august

1 Like
11

Although… well, looking on principle “Specifications Are the Product”, I can just publish the spec today or even yesterday - I just need to format it a bit more properly for making it public.

12

Sounds interesting, but one thing i don’t understand is is this acting at Layer-2 of OSI stack or above L2/L3? Would love to read the spec if it is ready as i may be missing something.

This sounds exactly like how gossipsub is designed with some additions like having a membership to join a VLAN.
In gossipsub each node joins a pub-sub-topic of its interest and relays all messages for that topic to the mesh. Gossipsub layer always attemps to maintin its mesh of peers(full and metadata only connection) to have a stable connectivity.

13

I deside to create a new topic for that

14

By the way this is looks like the same, what you mean here?

16

I updated the OP with more details.