Könnte eine 2/3-Mehrheit als Konsens verwendet werden

Ich verstehe, dass Bitcoin derzeit die Kette mit den meisten Proof-of-Work als Konsens verwendet. Dieses Verfahren könnte jedoch verbessert werden, indem beispielsweise nur ein Block zu einem bestimmten Zeitpunkt generiert wird und jeder Knoten diesen Block mit seinen eigenen vergangenen Daten verifiziert. Wenn es mehr als 2/3 Knoten gibt, die beweisen, dass der Block gültig ist, wird der Block der Kette hinzugefügt. Wenn jemand einen gefälschten Block erstellen möchte, muss er mindestens 2/3 der gesamten Knoten kontrollieren. Für welche Art von Angriff ist dieser Konsens anfällig?

Es ist einfach, Regeln aufzustellen, aber viel schwieriger, ein Protokoll genau zu spezifizieren, das sie sicher durchsetzt. Welche Beweise könnten beispielsweise beweisen, dass 2/3 der Nodes glauben, dass der Block gültig ist? Was passiert, wenn ein Angreifer mehrere Millionen virtuelle Maschinen hochfährt, die jeweils einen Knoten ausführen, der behauptet, ihr gefälschter Block sei gültig?
Jeder Knoten verifiziert den Block mit seinen eigenen Aufzeichnungen. Für den zweiten Angriff, wenn ein Angreifer einen so großen Angriff starten kann, könnte er dann nicht auch das aktuelle Bitcoin-Netzwerk übertreffen?
@ Yangrui, nein, konnte er nicht. Das ist der Sinn der Verwendung von Proof-of-Work. Es spielt keine Rolle, wie viele Maschinen es gibt, es kommt darauf an, wie leistungsfähig sie zusammen sind. VMs geben Ihnen diese Leistung nicht; Der einzige Weg, dieses Leistungsniveau zu erreichen, wäre sehr, sehr teuer. Sie müssten mehr Rechenleistung kaufen als der Rest des Netzwerks zusammen. Selbst wenn Sie diese Ressourcen hätten, hätten Sie mehr zu gewinnen, wenn Sie sich an die Regeln halten, als wenn Sie versuchen würden, sie zu brechen.

Antworten (2)

Ich verstehe, dass Bitcoin derzeit die Kette mit den meisten Proof-of-Work als Konsens verwendet.

Dieses Verfahren könnte jedoch verbessert werden, indem beispielsweise nur ein Block zu einem bestimmten Zeitpunkt generiert wird und jeder Knoten diesen Block mit seinen eigenen vergangenen Daten verifiziert.

Nein, es kann auf diese Weise nicht verbessert werden; nicht im erlaubnislosen oder dezentralisierten Bedrohungsmodell von Bitcoin, bei dem jeder Knoten dem Bitcoin-Netzwerk jederzeit beitreten und es verlassen kann. Es würde sogar noch schlimmer werden.

Um zu verstehen, warum Ihr Schema in der erlaubnislosen Umgebung nicht funktioniert , müssen Sie verstehen, wie Sybil-Angriffe [ 2 ] es brechen. Eigentlich ist es ganz einfach: Ein Angreifer kann immer dann eine Wahl gewinnen, wenn er eine Mehrheit der falschen Wähler kontrollieren kann. Aus diesem Grund funktioniert Ihr Schema in der erlaubnislosen Einstellung von Bitcoin nicht. In Ihrem Schema kann der Angreifer eine Mehrheit der falschen Wähler kontrollieren, indem er eine Reihe von Knoten hinzufügt, bis er 2/3 der Knoten im Netzwerk kontrolliert. Dann kann er den Konsens diktieren.

Tatsächlich erwog Satoshi natürlich, eine 2/3-Mehrheitsabstimmung (1 Knoten = 1 Stimme) zu verwenden, um Bitcoin zu sichern, aber bald erkannte er, dass Sybil-Angriffe jedes solche Konsensschema brechen würden, weil es sehr billig ist, falsche Wähler zu schaffen: einfach gefälschte Knoten hervorbringen . Auch das Whitepaper von Bitcoin erwähnt dies deutlich (siehe Abschnitt 4, S. 3) [ 1 ].

Es ist wichtig zu verstehen, dass das Spawnen von Knoten so einfach ist wie das Generieren von Schlüsselpaaren. Mit anderen Worten, eine Signatur von einem Knoten ist in der Permissionless-Einstellung wertlos . Was garantiert eine Signatur wirklich, wenn jeder Trottel Millionen von Knoten hervorbringen und Millionen von Signaturen bereitstellen kann?

Bitcoin verhindert Sybil-Angriffe, indem es Abstimmungen teuer macht. Da jeder Dummkopf dem Bitcoin-Netzwerk beitreten und versuchen kann, Chaos anzurichten, sagt Bitcoin im Wesentlichen: „Mach es! Aber übrigens, wenn du wählen willst, musst du ein paar Billionen SHA256-Hashes berechnen.“ Bitcoin verwendet immer noch eine Mehrheitsabstimmung, um einen Konsens zu erreichen, aber es zählt die Stimmen nicht nach der Anzahl der Knoten, sondern nach der Anzahl der CPUs. Wieso den? Weil Dummköpfe nicht viele CPUs haben. Daher wird es für sie schwieriger, die Mehrheit der Stimmrechte zu übernehmen.

Wenn ich bei Bitcoin einen Konsens diktieren will, muss ich ASIC-Miner im Wert von 160 Millionen Dollar kaufen (nach einigen groben Berechnungen) und dann auch noch eine riesige Stromrechnung bezahlen.

Jetzt hast du gesagt:

Ich verstehe, dass Bitcoin derzeit die Kette mit den meisten Proof-of-Work als Konsens verwendet.

... aber es scheint, als würden Sie den Grund nicht verstehen, warum Bitcoin 1 CPU = 1 Stimme verwendet, anstatt 1 Knoten = 1 Stimme zu verwenden. Auch hier lautet die Antwort: um Sybil-Attacken zu verhindern.

Wenn es mehr als 2/3 Knoten gibt, die beweisen, dass der Block gültig ist, wird der Block der Kette hinzugefügt. Wenn jemand einen gefälschten Block erstellen möchte, muss er mindestens 2/3 der gesamten Knoten kontrollieren. Für welche Art von Angriff ist dieser Konsens anfällig?

Sybil greift an, wie bereits erwähnt.

Ich hoffe, das hilft bei der Beantwortung Ihrer Frage.

PS: Ich möchte darauf hinweisen, dass Ihr System in einer zugelassenen Umgebung gut funktioniert , in der es eine feste Anzahl von Knoten oder einen Zugangskontrollprozess gibt, der Knoten überprüft, bevor sie in das System aufgenommen werden. In dieser Einstellung sind Sybil-Attacken kein Problem. Beachten Sie jedoch, dass diese Einstellung das genaue Gegenteil der Bitcoin-Einstellung ist. Bitcoin möchte dezentral/offen/erlaubnislos bleiben (und viele andere Schlagworte, die Bitcoin-Fanatiker gerne verwenden).

Vielen Dank für Ihre Erklärung. Ich habe zwei mögliche Lösungen für den imaginären Sybil-Angriff gefunden: 1) Begrenzen Sie die Anzahl der neuen Knoten, die in jeder Runde hinzugefügt werden. Da der Angreifer die Zahl der vorhandenen Knoten übertreffen muss, kann das Netzwerk die Anzahl der neuen Knoten auf nicht mehr als 1/3 der Gesamtzahl der Knoten begrenzen. Ich weiß nicht, was besser ist
Gern geschehen! Ihre erste Lösung funktioniert nicht: Nach meinen Berechnungen kann ein Angreifer in etwa 4 Runden eine 2/3-Mehrheit erreichen, wenn er der einzige ist, der Knoten hinzufügt (jede Runde erhöht die Anzahl der Knoten um das 1,333-fache). Ihre zweite Lösung ist der Proof-of-Work-Konsens von Bitcoin. Nicht sicher, wie Wähler auf die gleiche Weise ausgezeichnet werden könnten. Denken Sie daran, dass wenn 1 CPU = 1 Stimme ist, ich dann doppelt so viel bekomme, wenn ich 2 CPUs habe.
Gibt es andere Proof-of-Work-Methoden, als nur einen Hash millionenfach zu berechnen?
Ja, dazu gibt es eine ganze Menge Literatur. Wenn Sie mehr erfahren möchten, ist es wahrscheinlich am besten, eine separate Frage zu diesem Thema zu stellen.

Ihr Vorschlag ist nicht ausreichend spezifiziert:

  • Wie wird der Authoring-Knoten ausgewählt?
  • Wie beweist ein Node seine Autorität, einen Block zu schreiben?
  • Wie zeigen andere Knoten Unterstützung für den veröffentlichten Block?
  • Wie kann die Unterstützung für einen veröffentlichten Block von anderen Knoten überprüft werden?

Es ist nicht klar, wie Ihr Vorschlag überhaupt Konsens erzielt. Darüber hinaus scheint die Abstimmung über Blöcke keine nennenswerten Kosten zu verursachen, sodass der Vorschlag anfällig für Sybil-Angriffe ist .

Ich denke, dass jeder Knoten im Moment gleichermaßen berechtigt ist, abzustimmen. Wenn ein Node einen Block genehmigt, signiert er den Block-Header mit seinem privaten Schlüssel, sodass wiederum andere Nodes ebenfalls überprüfen können, wer den Block signiert hat. Wenn ein Angreifer das Netzwerk angreifen möchte, muss er zuerst die privaten Schlüssel von mindestens 2/3 der gesamten Knoten erhalten.
Wer entscheidet, welche Nodes autorisiert sind?
Das Signieren des Headers als Genehmigung bedeutet, dass nicht nur jeder Knoten jede Signatur erhalten muss, sondern auch jeder Knoten eine Liste aller anderen Knoten und ihrer öffentlichen Schlüssel führen muss, um die Unterstützung zu messen. Wenn jemand einen Knoten starten und mit dem Signieren beginnen kann, führt dies zu Meinungsverschiedenheiten bei der Akzeptanz in einem Netzwerk, in dem Knoten ein- und aussteigen, da Knoten mit unterschiedlichen Gesamtunterzeichnern rechnen. Auch wenn ein Drittel der Knoten offline ist, kann kein Block validiert werden ... Es ist also ineffizient mit der Bandbreite, verzweigt sich und ist für DOS trivial. Ihr Vorschlag erfordert mehr Arbeit. ;)
@Yangrui, denk an Nates Standpunkt. Wenn ein Knoten autorisiert werden muss, kontrolliert derjenige, der die Autorisierung durchführt, das Netzwerk. Sie haben Bitcoin gerade in ein zentralisiertes System mit Berechtigungen umgewandelt. Diese Art vereitelt den gesamten Zweck.
Die Knoten haben das gleiche Stimmrecht. Sie müssen also abstimmen. Solange ein Node keinen Betrug begeht, darf er abstimmen.
@Murch guter Punkt. Es müssen jedoch nicht alle Knoten online sein. Ja, die Signatur wird mit dem öffentlichen Schlüssel jedes Knotens verifiziert, und alle öffentlichen Schlüssel müssen gespeichert werden. Allerdings sind nur Online-Knoten eingeladen, in jeder Runde abzustimmen. Der gute Punkt ist, dass Sie überprüfen können, ob die vergangenen Blöcke nur gültige Signaturen enthalten