Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 28 September, 2023
Diese Woche haben wir uns die Ergebnisse des Testnetzes angesehen und an Fehlerbehebungen gearbeitet. Um das Debuggen zu erleichtern, ist zunächst zu beachten, dass das Testnetz bewusst unnachgiebig war und ein Teil auf alle acht Knoten der nahen Gruppe repliziert werden musste, um als gültig zu gelten. Allerdings hat es einige Merkwürdigkeiten in Bezug auf fehlende Teile zutage gefördert, mit denen @qi_ma und @joshuef sich beschäftigt haben.
Das Herunterladen großer Dateien schlug gelegentlich fehl, weil beim Download ein oder mehrere Teile fehlten. Vielen Dank an alle, die dies gemeldet haben. Wir vermuten, dass ein Grund dafür im Caching liegt. Beim Abrufen einer Aufzeichnung aus Kademlia haben wir einige Möglichkeiten. „Quorum::One“ bedeutet, dass wir die erste Antwort erhalten, die wir erhalten. „Quorum::All“ bedeutet, dass wir darauf warten, dass alle Antworten eingehen, und prüfen, ob sie übereinstimmen. Da Chunks selbstüberprüfbar sind (Inhalt wird adressiert), sollte eine Antwort ausreichen, da wir ihre Gültigkeit vor Ort überprüfen können.
Es scheint jedoch, dass Kademlia-Caching, das bei Verwendung von „Quorum::One“ Chunks auf näheren Knoten zwischenspeichern sollte, nicht ganz so funktioniert, wie wir es uns vorgestellt haben … Es scheint nur sicherzustellen, dass ein Knoten die Daten speichert, nur (wie im Gegensatz dazu, immer noch sicherzustellen, dass es an alle Dateninhaber geht, obwohl wir nur eine Kopie zurück benötigen). Deshalb deaktivieren wir das vorerst und kehren zu „Quorum::All“ zurück, um zu sehen, wie es weitergeht.
Falsche Lagerkosten sind ein weiterer möglicher Grund für fehlende Stücke. Manchmal fordert der Client Speicherkosten von anderen Knoten an als denen, die letztendlich die Blöcke speichern. Dies führt dazu, dass die Speicherknoten nicht bezahlt werden. Da wir auch einige Replikationsfehler feststellen, untersuchen wir diese ebenfalls. (Dies könnte durchaus mit der oben genannten „Quorum“-/Caching-Arbeit zusammenhängen!)
Um das Leben einfacher zu machen, haben wir es so gestaltet, dass der gesamte Vorgang mit der Fehlermeldung „MissingChunk“ stoppt, wenn ein Chunk nicht heruntergeladen werden kann, anstatt bis zum Ende zu warten. Wir verbessern außerdem die Protokollierung, um jeden Upload- und Download-Batch zu debuggen. Und da Protokolle wertvolle Debugging-Informationen liefern, protokollieren wir jetzt standardmäßig die Ausgabe von Clients und Knoten. Die Protokolle sind recht ausführlich. Beachten Sie daher, dass kleine Instanzen wahrscheinlich schneller voll sind.
Und wir haben hartcodierte Bootstrap-Peers zum Knoten- und Client-Code hinzugefügt, sodass die Variable „SN_PEERS“ nicht mehr festgelegt werden muss.
„Stapelgröße“ und „Parallelität“ scheinen einen gewissen Effekt zu haben, wobei größere Stapelgrößen die Downloads erheblich beschleunigen und größere Parallelitätseinstellungen, bis zu 40 oder so, das Gleiche bewirken. Wir experimentieren derzeit mit den Auswirkungen auf die Leistung, wenn die Größe der geschlossenen Gruppe von 8 auf 5 reduziert wird, was zu schnelleren Downloads und einer geringeren Speichernutzung führen sollte.
Vielen Dank wie immer an alle, die sich engagiert und das Ding auf Herz und Nieren geprüft haben. Als Belohnung konnte man den Spaß genießen, in einem hyperinflationären Umfeld zu leben, und ein oder zwei Leute wurden extrem reich an SNT. Geben Sie nicht alles auf einmal aus, Leute.
CashNotes
CashNotes ist der neue Name für DBCs, der die Art und Weise, wie Zahlungen tatsächlich erfolgen, besser widerspiegelt. Der zugrunde liegende Code dafür hat sich hier nicht geändert.
Im Wesentlichen handelt es sich dabei um eine lokale Darstellung von Token in einer Wallet. Sie können von den Empfängern im Netzwerk im Austausch gegen neue mit demselben Wert (Gesamtsende-Eingabe-/Ausgabewert) ausgegeben werden.
CashNotes werden in Transaktionen erstellt und abgeleiteten öffentlichen Schlüsseln zugeordnet. Die abgeleiteten Schlüssel werden aus dem öffentlichen Schlüssel des Empfängers und einem zufälligen Index erstellt. Für jede Transaktion wird ein anderer abgeleiteter Schlüssel verwendet, wodurch jede CashNote einzigartig und nicht mit dem ursprünglichen öffentlichen Schlüssel des Eigentümers verknüpft werden kann.
Der Empfänger benötigt den geheimen Zufallsindex zusammen mit den übergeordneten Transaktionsinformationen, um den entsprechenden abgeleiteten privaten Schlüssel zu generieren, um die CashNote für den Empfang von Zahlungen einzulösen.
Allgemeiner Fortschritt
@joshuef und @qi_ma waren die Hauptteammitglieder, die sich mit der Untersuchung falscher Filialkosten, fehlgeschlagener Replikation und fehlender Chunks befassten. Josh hat eine PR ausgelöst, um schnell scheitern zu melden, sobald Chunks während des Downloads fehlen, und vorübergehend Kademlia-Caching entfernt und wechselte zurück zu Quorum::All, um das Problem mit den fehlenden Chunks zu beheben.
Qi hilft nicht nur beim Debuggen, sondern erforscht auch weiterhin das „libp2p“-Caching, um es besser zu verstehen, und untersuchte die „GossipSub“-Pub/Sub-Implementierung, an der @bochaco ebenfalls arbeitet. Das befindet sich derzeit in der Testphase und sie verfolgen, wie sich Nachrichten zwischen Knoten verbreiten. Da ist es noch ein kleiner Weg. @bochaco hat auch an Belohnungsbenachrichtigungen im Knoten gearbeitet.
@Anselme hat nicht verwendeten Code bereinigt in der sn_transfers-Kiste, das Sicherheitsrisiko minimiert, indem Module privat gemacht wurden, und Benchmarks mithilfe von High-Level-Transfer-APIs neu geschrieben, um dies zu bewältigen ändern.
@bzee arbeitet an der Wiederverwendung von Transfers, wenn sich die Knotenkosten ändern. Wenn der StorWenn ein Knoten seinen Preis zwischen dem Zeitpunkt, an dem der Kunde einen Shop anfordert, und dem Zeitpunkt, an dem er die Zahlung leistet, erhöht, reicht diese Zahlung nicht aus. Anstatt noch einmal von vorne beginnen zu müssen, möchten wir es mit der ursprünglichen CashNote noch einmal versuchen. Wenn dies erneut fehlschlägt, füllen wir es mit einer zusätzlichen CashNote auf, was schneller geht.
@Chriso hat Unterstützung für versionierte Binärdateien zum automatisierten Testnet-Bereitstellungstool hinzugefügt und hat daran gearbeitet, dies zusammen mit einigen netten Verbesserungen zum Laufen zu bringen das „sichere“ ux.
@roland arbeitete auch an Korrekturen als Reaktion auf die Testnet-Ergebnisse und @dirvine reduzierte die Größe der geschlossenen Gruppe von 8 auf 5, um die Leistung zu verbessern. David hat außerdem weitere Überlegungen zu einem sicheren Upgrade-Mechanismus für Safe angestellt.
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.
En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!