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.
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:
- Knoten 1 sendet die Nachricht, die alle sehen sollen
- 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) - 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?
- Das Netzwerk läuft noch
- 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:
- Der Angreifer kontrolliert >=1/3 Knoten
- 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!