und verbrachte einige Zeit damit, über Blockchain zu lesen, glücklicherweise nicht aus der Perspektive eines Krypto-Brüders, sondern eher aus echter Neugier, wie es tatsächlich funktioniert. Und während ich mich in diesem Kaninchenbau bewegte, stieß ich immer wieder auf ein Konzept, von dem ich noch nie zuvor gehört hatte. Das conflict Byzantinische Fehlertoleranz.
Kurz gesagt ist Byzantine Fault Tolerance eine Systemeigenschaft, die es einem System ermöglicht, weiterhin ordnungsgemäß zu funktionieren, selbst wenn einige böswillige Akteure in das System einbezogen sind. In diesem Water Cooler Small Speak geht es additionally um die byzantinische Fehlertoleranz: Was sie ist, woher sie kommt, warum sie wichtig ist und wie Blockchain zu einer der elegantesten Lösungen für ein sehr altes Downside wurde.
Additionally schauen wir mal rein!
von byzantinischen Generälen bis hin zu Computern
Byzantinische Fehlertoleranz ist additionally eine Systemeigenschaft, die ihren Namen dem folgenden spieltheoretischen Downside verdankt, nämlich dem Downside der byzantinischen Generäle:
Eine Gruppe byzantinischer Generäle hat eine Festung umzingelt. Sie müssen eine kollektive Entscheidung treffen, entweder anzugreifen oder sich zurückzuziehen. Sowohl die Entscheidung zum Rückzug als auch zum Angriff können funktionieren, aber nur, wenn alle koordiniert handeln. Ein koordinierter Angriff gelingt. Auch ein koordinierter Rückzug gelingt. Aber wenn einige Generäle angreifen, während andere sich zurückziehen, ist das Ergebnis eine Niederlage.
Die Kommunikation zwischen den Generälen erfolgt umfassend und die Generäle können nur kommunizieren, indem sie sich gegenseitig Boten schicken. Allerdings könnten einige der Generäle Verräter sein. Insbesondere wählt ein Verräter nicht nur falsch, sondern versucht auch, die anderen Generäle zu täuschen, indem er widersprüchliche Nachrichten an verschiedene Generäle sendet. Zum Beispiel kann ein Verräter einem Normal sagen, dass er angreifen soll, und einem anderen, sich zurückzuziehen, und dabei absichtlich versuchen, etwas zu erschaffen eine Spaltung. Unterdessen haben die loyalen Generäle keine Möglichkeit, im Voraus zu wissen, wer die Verräter sind.
Das Downside ist: Ist es möglich und wenn ja, wie und unter welchen Bedingungen kann eine solche Generalkonstellation einen Konsens erzielen?
Dieses Downside wurde erstmals offiziell von den Informatikern Leslie Lamport, Robert Shostak und Marshall Pease beschrieben ihre Arbeit von 1982. Und obwohl die Umgebung mittelalterlich und militärisch ist, ist das beschriebene Downside eine der grundlegendsten Herausforderungen in der Informatik. Das heißt, Wie erreicht man in einem verteilten System einen zuverlässigen Konsens, wenn einige Teilnehmer möglicherweise falsche Informationen senden?
In einem verteilten Computersystem haben wir anstelle von Generälen Knoten: einzelne Laptop oder Server, von denen jeder eine Kopie eines gemeinsamen Zustands enthält (eine Datenbank, ein Hauptbuch, eine Aufzeichnung von Transaktionen). Alle Knoten eines verteilten Methods müssen sich auf den gemeinsamen Wahrheitsstand einigen. Wie die Generäle kommunizieren sie, indem sie sich gegenseitig Nachrichten senden, und wie die Generäle könnten einige dieser Knoten fehlerhaft sein.
Aber warum nicht einfach wählen? Intuitiv könnte man davon ausgehen, dass jeder Normal einfach seine Stimme (Angriff oder Rückzug) an alle anderen Generäle senden, dann die Stimmen zählen und tun könnte, was die Mehrheit vorschlägt. Angreifen, wenn mehr als die Hälfte Angriff sagen, Rückzug, wenn mehr als die Hälfte Rückzug sagen.
Das Downside ist, dass dies nur funktioniert, wenn jeder Normal (Knoten) wirklich funktioniert vertraut die Nachrichten, die sie erhalten. Aber in ein solches Netzwerk können auch Verräter eingebunden sein, die unterschiedliche Stimmen an verschiedene Generäle schicken, mit dem Ziel, eine geteilte Entscheidung herbeizuführen. Normal A könnte eine Nachricht erhalten, die besagt: „Ich wähle Angriff“während Normal B eine Nachricht von demselben Verräter erhält, der besagt: „Ich stimme für Rückzug“. Daher könnten die Generäle A und B unterschiedliche Vorstellungen darüber haben, wofür sich die Mehrheit des Netzwerks entschieden hat. Mit anderen Worten: Wir können nicht mehr nur der Mehrheitsentscheidung vertrauen, da die Mehrheit für jeden Knoten möglicherweise unterschiedliche Nachrichten zählt. Und diese Unfähigkeit, einen Konsens zu erzielen, ist sowohl für diese hypothetischen byzantinischen Generäle als auch für verteilte Computernetzwerke ein echtes Downside.
Im Wesentlichen ist dies die Definition dessen, was ein byzantinischer Fehler ist. Ein byzantinischer Fehler ist ein Fehler in einem verteilten System, bei dem eine Komponente nicht einfach ausfällt, sondern sich stattdessen auf unvorhersehbare Weise verhält. Dies bedeutet, dass widersprüchliche Informationen an verschiedene Knoten gesendet werden, dass einige Knoten den Eindruck erwecken, dass sie korrekt funktionieren, während andere nicht funktionieren, dass aktiv falsche Ausgaben erzeugt werden und so weiter. Dennoch muss ein byzantinischer Fehler nicht unbedingt von einem böswilligen Akteur im Netzwerk herrühren, da er auch durch elektrische Fehler, Softwarefehler oder Hardwarefehler verursacht werden kann, die dazu führen, dass ein Knoten willkürliche Ausgaben erzeugt. Ein Knoten mit einem solchen Verhalten wird als byzantinischer Knoten bezeichnet.
Auf jeden Fall beweisen die Autoren dies in der Originalarbeit von 1982 mathematisch für ein System mit n Knoten, um den normalen Betrieb fortzusetzen (d. h., um tolerieren) f Zumindest byzantinische (Verräter-)Knoten n ≥ 3f + 1 Die Gesamtzahl der Knoten wird benötigt. Mit anderen Worten: Wenn mehr als ein Drittel der Knoten byzantinisch sind, ist es für ein solches System mathematisch unmöglich, zuverlässig einen Konsens zu erzielen, und es gibt keinen Algorithmus, der dafür sorgt, dass ein solches System weiter funktioniert. Ein System, bei dem mindestens zwei Drittel der gesamten Knoten unbeschädigt sind und das auch regular funktionieren und einen Konsens erzielen kann, verfügt über die Eigenschaft der byzantinischen Fehlertoleranz oder wird als byzantinisches fehlertolerantes System bezeichnet.
Was ist mit Blockchain?
Jahrzehnte nach der Veröffentlichung von 1982 blieb die byzantinische Fehlertoleranz ein theoretisches Downside mit praktischen Lösungen nur in streng kontrollierten Umgebungen wie Luft- und Raumfahrtsystemen, Kernkraftwerken oder jedem anderen Ort, an dem jeder Knoten im Voraus überprüft werden konnte und garantiert werden konnte, dass weniger als ein Drittel abtrünnig wird. Mit anderen Worten, es conflict ein gewisses Vertrauen zwischen den Knoten erforderlich, aus denen das Netzwerk besteht. Selbst wenn sich einige der Knoten an Verräter wenden würden, würden diese Verräter (hoffentlich) immer noch unter der 1/3-Schwelle liegen.
1. Bitcoin und Arbeitsnachweis
Dies conflict bis 2008 der Fall, als das Bitcoin-Whitepaper veröffentlicht wurde. völlige Umgehung des klassischen Abstimmungsansatzes. Im Gegensatz zu den bisher existierenden verteilten Netzwerken, bei denen der Konsens durch Mehrheitsbeschluss (hoffentlich) vertrauenswürdiger Parteien erreicht wird, wurde im Bitcoin-Whitepaper ein Mechanismus für den Betrieb eines vorgeschlagen vertrauenslos verteiltes System. Dies bedeutet, dass im Gegensatz zu Kernkraftwerken, wo im Vorfeld Vertrauen zwischen den Knoten bestand, Bitcoin kann funktionieren, ohne dass einer der Knoten einander vertrautweil der Bitcoin-Konsensmechanismus selbst die Transaktionen garantiert.
Der spezifische Mechanismus, durch den Bitcoin dies schafft, wird aufgerufen Arbeitsnachweis (PoW). Um es einfach auszudrücken: PoW macht es rechenintensiv, am Konsensprozess teilzunehmen, und noch teurer (praktisch unmöglich), ein Verräter zu sein. Genauer gesagt muss ein Knoten zum Hinzufügen einer neuen Transaktion ein kryptografisches Rätsel lösen, das enorme Mengen an Rechenleistung erfordert. Dieses Rätsel ist für den Knoten, der die Transaktion vorschlägt, schwer zu lösen, für andere Knoten ist es jedoch leicht zu überprüfen, ob die Lösung des Rätsels korrekt ist.
Ein Verräterknoten, der das System beschädigen und eine falsche Transaktion vorschlagen möchte, müsste die Rechenarbeit wiederholen, nicht nur für die Transaktion, die er beschädigen möchte, sondern für jede nachfolgende Transaktion. Das ist VIEL Rechenaufwand! Darüber hinaus müsste es dies schneller tun als der Relaxation des ehrlichen Netzwerks zusammen. In der Praxis würde dies die Kontrolle von mehr als 50 % der gesamten Rechenleistung des Netzwerks erfordern, was außerordentlich teuer und praktisch unmöglich ist. Auf diese Weise übersteigen die Kosten des Betrugs jeden potenziellen Nutzen, den man vom Betrug erwarten kann, und machen ihn wirtschaftlich irrational. Selbst wenn PoW zuverlässige Transaktionen in einem vertrauenswürdigen, dezentralen System ermöglicht, ist es aufgrund des enormen Rechenaufwands auch mit hohen Kosten und einer hohen Latenz verbunden (die Fertigstellung von Bitcoin-Transaktionen kann bis zu 10 Minuten dauern).
2. Moderne Blockchains und Proof of Stake
Darauf aufbauend „Das macht es wirtschaftlich irrational, zu betrügen”-Konzept, aber auch der Versuch, das System selbst schneller zu machen, ist ein weiterer Konsensansatz Nachweis des Einsatzes (PoS). PoS wird seit 2022 auf der Blockchain von Ethereum und auf anderen modernen Blockchains wie verwendet Solana Und Sui. Der Grundgedanke hinter PoS ist derselbe wie bei PoW, aber anstatt Betrug indirekt durch Berechnung wirtschaftlich teuer zu machen, macht es ihn direkt teuer, indem Netzwerkknoten gezwungen werden, wirtschaftliche Sicherheiten einzureichen. Insbesondere in einer PoS-Blockchain müssen Validatoren (Knoten, die Transaktionen vorschlagen) einen erheblichen Teil des Blockchain-Tokens sperren, um Transaktionen vorschlagen und überprüfen zu können. Wenn ein Knoten eine falsche Transaktion vorschlägt, bestraft das System dies und behält einen Teil der eingereichten Sicherheiten. Der Unterschied zu PoW besteht darin, dass byzantinisches Verhalten bei PoS wirtschaftlich bestraft und nicht rechnerisch undurchführbar gemacht wird.
Eine weitere Sache bei PoS ist, dass es das System BFT-ähnlicher macht. Im Gegensatz zu Proof of Work, das das klassische BFT-Abstimmungsmodell vollständig umgeht und die Korruptionsschwelle auf 50 % der gesamten Rechenleistung festlegt, bringt uns Proof of Stake wieder näher an das ursprüngliche byzantinische Fehlertoleranz-Framework heran. In einem PoS-System stimmen Validatoren über die Gültigkeit von Transaktionen ab, indem sie ihre eingesetzten Token als Gewicht verwenden. Dies bedeutet, dass die 1/3-Schwelle aus dem Originalpapier von 1982 wieder gilt: Wenn mehr als 1/3 des gesamten Einsatzwerts von byzantinischen Validatoren kontrolliert wird, kann der Konsens zusammenbrechen. PoS ist explizit byzantinische Fehlertoleranz im klassischen Sinne, PoW dagegen nicht – es löst lediglich eine andere Model desselben Issues.
Meiner Meinung nach: BFT jenseits der Blockchain
Was mich an BFT am meisten beeindruckt hat, ist, wie alt das Downside ist und wie lange es gedauert hat, von der Dokumentation des theoretischen Issues zu funktionierenden Lösungen zu gelangen. Insbesondere wird das Downside in der Originalarbeit von 1982 identifiziert und formalisiert, aber der erste praktische Algorithmus zur Handhabung in realen Computersystemen, genannt Sensible Byzantine Fault Tolerance (PBFT), erschien erst 1999. Und das erste System, das es tatsächlich in einer realen Umgebung (Bitcoin) einsetzte, kam erst 2008 auf den Markt.
Das andere, worüber ich immer wieder nachdenke, ist, wie universell das Downside ist. Über die Blockchain hinaus gibt es überall um uns herum byzantinische Fehlertoleranz oder allgemeiner das Downside, einen Konsens unter potenziell unzuverlässigen Teilnehmern zu erzielen. Immer wenn Sie mehrere unabhängige Parteien haben, die sich auf etwas einigen müssen, und Sie nicht allen vollständig vertrauen können, haben Sie eine Model des Issues der byzantinischen Generäle.
In verteilten Datenbanken stellen BFT-Protokolle sicher, dass sich ein Cluster von Datenbankservern auf den aktuellen Standing der Daten einigen kann, selbst wenn einige Server beschädigt sind oder falsche Informationen senden. In der Luft- und Raumfahrt nutzen Flugsteuerungscomputer Abstimmungen im BFT-Stil, um sicherzustellen, dass ein einzelner fehlerhafter Sensor keinen katastrophalen Ausfall verursachen kann. Ein Ausschuss, der mit einigen böswilligen Mitgliedern eine Entscheidung trifft. Eine Lieferkette, in der einige Lieferanten möglicherweise betrügerische Informationen senden. Ein verteiltes KI-Trainingssetup, bei dem einige Geräte möglicherweise verfälschte Updates senden. Die Generäle sind überall. Die Frage ist immer dieselbe: Wie erreicht man einen verlässlichen Konsens, wenn man nicht jedem im Raum vertrauen kann?
✨ Danke fürs Lesen! ✨
Wenn du es bis hierher geschafft hast, Vielleicht finden Sie Pialgorithmen nützlich: eine von uns entwickelte Plattform, die Groups dabei hilft, organisatorisches Wissen sicher an einem Ort zu verwalten.
Hat Ihnen dieser Beitrag gefallen? Begleiten Sie mich auf 💌 Unterstapel und 💼 LinkedIn
Alle Bilder vom Autor, sofern nicht anders angegeben