Bridges, Layer 2s, Sidechains und andere Blockchain-Architekturen

Spuren bleiben selten auf Bitcoin oder dem Ethereum-Mainnet. Gestohlene Gelder werden über Bridges auf Rollups und Sidechains übertragen, als Stablecoins auf Tron bewegt, durch Solana-Programme geleitet oder zwischen Cosmos-Chains transportiert. An jedem Übergang wird eine Spur entweder belastbar oder bricht ab. Ein gut dokumentierter Übergang hinterlässt auf beiden Ledgern eine Kennung, die Einzahlung und Auszahlung ebenso eindeutig verbindet, wie ein ausgegebener Output zwei Bitcoin-Transaktionen verbindet; ein schlecht dokumentierter Übergang lässt nur eine Vermutung anhand von Betrag und Zeitpunkt zu. Der Prüfer muss diese Kennung finden, die Zuordnung auf beiden Chains belegen, jede Betragsabweichung erklären, wissen, wo jede Chain ihre Daten speichert und wer sie umschreiben könnte, und wissen, welcher Betreiber über die Informationen verfügt, die auf den Chains nicht sichtbar sind. Lektion 5.3 behandelt Chain-Hopping-Muster und die Zuordnung anhand von Betrag und Zeitpunkt; diese Lektion behandelt die Mechanismen und die Beweisspuren, die sie jeweils hinterlassen.

Bridge-Architekturen und ihre Verknüpfungsschlüssel

Zwischen beiden Seiten liegt eine Verifizierungsschicht: eine Validatorengruppe, ein Light Client, ein optimistisches Anfechtungsfenster oder ein Zero-Knowledge-Beweis. Bridges zu Sidechains werden gewöhnlich von einer kleinen Validatorengruppe signiert; eine „deterministische“ Verknüpfung gilt dort daher nur im Rahmen des Vertrauens in diese Validatoren. Der Bericht sollte dies ausdrücklich angeben.

Die meisten Bridges basieren auf einer Messaging-Schicht. Wormhole identifiziert jede Nachricht anhand von Absender-Chain, Absenderadresse und Sequenznummer; LayerZero weist jedem Paket einen Ausgangsendpunkt, einen Absender und eine Nonce sowie eine globale 32-Byte-Kennung (GUID) zu. Anwendungen übernehmen diese Kennungen; ermitteln Sie daher zunächst, welche Schicht eine Bridge verwendet. Das Cross-Chain Transfer Protocol (CCTP) von Circle für USDC nutzt Burn-and-Mint: Auf der Ausgangsseite wird DepositForBurn ausgegeben (Betrag, Einzahler, Mint-Empfänger, Zieldomäne), auf der Zielseite MessageReceived (Ausgangsdomäne, Nonce). In der aktuellen Version weist der Emittent Nonces außerhalb der Chain zu, und sein Attestierungsdienst liefert sie zu einem Ausgangstransaktionshash zurück. Ein Teil des Schlüssels stammt somit vom Betreiber: Behandeln Sie diese API-Antwort als Beweisstück, einschließlich Anfrage, Abrufzeitpunkt und Hash der Antwort.

Bridges nummerieren Chains außerdem auf eigene Weise: Wormhole hat eigene 16-Bit-Chain-IDs, LayerZero Endpunkt-IDs und CCTP Domänen (Ethereum 0, Arbitrum 3, Solana 5, Base 6), während die EIP-155-Chain-ID von Arbitrum One 42161 lautet. Wenn Sie destinationDomain = 3 als „Chain 3“ lesen, landen Sie im falschen Netzwerk. Halten Sie jede Zuordnung und ihre Quelle fest: die Bridge-Dokumentation in einer datierten Fassung.

Eine Einzahlung ihrer Freigabe zuordnen

Eine belastbare Zuordnung besteht sieben Prüfungen:

1. Dekodieren Sie das Ausgangsereignis aus dem Transaktionsbeleg, nicht aus einer Explorer-Zusammenfassung: Contracts, Betrag, Einzahler, Empfänger, Zielkennung, Verknüpfungsschlüssel.
2. Ordnen Sie die Zielkennung einem Netzwerk zu und dokumentieren Sie die Zuordnung.
3. Suchen Sie das Zielereignis mit demselben Schlüssel (und auf Messaging-Schichten mit demselben Nachrichtenabsender oder Sender).
4. Prüfen Sie den Empfänger anhand des im Ausgangsereignis eingetragenen Empfängers; erklären Sie jede Abweichung, bevor Sie fortfahren.
5. Gleichen Sie den Betrag ab: Der Zielbetrag entspricht dem Ausgangsbetrag abzüglich der angegebenen Gebühr. Prüfen Sie dabei die Dezimalstellen auf beiden Seiten, da Wrapped Token nicht immer die Dezimalstellen des Originals beibehalten.
6. Prüfen Sie Reihenfolge und Status: Die Freigabe erfolgt nach der Einzahlung; eine Einzahlung ohne Freigabe kann ausstehend, abgelaufen oder erstattet sein.
7. Wiederholen Sie die Zuordnung anhand einer zweiten Datenquelle und dokumentieren Sie beide.

Sind alle sieben Prüfungen bestanden, ergibt sich auf der Skala aus Lektion 3.2 eine Geldflussverknüpfung der Stufe A; schlägt die Empfänger- oder Betragsprüfung fehl, liegt bis zur Klärung keine Zuordnung vor. In einem Data Warehouse erfolgt die Zuordnung als LEFT JOIN von Einzahlungen zu Ausführungen anhand der ID der Ausgangs-Chain und der Einzahlungs-ID, nicht als Suche nach Betrag: Dadurch bleiben nicht ausgeführte Einzahlungen für die Erstattungsprüfung erhalten, die implizite Gebühr wird berechnet und der Relayer wird benannt, damit ihn niemand mit der untersuchten Person verwechselt. Relayer-Ausführungen können Sekunden nach der Einzahlung eintreffen, noch bevor die Ausgangs-Chain Finalität erreicht hat. Würde der Ausgangsblock durch eine Reorganisation entfallen, trüge gewöhnlich der Relayer den Verlust; Ihre Beweisdokumentation würde jedoch auf eine nicht mehr existierende Transaktion verweisen. Halten Sie den Hash des Ausgangsblocks und seinen Finalitätsstatus fest (Lektion 8.2).

Fallstricke, die eine Verknüpfung schwächen:

• Relayer, Ausführer und Finalisierer sind keine Eigentümer. Eine naive Nachverfolgung durch eine Liquiditäts-Bridge springt in die Geldmittel einer unbeteiligten Partei.
• Der Empfänger ist nicht der Einzahler. Das Empfängerfeld des Ausgangsereignisses ist der Beleg.
• Aggregatoren können als Einzahler erscheinen; lesen Sie den Ausführungs-Trace, um festzustellen, wer sie aufgerufen hat.
• Gleiche Adresse, anderer Eigentümer. Ein extern kontrolliertes Konto (EOA) hat auf jeder EVM-Chain dieselbe Adresse, eine Contract-Adresse kann jedoch andernorts anderen Code oder gar keinen Code enthalten. Im Juni 2022 gingen etwa 20 Millionen OP-Token an eine Optimism-Adresse, an der die vorgesehene Multisig nur auf Ethereum existierte; ein Angreifer stellte dort eine andere Multisig bereit und nahm die Token an sich.
• Token anhand des Contracts bestimmen, nicht anhand des Tickers: Mehrere über Bridges übertragene Versionen eines Vermögenswerts können nebeneinander existieren.

Treuhandbestand und Umlaufmenge abgleichen

Die Invariante einer Lock-and-Mint-Bridge lautet: Die Umlaufmenge der Wrapped Token auf der Zielseite übersteigt niemals die Sicherheiten im Treuhandbestand auf der Ausgangsseite, abgesehen von Einzahlungen in Übertragung. Vergleichen Sie balanceOf des Treuhandbestands mit totalSupply() des Wrapped Token zu aufeinander abgestimmten Zeitpunkten oder führen Sie täglich fortgeschriebene Summen der netto gesperrten und netto erzeugten Einheiten. Eine kleine positive Differenz ist normal; eine negative Differenz bedeutet ungedeckte Token. Exploits kehren die Nachverfolgung um: Mittel erscheinen ohne legitime Einzahlung. Beginnen Sie daher bei der Token-Erzeugung oder Freigabe (die Ursachen behandelt Lektion 5.5).

Die sechs Tage bei Ronin sprechen für eine kontinuierliche Überwachung. Kreditprotokolle benötigen dieselbe Prüfung (ausgegebene Token gegenüber gehaltenen Basiswerten zuzüglich Forderungen), und ihre Ereignisse unterscheiden zwischen wer gehandelt hat und wessen Position sich geändert hat: Ein Router erscheint als user, der Eigentümer als onBehalfOf. Verzinsliche Guthaben wie aTokens wachsen ohne Transfer-Ereignisse; lesen Sie sie daher aus dem Zustand aus. Der Kapitalbetrag eines Flash Loans geht innerhalb einer einzigen Transaktion ein und wieder aus und muss bei jedem Verlust herausgerechnet werden (Lektion 5.5).

Betreiber als Quellen. Die Chain zeigt den Transfer; Betreiber können die Person dahinter sichtbar machen. Ein Bridge-Betreiber oder Frontend kann API- und Webprotokolle (IP-Adressen, User-Agents, verbundene Wallets), Relayer-Ausführungen, Attestierungen, Supporttickets und Screening-Protokolle vorhalten; Emittenten hinter Burn-and-Mint-Bridges können außerdem Guthaben einfrieren (Lektion 10.1). Eine vollständig dezentrale Bridge hat möglicherweise keinen Betreiber; wenden Sie sich daher an das Frontend, das die untersuchte Person verwendet hat. Nennen Sie Chain, Einzahlungshash, Einzahler, Empfänger, UTC-Zeitfenster und Felder und bitten Sie zuerst um Datensicherung (Lektion 1.4).

Rollups und Sidechains

Die Historie eines Rollups lässt sich grundsätzlich aus L1 rekonstruieren; die einer Sidechain ist nur so verlässlich wie deren Validatoren. Dokumentieren Sie bei einer Sidechain die Konsens- und Finalitätsregeln, die Validatorengruppe, sofern veröffentlicht, und ob Sie ihren einzigen Explorer oder einen eigenen Knoten verwendet haben.

Sequencer und mehrstufige Finalität. Die meisten Rollups haben einen einzelnen Sequencer, der Transaktionen ordnet, L2-Zeitstempel innerhalb der Protokollgrenzen setzt und Batches auf L1 veröffentlicht. OP-Stack-Knoten stellen die Kettenspitzen unsafe (nur vom Sequencer, reorganisierbar), safe (aus L1-Daten abgeleitet) und finalized bereit; stützen Sie Beweise auf sichere oder finalisierte Blöcke und dokumentieren Sie die verankernde L1-Transaktion. Seit dem Dencun-Upgrade (13. März 2024) veröffentlichen die meisten Rollups Blobs, die L1-Knoten nach 4.096 Epochen, etwa 18 Tagen, löschen, wobei ein versionierter Hash zurückbleibt. Um zu zeigen, dass sich die L2-Historie unabhängig rekonstruieren lässt, sichern Sie die Blob-Daten innerhalb dieses Zeitfensters oder benennen Sie das verwendete Archiv. Sequencer-Betreiber und öffentliche RPC-Anbieter können Metadaten zur Einreichung protokollieren und gezielte Anfragen erhalten.

Einzahlungen. Auf OP-Stack-Chains gibt das L1-OptimismPortal TransactionDeposited aus, und L2 erzeugt eine unsignierte Einzahlungstransaktion vom Typ 0x7E (126 als Ganzzahl), deren sourceHash, berechnet aus L1-Blockhash und Log-Index, ein exakter Verknüpfungsschlüssel ist; ihr Feld mint bezeichnet auf L2 erzeugte ETH, denen auf L1 gesperrte ETH gegenüberstehen. Da keine Signatur vorliegt, ergeben sich Berechtigung und Zuordnung aus dem L1-Absender. Auf Arbitrum wartet ein Retryable Ticket, dessen automatische Einlösung fehlschlägt, bis zu einer Woche, sodass die Wirkung auf L2 um Tage verzögert sein kann. Beide Familien bilden für L1-Contracts einen Alias, indem sie 0x1111000000000000000000000000000000001111 addieren: Der L1-Contract 0x5d3a…7c10 erscheint auf L2 als 0x6e4b…8d21. EOAs erhalten keinen Alias; suchen Sie nach dem Alias.

Auszahlungen. Eine kanonische OP-Stack-Auszahlung umfasst drei Schritte, die durch einen Auszahlungshash verknüpft sind: auf L2 einleiten (MessagePassed), auf L1 nachweisen (WithdrawalProven), nach Ablauf des Anfechtungsfensters finalisieren (WithdrawalFinalized). Bei Arbitrum entfällt der Nachweisschritt (sendTxToL1, dann Outbox-Ausführung etwa eine Woche später). Sobald die Einleitung sichtbar ist, sind der L1-Empfänger und der frühestmögliche Eingang Tage im Voraus bekannt, sodass eine Börse vor dem Eintreffen der Mittel gewarnt werden kann (Lektion 10.1). Nachweisersteller und Finalisierer sind häufig Relayer; außerdem unterscheiden sich die Zeitfenster je nach Chain und ändern sich. Dokumentieren Sie daher den jeweils geltenden Parameter. Täter nutzen deshalb für den Ausstieg gewöhnlich Liquiditäts-Bridges.

Verwenden Sie in jeder Tabelle Chain-ID und Adresse als Schlüssel: Ethereum 1, OP Mainnet 10, BNB Smart Chain 56, Polygon PoS 137, zkSync Era 324, Base 8453, Arbitrum One 42161, Linea 59144, Scroll 534352.

Andere Blockchain-Architekturen

Tron ist EVM-kompatibel (TRC-20 gibt das Transfer-Ereignis von ERC-20 aus), trägt einen großen Anteil von USDT und erzeugt etwa alle drei Sekunden einen Block. T…-Adressen kodieren ein 0x41-Byte plus einen 20-Byte-Adresskörper; konvertieren Sie sie zur Verknüpfung mit EVM-Daten in Hex und behalten Sie die Chain-Kennung in jeder Zeile bei. Gebühren verbrauchen Bandbreite und Energie, die delegiert oder gemietet werden können; das zahlende Konto kann daher ein Vermietungsdienst sein. Eine neue Adresse wird gewöhnlich beim ersten Empfang von TRX aktiviert, und der Aktivierer ist ein Ermittlungsansatz. Der USDT-Emittent kann eine Adresse einfrieren (AddedBlackList) und ihr Guthaben vernichten (DestroyedBlackFunds); prüfen Sie beides, bevor Sie Mittel als verfügbar bezeichnen.

Solana speichert alles in Konten (1 SOL = 1.000.000.000 Lamports). Programme halten keinen Zustand; ein Mint-Konto definiert einen Token, und Guthaben liegen in Token-Konten, gewöhnlich im zugehörigen Token-Konto, das aus Eigentümer, Token-Programm und Mint abgeleitet wird. Token bewegen sich zwischen Token-Konten; ordnen Sie daher jedes Konto seinem Eigentümer zum Zeitpunkt des Transfers zu. Dokumentieren Sie die erste Signatur (die Transaktions-ID), den Slot und die geschätzte blockTime. Der Vergleich von preTokenBalances und postTokenBalances ist der Dekodierung interner Anweisungen überlegen: Ein Konto, dessen Guthaben bei 6 Dezimalstellen von 900.000.000 auf 650.000.000 Basiseinheiten fällt, hat 250 Token gesendet. Viele Knoten halten nur die jüngste Historie vor; benennen Sie die Archivquelle.

Cardano erweitert UTXO (eUTXO): Outputs enthalten ADA und native Token; Skript-Outputs enthalten ein Datum und werden mit einem Redeemer ausgegeben. Zahlungsadressen mit derselben Delegationsberechtigung gehören in den meisten Fällen zu einer Wallet – ein starkes Clustering-Indiz, aber kein Beweis.

Cosmos-Chains verwenden Bech32-Adressen mit Präfix (cosmos1…, osmo1…), und ein Schlüssel erzeugt häufig entsprechende Adressen auf verschiedenen Chains. IBC sperrt auf der Ausgangsseite treuhänderisch Vermögenswerte und erzeugt einen Gutschein mit einer Denomination aus ibc/ plus einem SHA-256-Hash von Pfad und Basisdenomination; Port, Kanal und Sequenznummer des Pakets erscheinen in send_packet sowie in recv_packet und acknowledge_packet und bilden einen exakten Verknüpfungsschlüssel. Ein Vermögenswert, der über zwei Pfade eintrifft, hat zwei unterschiedliche Denominationen.

Monero und abgeschirmtes Zcash verbergen Beteiligte und Beträge; die Analyse konzentriert sich auf Ein- und Ausstiegspunkte (Lektion 6.4).

Nicht unterstützte Chains. Wenn Ihre Werkzeuge eine Chain nicht dekodieren können: Lesen Sie ihre Dokumentation in einer datierten Fassung; beziehen Sie Daten aus zwei Quellen und speichern und hashen Sie die Rohantworten (Lektion 8.3); validieren Sie anhand bekannter Sachverhalte, etwa einer Einzahlung, zu der Ihnen Börsenaufzeichnungen vorliegen; berichten Sie nur validierte Felder; stützen Sie sich auf die Bridges und Börsen an den Übergängen; und legen Sie jede Einschränkung dar (Lektion 3.6).

Prüfungsschwerpunkt: die vier Bridge-Architekturen und ihre jeweiligen Spuren auf beiden Chains; Kennungen von Wormhole, LayerZero und CCTP, vom Emittenten zugewiesene CCTP-Nonces und die Zuordnung von Bridge-Kennungen wie CCTP-Domänen zu Netzwerken; die Zuordnung in sieben Schritten; Relayer, Aggregatoren und Finalisierer als Nicht-Eigentümer; die Invariante, dass die Umlaufmenge der Wrapped Token niemals den Treuhandbestand übersteigt, und wie Wormhole, Ronin und Nomad darin sichtbar werden; handelnde Adresse gegenüber onBehalfOf; optimistische und ZK-Rollups gegenüber Sidechains; die Kettenspitzen unsafe, safe und finalized sowie die Löschung von Blobs nach etwa 18 Tagen; sourceHash, Retryable Tickets und Aliasbildung; die dreistufige Auszahlung als Vorwarnzeit; Schlüsselbildung aus Chain-ID plus Adresse; Tron-Ressourcen, Aktivierung und USDT-Einfrierungen; Solana-Token-Konten und Guthabendifferenzen; Cardano-Delegationsberechtigungen; IBC-Paketschlüssel.