Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 08 June, 2023
Überall auf der Welt brummen immer noch Tausende von Knoten, die sorgfältig und fraglos die Hahnenbilder und unergründlichen Musikauswahlen der Community für immer und ewig speichern und reproduzieren. Keine Sorge, wir werden dieses Testnetz zu gegebener Zeit abschalten. Wir sind noch nicht so weit, aber mit der Zeit wird das Netzwerk spürbar stabiler, vorhersehbarer und skalierbarer – was äußerst erfreulich ist. Bitte fahren Sie mit dem Hochladen und Teilen fort und veröffentlichen Sie Ihre Protokolle, wenn Sie etwas Ungewöhnliches bemerken.
Unter der Haube
Einige schlüssige Testergebnisse haben uns überzeugt, unser Datenreplikationsmodell von Push auf Pull umzustellen. Bei dem Push-Modell, das wir bisher verwendet haben, schieben Knoten mit Kopien der Daten, die vom toten Knoten gespeichert sind, bei einem Churn (ein Knoten geht offline) diesen zum nächstgelegenen Knoten. Einige dieser Knoten werden ihre Chunks erfolgreich pushen, andere nicht, aber es sollte genügend Toleranz im System vorhanden sein (wie durch die Wahl von k-value), um sicherzustellen, dass keine Daten verloren gehen.
Die Pull-Methode ist ähnlich, außer dass der neue Knoten, der erkennt, dass er der Erbe des toten Knotens ist, Chunks von seiner nahen Gruppe anfordert. Auch hier können einige Anfragen erfolgreich sein, andere nicht, aber am Ende sollten alle Teile empfangen werden.
Was ist also der Unterschied? Es kommt auf die Anzahl der gesendeten Nachrichten und die Anzahl zusätzlicher Kopien an, die erforderlich sind, damit das Push-Modell funktioniert. @Qi_ma hat Tests unter extremen Abwanderungsbedingungen durchgeführt und herausgefunden, dass Pull bei jeder Metrik überlegen ist – Nachrichten, CPU, Speicher und Erfolgsquote. Daher war ein Wechsel eine Selbstverständlichkeit. Ab sofort verwenden wir das Pull-Modell.
Es ist viel besser, aber wir sehen immer noch gelegentlich verworfene Nachrichten, weshalb der Erfolg noch nicht 100 % ist.
Andernorts werden DBCs nun repliziert und legen damit den Grundstein für die Bezahlung von Daten, die Gegenstand eines zukünftigen Testnetzes sein werden. @bochaco hat eine Illustration von Merkle DAGs erstellt und wie sie einen Baum dafür erstellen Chunks, die es uns ermöglichen, die Wurzel des Baums als Speicherzahlungsnachweis zu verwenden, den wir hier reproduzieren werden.
Die Speicherzahlungsnachweise werden mithilfe eines binären Merkle-Baums generiert:
Ein Merkle-Baum, auch Hash-Baum genannt, ist eine Datenstruktur, die zur Datenüberprüfung verwendet wird
und Synchronisation. Es handelt sich um eine Baumdatenstruktur, bei der jeder Nicht-Blattknoten ein Hash von ist
seine untergeordneten Knoten. Alle Blattknoten liegen gleich tief und sind so weit links wie möglich
möglich. Es wahrt die Datenintegrität und nutzt zu diesem Zweck Hash-Funktionen.
Um in Safe das Netzwerk für die Datenspeicherung bezahlen zu können, werden alle Dateien zunächst selbstverschlüsselt
Erhalten Sie alle Blöcke, für die der Benutzer bezahlen muss, bevor Sie sie hochladen. Ein binärer Merkle
Der Baum wird unter Verwendung der Adressen/Xornamen aller dieser Chunks und jedes Blatts im Merkle-Baum erstellt
enthält den Wert, der durch Hashing jedes Xornamens/jeder Adresse des Chunks erhalten wird.
Der folgende Baum zeigt, wie zwei Dateien A und B mit jeweils zwei Chunks verwendet werden würden
So erstellen Sie den Merkle-Baum:
[ Root ]
hash(Node0 + Node1)
^
|
*-------------------------------------------*
| |
[ Node0 ] [ Node1 ]
hash(Leaf0 + Leaf1) hash(Leaf2 + Leaf3)
^ ^
| |
*----------------------* *----------------------*
| | | |
[ Leaf0 ] [ Leaf1 ] [ Leaf2 ] [ Leaf3 ]
hash(ChunkA_0.addr) hash(ChunkA_1.addr) hash(ChunkB_0.addr) hash(ChunkB_1.addr)
^ ^ ^ ^
^ ^ ^ ^
| | | |
[ ChunkA_0 ] [ ChunkA_1 ] [ ChunkB_0 ] [ ChunkB_1 ]
^ ^ ^ ^
| | | |
*----------------------* *----------------------*
| |
self-encryption self-encryption
| |
[ FileA ] [ FileB ]
Der Benutzer verknüpft die geleistete Zahlung mit den Speicherknoten, indem er den Merkle-Baum-Wurzelwert festlegt
als „Dbc::reason_hash“-Wert. Dank der Eigenschaften des Merkle-Baums kann der Benutzer
Stellen Sie dann den Ausgabe-DBC und den Prüfpfad für jeden der damit bezahlten Chunks bereit
DBC und Baum, an die Speicherknoten beim Hochladen der Chunks, um sie im Netzwerk zu speichern.
@Anselme hat einige Fehler im Faucet und Wallet behoben, die dazu führen, dass DBCs derzeit nicht als im Netzwerk ausgegeben markiert werden. Er hat auch einige Protokollierungsprobleme gelöst.
@Roland hat eine PR erstellt, um System-, Netzwerk- und Prozessmetriken zu sammeln. Dies befindet sich hinter einem Feature-Gate, was bedeutet, dass es je nach Bedarf ein- und ausgeschaltet werden kann. Es sollte während Testnets nützlich sein, Metriken von der Community zu sammeln. Später werden wir OpenSearch-Metriken aktivieren, aber das ist vorerst eine einfache Lösung.
@ChrisO verfügt über einen automatisierten Testnet-Release-Prozess, der experimentell funktioniert. Sollte sehr bald für den Live-Einsatz bereit sein. Er und @aed900 haben auch an anderen Aspekten von Testnetzen gearbeitet, einschließlich der Verwaltung von Geheimnissen auf Digital Ocean. Angus hat sich auch mit einem Problem befasst, bei dem private Knoten (hinter NAT) in die Routing-Tabelle geschrieben werden, was nicht das ist, was wir wollen.
Glücklicherweise glaubt @bzee, der sich mit „libp2p“ beschäftigt hat, dass eine kommende Version dieses Problem für uns lösen sollte.
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!