IPFS 0.5.0, die neue Version des interplanetaren Dateisystems, soll deutlich schneller arbeiten. Laut den Programmierern behebt das bislang größte Update auch diverse Probleme.

IPFS ist der Versuch, ein Peer-to-Peer-basiertes Internet nachzubauen und die Inhalte darin mehrfach und dezentral zu verteilen. Version 0.5 von “go-ipfs” sei das “bisher größte Update” und enthalte laut Changelog rund 2500 Commits von knapp 100 Entwicklern. Ein Fokus für die Version 0.5 lag dabei auf Content Routing: Also die Inhalte effizienter im dezentralen Netzwerk anzukündigen und zu finden.

Drei Herausforderungen…

Um das zu erreichen, haben die Entwickler vor allem an den Distributed Hash Tables (DHT) gearbeitet und die Implementierung fast komplett neu geschrieben. Über DHT behalten die IPFS-Knoten im Auge, welche Daten wo zu finden sind. Das Netzwerk skaliere inzwischen auf bis zu 100 000 Nodes.

Im Prinzip sind die Entwickler dabei drei zentrale Probleme angegangen. Nummer eins ist, dass sich die meisten Peers nicht erreichen lassen, da sie sich hinter NAT und Firewalls befinden. Zweitens sucht die Abfragelogik von DHT auch im Erfolgsfall immer weiter nach Resultaten. Drittens sind die Routing-Tabellen schlecht gepflegt, was die Suchperformance mit zunehmender Netzwerkgröße einbrechen lässt.

…und die Rezepte dagegen

Ab IPFS 0.5 werden nicht erreichbare Nodes erst dann zu Server Nodes, wenn sie über das Public Internet zu erreichen sind. Zugleich startet “go-ipfs” nun zwei verteilte Hashtabellen: eine für private und eine für das öffentliche Internet.

Jeder Knoten partizipiert dabei in einer LAN DHT (privat) und einer WAN DHT (öffentlich). Ist der Knoten nicht im öffentlichen Internet erreichbar, veröffentlicht er Provider- (das sind Informationen über die publizierten Inhalte) und IPNS-Einträge nur im LAN DHT. Ist er öffentlich erreichbar, sucht er zwar Peers, Inhalte und IPNS Records in beiden DHTs, veröffentlicht aber Provider und IPNS Records nur im WAN DHT, um das LAN nicht zu fluten. Zum WAN DHT gehören dabei nur Knoten mit mindestens einer IP-Adresse, wobei IPFS nur IPv6-Adressen aus dem öffentlichen Raum berücksichtigt (2000::/3).

Die zweite große Änderungen adressiert die Suchlogik der DHTs. Die folgt nun stärker der von Kademlia. Die Suche stoppt in diesem Fall, wenn sie den nächsten Peer erreicht und wartet nicht auf ein Timeout oder bis sie keinen Peer mehr findet. Das soll sowohl das Auflösen von IPNS-Adressen als auch das Ankündigen von IPNS und Provider-Records beschleunigen.

Auch gegen die schlecht gepflegten Routing-Tabellen gehen die Entwickler an. So unterbricht der Verbindungsmanager seltener Verbindungen zu Peers aus der Routing-Tabelle. Diese behält nun auch nach einer Verbindung die Peers. Regelmäßige DHT-Anfragen halten die Tabelle außerdem aktuell. Nicht zuletzt priorisiert “go-ipfs” nun Peers, die schnell antworten.

Inhalte übertragen

Ein zweiter Fokus der Entwickler lag auf dem Übertragen von Inhalten. Ein überarbeitetes und rückwärts-kompatibles Bitswap-Protokoll soll die IPFS-Performance signifikant erhöhen. Es soll dabei keine doppelten Blöcke beim Abholen der Blöcke von Nodes geben, die das neue Protokoll sprechen. Die Parallelisierung beim Download von mehreren Peers soll besser klappen. Diese Optimierungen manifestieren sich aber erst, wenn die Clients und Inhalte-Provider im Netzwerk auf Version 0.5.0 aktualisiert sind, was eine Weile dauern dürfte.

Breaking Changes

Weniger rückwärtskompatibel ist der Wechsel von Content-IDs auf Multihash beim Ankündigen von Inhalten. Dieser soll dafür sorgen, dass sich Inhalte auch dann wiederfinden lassen, wenn sich Content-IDs (CIDs) nach der Erstveröffentlichung ändern. Der Multihash sorgt dafür, dass sich die CIDs beim Publizieren ändern dürfen, aber die Nodes diese Inhalte trotzdem wiederfinden. Das funktioniert allerdings nicht mehr für Inhalte, die Version 1 der CIDs verwenden. Laut der Ankündigung dürften das aber nicht allzu viele sein, weil CIDv1 nicht standardmäßig aktiviert war.

Testbett und Graphsync

Neu für das Projekt ist Testground, ein Test-Framework. Das erlaubt es, ein Testnetz mit mehreren Tausend Nodes unter simulierten Echtwelt-Netzwerk-Bedingungen zu starten. Mit Testground und einigen angepassten Analysetools sei das Projekt nun in der Lage, die Auswirkungen neuer DHT-Implementierungen zu studieren.

Experimentell ist der Support für Graphsync, einem neuen Austauschprotokoll. Das fuße auf dem IPLD-Graphlayer anstatt auf dem Blocklayer wie das Bitswap-Protokoll. Das Protokoll sei komplexer, spare aber Roundtrips ein und ermögliche ausgefeiltere Anfragen an das Nezwerk. Mit nur wenigen Roundtrips sei es möglich, größere Mengen an Daten herunterzuladen. Aktuell lasse sich das Feature nutzen, um Inhalte über das Protokoll anzubieten. Der Download von Inhalten anderer Peers über Graphsync funktioniere hingegen noch nicht.

Datenspeicher

Updates gab es auch für die Datenspeicher von “go-ipfs”, Badger und FlatFS. Badger sei nun stabil (aber noch nicht der Standard). Badger schreibe nicht mehr synchron auf die Festplatte sondern synchronisiere nur noch, wenn es Sinn ergebe, was den Schreibdurchsatz erhöhe. FlatFS bleibt der Standard in “go-ipfs”. Es speichert Datenblöcke als individuelle Dateien. Wem FlatFS zu langsam ist, der sollte auf Badger wechseln, das beim Ergänzen und Holen von Daten bis zu 32 Mal schneller arbeite. Wie der Wechsel funktioniert, erklärt die Ankündigung, die auch über die bestehenden Nachteile von Badger informiert.

Auch die Libp2p erhält diverse Neuerungen. Dazu zählen eine verbesserte Backoff-Logik (beim Aussortieren von Peers), die Einführung AutoNAT (um die Erreichbarkeit eines Nodes zu erkennen), ein verbessertes Adressformat, eine Mindestlänge für RSA-Keys und TLS als Standard. Es gibt Verbesserungen am Nameserver-System (IPNS), am Gateway, an PubSub und an CLI und API. Eine komplette Übersicht der Features liefert Github.