Layer 2, Sidechains und Bridges als Datenquellen

Ein großer Teil der Aktivitäten auf Ethereum-ähnlichen Netzwerken findet inzwischen auf Layer-2-Blockchains und Sidechains statt und nicht mehr auf der Basiskette selbst. Gelder werden über Bridges zwischen den Layern bewegt, und jedes Layer hat seine eigenen Blöcke, seinen eigenen Explorer und seine eigene Chain-ID. Wer als Analyst Gelder nur auf Layer 1 verfolgt, sieht sie in einem Bridge-Vertrag verschwinden. Wer dagegen versteht, wie die Layer Einzahlungen, Auszahlungen und Nachrichten erfassen, kann sie layerübergreifend verfolgen und angeben, wie sicher die einzelnen Verknüpfungen sind.

Ein Überblick über das Gebiet

Für Belege ist entscheidend, wo die Daten liegen und wer sie umschreiben könnte. Die Historie eines Rollups kann grundsätzlich aus L1 rekonstruiert werden; die Historie einer Sidechain ist nur so zuverlässig wie ihre eigenen Validatoren.

Sequencer und Finalität auf L2

Die meisten Rollups haben einen einzelnen Sequencer, der Transaktionen sortiert und schnell L2-Blöcke erzeugt (auf OP-Stack-Chains normalerweise alle 2 Sekunden, auf einigen anderen schneller). Nutzer erhalten innerhalb von Sekunden eine „vorläufige“ Bestätigung vom Sequencer. Die Transaktion wird verankert, wenn der Sequencer den Batch auf L1 veröffentlicht, und abgeschlossen, wenn dieser L1-Block finalisiert ist. Bei den meisten Rollups können Nutzer eine Transaktion auch über L1 erzwingen, falls der Sequencer sie zensiert.

Für die Analyse entsteht dadurch eine mehrstufige Finalität. OP-Stack-Nodes stellen die Heads unsafe (nur vom Sequencer), safe (aus auf L1 veröffentlichten Daten abgeleitet) und finalized (aus finalisierten L1-Blöcken abgeleitet) bereit. Die Tags safe und finalized funktionieren in standardmäßigen JSON-RPC-Aufrufen. Erstelle Datensätze aus sicheren oder finalisierten L2-Blöcken, wie du es auf L1 tun würdest (siehe die Lektion Blöcke und Header als Daten). Auf mehreren Rollups kam es zu Ausfällen der Sequencer, und der unsafe-Head kann reorganisiert werden.

Datenverfügbarkeit: Wo L2-Daten zu finden sind

In der Praxis lesen Analysten L2-Daten von L2-Nodes, Explorern und Data Warehouses, genau wie auf L1, mit denselben Receipts, Logs und Traces. Die L1-Kopie ist wichtig für die Verifizierung und um die Kosten zu verstehen:

• Bis März 2024 veröffentlichten Rollups Batches als L1-Call-Data, die für immer gespeichert wurden.
• Seit dem Dencun-Upgrade (13. März 2024) veröffentlichen die meisten sie als Blobs (EIP-4844). L1-Konsens-Nodes behalten Blob-Daten 4.096 Epochen lang, also etwa 18 Tage, und entfernen sie dann; nur ein versionierter Hash bleibt in der L1-Transaktion. Um ältere L2-Historien aus L1 zu rekonstruieren, ist daher ein Blob-Archiv erforderlich.
• Einige ZK-Rollups veröffentlichen Zustandsdifferenzen statt Transaktionen, sodass die L1-Kopie zwar Guthaben belegt, aber nicht jede Überweisung auflistet.

Erfasse für jeden L2-Datensatz die Chain-ID, den L2-Blockbereich, den Node oder Anbieter und, sofern relevant, den L1-Block, der ihn verankert hat.

Von L1 zu L2: Einzahlungen und Nachrichten

Eine Einzahlung überträgt einen Wert oder eine Nachricht von L1 zu L2. Auf OP-Stack-Chains ruft ein Nutzer (oder der Standard-Bridge-Vertrag in seinem Namen) auf L1 den OptimismPortal auf, der TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData) ausgibt. L2-Nodes lesen diese Events und erstellen am Anfang eines späteren L2-Blocks eine Einzahlungstransaktion des Typs 0x7E. So gibt ein OP-Stack-Node sie zurück:

{
  "type": "0x7e",
  "sourceHash": "0x3c9e…a0d4",
  "from": "0xA1b2…9F",
  "to": "0xA1b2…9F",
  "mint": "0x6f05b59d3b20000",
  "value": "0x6f05b59d3b20000",
  "gas": "0x186a0",
  "input": "0x"
}

Eine Einzahlungstransaktion hat keine Signatur: Ihre Autorisierung stammt aus dem L1-Event. mint ist das auf L2 erzeugte ETH (hier 0,5 ETH), dem auf L1 im Portal gesperrtes ETH gegenübersteht. sourceHash identifiziert den L1-Ursprung eindeutig. Er wird aus dem L1-Block-Hash und dem Log-Index des Events berechnet und ist damit der exakte Verknüpfungsschlüssel zwischen dem L1-Event und der L2-Transaktion. In einem Data Warehouse, das den Typ als Ganzzahl speichert, entsprechen diese Einträge dem Typ 126.

Arbitrum verwendet Retryable Tickets: Ein L1-Aufruf von createRetryableTicket auf dem Inbox-Vertrag erstellt ein Ticket, das normalerweise automatisch auf L2 eingelöst wird. Wenn die automatische Einlösung fehlschlägt, wartet das Ticket bis zu einer Woche auf eine manuelle Einlösung. Daher kann ein Analyst eine Einzahlung auf L1 sehen, deren Auswirkung auf L2 erst Tage später sichtbar wird.

Beide Systeme verwenden Adress-Aliasing. Wenn ein L1-*Vertrag* eine Nachricht an L2 sendet, wird seine Adresse auf L2 verschoben, indem 0x1111000000000000000000000000000000001111 hinzugefügt wird. So kann er sich nicht als L2-Vertrag mit derselben Adresse ausgeben. Eine Nachricht vom L1-Vertrag 0x5d3a…7c10 kommt daher auf L2 von 0x6e4b…8d21 an. EOAs werden nicht per Alias abgebildet. Wer auf L2 nach der Adresse des L1-Vertrags sucht, findet nichts; suche nach dem Alias.

Von L2 zu L1: Auszahlungen

Eine kanonische Auszahlung ist ein mehrstufiger Prozess, der sich über zwei Chains und mehrere Tage erstreckt. Auf OP-Stack-Chains:

1. Auf L2 einleiten: Der Nutzer ruft das Predeploy L2ToL1MessagePasser unter 0x4200…0016 auf (direkt oder über die L2-Bridge). Dieses gibt MessagePassed mit einem Auszahlungs-Hash aus.
2. Auf L1 beweisen: Sobald der L2-Zustand mit dieser Nachricht auf L1 vorgeschlagen wurde, kann jeder einen Beweis an das OptimismPortal übermitteln. Dieses gibt WithdrawalProven(bytes32 indexed withdrawalHash, address indexed from, address indexed to) aus.
3. Auf L1 abschließen: Nach Ablauf der Anfechtungsfrist kann jeder den Abschluss aufrufen. Das Portal gibt WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success) aus und gibt die Gelder frei.

Auf Arbitrum ruft die L2-Seite den ArbSys-Precompile (Adresse 100, 0x…0064) mit sendTxToL1 auf. Etwa eine Woche später wird die Nachricht auf L1 über die executeTransaction-Funktion des Outbox-Vertrags ausgeführt.

Der Auszahlungs-Hash verknüpft alle drei Schritte. Zwei Stolperfallen: Die Adresse, die den Auszahlungsbeweis einreicht oder den Abschluss ausführt, kann jeder Person gehören, oft einem Relayer, und ist nicht unbedingt die des Eigentümers. Außerdem unterscheiden sich die Anfechtungsfristen je nach Chain und ändern sich mit der Weiterentwicklung der Beweissysteme (einige Chains haben sie mit neueren Beweissystemen verkürzt). Prüfe daher die zum betreffenden Zeitpunkt geltenden Parameter. Da eine Woche lang ist, nutzen viele Nutzer stattdessen Drittanbieter-Bridges oder Liquiditätsanbieter für den Ausstieg. Diese zahlen auf L1 aus eigenen Mitteln und unterbrechen damit die kanonische Verknüpfung. Wie sich solche Zahlungsströme abgleichen lassen, wird in der Lektion Chain-übergreifende Nachverfolgung behandelt.

Chain-IDs und Identitäten über Layer hinweg

Jede EVM-Chain hat eine Chain-ID (EIP-155), die von eth_chainId zurückgegeben und in signierte Transaktionen eingebettet wird:

Verknüpfe jede Tabelle immer anhand der Chain-ID und der Adresse gemeinsam, niemals nur anhand der Adresse. Derselbe private Schlüssel kontrolliert auf jeder EVM-Chain dieselbe EOA-Adresse. Dadurch lässt sich die Identität von EOAs leicht chainübergreifend zuordnen. Bei Verträgen ist das anders: Unter einer Adresse kann sich auf einer Chain ein Vertrag befinden, auf einer anderen dagegen nichts oder der Vertrag einer anderen Person. Im Juni 2022 wurden etwa 20 Millionen OP-Token an eine Adresse auf Optimism gesendet, an der sich das Multisig des vorgesehenen Empfängers nur auf Ethereum befand. Noch bevor der Eigentümer das Multisig dort bereitstellen konnte, setzte ein Angreifer unter dieser Adresse auf Optimism ein anderes Multisig ein und nahm die Token an sich. Dieselbe Adresse bedeutet nicht denselben Eigentümer, sofern der Code und die Bereitstellung nicht auf jeder Chain verifiziert wurden.

Eine tägliche Zählung von OP-Stack-Einzahlungen zeigt den Standardfilter:

-- Tägliche Einzahlungen von L1 zu L2 auf einer OP-Stack-Chain (Einzahlungstyp 0x7E = 126)
SELECT
  CAST(block_timestamp AS DATE)     AS day,
  COUNT(*)                          AS deposits,
  SUM(mint) / 1e18                  AS eth_minted
FROM transactions
WHERE chain_id = 8453
  AND tx_type = 126
  AND block_timestamp >= TIMESTAMP '2026-01-01 00:00:00'
GROUP BY 1
ORDER BY 1;

Die Abfrage filtert nach einer Chain und nach Einzahlungstransaktionen und summiert dann das erzeugte ETH. Spaltennamen unterscheiden sich je nach Datensatz (type oder transaction_type; mint fehlt möglicherweise), und die Zeitstempeltypen variieren je nach Engine. Prüfe das Schema, bevor du einem Ergebnis von null vertraust.

Prüfungsschwerpunkt: Optimistic Rollups im Vergleich zu ZK-Rollups und Sidechains sowie der Speicherort der jeweiligen Daten; Sequencer und die Heads unsafe, safe und finalized; Blobs seit März 2024 und ihre Aufbewahrungsdauer von ungefähr 18 Tagen; OP-Stack-Einzahlungen (TransactionDeposited, Typ 0x7E, mint, sourceHash als Verknüpfungsschlüssel) und Arbitrum Retryable Tickets; Adress-Aliasing von L1-Verträgen durch Addition von 0x1111…1111; die Schritte Einleiten, Beweisen und Abschließen bei einer OP-Stack-Auszahlung und der Auszahlungs-Hash, der sie verknüpft; warum die Person, die eine Auszahlung abschließt, nicht unbedingt der Eigentümer ist; Chain-IDs, die Verknüpfung von Daten anhand von Chain-ID und Adresse sowie der Grund, warum dieselbe Vertragsadresse auf zwei Chains nicht denselben Eigentümer bedeutet.