Testnet tx erscheint nach 90 Blöcken erneut

Irgendwann meldete der lokale Geth-Knoten tx 2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a im Block 1369316 im Testnetz. Es verschwand dann irgendwann während der nächsten 1-12 Blöcke aus der Kette.

Der lokale Geth -Knoten zeigt die Transaktionsdaten relativ zu seiner aktuellen Kopie der Blockchain; Auch wenn die Transaktion mit dem entsprechenden Hash in der Kopie vorhanden ist, bedeutet dies nicht, dass sie vom Netzwerk bestätigt wurde (sie muss zuerst weitergeleitet und geschürft werden. Erst dann wird sie der Blockchain hinzugefügt).

Derselbe TX tauchte nach 90 Blöcken auf dem Block 1369406 wieder auf und ist jetzt Teil der Blockchain.

Eine Transaktion kann nicht in dem Sinne „(erneut) erscheinen“, dass nur eine einzige Transaktion in der Blockchain mit einem Transaktions-Hash existieren darf, damit die Blockchain gültig ist.

Wenn es "verschwunden" ist, ist eines der folgenden Szenarien wahrscheinlich:

• die Transaktion wurde "absichtlich" von einem oder mehreren Knoten manipuliert (durch Bit-Manipulation) und an das Netzwerk weitergeleitet. Der Rest des Netzwerks hat es als ungültig markiert und daher nicht zur Blockchain hinzugefügt (mit Blockchain meine ich die gesamte Blockchain, auf die sich das Netzwerk geeinigt hat)
• die Transaktion existierte noch in den Blockchain-Kopien von Knoten, die validiert und mit Knoten synchronisiert wurden, die sie zuvor als ungültig markiert hatten (glücklicherweise bestrafen aktuelle Implementierungen von Ethereum Knoten, die ungültige Transaktionen weiterleiten (und nicht den Knoten, der die Transaktion durchgeführt hat)).
• Es wurde ein 51-%-Angriff durchgeführt (obwohl aufgrund der Kosten und des fehlenden finanziellen Gewinns im Testnetz unwahrscheinlich), und der Angreifer manipulierte die Transaktionsreihenfolge.
• Ethereum verwendet das GHOST -Protokoll, um Anreize für das Mining von Blockchains zu schaffen (deren Blöcke als Onkel der gültigen Hauptkette bezeichnet werden), die ungültige Daten, aber gültige Header bis zu einer bestimmten Höhe haben (die Gebühren für das Mining von Onkelblöcken werden pro Block exponentiell reduziert). Ihre Transaktion ist möglicherweise in einem solchen Block gelandet und hat sich später mit dem Hauptblock neu synchronisiert (da sie sowohl Header- als auch Datenmäßig gültig war).

Wir waren uns einig, dass das Warten auf 12 Blöcke ausreichen würde.

Sie können nicht wirklich einen absoluten Wert (von 12) Blöcken verwenden. Die „ausreichende“ Anzahl an Bestätigungen ist abhängig von den Mining-Knoten und deren beworbenen Blöcken. Man kann mit Sicherheit sagen, dass es umso besser ist, je höher die Anzahl der Bestätigungen ist (mehr Knoten haben sich auf die Blockchain „geeinigt“).

Wird dies durch einen Fork oder einen Replay-Angriff verursacht? Wenn ja, wie ist damit umzugehen?

Es ist höchst unwahrscheinlich, dass es durch einen Fork verursacht wird, da sich alle Bergleute darauf einigen müssten, auf einer neuen Blockkette ab einem bestimmten Block zu schürfen.

Nun, nach dem Prinzip der Blockchain, dass jeder beitreten und mit jeder Mining-Power beitragen kann, kann es nicht gemildert werden (durch die aktuellen Implementierungen von Ethereum). Eine Lösung wäre die Verwendung von zugelassenen Blockketten (dh eris ), die ACLs für Peers ermöglichen, die dem Netzwerk beitreten.