Safe Network Entwickler Update 🇩🇪 15. September 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 15 September, 2022

Diese Woche beschäftigen wir uns mit der Frage der Autorität. Wer kann was und welche Nachweise braucht er dafür? Das Thema entsteht, da wir versuchen, den Code zu vereinfachen, Nachrichtenfiltermuster zu entfernen, die wir nicht mehr verwenden, und sicherzustellen, dass die Grundlagen logisch und leicht verständlich sind.

Allgemeiner Fortschritt

@anselme hat eine Gossip-Schicht implementiert, um verpasste Instanzen zu behandeln, wenn das neue DKG-System nicht beendet werden kann, und untersucht nun Fälle, in denen wir gleichzeitig geteilte DKGs haben, die zusammen beendet werden. DKG scheint ansonsten ziemlich stabil zu sein.

Und @roland hat den Wechsel von SectionChain (einer sicher verknĂĽpften Liste) zum neuen Design von Section DAG so gut wie abgeschlossen. Ein bisschen mehr testen und wir sind da.

@qi.ma hat nach potenziellen Fehlern in FilesContainers gesucht, da die Komnets kürzlich einige verdächtige Versionskonflikte hervorgehoben haben.

Wir haben uns auch mit einigen Client-Verbindungsproblemen von Knoten beschäftigt, die einige Antworten zu verwerfen scheinen. Und das Entfernen unnötiger Serialisierungsschritte um „OperationId“, wodurch die Belastung der Knoten weiter verringert wird.

Autorität

Wenn Sie an Autorität in Bezug auf Macht denken, könnten Sie denken, dass die Ältesten, die schlauen alten Graubärte, die größte Autorität hätten. Schließlich kontrollieren sie alles, was in ihrem Bereich vor sich geht, einschließlich der Macht über Leben und Tod anderer Knoten. Du liegst falsch. Wenn es darum geht, Änderungen im Netzwerk vorzunehmen, haben einzelne Knoten keinerlei individuelle Autorität. Erwachsene haben kein Mitspracherecht, während Älteste nur als Kollektiv durch eine Schwellenabstimmung Autorität haben.

Tatsächlich ist der stärkste Akteur der Kunde – der Kunde ist König, wenn Sie so wollen. Das liegt daran, dass der Client beispielsweise veränderliche Daten (Container), die ihm gehören, bearbeiten und die Neuausgabe eines DBC signieren kann. Die Knoten sind wirklich nur Boten, die Informationen über Operationen und Urteile hin und her weitergeben und meistens tun, was ihnen gesagt wird.

Warum ist das wichtig? Nun, es ist wichtig, weil wir klare Trennlinien darüber wollen, wer was tun kann. Wir wollen, dass die Autorität so weit wie möglich in Datentypen und Operationen implizit ist und dass dies durch Kryptografie gesteuert wird, nicht durch komplexe Hierarchien, und wir wollen möglichst einfache Autorisierungsstrukturen.

Datentypen

Berechtigungen sind in die Datentypen integriert.
Unveränderliche Daten
Wenn es um Mutation geht, sind Chunks unempfindlich gegenüber Autorität. Es gibt keine Behörde auf dem Planeten, die Ihnen erlaubt, die Daten zu ändern. Daher müssen wir uns keine Gedanken darüber machen, eine Autorisierungslogik für sie zu entwerfen.
Um einen Chunk zu speichern, benötigen wir jedoch eine Berechtigung. In diesem Fall wird sie von der Sektion bereitgestellt, in der sie gespeichert werden soll, und sobald diese Berechtigung erteilt wurde, gilt sie für immer. „SectionAuth“ ist ein gültiger Abschnittsschlüssel plus Signatur.

Veränderliche Daten
Das Speichern von Containern erfordert SectionAuth, während das Mutieren von Containern ClientAuth erfordert - nur der Besitzer sollte in der Lage sein, seine Daten zu ändern. Dieser Datentyp impliziert also, dass eine Client-Signatur erforderlich ist, bevor er geändert werden kann. „ClientAuth“ ist eine gültige Client-Signatur.

Die andere Art von veränderlichen Daten ist der SectionTree, ein Baum, der sich von Genesis verzweigt. Hier ist die Situation ein wenig anders, da es effektiv mehrere Eigentümer gibt (alle Abschnitte), aber jeder Abschnitt kann nur mit seinem SectionAuth ein Blatt zu seinem bestimmten Zweig hinzufügen.

DBCs sind insofern etwas komplexer, als sie von einem Client verlangen, dass er eine Neuausgabe autorisiert (ClientAuth) und einen Abschnitt, um sie abzumelden (SectionAuth). nicht zu gebrauchen.

Wichtig dabei ist, dass Knoten für Datenoperationen reine Nachrichtenträger sind und die Nachricht unabhängig vom Träger ist. Es ist uns egal, woher die Nachricht kommt, und es ist uns egal, wer sie unterzeichnet hat. Wir kümmern uns nur darum, dass das Datenelement die richtige Art von Signatur (Mandant oder Abschnitt) plus einen Schlüssel trägt.

Im einfachsten Beispiel kann ein Datenblock mit einem gĂĽltigen AbschnittssignaturschlĂĽssel im Universum herumfliegen, und wenn er zurĂĽckkehrt, muss das Netzwerk ihn akzeptieren, da eine Abschnittssignatur fĂĽr Daten bedeutet, dass er fĂĽr immer existiert.

Datenoperationen

In REST-API-Begriffen sehen Datenoperationen wie folgt aus:
GET-Operationen erfordern keinerlei Autorisierung.
PUT-Operationen erfordern „SectionAuth“ zum Speichern und eine Kombination aus „ClientAuth“ und „SectionAuth“ zum Bezahlen.
POST-Operationen erfordern „ClientAuth“, um Container zu mutieren, „SectionAuth“, um die einzelnen Blätter des SectionDAG zu mutieren

Token-Transfers erfordern eine Kombination aus „ClientAuth“ und „SectionAuth“.

Netzwerkbetrieb

Änderungen an der Zusammensetzung einer Sektion in Bezug auf ihre Ältesten und Erwachsenen, Splits usw. erfordern alle SectionAuth. Aber während einzelne Knoten in diesen Prozessen keine Autorität haben, sind zumindest die Ältesten nicht nur passive Nachrichtenträger wie bei Daten. Wenn zum Beispiel ein Ältester bemerkt, dass sich ein Knoten dysfunktional verhält, kann er eine Abstimmung darüber erzwingen, ob er es tun sollted bestraft werden.

Damit dies funktioniert, müssen Knoten in bestimmten Fällen identifizierbar sein, d. h. sie müssen Nachrichten mit ihren öffentlichen Schlüsseln signieren. Wenn also ein Client eine Anforderung für einen Chunk sendet und dieser Chunk verspätet ankommt oder eine Beschädigung vorliegt, ist die Signatur ein unwiderlegbarer kryptografischer Beweis für diesen Knoten, und der Client kann die Ältesten darüber informieren, dass es sich um einen schlechten Knoten handelt.

Und für die DKG ist es von entscheidender Bedeutung, dass die Nachrichten, die zwischen Ältesten mit ihren Stimmanteilen gesendet werden, autorisiert sind. Die Autorität der Nachricht ist die des Absenders und wird anhand seiner Unterschrift auf der Nachricht überprüft. Dies wird „NodeAuth“ genannt.

OK, aber wozu das alles?

Indem wir uns auf Autorität konzentrieren und unnötige Überprüfungen entfernen, insbesondere in Nachrichten, vereinfachen wir den Betrieb so weit wie möglich und verlassen uns auf Kryptografie und Datentypen, um die harte Arbeit für uns zu erledigen. Wir haben immer noch einige unnötige Nachrichtensignierungen, die von früheren Iterationen des Netzwerks hängen, und all dies hat Leistungseinbußen sowie Verwirrung zur Folge. Ein klares, einfaches Design ist ein effizientes Design.


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!