Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 06 October, 2022
Der größte Teil des Teams ist damit beschäftigt, „Authority“ zu überarbeiten, den Code, der uns sagt, welche Akteure welche Aktionen ausführen können und auf welcher Ebene Genehmigung, die sie benötigen. Wir übergeben an einen jungen Kerl namens @dirvine, um es weiter zu erklären.
Allgemeiner Fortschritt
Andere Fixes sind ebenfalls im Gange.
@anselme hat einen Fehler in der sn_sdkg-Kiste behoben, der dazu führte, dass die Abstimmungsbehandlung rekursiv wurde. Damit würde ein Knoten, der DKG alleine ausführt, rekursiv die Beendigung erreichen, wenn er seine erste Stimme in einem Anruf verarbeitet! (Nicht gut).
@bochaco debuggt weiterhin zusammen mit @qi_ma die Kommunikation zwischen den Knoten und korrigiert auch Probleme, die bei Singlethread-Befehlen und Abfragen/Abfragen in der CI-Pipeline (Continuous Integration) festgestellt wurden.
In der Zwischenzeit untersuchen @bzee und @chriso die Funktionsweise von Quinn, der Rust-Implementierung des Quic-Protokolls zum Herstellen und Aufrechterhalten von Verbindungen zwischen ihnen Peers, im Hinblick auf das Refactoring von qp2p.
Refactoring-Autorität
Im Moment haben wir eine ‚Berechtigung‘ pro Nachricht, und diese Berechtigung ist zwischen Knoten, Client, Abschnitt und Abschnitt_Teil aufgeteilt. Es ist sowohl verwirrend als auch fehleranfällig. In jüngerer Zeit haben wir uns mit „Autorität“ beschäftigt, was sie bedeutet und was sie uns einbringt.
Der erste Schritt bei dieser Bereinigung besteht darin, die Nachrichtenautorität zu entfernen und sich auf „Operationen“ zu konzentrieren. Damit meinen wir, dass die Operation in der Nachricht dort ist, wo wir die Autorität überprüfen und sie auch direkt auf Daten anwenden möchten. Dieser Teil erspart uns, 1: zweimal die Autorität (Signaturen) zu haben und 2: sicherzustellen, dass jede Datenmutation (einschließlich Speicherung) die relevante „Autorität“ hat.
Um das ein wenig aufzuschlüsseln. Um Chunks oder einen Container (ein Register) zu lagern, verlangen wir, dass Kunden bezahlen. Wenn sie bezahlt haben, gibt jeder Älteste eine Teilunterschrift zurück. Der Client aggregiert dann die Signatur, um eine Abschnittssignatur zu erstellen. Diese Abschnittssignatur bleibt bei den Daten und macht die Daten „NetworkValid“. Es macht also keinen Sinn, die gesamte Nachricht zu signieren, nur den Teil, der „Store ABC“ sagt, wobei ABC der Datenname ist. Somit hat jedes Datenelement jetzt „SectionAuthority“ und es ist uns egal, in welcher Nachricht oder in welchem Format wir die signierte Operation erhalten.
Na und, mögen sich manche fragen. Nun, im Wesentlichen ist das, was wir jetzt tun, aus mehreren Blickwinkeln ziemlich aufregend:
- Wieder weniger Code
- Konkretere Datentypen
- Entfernen der Anforderung von Nachrichtensignaturen (Vorbehalt in einer Minute).
- Und der Große … siehe unten
Der Scharfsinnige mag an dieser Stelle einen großen Gewinn für dezentrale Netzwerke feststellen. Mit SectionSigned-Datenelementen und dem SectionTree von ein paar Updates zurück haben wir netzwerkunabhängig gültige Daten. d.h. jedes Netzwerk, das auch unserem SectionTree vertraut, sogar der Großteil davon (im Falle eines Mega-Hacks) kann die NetworkValid-Daten validieren und ihnen vertrauen. Mit dieser Funktion können Daten in andere Netzwerke oder sogar in Safe II verschoben werden, wer weiß?
Wir haben jedoch Knoten, die Nachrichten signieren, und wir betrachten dies als „Beweis“. Knoten senden einander und Clients Nachrichten mit Daten oder Vorschlägen (wie Knoten X ist tot oder Knoten Y möchte beitreten usw.) und wir behandeln ihre Nachrichten als Infrastrukturbefehle (d. h. vorübergehend) oder Client-Service-Befehle (Gib mir Daten). Da diese Nachrichten zu Konsequenzen im Netzwerk führen, verlangen wir von den Knoten, dass sie sich verhalten. Wenn festgestellt wird, dass sie sich schlecht benehmen, müssen wir unwiderlegbare Beweise für ihr schlechtes Benehmen haben, damit wir sie bestrafen können. Die signierte Nachricht gibt uns einen unwiderlegbaren Beweis für das Verhalten eines Knotens.
Unter Berücksichtigung all dessen ist das aktuelle Refactoring ziemlich schnell, es dauert nur ein paar Tage, aber es verschafft uns eine Menge Einfachheit und gibt uns gleichzeitig mehr Flexibilität beim Speichern/Neuveröffentlichen von Daten. Stellen Sie sich vor, Sie finden einige alte Daten auf Ihrem Knoten, sie sind nicht im Netzwerk, sollten es aber sein. Dann sollten Sie nicht bezahlen müssen, um es zu speichern, Sie sollten einfach sagen, dass hier ‚SectionSigned‘-Daten sind, Sie MÜSSEN es speichern. Es ist der Vertrag des Netzwerks mit dem Planeten.
Nicht nur das, die Clients, die für das Speichern bezahlen, zahlen tatsächlich, um „SectionAuthority“ für die Daten zu erhalten, wodurch sie „NetworkValid“ werden. Das bedeutet jetzt, dass sie die Abschnittsautorität zu ihren Daten hinzufügen und sie jederzeit speichern können. Sie können es auch erneut veröffentlichen, wenn das Netzwerk sie irgendwie versagt hat.
3 oder 4 von uns übernehmen diese Woche diese Aufgabe und wir sehen bereits Verbesserungen in der Klarheit und finden möglicherweise einige seltsame Fehler, wenn wir den alten Code von früher entfernen (Messaging hat dort immer noch sehr alten Code). Es ist ein wirklich ordentlicher Refactor, der die Fehlersuche so viel einfacher macht, da er den Netzwerkbetrieb einfacher macht. Es macht auch das Netzwerk einfacher zu erklären.
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!