Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 10 August, 2023
Das nächste Testnetz, das jeden Tag gestartet werden soll, wird sich mit den variablen Filialkosten befassen. Zur Erinnerung: Wenn die Knoten voll sind, steigt der Preis für die Datenspeicherung, um mehr Knoten in das Netzwerk zu locken. Umgekehrt sinken die Ladenkosten, wenn im Netzwerk ausreichend Platz vorhanden ist.
Bevor ein Datenblock gespeichert wird, fragt ein Client nun eine Auswahl von Knoten im Adressbereich (eine enge Gruppe) nach einem Preis. Der von jedem Knoten angebotene Preis hängt davon ab, wie viele Daten ein Knoten derzeit verwaltet. Wie wir während der Testnetze gesehen haben, werden die freie Kapazität und damit der Preis bei einer Verteilung sinken. Während im letzten Testnetz einige Knoten vollständig gefüllt waren, waren die meisten irgendwo zwischen halbvoll und voll.
Wenn man bedenkt, dass jeder gespeicherte Block über eine Reihe von Knoten (derzeit 8) repliziert wird, ist es für den Kunden sinnvoll, nicht den niedrigsten Preis auszuwählen, da dies dazu führen könnte, dass nicht genügend Knoten die Zahlung aufrechterhalten und die Replikation verhindern, sondern stattdessen einen auszuwählen Laden Sie die Kosten in Richtung der Spitze des angebotenen Bereichs, was ein Preis ist, der für die Mehrheit der Knoten in der Gruppe akzeptabel ist. Zusammenfassend sollte der Kunde den niedrigsten Preis anstreben, der dennoch garantiert, dass ein Großteil der geschlossenen Gruppe den Block speichert.
Um dies richtig zu machen, werden einige Testnet-Iterationen erforderlich sein, aber wir freuen uns, endlich damit beginnen zu können.
Wir beschäftigen uns auch damit, wie man DBCs über das Netzwerk austauschen kann. Im Moment müssen DBCs außer Band ausgetauscht werden – per Messaging, E-Mail oder ähnlichem – aber @anselme und @dirvine arbeiten an einem Prozess, bei dem die DBCs, die in einer Transaktion ausgegeben werden, sicher im Netzwerk verfügbar gemacht werden, so die Der Empfänger kann sie abholen, sofern er die Adresse kennt und den richtigen Schlüssel hat.
An anderer Stelle arbeiten wir an einigen Fehlern aus dem letzten Testnetz. Es gibt immer noch einige Probleme mit Verbindungen, da einige Knoten nicht ordnungsgemäß zu den Routing-Tabellen anderer Knoten hinzugefügt werden. Ein weiteres Problem ist die Geschwindigkeit der Datenüberprüfung, die recht langsam ist. Wir haben jetzt eine CLI-Option eingeführt, um PUTs nicht zu überprüfen, um Uploads zu beschleunigen. Dies kann jedoch bei größeren Dateien zu Problemen führen. Das Warten auf die Antwort von 20 Knoten, bevor ein Client eine Verbindung zum Netzwerk herstellen kann, war ebenfalls ziemlich langsam, daher haben wir diese Anzahl auf 8 Knoten reduziert, was die Sache etwas schneller macht.
Positiv zu vermerken ist, dass die Zahlungen für die Datenspeicherung recht schnell abgewickelt wurden, sodass wir damit sehr zufrieden sind.
Allgemeiner Fortschritt
@joshuef hat die Kostenbemühungen für die Filialen vorangetrieben und den oben erwähnten Mehrheitsknotenpreis implementiert. Er hat auch eine PR für Cache-Speicherkosten beim Client erstellt und diese genutzt, um sicherzustellen, dass die Routing-Tabellen des Knotens aktualisiert werden, anstatt jeden Knoten anzupingen Zeit. Dies sollte PUT-Anfragen beschleunigen.
Der allgemeine Bugfinder @Qi_Ma hat einen Fehler in der Bereinigungslogik behoben und die Grundursache für die Überprüfung der doppelten Ausgaben, über die wir letzte Woche gesprochen haben, aufgespürt das auch beheben.
In der Zwischenzeit hat @Chriso die Möglichkeit eingeführt, benutzerdefinierte Zweige von Safenode zu erstellen und zum Testen bereitzustellen, sodass wir jetzt nicht zusammengeführten Code testen können unsere moderne Rusty-Version des Testnet-Deployer-Tools.
@Aed900 arbeitet weiterhin an „Knoten von zu Hause aus“. Er hat eine Prototyp-Relay-Funktion entwickelt, die es Knoten, die einen privaten Autonat-Status vom Netzwerk erhalten (d. h. sie befinden sich hinter einem Router oder einer Firewall), ermöglicht, mit dem Netzwerk zu kommunizieren und dabei einen anderen Knoten als Relay zu verwenden.
Auf einem ähnlichen Gebiet untersuchte @bzee ein Problem mit nicht routbaren Knoten in „libp2p“, das Probleme verursachte. Es kann an einer kürzlichen Änderung in „libp2p“ liegen, aber es sind weitere Nachforschungen erforderlich, und das erfordert offenbar spezielle Debug-Tools im Netzwerk-Stack.
Und @roland hat einen Fehler im Testnet-Code behoben, bei dem beim Starten des Faucets kein Bootstrap-Peer bereitgestellt wurde.
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!