Safe Network Entwickler Update đŸ‡©đŸ‡Ș 06. Oktober 2022

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:

  1. Wieder weniger Code
  2. Konkretere Datentypen
  3. Entfernen der Anforderung von Nachrichtensignaturen (Vorbehalt in einer Minute).
  4. 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!