Layer 2s, Sidechains und andere Chains

Viele Spuren verlassen Ethereum und Bitcoin in Richtung Rollups, Sidechains, Tron oder Solana, wo sich Datenmodell, Zeitstempel, Finalitätsregeln und verfügbare Tools unterscheiden. Wer als Prüfer Ethereum-Gewohnheiten auf diese Chains überträgt, kann Token-Bewegungen falsch interpretieren, Ereignisse falsch zeitlich einordnen und die Betreiber übersehen, die Aufzeichnungen aufbewahren. In dieser Lektion geht es darum, was jede dieser Gruppen zur Beweislage beiträgt und wie Sie auf einer Chain arbeiten, die von Ihren Tools kaum unterstützt wird.

Ein- und Auszahlungen von Rollups als Beweismittel

Die Abläufe werden in der IDFE-BA-Lektion Layer 2s, Sidechains und Bridges als Datenquellen behandelt. Die forensisch relevanten Punkte sind folgende.

Einzahlungen von L1 auf L2 sind deterministische Verknüpfungen. Auf OP-Stack-Chains gibt das L1-Portal TransactionDeposited aus, und auf L2 wird eine unsignierte Einzahlungstransaktion (Typ 0x7E) erstellt, deren sourceHash aus dem L1-Block-Hash und dem Log-Index berechnet wird: ein exakter Verknüpfungsschlüssel. Da die L2-Transaktion keine Signatur trägt, stammen ihre Autorität und ihre Zuordnung vom L1-Absender. Auf Arbitrum kann ein Retryable Ticket, dessen automatische Einlösung fehlschlägt, bis zu einer Woche warten. Deshalb kann die Wirkung einer L1-Einzahlung erst Tage später auf L2 sichtbar werden. Wenn ein L1-Vertrag die Nachricht sendet, wird seine L2-Adresse aliasiert (um 0x1111…1111 versetzt); suchen Sie nach dem Alias, nicht nach der ursprünglichen Adresse.

Kanonische Auszahlungen aus optimistischen Rollups werden auf L2 initiiert und nach einer Anfechtungsfrist von etwa einer Woche auf vielen Chains auf L1 abgeschlossen. Auf OP-Stack-Chains umfassen sie drei Schritte (Initiierung auf L2, Nachweis auf L1, Abschluss auf L1), die über einen Withdrawal-Hash verknüpft sind; bei Arbitrum gibt es keinen separaten Nachweisschritt. Diese Verzögerung bietet eine Ermittlungsmöglichkeit: Sobald die Initiierung sichtbar ist, kennen Sie den L1-Empfänger und den frühesten Zeitpunkt, zu dem die Gelder eintreffen können – Tage im Voraus. Ist der Empfänger eine Einzahlungsadresse einer Börse, kann die Börse benachrichtigt werden, bevor die Gelder eintreffen (siehe die Lektion Einfrierungs- und Beschlagnahmungsmöglichkeiten). Zwei wichtige Hinweise: Die Adresse, die den Nachweis erbringt oder den Abschluss ausführt, gehört häufig einem Relayer und nicht dem Eigentümer; außerdem unterscheiden sich Anfechtungsfristen zwischen Chains und ändern sich mit der Weiterentwicklung von Beweissystemen. Halten Sie daher den Parameter fest, der laut Chain-Dokumentation zu diesem Zeitpunkt galt.

Da eine Woche lang ist, verlassen Täter Rollups meist über Liquiditäts-Bridges. Diese zahlen auf L1 aus den Geldern eines Relayers aus und ersetzen die kanonische Verknüpfung durch die eigene Einzahlungs-ID der Bridge (siehe die Lektion Bridges: Lock-and-Mint, Burn-and-Release und Liquiditäts-Bridges).

Sequencer- und Batch-Daten

Die meisten Rollups haben einen einzelnen Sequencer, der Transaktionen ordnet, L2-Zeitstempel innerhalb der vom Protokoll festgelegten Grenzen zuweist und Batches auf L1 veröffentlicht. Daraus ergeben sich drei Folgen für Beweismittel:

• Die Finalität ist mehrstufig. Eine Transaktion, die nur vom Sequencer bestätigt wurde, kann weiterhin reorganisiert werden; eine Transaktion, die sich aus auf L1 veröffentlichten Daten ableitet, ist sicherer; eine Transaktion, die sich aus finalisierten L1-Blöcken ableitet, ist final. Halten Sie fest, welchen Head Sie abgefragt haben und welche L1-Transaktion den Batch verankert hat.
• Die L1-Kopie läuft teilweise ab. Seit dem 13. März 2024 veröffentlichen die meisten Rollups Batches als Blobs, die von Konsens-Nodes nach etwa 18 Tagen gelöscht werden; auf L1 bleibt nur ein versionierter Hash. Wenn Sie belegen müssen, dass sich der L2-Verlauf unabhängig von den eigenen Nodes des L2 wiederherstellen lässt, sichern Sie die Blob-Daten innerhalb dieses Zeitfensters oder nennen Sie das Blob-Archiv, auf das Sie sich gestützt haben (siehe die Lektion On-Chain-Beweismittel sichern).
• Der Sequencer ist ein Betreiber. Sequencer werden in der Regel von einem Unternehmen oder einer Stiftung betrieben, die Transaktionen über eigene RPC-Endpunkte empfängt. Ob dabei Übermittlungsmetadaten wie IP-Adressen protokolliert werden und wie lange, hängt von den jeweiligen Richtlinien ab; der Sequencer ist wie jeder Dienstleister ein möglicher Empfänger einer gezielten Anfrage. Ein weiterer möglicher Empfänger sind öffentliche RPC-Anbieter, die von der Wallet der betroffenen Person genutzt werden.

Sidechains und App-Chains

Der Verlauf einer Sidechain ist nur so zuverlässig wie ihr Validator-Set. Eine Chain mit einem kleinen Set kann angehalten, aktualisiert oder im schlimmsten Fall von denjenigen kontrolliert werden, die die Mehrheit der Schlüssel halten: Beim Diebstahl von Ronin im März 2022 wurden fünf von neun Validator-Schlüsseln verwendet, um Auszahlungen aus der Bridge zu signieren. Halten Sie für Beweismittel den Konsens und die Finalitätsregeln der Chain zum jeweiligen Zeitpunkt, das Validator-Set (falls veröffentlicht) und fest, ob Sie sich auf den einzigen Explorer der Chain oder auf einen selbst betriebenen Node gestützt haben. Bridges zu Sidechains werden üblicherweise von Validatoren signiert. Eine „deterministische“ Bridge-Verknüpfung ist daher nur innerhalb des Vertrauens in diese Validatoren deterministisch; weisen Sie im Bericht darauf hin.

Tron- und USDT-Zahlungsströme

Tron wickelt einen großen Anteil des im Umlauf befindlichen USDT ab und kommt häufig in Fällen von Betrug, OTC-Handel und Auszahlungen in Bargeld vor. Die virtuelle Maschine ist EVM-kompatibel, sodass TRC-20-Transfers dasselbe Transfer-Ereignis ausgeben wie ERC-20-Transfers (siehe die IDFE-BA-Lektion Andere Chain-Designs, denen Analysten begegnen). Blöcke kommen etwa alle drei Sekunden an. Für die Fallarbeit sind folgende Punkte wichtig:

• Adressformate. T…-Adressen sind Base58Check-Kodierungen aus einem 0x41-Präfixbyte und einem 20-Byte-Teil. Konvertieren Sie sie in Hexadezimalform, um sie mit EVM-Tools zu verknüpfen, und führen Sie in jeder Zeile die Chain-Kennung mit, da dieselben 20 Bytes auf Ethereum ein anderes Konto bezeichnen.
• Gebührenzahler. Transfers verbrauchen Bandbreite und Energie, die delegiert oder gemietet werden können. Das Konto, dessen Ressourcen die Gebühren bezahlt haben, kann zu einem Mietdienst gehören und muss nicht der Absender sein; daraus lässt sich keine Kontrolle ableiten.
• Aktivierung. Eine neue Adresse wird üblicherweise aktiv, wenn sie erstmals TRX empfängt. Der aktivierende Absender, häufig eine Börse, die eine Auszahlung vornimmt, oder ein Mietdienst, ist ein nützlicher Ermittlungsansatz.
• Sperren durch den Emittenten. Der USDT-Vertrag ermöglicht dem Emittenten, eine Adresse zu sperren, wobei AddedBlackList ausgegeben wird, und später den gesperrten Bestand zu vernichten, wobei DestroyedBlackFunds ausgegeben wird. Prüfen Sie, ob die von Ihnen verfolgten Gelder gesperrt wurden und wann, bevor Sie sie als verfügbar bezeichnen.

-- USDT auf Tron an Adressen der betroffenen Person, einschließlich etwaiger Sperren des Empfängers durch den Emittenten
SELECT t.txid, t.block_time, t.to_hex, t.amount_raw / 1e6 AS usdt,
       f.block_time AS frozen_at
FROM trc20_transfers t
LEFT JOIN usdt_freeze_events f
  ON f.target_hex = t.to_hex AND f.event_name = 'AddedBlackList'
WHERE t.token_contract = 'TR7N…Lj6t'          -- USDT-Vertrag auf Tron (gekürzt)
  AND t.to_hex IN ('41a3c9…7e10', '41f08b…22c4') -- Adressen der betroffenen Person in Hexadezimalform
  AND t.block_time >= TIMESTAMP '2026-06-16 00:00:00'
ORDER BY t.block_time;

Die Abfrage listet USDT-Transfers an die Adressen der betroffenen Person auf, rechnet den Rohbetrag anhand der 6 Dezimalstellen des Tokens um und fügt den Zeitpunkt eines Ereignisses hinzu, bei dem der Empfänger gesperrt wurde. Durch den LEFT JOIN bleiben nicht gesperrte Adressen erhalten, deren Feld frozen_at leer ist. Tabellen- und Spaltennamen hängen vom Datensatz ab; die Hexadezimalform jeder Adresse muss vor der Ausführung der Abfrage berechnet und überprüft werden.

Solana und andere Kontomodelle

Das Modell von Solana wird in der IDFE-BA-Lektion Andere Chain-Designs, denen Analysten begegnen behandelt. Forensisch relevant sind folgende Punkte:

• Token-Konten, keine Wallets. Token werden zwischen Token-Konten übertragen. Ordnen Sie jedes Konto seinem Eigentümer zum Zeitpunkt der Übertragung zu, da die Eigentümerschaft neu zugewiesen werden kann.
• Kennungen und Zeit. Eine Transaktion wird durch ihre erste Signatur identifiziert; sie befindet sich in einem Slot, und blockTime ist eine geschätzte Unix-Zeit. Halten Sie sowohl den Slot als auch die Zeit fest.
• Verlauf. Viele RPC-Nodes speichern nur den jüngsten Verlauf; der vollständige Verlauf stammt von Archiv-Nodes oder Anbietern. Geben Sie die Quelle an und führen Sie eine Stichprobenabfrage erneut bei einer zweiten Quelle durch.
• Kontostandsdifferenzen. Vorherige und nachfolgende Kontostände in den Transaktionsmetadaten zeigen die Nettoauswirkung komplexer Programmaufrufe zuverlässiger als die Dekodierung jeder internen Anweisung.
• Gebührenzahler. Wie bei Tron kann der Gebührenzahler ein Dienst oder ein Relayer sein.

Cosmos-Chains, die über IBC verbunden sind, bieten einen exakten chainübergreifenden Schlüssel (Quell-Port, Channel und Paket-Sequenz), wodurch IBC-Transfers deterministische Verknüpfungen sind.

Vergleich der Chain-Familien:

Halten Sie für jeden Hop den Verknüpfungsschlüssel, die Blockhöhe, die UTC-Zeit, den Finalitätsstatus und die Datenquelle fest.

Chains ohne geeignete Tools

Früher oder später führt eine Spur zu einer Chain, die Ihre Tools nicht dekodieren können. Gehen Sie eine feste Checkliste durch und halten Sie jeden Schritt fest:

1. Dokumentation lesen: Datenmodell, Adressformat, Kennungen, Zeitstempel und Finalität – anhand einer datierten Version.
2. Daten aus zwei Quellen beziehen: idealerweise von Ihrem eigenen Node; andernfalls von zwei unabhängigen Explorern oder APIs. Speichern Sie die Rohantworten und hashen Sie sie (siehe die Lektion Hashing, Protokollierung und Beweismittelkette).
3. Anhand bekannter Daten validieren: Leiten Sie einen Kontostand erneut her, den Sie überprüfen können, und dekodieren Sie eine Transaktion, deren Bedeutung Sie bereits kennen, etwa eine Einzahlung bei einer Börse, deren Aufzeichnungen Ihnen vorliegen.
4. Vorsichtig dekodieren: Berichten Sie nur über Felder, die Sie validiert haben, und kennzeichnen Sie den Rest als nicht interpretiert.
5. Die Übergänge nutzen: Die Bridge oder Börse, über die Gelder in die Chain hinein- und wieder herausflossen, verfügt in der Regel über bessere Aufzeichnungen als der Explorer der Chain.
6. Einschränkungen nennen: einzelne Quelle, nicht validierter Decoder, fehlender Verlauf. Eine klar benannte Einschränkung ist vertretbar, eine verschwiegene nicht (siehe die Lektion Tools, Reproduzierbarkeit und Validierung).

Prüfungsschwerpunkt: OP-Stack-Einzahlungen und sourceHash als Verknüpfungsschlüssel sowie die Zuordnung über den L1-Absender; Verzögerungen bei Arbitrum-Retryables und Adress-Aliasing; kanonische Auszahlungen (drei Schritte auf OP-Stack-Chains) und die Anfechtungsfrist als Zeitfenster, um eine Börse zu benachrichtigen; Relayer als Nachweisführer und Abschließende; mehrstufige Finalität, Löschung von Blobs nach etwa 18 Tagen und Sicherung von Batch-Daten; Sequencer und RPC-Anbieter als mögliche Inhaber von Aufzeichnungen; Vertrauen in Sidechain-Validatoren; Tron-Adresskonvertierung, Ressourcenzahler, Aktivierung und USDT-Sperrereignisse; Solana-Token-Konten, Signaturen, Slots und Archivverlauf; IBC-Paketschlüssel; die Checkliste für Chains ohne geeignete Tools.