Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 13 July, 2023
Es ist etwas eintönig, aber diese Woche können wir erneut berichten, dass das Testnetz „NodeDiscoveryNet“ immer noch in Betrieb ist. Die Kanten sind zwar etwas rau und bedürfen einer Verfeinerung, aber das Fundament macht einen sehr soliden Eindruck. Diese Stabilität ist keine Überraschung mehr, aber nach vielen Jahren voller Aufregung, während wir versucht haben, dieses Ding zum Fliegen zu bringen, ist das ehrlich gesagt die Art von Langeweile, mit der wir leben können.
Zu den Optimierungen, die sich aus den Testnet-Ergebnissen ergeben, gehört die Verbesserung der Fehlermeldungen an Benutzer, wenn ein Knoten keine ordnungsgemäße Verbindung herstellen kann. Wenn dies geschieht, gibt es derzeit keine offensichtlichen Anzeichen für den Benutzer, der in den Protokollen stöbern muss – obwohl das Fehlen von Chunks ein Hinweis darauf ist.
Die meisten Verbindungsfehler sind auf den Versuch zurückzuführen, eine Verbindung zu nicht zugänglichen Peer-Adressen herzustellen. Wir haben auch weitaus mehr Verbindungen zu gültigen Adressen gesehen, als Sie erwarten könnten (vorausgesetzt, libp2p bietet Multiplexing). Mehr als eine Handvoll pro Peer sollte es nicht gleichzeitig geben, aber wir haben Hunderte gesehen! Nach einigem Recherchieren stellte sich heraus, dass es sich hierbei um eine Funktion (keinen Fehler…) von libp2p handelte, die jedoch nicht für unseren Anwendungsfall optimiert war. @bzee meldete sich und Max Inden von Protocol Labs hat sich freundlicherweise einen Patch ausgedacht, der zu einem Rückgang der Anzahl der Verbindungen geführt hat von Dutzenden bis nur sechs oder sieben. Danke Max!
Wir haben festgestellt, dass Knoten jedes Mal, wenn ein neuer Knoten hinzugefügt wird, eine „get_closest“-Prüfung durchführen, während sie dies nur beim ersten Beitritt tun sollten, also ist das etwas mehr Overhead, den wir gespart haben. Da wird es noch mehr geben.
Darüber hinaus haben wir uns eingehender mit der Registersicherheit befasst und darüber nachgedacht, was passieren würde, wenn ein Angreifer, anstatt zu versuchen, Daten in einem Register zu ändern (was ohne die entsprechende Autorisierung praktisch unmöglich ist), einfach das gesamte Register austauscht – was bei unserem aktuellen Setup nicht unmöglich ist. Wir arbeiten daran, dies am besten zu beheben.
Allgemeiner Fortschritt
@joshuef hat einige Änderungen am Replikationsfluss vorgenommen, darunter eine, die auf die Replikation/den Abruf wartende Daten mischt, um zu verhindern, dass ein Ende der engen Gruppe vorhanden ist Aufgrund der Xorspace-Bestellung gehämmert. Zusammen mit den übermäßigen Verbindungen und dem Übermaß an Nachrichten ist dies eine weitere wahrscheinliche Ursache dafür, dass Knoten das Handtuch werfen.
@Roland hat an einem Test gearbeitet, um zu überprüfen, wo sich bestimmte Daten im Netzwerk befinden, und @Qi_ma bringt Register in den Abwanderungstest , damit wir sehen können, wie sie damit umgehen, wenn es wild zugeht. Danach werden wir uns mit der Verfeinerung unserer Datenaufbewahrungstests befassen und unsere Aufmerksamkeit auf DBCs richten.
Vor diesem Hintergrund hat @bochaco die Art und Weise überarbeitet, wie der Client Dateien während der Selbstverschlüsselung aufteilt und für deren Speicherung bezahlt. Zuvor haben wir Dateien zweimal aufgeteilt (zuerst zum Erstellen des Zahlungs-Merkle-Baums und dann beim Hochladen). Wir generieren jetzt Blöcke und speichern sie in einem lokalen temporären Ordner, wenn wir bezahlen, und lesen aus diesem temporären Ordner stapelweise, wenn wir die bezahlten Blöcke hochladen. Dies sollte den Speicherbedarf des Clients verringern, insbesondere bei großen Dateien, da diese nicht mehr im Speicher gespeichert werden müssen.
@Anselme hat den Wasserhahn aktualisiert. Die einfache eigenständige Datei, die sich auf dem lokalen Computer befand, ist jetzt ein HTTP-Server, der Token an die Adressen der Anfrage sendet. Es handelt sich also um eine Selbstbedienung, und wir brauchen nicht länger eine Person, die den Genesis-Schlüssel beansprucht und die Token dann manuell austeilt, wenn die Leute ihre Schlüssel verschicken. Das versetzt uns in eine gute Ausgangslage, wenn wir bereit sind, mit der Ausgabe von Token zu beginnen, um die DBCs in zukünftigen Testnetzen zu testen.
Dies wird bald zum Testnet-Tool hinzugefügt, das @aed900 zusammen mit @Chriso überarbeitet hat.
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!