Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 22 June, 2023
Während wir hier sprechen, läuft InstallNet immer noch gut und wir haben bereits einige nützliche Lehren daraus gezogen, einige Annahmen getestet und Pläne für Verbesserungen gemacht. Die aktuelle Iteration dient eigentlich dazu, den „Safeup“-Prozess zu testen, den @ChrisO zusammengestellt hat, um die Installation von „Safe“-Client, „Safenode“ und „Testnet“ auf macOS, Windows, Linux und letztendlich auch auf weiteren Plattformen zu automatisieren.
Die Inspiration ist, wie Sie vielleicht wissen, „Rustup“, das dasselbe für das Rust-Sprachökosystem tut. Ich bin mir sicher, dass Sie mir zustimmen werden, dass es zwar ein paar Macken zu beseitigen gilt, dies aber bereits zu einer besseren UX führt.
Vielen Dank wie immer an alle, die mitgeholfen haben. Ohne euch schaffen wir das nicht.
InstallNet – Erkenntnisse und Maßnahmen
-
Einige der Störungen, die Community-Tester erlebten, waren darauf zurückzuführen, dass neue Versionen von „safe“ und „safenode“ mit alten nicht kompatibel waren. Aktualisierungen erfolgen zahlreich und schnell, und manchmal enthalten diese Breaking Changes. Zukünftig müssen Testnetze hier an bestimmte Versionen gebunden werden (bis wir gut funktionierende Upgrades haben).
-
Eine dieser bahnbrechenden Änderungen besteht darin, dass wir jetzt jedem Datenelement einen „RecordHeader“ voranstellen. Dadurch können wir zwischen einem Chunk, DBC und Register unterscheiden, da Kademlia alles als Record im Netzwerk speichert. Die älteren Knoten können diese Header nicht verarbeiten.
-
Durch die Installation von „safeup“ als root/sudo (Linux) werden die Binärdateien an verschiedenen Orten abgelegt, die wir im Auge behalten müssen.
-
Die Protokollierung/Nachverfolgung muss bereinigt und standardisiert werden – wir sind dabei, unsere Optionen hier abzuwägen.
-
„Safe“- und „safenode“-Binärdateien waren auf iMac High Sierra 10.13.6, Arm v7 fehlerhaft. Hierfür gibt es bereits eine Lösung, aber es kommen weiterhin weitere Berichte und wir werden unser Bestes tun, um sie zu unterstützen
-
Der Standard-Chunk-Speicherort muss in Unterverzeichnisse aufgeteilt werden, eines pro Knoten auf dieser Maschine.
-
Es funktioniert auf Android!
-
Wir müssen die Anweisungen für Windows-Benutzer verfeinern.
-
Wir haben das Problem, dass Knoten lange brauchen, um Chunks zu empfangen, noch nicht gelöst. Es kann sein, dass, wenn sich die Kademila-Buckets (geschlossene Gruppen) füllen, neue „geschlossene“ Knoten nur dann hochgestuft werden, wenn ein anderer Peer nicht mehr reagiert, was darauf hindeutet, dass wir beim Start eine Ansammlung von Knoten haben, möglicherweise weil wir nur eine begrenzte Teilmenge von Knoten für den Erstkontakt bereitstellen. Wir graben hier rein.
Allgemeiner Fortschritt
@Joshuef und @qi_ma haben sich mit dem Problem inaktiver Knoten befasst, das zu vielen Konnektivitätsschleifen führt, da Knoten versuchen, (die gleichen) Peers zu finden und akzeptiert zu werden (was wiederum zu Speicherspitzen führen kann). Dies beinhaltet einen tiefen Einblick in die Funktionsweise von Kad, Überlegungen darüber, was ein Knoten braucht, um in einem kleinen Netzwerk wahrgenommen zu werden, und mögliche Problemumgehungen, wie z. B. einen erneuten Versuch mit neuen PeerIds.
Qi hat sich auch einige Speicherspitzen und Geschwindigkeitsprobleme angesehen, die im letzten Testnet festgestellt wurden (Sie können sehen, dass in den neuen Benchmark-Charts einige Fortschritte erzielt wurden )
@ChrisO hat eine Liste der Probleme aus dem neuesten Testnetz zusammengestellt und arbeitet an Verfeinerungen von „safeup“ und dem Veröffentlichungsprozess.
In der Zwischenzeit hat @anselme seine Arbeit an den Ausgaben abgeschlossen, überprüft, dass Doppelausgaben verhindert werden wie erwartet, und hat damit begonnen, Register in unserem Kad RecordStore zu speichern , Erarbeitung eines Prototyps einer Barebone-API, um zu imitieren, was es für Chunks und Ausgaben gibt.
@Bzee untersucht weiterhin die Feinheiten von „libp2p“-Verbindungen, um zu überlegen, wie viel I/O wir auf Knotenebene steuern können, und @bochaco arbeitet an der Überprüfung für Speicherzahlungseingaben.
Und einige vorläufige, aber sehr positive Neuigkeiten von @aed900. Er hat die Unterstützung von „libp2p“ für Hole-Punching über QUIC getestet, eine laufende Arbeit des „libp2p“-Teams. Er berichtet, dass bisher alles wie erwartet zu funktionieren scheint – es sind jedoch weitere Tests erforderlich, bevor wir den Champagner auspacken können.
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!