Soweit ich weiß, werden Transaktionen zu einem Block zusammengefasst, der Arbeitsnachweis wird erbracht, indem ein Hash-Wert für den Block berechnet und dann der Blockkette hinzugefügt wird. Wenn der Blockchain ein Block hinzugefügt wird, gilt die im Block enthaltene Transaktion als bestätigt.
Wie wird entschieden, von welchem Full Node die Blockchain abgefragt wird? Oder gegen wie viele Blockchains von vollständigen Knoten wird eine Transaktion geprüft?
Angenommen, ein Angreifer hat eine gegabelte Kette, und lassen Sie uns nichts über die Ablehnung oder Bestätigung dieser Gabelung durch andere vollständige Knoten annehmen. Kann meine Transaktion mit dieser gegabelten Kette des Angreifers und nicht mit anderen gültigen Blockketten, die von ehrlichen vollständigen Knoten verwaltet werden, überprüft werden?
Angenommen, ich habe 6 Bestätigungen erfolgreich durchgeführt, aber alle diese Blöcke sind eine Fork eines Angreifers. Ist das ein Problem?
Ihr Szenario ist nicht ganz klar, weil Sie uns nicht mitteilen, ob der Angreifer gültige Blöcke oder ungültige Blöcke produziert. Sie haben auch nicht definiert, ob Ihr eigenes Wallet ein Full-Node oder ein Thin Client ist.
Lassen Sie uns zunächst darüber sprechen, wie Blöcke durch das Netzwerk weitergeleitet werden:
Wenn ein neuer Block entdeckt wird, gibt ein Knoten über eine inv
(Bestands-)Nachricht bekannt, dass er diesen neuen Block hat. Andere vollständige Knoten senden eine getdata
Nachricht und fordern den gesamten Block an. Nachdem sie die Daten erhalten und validiert haben, senden sie eine inv
Nachricht an ihre Kollegen, um ihnen den neuen Block anzukündigen.
SPV-Knoten fordern nicht den vollständigen Block an. Sie erhalten nur den Block-Header, und wenn es interessante Transaktionen gibt, fordern sie ausdrücklich einen Nachweis für diese per merkleblock
Nachricht an. SPV-Knoten können die Gültigkeit neuer Blöcke nicht vollständig überprüfen, da sie die Blockchain nicht speichern.
Jetzt gibt es drei verschiedene mögliche Szenarien und zwei Arten von Wallets, die es zu berücksichtigen gilt:
Angreifer produziert ungültige Blöcke
Ein SPV-Wallet kann getäuscht werden, da es die Gültigkeit eines Blocks nicht überprüfen kann. Sie prüfen immer noch, ob die Block-Header wohlgeformt sind. Einige SPV-Wallets benötigen mehrere Peers, um ihnen denselben Block mitzuteilen. Daher kann dieser Angriff zusätzlich einen Sybil-Angriff oder die Kontrolle der Internetverbindung des SPV-Wallets erfordern .
Vollständige Knoten sind nicht betroffen, da sie ungültige Blöcke ablehnen.
Angreifer produziert gültige Blöcke mit niedriger Geschwindigkeit
. Ein SPV-Wallet reorganisiert sich zu einer längeren Kette, wenn es von einem anderen Peer davon erfährt. Auch hier muss die SPV-Wallet von anderen Informationen isoliert werden, damit dies funktioniert. Da die Informationen gültig sind, kann dieser Angriff auch gegen vollständige Knoten funktionieren. Dem Angegriffenen fällt möglicherweise die verdächtig langsame Aktualisierungsrate auf.
Der Angreifer produziert gültige Blöcke mit 51 % der Mining-Leistung
. Der Angreifer ist schneller als der gesamte Rest des Netzwerks. Indem er sich dafür entscheidet, nur auf seinen eigenen Blöcken aufzubauen, kann er 100 % der Blöcke abbauen und trotzdem das verbleibende Netzwerk übertreffen. Die Blöcke sind gültig und werden daher von allen Knoten akzeptiert (bis zu einer Art Eingriff). Der Angreifer kann Transaktionen zensieren und sogar eine kleine Anzahl von Blöcken zurücksetzen, indem er von einem früheren Block ausgeht, aber schließlich die natürliche Blockchain-Spitze überholt. Dies wird als Mehrheitsangriff bezeichnet und bricht die axiomatische Sicherheitsannahme von Bitcoin, dass mehr als die Hälfte der Mining-Power ehrlich ist.
Wie sicher sind sechs Bestätigungen im Fork eines Angreifers?
Wenn Sie in einen Sybil-Angriff geraten, wird Sie das täuschen. In allen anderen Fällen werden Sie nicht getäuscht, oder das gesamte Netzwerk ist das Ziel.
Sobald Sie eine Transaktion gesendet haben, übertragen Sie sie an das Netzwerk. Alle Full Nodes erhalten das und werden die Transaktion verifizieren, daher ignorieren Full Nodes die falschen Blöcke, wenn sie von Bergleuten übermittelt werden, und warten in Zukunft auf den richtigen Block und gehen davon aus, dass mehr als 50 % der Bergleute ehrlich sind, dass falsche Blöcke verwaist sein werden.
SPV-Clients suchen jedoch nur nach der längsten Kette und werden in diesem Fall vom falschen Block getäuscht.
Der von Ihnen beschriebene Angriff ist ein 51%-Angriff, bei dem der Angreifer 50% und mehr der gesamten Hashing-Power hat und daher in der Lage ist, gefälschte Blöcke übereinander zu erstellen, was zu einer wirklich verheerenden Situation führen kann und definitiv ein Problem darstellt.
Die im verwaisten Block verlorene gültige Trxid wird mit verzögerter Bestätigung im System in den nächsten verfügbaren Block eingereiht.
Der Grund für die Beibehaltung von zehnminütigen Lücken in jedem Block besteht darin, die Wahrscheinlichkeit zu verringern, dass 6 aufeinanderfolgende Transaktionen stattfinden.
Digitale Transaktionen mit schnellerer Blockrate oder geringerer Hashing-Leistung sind anfälliger für ein solches Ereignis
Jannes