Safe Network Entwickler Update 🇩🇪 6. Juli 2023

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 06 July, 2023

Eine der Änderungen, an denen wir diese Woche arbeiten, betrifft die aktualisierte Version von „libp2p“, die einige willkommene Verbesserungen für AutoNAT mit sich bringt – das Erkennen und Ermöglichen des Beitritts von Knoten, die sich hinter einer Firewall oder einem Router befinden. Wir werden bald in der Lage sein, zwischen globalen und privaten IP-Adressen zu unterscheiden, was bisher ein Problem war.

Unweigerlich bringt es jedoch auch einige neue Insekten mit sich, die uns auf Trab halten. Daher haben wir diese Woche hauptsächlich unter der Motorhaube gearbeitet und an den Stößeln herumgebastelt, statt die Frontpartie aufzupolieren.

Allerdings hat @ChrisO jetzt die Protokollierungsschnittstelle aktualisiert und bietet Leuten, die einen Knoten betreiben, Speicher- und Formatierungsoptionen. Benutzer können das Protokollausgabeverzeichnis oder die Standardausgabe angeben, wenn sie möchten. Standardmäßig sind dies jetzt jedoch:

       Linux: $HOME/.local/share/safe/node/<peer-id>/logs
       macOS: $HOME/Library/Application Support/safe/node/<peer-id>/logs
       Windows: C:\Benutzer\<Benutzername>\AppData\Roaming\safe\node\<Peer-ID>\logs

Clientprotokolle werden standardmäßig in den entsprechenden „…client/logs“-Verzeichnissen gespeichert.

Es gibt auch eine Auswahl an Formaten. JSON kann bei Bedarf ĂĽber die CLI angegeben werden.

Wie Sie wissen, folgen wir drei Maximen, wenn wir unsere Arbeit mit „libp2p“ integrieren. Eine besteht darin, es Kad zu überlassen, wo es möglich ist, denn es gibt viel mehr Augen auf den „libp2p“-Code und wir wollen ihn, wo immer möglich, standardisieren. Die zweite Möglichkeit besteht darin, es dem Kunden zu überlassen – je weniger die Knoten tun müssen, desto besser. Die dritte besteht darin, die Sicherheit zu maximieren – alles sollte signiert und die Daten verschlüsselt werden. Wir finden, dass diese derzeit widersprüchlich sind. @Anselme hat sich Register angesehen, die bei der Erstellung von „Kademlia Records“ nicht standardmäßig gesichert sind, was sie anfällig für fehlerhafte Knoten macht. Neue Rekorde sind auf Kad auch nicht CRDT, daher sind Rennbedingungen möglich. Nachfolgende Schreibvorgänge sind CRDT, also kein Problem. Anselme glaubt, für beide Probleme eine Lösung gefunden zu haben.

@Qi_ma und @joshuef arbeiten an einem weiteren Problem, bei dem es darum geht, wie ein Client beim Speichern von Chunks die nächstgelegenen Knoten findet und seine Daten weiterleitet. Wir sind der Meinung, dass der Kunde einen größeren Teil der Arbeit übernehmen sollte. Wir möchten, dass sie das Netzwerk wiederholt nach den nächstgelegenen Knoten fragen und wenn sie einen Patch erhalten, dann den Block bereitstellen, anstatt einen vollständigen Erkennungsprozess durchzuführen.

Unser derzeit bevorzugter Ansatz ist dieser feat: Using put record for upload by maqi · Pull Request #482 · maidsafe/safe_network · GitHub , der uns wieder dazu bringt, die „Put“-Implementierung von Kademlia zu verwenden, obwohl wir sie jetzt zum Put-Zeitpunkt überprüft haben. Dadurch werden fehlerhaften Knoten die Möglichkeit genommen, hinterhältige Dinge zu tun, und der Code rund um PUT wird ebenfalls erheblich vereinfacht.

Bisher sind die Uploads etwas langsamer, aber wir sind sicher, dass sie bei Bedarf später optimiert werden können.

Die Zahlungsabwicklung ist ein weiteres Problem, mit dem wir uns befassen, auch über netzwerkeigene DBCs, was bedeuten würde, dass wir nicht überprüfen müssen, ob Zahlungen an gültige Knoten gingen Damals (da wir dort keinen Abschnittsbaum + Verlauf mehr haben) vereinfacht dies die Dinge erheblich. Und später werden wir in der Lage sein, Belohnungen aus dem Netzwerk selbst auszuzahlen.

Und wir haben uns mit der Frage von Neustarts und Updates beschäftigt. Ein ausgefallener Knoten sollte nicht denselben Schlüssel behalten, aber ein gültiger Knoten, der beispielsweise während eines Upgrades abstürzt, sollte in der Lage sein, eine gültige ID und Schlüssel aus einem vorherigen Schlüssel neu zu erstellen.

Allgemeiner Fortschritt

@Bochaco arbeitet an der Logik von DBCs und Zahlungen an das Netzwerk.

@aed900 arbeitet an einer benutzerdefinierten Bin-Option für das Testnet-Tool GitHub Actions (CI) und @roland arbeitete an der Implementierung eines Scheinnetzwerks, das es uns ermöglicht, Knotenfunktionen gründlicher zu testen.

Mit dem Libp2p-Upgrade geht @Benno auf Fehlersuche und testet die AutoNat-Funktionen.

Neben der Korrektur der Registersicherheit hat @anselme auch die Faucet-Funktionalität verbessert.


NĂĽtzliche Links

FĂĽhlen Sie sich frei, unten mit Links zu Ăśbersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufĂĽgen.

Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!