Zum Inhalt springen
Financial Context Wiki

Verfügbarkeitsrisiko von Cross-Chain-Relayern

Das Risiko, dass eine authentifizierte Nachricht nicht rechtzeitig zugestellt oder ausgeführt wird; Diagnose trennt Quellfinalität, Proof, Zustellung, Ausführung und Buchung.

Aktualisiert

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

Direkte Antwort

Das Verfügbarkeitsrisiko eines Cross-Chain-Relayers besteht darin, dass eine gültige, authentifizierte Nachricht nicht rechtzeitig am Ziel eingereicht oder ausgeführt wird. Ein Relayer transportiert meist Nachricht und Proof oder Metadaten; er finalisiert weder das Quellereignis noch autorisiert er den Payload. Quellkonsens, Proof- oder Attestierungsproduktion, Zielverifikation und Receiver-Ausführung sind getrennte Abhängigkeiten.

Eine verzögerte Zustellung ist zunächst ein Verfügbarkeitsproblem, kein Beweis für gestohlene Assets. Sie kann dennoch Finanzierungskosten, verpasste Fristen, abgelaufene Tickets, unbrauchbare Liquidität oder dauerhaften Verlust verursachen. Umgekehrt beweisen Quell-Receipt und Frontend-Label Pending keinen Relayer-Ausfall: Die Quelle ist vielleicht nicht final, der Proof fehlt, das Ziel ist pausiert, Gas unterfinanziert oder der Receiver revertiert.

Permissionless-Zustellung ist protokollspezifisch. Hyperlane und Wormhole beschreiben Pfade, auf denen Dritte authentifizierte Nachrichten zustellen; andere Deployments beschränken Executors, Destination Callers oder Recovery-Funktionen. Offene Einreichung erlaubt keine Änderung eines authentifizierten Payloads, und eine Relayer-Allowlist ersetzt weder Zielprüfung noch Replay-Schutz.

Funktionsweise

Ein nützlicher Analysezyklus trennt source submitted, source finalized, proof pending, ready, destination submitted, failed/retryable, executed und expired/cancelled. Das sind Analysebegriffe; jedes Protokoll hat eigene On-Chain-Felder. OP-Stack-Withdrawal, CCTP-Burn-and-Mint-Nachricht, Wormhole-VAA und Hyperlane-Nachricht unterscheiden sich bei Proof, Zeit, Fee und Retry.

Zuerst ist festzustellen, ob die Quellaktion Wert sperrte, verbrannte oder versandte und die geforderte Finalität erreichte. Danach müssen erwarteter Root, Validatorsignaturen, Guardian-VAA oder Attestierung verfügbar und aktuell sein. Erst dann wird geprüft, ob der Relayer die Nachricht sah, die Fee-Policy akzeptierte, korrekte Metadaten baute und an den exakten Zielvertrag übermittelte.

Die Zielausführung hat eigene Fehler: Chain- oder Sequencer-Ausfall, veralteter RPC, Pause, falsche Receiver-Version, zu wenig Gas, Ordered-Nonce-Blockade, Expiry oder Application-Revert. Ein Transaktionshash ist nur eine Submission-Referenz. Abschluss erfordert erfolgreiches Receipt, Processed-Status, Receiver-Event oder Zustandsänderung, korrekte Token-Identität und erwarteten Saldoeffekt unter der nötigen Zielfinalität.

Manuelles Relay ist kein universeller Rettungsknopf. Es funktioniert nur, wenn das Deployment einen geeigneten Entry Point bietet, Originalnachricht und Proof erhältlich sind, der Caller berechtigt ist, die Nachricht unverbraucht und nicht abgelaufen ist und Ziel-Gas sowie Wert finanziert werden können. Simulieren Sie den offiziellen Zielaufruf. Erzeugen Sie nie einen neuen Quell-Lock oder -Burn, um eine ungeklärte erste Nachricht zu reparieren.

Retry und Replay sind verschieden. Ein dokumentierter Retry reicht dieselbe kanonische Nachricht nach fehlgeschlagenem Zieleffekt erneut ein; korrekter Consumed- oder Nonce-Status erlaubt höchstens einen Erfolg. Mehrere Relayer können konkurrieren und Gas verbrauchen, während Replay-Schutz die Sicherheit wahrt. Das Abbrechen einer lokalen Aufgabe holt keine bereits übertragene oder inkludierte Zieltransaktion zurück.

Verwenden Sie diesen Ablauf:

  1. Fixieren Sie Protokoll, Lane, Deployment-Version, Domänen und Verträge, Quelltransaktion und Log, ID oder Nonce, Asset-Aktion, Raw Amount, Receiver und Expiry.
  2. Prüfen Sie Quell-Receipt und Event und wenden Sie Bestätigungs- oder Finalitätsregel an; prüfen Sie Blockidentität und Reorg statt der Oberfläche zu vertrauen.
  3. Finden Sie Proof, VAA, Attestierung, Checkpoint oder Root; prüfen Sie Quellzustand, Version, Signer Set, Verfügbarkeit sowie Invalidierung oder Expiry.
  4. Prüfen Sie Zielzustand, Messenger-/Receiver-Versionen, Pause, Nonce oder Processed State, Vorgänger, Deadline und nötiges natives Gas.
  5. Bestimmen Sie permissionless, allowlisted oder caller-restricted; rekonstruieren und simulieren Sie beim manuellen Pfad Original-Payload, Proof und offiziellen Zielaufruf.
  6. Aktualisieren Sie Gas Limit, Price, Wechselkursaufschlag, Fee Cap, Refund und Expiry; senden oder wiederholen Sie dieselbe Nachricht, behandeln Sie Duplicate-/Replacement-Races und sichern Sie das Receipt.
  7. Gleichen Sie Escrow oder Burn, In-flight Liability, Mint, Unlock oder Call, Fees, Refunds und Endstatus ab; eskalieren Sie dokumentiert, ohne Seed Phrase oder Private Key zu teilen.

Beispiele

  • Verzögerung zuordnen. Quellfinalität dauert 12 minutes, Proof-Erzeugung 8 minutes, Relayer-Queue 35 minutes, Zielinklusion 5 minutes. Gesamt: 12 + 8 + 35 + 5 = 60 minutes. Nur die 35-minute-Queue gehört zur Delivery Liveness; erste 20 minutes und letzte 5 minutes haben andere Verantwortliche.
  • Gas-Quote wird unzureichend. Gas Limit 300,000. Bei 25 gwei: 300,000 * 25 * 10^-9 = 0.0075 ETH. Bei Ausführung erfordern 60 gwei dann 0.018 ETH; Fehlbetrag 0.018 - 0.0075 = 0.0105 ETH. Mehr Quell-Gas finanziert nicht zwingend das Ziel.
  • Doppelte Relayer verbrauchen Gas, nicht Principal. Drei senden dieselbe 100,000 USDC-Nachricht. Der Gewinner nutzt 180,000 gas * 30 gwei = 0.0054 ETH; zwei verlieren nach je 70,000 gas * 30 gwei = 0.0021 ETH. Gesamt 0.0054 + 0.0021 + 0.0021 = 0.0096 ETH; korrekter Replay State erlaubt 100,000 USDC, nicht 300,000 USDC.
  • In-flight Liability verfolgen. Eine Lock-and-Mint-Route sperrt 25 ETH; nach Fehlschlag: Escrow +25 ETH, Wrapped Supply +0 ETH, In-flight Liability 25 ETH. Erfolgreicher Retry lässt Escrow bei 25 ETH, hebt Supply auf 25 ETH und senkt Liability auf 0 ETH. Eine neue Einzahlung von 25 ETH erzeugte 50 ETH Escrow und zwei Verpflichtungen.

Risiken

  • Quelltransaktion bleibt pending oder revertiert, während die Oberfläche sent meldet.
  • Ein Quellereignis wird vor ausreichender Finalität verwendet.
  • Eine Reorg entfernt oder ändert das Ereignis.
  • Proof, Attestierung, Checkpoint oder Signaturdaten fehlen.
  • Ein veralteter, falscher oder invalidierter Root oder Signer Set wird genutzt.
  • Allowlisted Relayer-Key oder Dienst fällt aus.
  • Permissionless wird mit garantiert zeitnaher Zustellung verwechselt.
  • Caller-restricted Entry Point wird für einen öffentlichen manuellen Pfad gehalten.
  • Ziel-Chain, Sequencer, RPC oder Indexer ist ausgefallen oder veraltet.
  • Ziel-Messenger oder Receiver ist pausiert.
  • Receiver-Upgrade oder Address Mismatch lässt den Aufruf revertieren.
  • Ziel-Gas-Limit ist zu niedrig.
  • Gas Quote, Wechselkurs, Fee Cap oder Refund-Annahme veraltet.
  • Wallet besitzt nicht das korrekte native Ziel-Gas-Asset.
  • Nachricht, Ticket, Proof oder Execution Deadline läuft ab.
  • Eine Ordered-Nonce-Lücke blockiert spätere Nachrichten.
  • Retry-/Consumed-Logik dupliziert oder verhindert Recovery.
  • Duplicate-, Cancellation- oder Replacement-Races verbrauchen Gas.
  • Falscher Support liefert bösartige Verträge, Proofs oder Calldata.
  • Quell-Lock/Burn, In-flight Claims, Zieleffekte, Fees und Refunds werden falsch abgeglichen.

Häufige Irrtümer

  • Der Relayer authentifiziert die Nachricht. Die Zustellung trägt Evidenz; Ziel-Verifier und Anwendung erzwingen Source-, Sender-, Payload- und Replay-Regeln.
  • Relayer-Ausfall bedeutet Verlust oder automatischen Refund. Zunächst entsteht Verzögerung; Expiry, Recovery, Solvenz und Refund sind produktspezifisch.
  • Permissionless erlaubt Payload-Änderung oder garantiert sofortige Ausführung. Authentifizierung verhindert Änderung; Proof, Gas, Chain und Receiver steuern Liveness.
  • Jeder Retry dupliziert den Mint. Ein korrekter Retry nutzt eine Nachricht und erlaubt einen Effekt; neuer Quelltransfer erzeugt neue Verpflichtung.
  • Zielhash oder Completed-Label beweist Empfang. Prüfen Sie Receipt, Processed State, Receiver-Events, Salden, Token-Identität und Finalität.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...