Wie erhalten Full Nodes die Informationen über veraltete Blöcke?

Bei Bitcoin treten viele Forks auf, wenn mehrere Miner gleichzeitig Blöcke abbauen. Dann gibt es mehrere Blöcke auf derselben Blockhöhe. Ich habe mir den Bitcoin P2P-Entwicklerleitfaden unter https://developer.bitcoin.org/devguide/p2p_network.html angesehen

Für die Weitergabe von Blöcken sendet ein Relais eine "inv"-Nachricht an seine Peers. Die Peers fordern Header-Informationen mit „getheaders“ an und das Relay antwortet mit der „headers“-Nachricht. Dann fordern die Peers Blockinformationen mit "getdata" an und das Relay antwortet mit der "block"-Nachricht.

Wie können Peers in diesem Fall sicherstellen, dass sie mehrere Blöcke mit derselben Blockhöhe erhalten? Ein Relais könnte absichtlich "inv"- und "headers"-Nachrichten für nur einen der Blöcke auf derselben Blockhöhe verbreiten.

Wie können Peers überhaupt wissen, dass ein Fork stattgefunden hat? Liegt es in der Verantwortung des Relays oder des Peers, die Informationen über den Fork zu erhalten?

Antworten (1)

Eine Sicherheitsannahme ist, dass Knoten mit mindestens einem ehrlichen Peer verbunden sind. Wenn alle ihre Kollegen böswillig sind, ist es für sie durchaus möglich, einem Opfer Informationen über bestimmte Blöcke oder Transaktionen vorzuenthalten. Sehen Sie sich Eclipse-Angriffe an, wenn Sie mehr über diese Art von Angriffen oder die Gegenmaßnahmen wissen möchten.

Wird also von einem ehrlichen Relay erwartet, dass es Header für beide Seitenketten in der Nachricht "inv" und "headers" sendet? Wenn mehrere Relays eine "inv"-Nachricht an einen Knoten senden, wird der Knoten dann eine "getheaders"-Nachricht an jeden von ihnen senden und vergleichen? Oder sendet der Knoten die "getheaders"-Nachricht nur an eines der Relais?
Unter der Annahme, dass mindestens eines der Relais ehrlich ist, welche Überprüfungen/Mechanismen verwendet der Knoten, um sicherzustellen, dass er eine vollständige Ansicht hat?
Es gibt keine "Gesamtansicht". Jeder Knoten entscheidet unabhängig, welchen Block er als den aktuell aktiven betrachtet, basierend auf den Informationen, die er hat, und ehrliche Knoten werden diese Informationen an ihre Kollegen weitergeben. Nodes wissen nur von veralteten Blöcken, weil sie zum Zeitpunkt ihrer Weiterleitung aus Sicht des Relayers nicht veraltet waren.
Danke, Pieter :) Bitte lassen Sie mich wissen, ob das richtig ist. Angenommen, ein Knoten ist mit 8 Peers verbunden. Jeder der (ehrlichen) Peers, der einen neuen Block hat, sendet eine "inv"-Nachricht an den Knoten, "wenn der Peer diesen Block als Teil der Hauptkette betrachtet". Der Knoten antwortet mit der „getheaders“-Nachricht an „alle Peers“, die die „inv“-Nachricht gesendet haben. Immer wenn ein Peer einen Header zurücksendet, fordert der Knoten "getdata" an denselben Peer an. Wenn der Knoten den "Block" nicht innerhalb von 2 Sekunden erhält, wählt der Knoten einen anderen Peer aus, der denselben Header gesendet hat, und fordert von ihm "getdata" an.
Gibt es eine (etwas) formale Spezifikation der erforderlichen Annahmen für die Bitcoin-Blockausbreitung, um zu funktionieren? Bsp.: Was bedeutet hier „ehrlicher“ Peer? Welche Informationen muss ein "ehrlicher" Peer weitergeben, und welche sind optional? Ich versuche, Bitcoin mit einer anderen Blockchain zu integrieren. Formale Annahmen zu kennen ist irgendwie wichtig.
Gibt es irgendwo einen Pseudocode dafür, wie die Knoten beim Propagieren von Blöcken funktionieren?
Eine formale Spezifikation des Bitcoin-Protokolls kann es nicht geben, da es keine Instanz gibt, die darüber entscheiden kann. Die Regeln des Netzwerks werden durch das definiert, was die Leute ausführen, so unbefriedigend das auch sein mag. Stellen Sie sich vor, wir schreiben ein Dokument und segnen es irgendwie als Bitcoin-Protokollspezifikation. Und jetzt findet jemand eine Diskrepanz zwischen diesem Dokument und der Knotensoftware, die tatsächlich im Netzwerk läuft. Ohne eine Autorität, die jeden dazu zwingen kann, neue Software herunterzuladen, ist die einzige Schlussfolgerung, dass das Dokument falsch ist und korrigiert werden muss.
Es gibt natürlich Dokumentationen, wo Leute die Regeln beschreiben (statt sie vorzuschreiben ). Einiges davon kann im bitcoin.it- Wiki (obwohl vieles dort veraltet ist) und developer.bitcoin.org gefunden werden . Die wichtigsten Änderungen, die sich auf die Interaktion zwischen verschiedenen Implementierungen auswirken, werden zuerst als BIPs ( github.com/bitcoin/bips ) vorgeschlagen, aber viel mehr clientspezifische Richtlinien wie das Relay-Verhalten befinden sich einfach in den jeweiligen Quellcodes des Clients.