---
title: "Replay-Schutz für Cross-Chain-Nachrichten"
description: "Replay-Schutz bindet eine authentifizierte Quellnachricht an eine Protokollversion und Zieldomäne und erlaubt Wiederholungen, ohne mehr als einen erfolgreichen wirtschaftlichen Effekt zu erzeugen."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Replay-Schutz für Cross-Chain-Nachrichten

> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

<a id="answer"></a>

## Direkte Antwort

Der Replay-Schutz für Cross-Chain-Nachrichten stellt sicher, dass eine authentifizierte Quellnachricht in ihrer vorgesehenen Zieldomäne höchstens einen erfolgreichen wirtschaftlichen Effekt auslöst. Ein Relayer darf denselben Nachweis mehrfach zustellen und ein fehlgeschlagener Versuch darf wiederholbar sein. Eine abgeschlossene Nachricht darf jedoch weder erneut minten oder entsperren noch den Empfänger nochmals aufrufen.

Authentizität, Finalität und Replay-Schutz sind getrennte Prüfungen. Eine gültige Signatur, Validator-Attestierung oder Storage-Proof kann Daten authentifizieren, ohne zu beweisen, dass das Quellereignis final ist, Ziel und Empfänger gebunden wurden oder die Zielseite es noch nicht verarbeitet hat. Ein autorisierter Relayer ist nur der Transportweg; seine Identitat ersetzt nicht die Nachrichtenauthentifizierung.

Es gibt keine universelle Cross-Chain-`messageId`. Die jeweilige Protokollspezifikation bestimmt Serialisierung und Identitat. Ein robuster Envelope bindet typischerweise Protokoll und Version, Quelldomäne und Messenger oder Emitter, Quellabsender, Nonce oder Quelltransaktions-/Log-Identitat, Zieldomäne und Empfänger, Wert, Payload und gegebenenfalls Ablaufzeit. Wormhole, CCTP, Optimism und ERC-5164 verwenden unterschiedliche Felder und Zustandsautomaten; ihre IDs sind nicht austauschbar.

<a id="mechanism"></a>

## Funktionsweise

Eine Quellaktion emittiert oder speichert eine Nachricht. Nach der vorgeschriebenen Bestätigungs- oder Finalitatsregel authentifizieren Validatoren, Guardians oder ein Proof-System sie. Auf der Zielseite prüft der Verifier Root oder Signaturmenge, Version, vertrauenswürdige Gegenstelle, Ziel, Empfänger, Payload und Zeitgrenzen. Der Empfänger leitet die protokolldefinierte Identitat ab und liest den persistenten Processed-Status, bevor er einen externen Effekt auslöst.

Die Zustellung erfolgt haufig at-least-once, der gewunschte Geschaftseffekt dagegen effektiv einmal. Ein sinnvoller Zustandsautomat unterscheidet nie versucht, in Bearbeitung, fehlgeschlagen oder wiederholbar sowie erfolgreich oder verbraucht. Ein fehlgeschlagener Zielaufruf ist nicht automatisch ein Replay-Angriff. ERC-5164 verlangt beispielsweise höchstens eine erfolgreiche Ausfuhrung und erlaubt nach einem Fehlschlag einen weiteren Versuch. Produktspezifische Regeln für Retry, Gas und Wert gelten weiterhin.

Replay-Flag oder Processing-Guard sollten vor einem nicht vertrauenswürdigen externen Aufruf gesetzt und Reentrancy kontrolliert werden. Revertiert die gesamte Transaktion, revertiert normalerweise auch diese Zustandsänderung, sodass ein definierter Retry-Pfad bleibt. Fängt ein Protokoll einen Downstream-Fehler bewusst ab, muss es einen eigenen Failed-Status speichern, ohne versehentlich Teilwerte oder Teileffekte zu behalten. Der Empfänger sollte zudem idempotent sein, falls Downstream-Systeme über einen anderen Pfad erreichbar sind.

Der Gültigkeitsbereich der Nonce ist entscheidend. Eine sequenzielle Nonce erzwingt Reihenfolge, kann aber spätere Nachrichten hinter einer fehlenden blockieren. Ungeordnete Nonces oder Bitmaps erlauben unabhängige Zustellung, verlangen jedoch eine exakte Word- und Bit-Berechnung. Batch-Designs müssen festlegen, ob der gesamte Batch atomar ist oder jedes Leaf eigenen Proof und Processed-Status besitzt. Nur die Batch-Root nach Teilausfuhrung als verbraucht zu markieren, kann erfolgreiche Leaves duplizieren oder fehlgeschlagene stranden lassen.

Die Reorganisationsregel der Quell-Chain gehört zur Replay-Sicherheit. Eine vor ausreichender Finalität signierte Beobachtung kann kryptografisch gültig bleiben, obwohl das Quellereignis später nicht mehr kanonisch ist. Upgrades bilden eine weitere Grenze: Proxy-Storage-Layout, Processed-Mappings, Versionsdomanen, alte Entry Points, Peer-Rotation sowie Forks oder wiederverwendete Chain IDs müssen alte Identitaten erhalten oder gezielt invalidieren, ohne verbrauchte Nachrichten wieder zu offnen.

Verwenden Sie diesen Ablauf:

1. Fixieren Sie Protokoll, Deployment-Version, Quell- und Zieldomäne, vertrauenswürdigen Messenger oder Emitter, Absender, Empfänger, Wert, Payload, Nonce oder Ereignisidentitat und Ablaufsemantik.
2. Reproduzieren Sie kanonische Codierung und `messageId`-Testvektor; verwerfen Sie mehrdeutige Verkettung, fehlende Felder und Annahmen aus anderen Bridges.
3. Prüfen Sie Quell-Inclusion und geforderte Finalitats- oder Bestätigungsregel, danach korrekten Root, Signaturquorum, Validator- oder Guardian-Set und Version.
4. Prüfen Sie Ziel, Empfänger, Cross-Domain-Absender, Wert, Payload und Ablauf separat; behandeln Sie den Relayer als Transport, nicht als Autoritat.
5. Lesen Sie den persistenten Status und wechseln Sie vor jedem nicht vertrauenswürdigen Aufruf in Processing oder Consumed; testen Sie Reentrancy und Transaktions-Revert explizit.
6. Definieren Sie Successful-, Failed- und Retry-Ubergange, Ordered- oder Bitmap-Nonce, Batch-Atomaritat und Wertbuchung; beweisen Sie, dass erneute Zustellung kein erfolgreiches Leaf wiederholt.
7. Testen Sie Upgrades, Storage-Migration, deaktivierte Legacy Entry Points, Peer-Rotation, Forks und Notfallwiederherstellung; gleichen Sie Receipts, Events, Processed-Status und Zielsalden ab.

<a id="example"></a>

## Beispiele

- **Bindung an die Zieldomäne.** Zwei Anweisungen tragen Nonce `42` und Wert `1,000`, aber eine zielt auf Chain `10`, die andere auf Chain `8453`. Eine ID ohne Ziel behandelt `2 messages` als Kollisionskandidaten; kanonische Codierung mit Ziel erzeugt `2 distinct IDs`. Hashfunktion und Domanendarstellung bestimmt das Protokoll.
- **Ungeordnete Bitmap.** Fur Nonce `513` gilt `word = floor(513 / 256) = 2`, `bit = 513 mod 256 = 1` und `mask = 1 << 1 = 2`. Der erste Erfolg andert Bitmap-Word `2` von `0` auf `2`. Ein Duplikat findet `2 & 2 = 2` und wird abgewiesen; Nonce `512` nutzt Bit `0` unabhängig.
- **Retry ist kein zweiter Effekt.** Dieselbe Nachricht wird `3`-mal zugestellt. Zielaufrufe mit `110,000` und `125,000` Gas schlagen fehl und revertieren; der dritte mit `140,000` Gas ist einmal erfolgreich. Insgesamt fallen `110,000 + 125,000 + 140,000 = 375,000` Gas an; bei `20 gwei` sind das `0.0075 ETH`. Es gibt `3` Zustellungen, aber `1` erfolgreichen Geschaftseffekt.
- **Teilweise Batch-Buchung.** Vier unabhängig ausfuhrbare Leaves enthalten `25 + 40 + 15 + 20 = 100` Einheiten. Leaves `0`, `1` und `3` liefern `25 + 40 + 20 = 85`; Leaf `2` schlagt fehl und lasst `15` offen. Nur die Root zu verbrauchen stranden lässt die `15`; den ganzen Batch ohne Leaf-Status zu wiederholen, kann die `85` duplizieren. Erforderlich sind atomarer Rollback oder Processed-Status je Leaf.

<a id="risks"></a>

## Risiken

- Die ID lasst Ziel-Chain oder Zieldomäne aus.
- Die ID lasst Quell-Messenger oder Emitter aus.
- Protokoll- oder Nachrichtenversion fehlt in der Domäne.
- Ein Nonce-Namespace kollidiert zwischen Absendern oder Deployments.
- Mehrdeutige Packed-Codierung erzeugt Kollisionen verschiedener Felder.
- Ein Fork oder wiederverwendete Chain ID macht eine alte Domäne gültig.
- Ein Ereignis wird vor ausreichender Finalität akzeptiert und reorganisiert.
- Falscher Proof-Root, Validator- oder Guardian-Satz wird akzeptiert.
- Eine alte Signaturdomane bleibt nach einem Upgrade gültig.
- Beschädigtes Proxy-Storage setzt Processed-Status zurück oder aliasiert ihn.
- Migration vergisst verbrauchte Nachrichten oder lasst Legacy Entry Point aktiv.
- Status wird erst nach externem Aufruf markiert und ermöglicht Reentrancy.
- Ein fehlgeschlagener Aufruf gilt als erfolgreich und ist nicht wiederholbar.
- Ein erfolgreicher Aufruf wird nicht persistiert und wiederholt seinen Effekt.
- Eine fehlende Ordered Nonce blockiert alle spateren Nachrichten.
- Word-, Bit- oder Invalidierungsarithmetik der Bitmap ist falsch.
- Batch-Root-Status widerspricht partieller Leaf-Ausfuhrung.
- Ein Retry wiederholt bereits erfolgreiche Leaves.
- Einheiten von Deadline, Expiry oder Zieluhr werden verwechselt.
- Eine Relayer-Allowlist wird mit Nachrichtenautorisierung verwechselt.

<a id="misconceptions"></a>

## Häufige Irrtümer

- **Eine Nonce allein ist global eindeutig.** Absender, Protokoll, Deployment sowie Quell- und Zieldomäne definieren ihren Namespace.
- **Nur autorisierte Relayer verhindern Replay.** Relayer liefern; Zielprufung und persistenter Consumed-Status erzwingen Autoritat und Replay-Schutz.
- **Jede wiederholte Zustellung ist ein Angriff.** At-least-once-Netze durfen Fehlschlage wiederholen; invariant ist höchstens ein erfolgreicher Effekt.
- **Ein gultiger Proof oder eine Signatur beweist Finalität und Absicht.** Ziel kann fehlen, eine falsche Version gebunden oder ein später reorganisierter Zustand attestiert sein.
- **Eine erfolgreiche Bridge-Transaktion beweist exactly-once.** Prüfen Sie Receipt, Processed-Storage, Empfänger-Events und Salden, auch für jedes Leaf.

<a id="related"></a>

## Verwandte Themen

- [Cross-Chain-Bridge](/de/crypto/cross-chain-bridge/)
- [Kanonische Bridge](/de/crypto/canonical-bridge/)
- [Ausfall eines Cross-Chain-Relayers](/de/crypto/bridge-relayer-liveness-risk/)

<a id="sources"></a>

## Quellen

- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (abgerufen: 2026-08-13)
- [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (abgerufen: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (abgerufen: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (abgerufen: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (abgerufen: 2026-08-13)
- [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (abgerufen: 2026-08-13)

Source: https://wiki.fcontext.com/de/crypto/bridge-message-replay-protection/index.mdx