Wiki/EIP-155: Replay-Schutz und die Chain-ID erklärt
EIP-155: Replay-Schutz und die Chain-ID erklärt - Biturai Wiki Knowledge
FORTGESCHRITTEN | BITURAI KNOWLEDGE

EIP-155: Replay-Schutz und die Chain-ID erklärt

EIP-155 führte eine entscheidende Sicherheitsmaßnahme für Ethereum-basierte Transaktionen ein, indem es eine eindeutige Kettenkennung integrierte. Dies verhindert, dass böswillige Akteure eine auf einem Netzwerk gültige Transaktion auf

Biturai Knowledge
Biturai Knowledge
Research-Bibliothek
Aktualisiert: 26.6.2026
Technisch geprüft

Struktur, Lesbarkeit, interne Verlinkung und SEO-Metadaten wurden automatisiert geprüft. Der Artikel wird fortlaufend aktualisiert und dient der Bildung, nicht als Finanzberatung.

Definition

EIP-155, eine Abkürzung für Ethereum Improvement Proposal 155, führte eine grundlegende Sicherheitsverbesserung für die Ethereum-Blockchain ein. Sein Hauptzweck ist der Replay-Schutz für Transaktionen. Vor EIP-155 konnte eine auf einem Ethereum-basierten Netzwerk signierte Transaktion potenziell auf einem anderen, oft unterschiedlichen Netzwerk wiederholt und ausgeführt werden. Diese Schwachstelle entstand, weil die kryptografische Struktur von Transaktionen und Adressen über Ketten hinweg identisch war, die eine gemeinsame Abstammung teilten, wie Ethereum und Ethereum Classic nach dem DAO-Fork. EIP-155 begegnet diesem Problem, indem es eine eindeutige Chain-ID direkt in die Signaturdaten der Transaktion einbettet, wodurch jede signierte Transaktion kryptografisch an ihre beabsichtigte Blockchain gebunden wird. Dies stellt sicher, dass eine Transaktion, die beispielsweise für das Ethereum-Mainnet bestimmt ist, nicht gültig auf einer anderen Kette wie der BNB Smart Chain verarbeitet werden kann, selbst wenn die Sender- und Empfängeradressen auf beiden existieren.

Kernaussage

Das Kernprinzip von EIP-155 besteht darin, Transaktionen kryptografisch an ihre spezifische Blockchain zu binden. Es stellt sicher, dass eine auf einem Netzwerk signierte und gesendete Transaktion nicht böswillig oder versehentlich auf einem anderen Netzwerk erneut ausgeführt werden kann, selbst wenn beide Netzwerke dasselbe Adressformat und dieselbe Transaktionslogik teilen. Dieser Mechanismus ist entscheidend für die Aufrechterhaltung der Integrität der Benutzervermögenswerte und des unterschiedlichen Zustands verschiedener EVM-kompatibler Blockchains, wodurch unbeabsichtigte Vermögensübertragungen oder Zustandsänderungen über verschiedene Ketten hinweg verhindert werden. Ohne EIP-155 wäre die Sicherheitslandschaft des Multi-Chain-Ethereum-Ökosystems erheblich gefährdet, was zu weitreichenden Schwachstellen für Benutzer führen würde, die über mehrere Netzwerke hinweg agieren.

Mechanik

Vor der Implementierung von EIP-155 umfasste der Prozess der Signierung einer Ethereum-Transaktion das Hashing von sechs RLP (Recursive Length Prefix)-kodierten Elementen: (nonce, gasprice, startgas, to, value, data). Der resultierende Hash wurde dann mit dem privaten Schlüssel des Senders signiert, wodurch eine Signatur bestehend aus den Werten r, s und v erzeugt wurde. Der v-Parameter war in diesem Kontext typischerweise {0,1} + 27, was die Parität der y-Koordinate des zur Wiederherstellung verwendeten öffentlichen Schlüssels angibt. Der entscheidende Fehler in diesem Design war, dass, wenn zwei Blockchains bis zu einem bestimmten Punkt dieselbe Transaktionshistorie teilten oder einfach dasselbe Adressgenerierungs- und Transaktionsformat verwendeten, eine auf einer Kette gültige Transaktion auch auf der anderen gültig war. Dies schuf einen Replay-Angriffsvektor, bei dem eine im Ethereum-Mainnet gesendete Transaktion beispielsweise kopiert und im Ethereum Classic erneut gesendet werden konnte, was zu einer unbeabsichtigten Übertragung von Geldern auf letzterer führte.

EIP-155 änderte diesen Signaturprozess grundlegend, um eine ketten-spezifische Eindeutigkeit einzuführen. Für Transaktionen, die EIP-155 entsprechen, enthält der Hash für die Signierung nun drei zusätzliche RLP-kodierte Elemente: (nonce, gasprice, startgas, to, value, data, chainid, 0, 0). Die chainid ist eine eindeutige Kennung, die jeder Blockchain zugewiesen wird (z. B. hat das Ethereum-Mainnet die Chain-ID 1, die BNB Smart Chain hat 56). Entscheidend ist, dass die Berechnung des v-Parameters in der Signatur ebenfalls auf {0,1} + CHAIN_ID * 2 + 35 geändert wurde. Dieser neue v-Wert kodiert direkt die Chain-ID, wodurch die gesamte Signatur kryptografisch eindeutig für diese spezifische Kette wird. Wenn ein Ethereum-Knoten eine Transaktion empfängt, kann er den v-Wert überprüfen, um festzustellen, ob es sich um eine EIP-155-geschützte Transaktion handelt, und, falls ja, überprüfen, ob die eingebettete Chain-ID mit seiner eigenen übereinstimmt. Bei einer Nichtübereinstimmung wird die Transaktion abgelehnt, wodurch Replay-Angriffe effektiv verhindert werden. Obwohl Knoten technisch immer noch ältere, ungeschützte Transaktionen akzeptieren können, erzwingen moderne Wallets und Netzwerkkonfigurationen die EIP-155-Konformität für verbesserte Sicherheit.

Trading-Relevanz

Für Teilnehmer an den Kryptowährungsmärkten ist das Verständnis von EIP-155 von größter Bedeutung, um die Sicherheit ihrer digitalen Vermögenswerte zu gewährleisten, insbesondere wenn sie mit verschiedenen EVM-kompatiblen Netzwerken interagieren. Ein direkter Replay-Angriff, bei dem eine für eine Kette bestimmte Transaktion auf einer anderen ausgeführt wird, könnte zu erheblichen finanziellen Verlusten führen. Wenn beispielsweise ein Trader Token im Ethereum-Mainnet sendet und ein böswilliger Akteur diese Transaktion auf einer anderen EVM-Kette wiederholt, auf der der Trader ebenfalls Vermögenswerte hält, könnten diese Vermögenswerte unbeabsichtigt ohne die Zustimmung des Traders auf der zweiten Kette übertragen werden. EIP-155 dient als grundlegender Schutz gegen solche Szenarien und stellt sicher, dass eine Übertragung von 1 ETH im Ethereum-Mainnet nicht gleichzeitig 1 ETC im Ethereum Classic übertragen kann.

Darüber hinaus untermauert EIP-155 das breitere Sicherheitsmodell des Multi-Chain-Ökosystems. Während es direkte Transaktionswiederholungen verhindert, bietet es auch eine grundlegende Vertrauensebene für komplexere Cross-Chain-Operationen, wie sie durch Blockchain-Brücken ermöglicht werden. Trader, die Cross-Chain-Vermögensübertragungen durchführen, verlassen sich auf die zugrunde liegende Sicherheit, die EIP-155 bietet, da sie wissen, dass ihre ursprüngliche Transaktion auf einer Kette definitiv an diese Kette gebunden ist. Es ist für Trader unerlässlich, Wallets und Plattformen zu verwenden, die EIP-155-konform sind, da nicht-konforme Systeme sie Schwachstellen aussetzen könnten. Dieses Bewusstsein erstreckt sich auch auf das Verständnis der Auswirkungen von Hard Forks; jeder neue Fork einer EVM-Kette muss eine eindeutige Chain-ID annehmen und EIP-155 implementieren, um Replay-Probleme mit ihrer übergeordneten Kette oder anderen Derivaten zu verhindern.

Risiken

Das Hauptrisiko, das EIP-155 adressiert, ist der Replay-Angriff. Vor seiner Implementierung, wenn ein Benutzer Vermögenswerte sowohl im Ethereum-Mainnet als auch im Ethereum Classic (nach dem DAO-Fork) hielt, konnte eine auf einer Kette signierte und gesendete Transaktion, z. B. zum Senden von 1 ETH, erfasst und auf der anderen Kette erneut gesendet werden, wodurch effektiv 1 ETC ohne die ausdrückliche Absicht oder Kenntnis des Benutzers im ETC-Netzwerk gesendet wurde. Dies stellte eine ernsthafte Bedrohung für Benutzergelder dar und führte in den frühen Tagen der Ethereum-Trennung zu erheblicher Verwirrung und Potenzial für Ausbeutung. Das Risiko war nicht nur theoretisch; es war ein drängendes Problem, das eine schnelle und robuste Lösung erforderte.

Auch mit der weit verbreiteten Einführung von EIP-155 bestehen bestimmte Risiken, die hauptsächlich mit Nicht-Konformität oder Missverständnissen zusammenhängen. Benutzer, die mit veralteten Wallets, Knoten oder dApps interagieren, die EIP-155 nicht ordnungsgemäß durchsetzen, könnten immer noch anfällig sein. Während die meisten modernen Infrastrukturen EIP-155 vorschreiben, könnten ältere Systeme oder benutzerdefinierte Implementierungen dieses kritische Sicherheitsmerkmal übersehen. Darüber hinaus kann das Konzept des Replay-Schutzes missverstanden werden; EIP-155 verhindert, dass eine Transaktion zwischen verschiedenen Ketten wiederholt wird, aber es verhindert nicht, dass eine Transaktion innerhalb derselben Kette wiederholt wird, wenn die Nonce nicht inkrementiert wird oder wenn andere Transaktionsparameter nicht korrekt verwaltet werden. Des Weiteren isoliert EIP-155 Transaktionen zwischen verschiedenen Ketten, schützt jedoch nicht von Natur aus vor Schwachstellen, die sich aus neuen, ungeplanten Hard Forks ergeben, die möglicherweise nicht sofort eine neue Chain-ID annehmen oder EIP-155 implementieren, wodurch potenziell Replay-Angriffsvektoren zwischen dem Original und dem neuen Fork wieder eingeführt werden könnten.

Geschichte und Beispiele

Die Entstehung von EIP-155 ist untrennbar mit einem der bedeutendsten Ereignisse in der Geschichte von Ethereum verbunden: dem DAO-Fork. Im Jahr 2016, nach einem großen Exploit der dezentralen autonomen Organisation The DAO, stimmte die Ethereum-Community für die Implementierung eines Hard Forks, um die gestohlenen Gelder zurückzuholen. Diese Entscheidung führte zu einer Spaltung des Netzwerks: Die ursprüngliche Kette wurde als Ethereum Classic (ETC) fortgesetzt, während die neue, geforkte Kette zu Ethereum (ETH) wurde. Da beide Ketten bis zum Fork-Block eine identische Transaktionshistorie teilten und dieselben kryptografischen Primitive für Adressen und Transaktionssignierung verwendeten, entstand eine kritische Schwachstelle. Jede auf einer Kette signierte Transaktion (z. B. das Senden von ETH) war auch auf der anderen Kette (Senden von ETC) gültig, wodurch ein direkter Replay-Angriffsvektor entstand. Benutzer, die ihre ETH nach dem Fork bewegten, riskierten, dass ihre ETC gleichzeitig ohne ihre ausdrückliche Zustimmung bewegt wurden.

Um diese schwerwiegende Sicherheitslücke zu beheben, schlug Vitalik Buterin EIP-155 vor. Der Vorschlag wurde formell eingeführt und anschließend als Teil des Spurious Dragon Hard Forks implementiert, der im Oktober 2016 im Ethereum-Mainnet aktiviert wurde. Dieser Hard Fork führte speziell die Änderungen am Transaktionssignaturmechanismus ein, indem die Chain-ID in den v-Parameter der Signatur eingebettet wurde. Die unmittelbare Auswirkung war die effektive Isolation von Transaktionen zwischen Ethereum und Ethereum Classic, wodurch Benutzer vor Replay-Angriffen geschützt wurden. Seitdem ist EIP-155 zu einem De-facto-Standard für alle EVM-kompatiblen Blockchains geworden. Jede neue EVM-Kette, wie die BNB Smart Chain (Chain-ID 56), Polygon (Chain-ID 137) oder Avalanche C-Chain (Chain-ID 43114), übernimmt eine eindeutige Chain-ID und implementiert EIP-155, um sicherzustellen, dass Transaktionen, die auf einem dieser Netzwerke entstehen, nicht auf einem anderen wiederholt werden können. Diese weit verbreitete Akzeptanz unterstreicht seine grundlegende Bedeutung für die Sicherheit und Interoperabilität des breiteren EVM-Ökosystems.

Häufige Missverständnisse

Ein weit verbreitetes Missverständnis ist die Gleichsetzung von EIP-155 mit einer Cross-Chain-Brücke oder einem Mechanismus zur Übertragung von Vermögenswerten zwischen verschiedenen Blockchains. EIP-155 erleichtert nicht die Vermögensbewegung über Ketten hinweg; vielmehr verhindert es unbeabsichtigte Übertragungen, indem es sicherstellt, dass eine Transaktion nur in ihrem vorgesehenen Netzwerk gültig ist. Um Vermögenswerte vom Ethereum-Mainnet beispielsweise nach Polygon zu verschieben, ist ein dediziertes Brückenprotokoll erforderlich, das typischerweise das Sperren von Vermögenswerten auf einer Kette und das Prägen von Wrapped-Versionen auf der anderen oder die Verwendung von Atomic Swaps beinhaltet. EIP-155 bietet lediglich die kryptografische Gewissheit, dass eine auf Ethereum initiierte Transaktion nicht versehentlich auf Polygon ausgeführt wird.

Ein weiteres häufiges Missverständnis ist, dass der Replay-Schutz, wie er von EIP-155 implementiert wird, ein universelles Merkmal aller Blockchain-Architekturen ist. Während EIP-155 für EVM-basierte Ketten Standard ist, verfügen andere Blockchain-Designs, wie die mit dem Cosmos SDK erstellten, oft über einen inhärenten Replay-Schutz aufgrund grundlegend unterschiedlicher Adressformate, Transaktionsstrukturen oder Signaturschemata. Zum Beispiel ist das Adressformat einer Cosmos-Transaktion typischerweise einzigartig für ihre spezifische Kette, wodurch sie ohne EIP-155-ähnliche Mechanismen auf einer anderen Cosmos-Kette von Natur aus ungültig ist. Daher ist EIP-155 eine Lösung, die speziell auf die Herausforderungen zugeschnitten ist, die durch die gemeinsame Transaktions- und Adressstruktur der EVM über mehrere Ketten hinweg entstehen. Des Weiteren könnten einige Benutzer fälschlicherweise annehmen, dass alte, Pre-EIP-155-Transaktionen heute noch aktiv anfällig für weit verbreitete Replay-Angriffe sind. Obwohl die theoretische Schwachstelle existiert, ist das praktische Risiko erheblich gemindert, da die meisten modernen Wallets, Knoten und dApps die EIP-155-Konformität durchsetzen, was es schwierig macht, solche ungeschützten Transaktionen in einem Live-Netzwerk zu senden und auszuführen.

Zusammenfassung

EIP-155 stellt ein entscheidendes Sicherheits-Upgrade für das Ethereum-Ökosystem und alle EVM-kompatiblen Blockchains dar. Durch die Einbettung einer eindeutigen Chain-ID in die Transaktionssignatur führte es effektiv den Replay-Schutz ein, der sicherstellt, dass eine für ein Netzwerk bestimmte Transaktion nicht böswillig oder versehentlich auf einem anderen ausgeführt werden kann. Diese Innovation adressierte direkt die kritische Schwachstelle, die aus dem Ethereum/Ethereum Classic-Fork entstand, bei dem Transaktionen auf beiden Ketten gültig sein konnten. Der Mechanismus von EIP-155, der den Transaktionshash und den v-Parameter der Signatur modifiziert, ist zu einem grundlegenden Standard geworden, der Benutzervermögen schützt und den sicheren, eigenständigen Betrieb zahlreicher EVM-basierter Netzwerke ermöglicht. Seine weit verbreitete Akzeptanz unterstreicht seine Bedeutung für die Aufrechterhaltung der Integrität und Sicherheit der dezentralen Finanzlandschaft.

OKX EU · Offizieller Biturai-Partner

MiCA-lizenziert handeln. Flexibel mit Euro einzahlen.

Starte mit OKX EU auf einer vollständig MiCA-lizenzierten Plattform für den EWR. Zahle Euro per SEPA oder PayPal ein, kaufe Krypto mit Karte, Apple Pay oder Google Pay und prüfe die monatlichen 1:1-Reserven selbst.

  • Vollständige MiCA-Lizenz für alle 30 EWR-Staaten
  • Euro einzahlen per SEPA oder PayPal
  • Krypto kaufen mit Karte, Apple Pay und Google Pay
  • 1:1 gedeckte Reserven, monatlich nachprüfbar
Jetzt OKX EU Konto eröffnen

Partnerlink · Biturai kann bei Nutzung eine Vergütung erhalten · PayPal für vollständig verifizierte EU-Konten · keine Anlageberatung

OKX EU

Haftungsausschluss

Dieser Artikel dient ausschließlich zu Informationszwecken. Die Inhalte stellen keine Finanzberatung, Anlageempfehlung oder Aufforderung zum Kauf oder Verkauf von Wertpapieren oder Kryptowährungen dar. Biturai übernimmt keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität der Informationen. Investitionsentscheidungen sollten stets auf Basis eigener Recherche und unter Berücksichtigung der persönlichen finanziellen Situation getroffen werden.

Transparenz

Biturai kann KI-gestützte Werkzeuge zur Recherche, Strukturierung oder Aktualisierung von Wiki-Artikeln einsetzen. Redaktionell geprüfte Artikel werden separat gekennzeichnet; alle Inhalte bleiben Bildungsinhalte und ersetzen keine eigene Prüfung.