Safe Network Entwickler Update đŸ‡©đŸ‡Ș 17. November 2022

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 17 November, 2022

Byzantinische Fehlertoleranz, basierend auf dem Problem der Byzantinischen GenerĂ€le, ist ein Muss fĂŒr dezentrale Netzwerke, in denen sich Knoten einigen mĂŒssen, auch wenn einige bösartig sind. @dirvine geht durch, was BFT ist und vor allem, was es vermisst.

Allgemeiner Fortschritt

@davidrusu Hat daran gearbeitet, AE von den Join-Nachrichten zu entkoppeln und hat dort einige gute Fortschritte gemacht, der Join-Code ist jetzt etwas einfacher.

@joshuef befasst sich auch mit dem Verbinden von Knoten und hat einige Anomalien gefunden. Wenn mehr als ein Drittel der Antworten von Ältesten eingegangen sind, fragt der beitretende Knoten erneut. Bei fĂŒnf Ältesten, die zwei Antworten erhalten haben, versucht es der Knoten erneut und erhĂ€lt zwei weitere Antworten. Aber in diesem Stadium erhĂ€lt es eine Antwort fĂŒr den ersten Versuch, was zu einer Stall/Ghost-Node-Situation fĂŒhrt.

Außerdem hat er erfolgreich weitere Sperren entfernt, sodass Erwachsene jetzt ohne Zwischenschritte direkt in das Dateisystem schreiben können. Eine wichtige Vereinfachung.

Und in einer weiteren Optimierung hat @bzee einen Teil von qp2p in eine Quinn-Ă€hnlichere API umgestaltet, bei der keine separate Datenstruktur fĂŒr eingehende Verbindungen oder Streams benötigt wird.

Byzantinische Fehlertoleranz

Das Problem der byzantinischen GenerÀle in der realen Welt

Beim Problem der byzantinischen GenerĂ€le wird die Stadt Byzanz von einer Armee belagert. Die GenerĂ€le, die diese StreitkrĂ€fte befehligen, mĂŒssen den Zeitpunkt des Angriffs bestimmen. Wenn alle GenerĂ€le ihre StreitkrĂ€fte gleichzeitig zum Angriff auf die Stadt fĂŒhren, ist der Sieg sicher, aber wenn sie zu unterschiedlichen Zeiten angreifen, verlieren sie. Die GenerĂ€le haben keine direkte Kommunikation miteinander und die NachrichtentrĂ€ger können feindliche Spione sein, von den VerteidigungskrĂ€ften getötet oder die Nachrichten selbst könnten verĂ€ndert worden sein. Außerdem könnten natĂŒrlich einige der GenerĂ€le selbst VerrĂ€ter sein. Wie stellen die GenerĂ€le sicher, dass ihre StreitkrĂ€fte alle gleichzeitig angreifen?

Dies ist das Problem, das dezentrale Netzwerke ĂŒberwinden mĂŒssen.

Wenden wir die Analogie auf dezentralisierte Systeme an, erhalten wir:

  • Loyale GenerĂ€le ==> ehrliche Knoten
  • VerrĂ€terische GenerĂ€le ==> fehlerhafte Knoten
  • Feindliche Armee, wir senden Nachrichten ĂŒber ==> unzuverlĂ€ssiges asynchrones Netzwerk, das Nachrichten verwerfen und verzögern kann

Diese Geschichte ist eine verdauliche Tarnung fĂŒr einige ziemlich schwere Mathematik, in der sich herausstellt, dass die ehrlichen GenerĂ€le ihre PlĂ€ne erfolgreich koordinieren können, solange nicht mehr als ein Drittel der GenerĂ€le verrĂ€terisch sind – byzantinische Fehlertoleranz (BFT).

Wir haben mehrere Knoten, von denen einige unehrlich sein können und andere KommunikationsausfÀlle zwischen ihnen erleiden können.

Das klassische Problem der byzantinischen GenerĂ€le ist eines der lokalen Zustandssynchronisierung trotz verrĂ€terischer GenerĂ€le, die versuchen, die Staaten voneinander zu trennen. Um es etwas auszuweiten, wĂ€ren sowohl „ANGRIFF“ als auch „RÜCKZUG“ richtige (gĂŒltige) Antworten
 solange alle loyalen KrĂ€fte dasselbe tun.

FĂŒr unsere Zwecke ist das Problem der klassischen byzantinischen GenerĂ€le eine eingeschrĂ€nkte Sicht auf BFT. Es konzentriert sich ausschließlich auf Konsens und muss sich daher mit mehr Arten von Fehlern befassen.

Es gibt andere Begriffe von BFT, die wir uns stattdessen ansehen können, um Probleme mit der Mitgliedschaft zu lösen.

Hier ist das Problem, dass wir eine Gabelung haben. Wenn Erwachsene und Älteste die Knoten verlassen oder sich ihnen anschließen, können sie unterschiedliche Ansichten des Abschnitts haben. Obwohl diese Verzweigung schließlich aufgelöst wird, werden die wĂ€hrend der geteilten Ansicht getroffenen Entscheidungen, z. B. eine DBC-Ausgabe, sind schwer zu handhaben. Daher versuchen wir, diese geteilte Meinung durch Konsens zu vermeiden.

Eine Option, an der Mostafa und @Davidrusu arbeiten, ist ein Broadcast-Protokoll namens Verifiable Consistent Broadcast (VCBC).

BFT-Broadcast-Protokolle

Ein Broadcast-Protokoll versucht, eine Nachricht von einem Knoten an das Netzwerk zu verbreiten. Die BFT-Version versucht sicherzustellen, dass sich alle Knoten auf die Nachricht einigen, die dieser Knoten gesendet hat:

Auf der linken Seite haben wir einen ehrlichen Knoten „1“, der „msg“ an 2,3,4,5 sendet. Rechts haben wir einen fehlerhaften Knoten „1“, der „a“ an 2,3 und „b“ an 4,5 sendet.

1

Ein BFT-Broadcast-Protokoll schĂŒtzt im zweiten Fall vor dem Fork, indem sichergestellt wird, dass alle ehrlichen Knoten entweder derselben Nachricht von „Knoten 1“ zustimmen oder sich alle weigern, eine Nachricht von „Knoten 1“ zu akzeptieren.

Dies geschieht in VCBC ĂŒber ein 3-Phasen-Protokoll:

  1. Knoten 1 sendet die Nachricht, die alle sehen sollen
  2. Alle Knoten prĂŒfen, ob dies das erste Mal ist, dass Knoten 1 eine Nachricht gesendet hat, wenn ja, antwortet er mit einem Signaturanteil ĂŒber die Nachricht: sigma_j(m)
  3. Knoten 1 wartet, bis sie > 2/3 der Signaturanteile erhalten, um sie zu einer vollstĂ€ndigen Signatur zu aggregieren, und sendet dann die vollstĂ€ndige Signatur an das Netzwerk, um alle davon zu ĂŒberzeugen, dass sie alle die gleiche Nachricht haben.

Schauen wir uns an, wie dieser Algorithmus zusammenbricht.

VCBC ist entscheidend darauf angewiesen, dass mehr als 2/3 des Netzwerks dem Protokoll treu folgen. Wir können uns fragen: „Welchen Schaden kann es anrichten, wenn 1/3 oder mehr der Knoten fehlerhaft sind?“

Wenn mehr als 1/3, aber weniger als 2/3 + 1 fehlerhaft sind, dann ist das Schlimmste, was sie tun können, das Netz zum Stillstand zu bringenArbeit, indem sie sich weigern, Signaturanteile beizutragen.

Wenn mehr als 2/3 fehlerhaft sind, können die fehlerhaften Knoten Signaturen ĂŒber jede beliebige Nachricht erstellen.

Diese Tatsache gilt jedoch nur, wenn die BFT-Knoten konspirieren. Das heißt, wenn es sich nicht um denselben Angreifer handelt, spielen sie keine Rolle. Sie werden keinen Fork erstellen.

Ein entscheidender Teil der BFT-Vermeidung ist also das Wort COLLUDING.

Ein großartiges Gedankenexperiment ist das Lösen des BFT-Problems durch VIELE Angreifer. Auf diese Weise wird der einzelne konspirierende Angreifer durch andere Angreifer und ehrliche Knoten verwĂ€ssert.

Was bedeutet das im wirklichen Leben?

Betrachten wir den Verstand eines Angreifers. Was wĂŒrde er bevorzugen?

  1. Das Netzwerk lÀuft noch
  2. Sein Feind hat die Kontrolle ĂŒber das Netzwerk ĂŒbernommen

Die Antwort ist eindeutig, dass das Netzwerk immer noch ehrlich lĂ€uft. Wenn ein Angreifer also keine Mehrheitskontrolle hat (2f+1, wobei f = die Anzahl der schlechten, geheimen Knoten ist), kann er das Netzwerk nicht ĂŒbernehmen.

Wenn wir also N==9 haben und Knoten angreifen==9, aber Knoten kooperieren==0, dann haben wir keine Probleme?

Es ist also in Ordnung, dass 100 % der Knoten Angreifer sind.

Nur wenn wir schlechte Knoten miteinander verschwören, haben wir Probleme. Hier sind zwei Wege/Schwellen im Spiel. Wenn wir einen geheimen Angreifer in Betracht ziehen, dann sind die Schwellenwerte:

  1. Der Angreifer kontrolliert >=1/3 Knoten
  2. Der Angreifer kontrolliert >=2f+1 Knoten.

1 Ist ein Vandalismus-Angriff, bei dem er Entscheidungen und das Netzwerk aufhalten kann.
2 Ist eine Übernahme des Abschnitts mindestens.

Hier kommt es also auf die Perspektive an. Je mehr Angreifer wir haben, desto sicherer ist unser Netzwerk! Wir können den Einfluss eines Angreifers verringern, indem wir viele Angreifer und/oder viele ehrliche Knoten haben.

Also, was ist der BFT-Angriff auf ein Broadcast-Protokoll?

Wenn wir ĂŒber einen BFT-Angriff sprechen, meinen wir einen geheimen Angreifer. Einzelne Angreifer sind in Ordnung.

Wir können weniger als 1/3 abstimmender schlechter Knoten tolerieren. WĂ€hrend es viele schlechte Knoten geben kann, sind wir geschĂŒtzt, solange keine konspirierende Gruppe mehr als 1/3 der EntscheidungstrĂ€ger (zum Stillstand) oder 2f + 1 zum Erstellen eines Forks (Übernahme) umfasst.


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!