Safe Network Entwickler Update ­čçę­čç¬ 18. November 2021

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Update 18 November 2021

Also ├╝bergeben wir diese Woche an Gab
Wie du wei├čt, ist er nicht der, der prahlt
Aber er hat leise einen Nachrichten-Problem behoben
Durch Speichern von SectionChains in einem DAG
OK, es ist kein Lambo oder gar ein Jag
Aber f├╝r Netzwerkbetriebe ist es wirklich fabelhaft
Schau es dir an, wenn das deine Tasche ist

Allgemeiner Fortschritt

@danda hat UML-Diagramme f├╝r alle Safe-Network-Kisten erstellt, damit Sie leicht sehen k├Ânnen, wie sie alle zusammenpassen. F├╝r Nicht-Techniker gibt die M├Âglichkeit, die Namen der Codebl├Âcke und ihre Verkn├╝pfung durchzusehen, einen Einblick in die Funktionsweise des Netzwerks. ├ähnlich wie bei allen Zahnr├Ądern in einer Uhr verstehen Sie m├Âglicherweise nicht alle Details der Teilung und der Anzahl der Z├Ąhne, aber es kann gut sein, die Zahnr├Ąder hinter der L├╝nette zu sehen, um ein besseres Verst├Ąndnis der Funktionsweise zu erhalten. Sie k├Ânnen nackte, kompakte und vollst├Ąndige Versionen jeder Kiste mit zunehmender Detailgenauigkeit sehen, wobei gr├╝ne Bl├Âcke Merkmale, blaue Strukturen und gelbe Aufz├Ąhlungen darstellen. Die Website wird am besten in Chrome angezeigt.

Eine ÔÇÜnackteÔÇś SVG-Darstellung der Kiste sn_dbc

Inzwischen richten @qi_ma und @lionel.faber ihre Aufmerksamkeit auf die Implementierung des Anti-Entropie-Musters in den Prozess der verteilten Schl├╝sselgenerierung.

OK r├╝ber zu Gabriel (@bochaco).

Umgang mit Netzwerkwissen

Netzwerkwissen beschreibt die Prozesse, mit denen ├älteste die Topologie des Netzwerks verfolgen. Da Safe asynchron ist und sich st├Ąndig ├Ąndert, erfolgt dies nach dem Need-to-Know-Prinzip, wobei, wenn ein Knoten einen anderen Knoten kontaktiert, er sein Wissen zuerst synchron durch den Austausch von Anti-Entropie-Nachrichten (AE) erh├Ąlt.

Um die Nachrichten├╝bermittlung zu reduzieren, haben wir jetzt einen DAG, um alle SectionChains zu verfolgen und eine PrefixMap, um aktuelle Abschnitts-SAPs zu speichern. Im Folgenden wird erl├Ąutert, wie sich dies auf die AE- und SAP-Verifizierung auswirkt, wenn eine Erstnachricht abgelehnt wird.

SectionChain

Eine SectionChain ist eines der wichtigsten Werkzeuge, die einem Knoten zur Verf├╝gung stehen, da sie es ihm erm├Âglicht, zu ├╝berpr├╝fen, ob ein Datenelement oder eine Nachricht g├╝ltig ist (Netzwerkberechtigung hat).

Eine SectionChain ist eine verkn├╝pfte Liste von Abschnittsschl├╝sseln, bei der der Schl├╝ssel jedes Blocks in der Kette mit dem Schl├╝ssel des vorherigen Blocks bis hin zum Genesis-Schl├╝ssel signiert ist.

Jeder Block in der Kette enth├Ąlt den Abschnittsschl├╝ssel, mit dem die ├ältesten - zu diesem bestimmten Zeitpunkt - alle Vereinbarungsverfahren unterschrieben haben. Bei jedem ├ältestenwechsel (Abwanderung) wird ein neuer Abschnittsschl├╝ssel generiert und der Abschnittskette ein neuer Block hinzugef├╝gt.

Wie wird es verwendet, um Nachrichten und Daten zu ├╝berpr├╝fen? Nun, jeder Inhalt oder jede Information, die mit einem Abschnittsschl├╝ssel signiert ist, kann durch einen Blick auf die Abschnittskette ├╝berpr├╝ft werden. Wenn der Schl├╝ssel dort gefunden wird, bedeutet dies, dass der Inhalt/die Information in der Vergangenheit von der Sektion signiert wurde und daher Netzwerkautorit├Ąt besitzt.

Anti-Entropie-Wiederholung und -Umleitung

Das Netzwerk verwendet eine Reihe von Anti-Entropie-Nachrichten (AE) f├╝r Knoten, um sich ├╝ber die Topologie des Netzwerks und den Abschnitt, zu dem sie geh├Âren, zu synchronisieren. Jede an einen Knoten oder einen anderen Abschnitt gesendete Nachricht muss den aktuellen Abschnittsschl├╝ssel des Ziels enthalten, damit die Nachricht vom Empf├Ąnger akzeptiert wird. Ist dies nicht der Fall, lehnt der Empf├Ąnger die Nachricht ab und schickt sie in einer ÔÇ×AE-RetryÔÇť-Nachricht an den Absender zur├╝ck. Die AE-Retry-Nachricht enth├Ąlt aktuelle Informationen ├╝ber ihre Sektion, dh den aktuellen Section Authority Provider (SAP), der die aktuellen Sektions├Ąltesten auflistet, und den aktuellen Sektionsschl├╝ssel (siehe das AE-Kapitel in der Einf├╝hrung).

Ein ├Ąhnlicher Ereignisfluss wird ausgel├Âst, wenn eine Nachricht an einen falschen Abschnitt gesendet wird, was daran liegen kann, dass dem Absender die neuesten Informationen ├╝ber die Topologie des Netzwerks fehlen. Der Empf├Ąnger wird auch die Nachricht ablehnen, die sie innerhalb einer ÔÇÜAE-RedirectÔÇś-Nachricht an den Absender zur├╝cksendet. In diesem Fall enth├Ąlt die ÔÇÜAE-RedirectÔÇś-Nachricht den SAP des Abschnitts, an den die Nachricht erneut gesendet werden soll.

Wenn der Sender einen neuen SAP durch eine ÔÇÜAE-RetryÔÇś- oder ÔÇÜAE-RedirectÔÇś-Nachricht empf├Ąngt, muss er zuerst ├╝berpr├╝fen, ob es sich um einen g├╝ltigen und vertrauensw├╝rdigen SAP handelt, d. h. ├╝berpr├╝fen, ob der SAP dem Netzwerk entspricht, dem der Sender vertraut.

Dazu muss der Node pr├╝fen, ob der im empfangenen SAP gefundene Abschnittsschl├╝ssel mit der SectionChain bis hin zum Genesis-Schl├╝ssel kryptographisch verifizierbar ist, andernfalls k├Ânnte ein b├Âsartiger Knoten ihn auf einen anderen (nicht sicheren) umleiten. Netzwerk oder an b├Âswillige Peers oder Abschnitte. Aus diesem Grund tr├Ągt jede Anti-Entropie-Nachricht auch eine ProofChain, damit der urspr├╝ngliche Absender das neue SAP ├╝berpr├╝fen und ihm vertrauen kann.

Eine ProofChain sind die letzten paar Bl├Âcke der SectionChain - wir m├╝ssen nicht die vollst├Ąndige SectionChain senden, wenn wir k├╝rzlich mit einer anderen Sektion in Kontakt waren, nur das Delta.

Was hat sich ge├Ąndert?

Bisher hatte jeder Knoten eine Kopie seiner eigenen SectionChain und SAP. Dies wurde verwendet, um alle eingehenden Nachrichten oder neuen SAP-Nachrichten zu validieren, die in AE-Nachrichten empfangen wurden, und um beim Senden eine ProofChain zu erstellenAE-Nachrichten an andere Peers senden.

Was f├╝r Abschnitte, die wir kennen, in Ordnung war, aber f├╝r entfernte, unbekannte Abschnitte verursachte es einiges an zus├Ątzlicher Arbeit.

Nehmen wir an, wir senden eine Nachricht und sie wird zur├╝ckgegeben, dass wir sie an einen Abschnitt umleiten m├╝ssen, den wir noch nicht kontaktiert haben, und einschlie├člich des SAP dieses unbekannten Abschnitts. Wir kennen den Abschnitt durch sein XOR-Adresspr├Ąfix, aber sonst wissen wir nichts dar├╝ber oder es uns. Wir haben sein SAP noch nie gesehen und wir haben keine ProofChain. Bevor wir die Nachricht also erneut an den neuen Abschnitt senden k├Ânnen, m├╝ssen wir zus├Ątzliche Nachrichten an den Austausch von SectionChains senden, was komplex und fehleranf├Ąllig ist.

Aus diesem Grund haben wir k├╝rzlich daran gearbeitet, dass alle Knoten die SectionChains von allen anderen Abschnitten verfolgen. Dies erm├Âglicht es jedem Knoten, Peers nicht nur dann eine ProofChain bereitzustellen, wenn er sie mit dem SAP seines eigenen Abschnitts aktualisiert, sondern auch, wenn eine ÔÇÜAE-RedirectÔÇś-Nachricht ihn dazu auffordert, dies f├╝r einen entfernten Abschnitt zu tun.

Dadurch wird ein Teil des AE-Verkehrs und der Komplexit├Ąt vermieden und es k├Ânnen Knoten auch sicherstellen, dass sie nur mit Peers interagieren, denen sie vertrauen, dass sie demselben Netzwerk angeh├Âren, indem sie jeden Abschnittsschl├╝ssel, den sie erhalten, bis hin zum Genesis-Schl├╝ssel kryptografisch verifizieren.

Aber wie k├Ânnen wir diese Informationen sicher und effizient speichern, damit Knoten bei Bedarf darauf zugreifen k├Ânnen und bei Splits und Churn aktualisiert werden?

Wir haben jetzt einen DAG (directed acyclic graph) implementiert, um alle SectionChains und eine PrefixMap (ein Register, das das Pr├Ąfix eines Abschnitts seinem SAP zuordnet) zu verfolgen speichert die aktuellen SAPs aller Sektionen.

###Der DAG
Das Netzwerk beginnt mit einem Genesis-Schl├╝ssel, der der allererste Block in der SectionChain des Genesis-Abschnitts ist, und der Schl├╝ssel des allerersten Knotens wird vom Genesis-Schl├╝ssel signiert, um den zweiten Block in dieser SectionChain zu erstellen. Wenn Knoten beginnen, sich diesem allerersten Abschnitt, d. h. dem Genesis-Abschnitt, anzuschlie├čen, w├Ąchst die SectionChain weiter.

Irgendwann, wenn die Genesis-Sektion mit genügend Mitgliedern gewachsen ist, um sich in zwei separate Sektionen aufzuteilen, werden sich die beiden Gruppen von Gleichaltrigen, die Ältesten werden, darauf einigen, welcher ihr eigener Sektionsschlüssel wird (durch den DKG-Prozess). Sobald sich alle auf die beiden neuen Abschnittsschlüssel geeinigt haben, wird sich die aktuelle Gruppe von Ältesten darauf einigen, den Abschnitt aufzuteilen, die beiden neuen Abschnittsschlüssel mit dem aktuellen Abschnittsschlüssel zu signieren und zwei Zweige in der Abschnittskette des Genesis-Abschnitts zu erstellen.

Dieser Vorgang wird in jedem der beiden neuen Zweige unabh├Ąngig voneinander wiederholt. Sie teilen sich in mehr Abschnitte auf und erstellen mehr Verzweigungen in ihren jeweiligen Abschnittsketten. Dies bildet nat├╝rlich einen DAG, wobei jeder der Scheitel einen Abschnittsschl├╝ssel und die Signatur enth├Ąlt, die mit dem Abschnittsschl├╝ssel des vorhergehenden Scheitels erstellt wurde.

Bei einem beliebigen Abschnittsschl├╝ssel kann seine ProofChain aus dem DAG erstellt werden, indem alle Vertices (Abschnittsschl├╝ssel und Signaturen) gesammelt werden, die sich im Pfad vom Genesisschl├╝ssel zu diesem Abschnittsschl├╝ssel befinden. Beachten Sie, dass es immer einen eindeutigen Pfad vom Genesis-Schl├╝ssel zu jedem anderen Abschnittsschl├╝ssel in der DAG gibt, da die Abschnitte nie zusammengef├╝hrt, sondern nur geteilt werden, mit anderen Worten, es gibt f├╝r jeden gegebenen Abschnittsschl├╝ssel eine eindeutige Beweiskette vom Genesis-Schl├╝ssel.

Diese Entwicklung wird in dieser PR detailliert beschrieben.


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!