Zum Inhalt springen
Financial Context Wiki

Layer-2-Netzwerke

Deployment-spezifischer Leitfaden zu Layer-2-Ausführung, Datenverfügbarkeit, Zustandsvalidierung, Settlement, Finalität, Sequenzern, Governance, Bridges, Gebühren und ausführbaren Ausstiegen.

Aktualisiert

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

Direkte Antwort

Layer 2 bezeichnet ein Protokoll, das Aktivitäten außerhalb einer Basischain ausführt oder koordiniert und sich für einen definierten Teil der Validierung, Datenverfügbarkeit, des Settlements oder der Durchsetzung von Ausstiegen auf diese Basischain stützt. Die Bezeichnung ist kein universeller Standard. Ein Rollup, das hinreichende Daten veröffentlicht und Zustandsübergänge durch Fault Proofs oder Gültigkeitsnachweise durchsetzt, beruht auf anderen Vertrauensannahmen als ein Validium, State Channel, eine Sidechain, Multisig-Bridge oder ein Börsenbuch, selbst wenn sich alle Produkte als L2 bezeichnen.

Bei einem konkreten Deployment ist zu prüfen, was der L1-Contract tatsächlich akzeptiert, wo die Ableitungsdaten liegen, wer Transaktionen ordnet, wie ein ungültiger Zustand abgewiesen wird, wann ein Block als safe oder finalized gilt, wer das System aktualisieren oder pausieren kann und ob ein Nutzer ohne den Betreiber aussteigen kann. Schnellere Bestätigungen und niedrigere Gebühren sind nützlich, belegen für sich allein aber keine geerbte Sicherheit.

Funktionsweise

  1. Legen Sie die Systemidentität fest: L1- und L2-Chain-IDs, Genesis und Fork, Rollup-Stack und Version, Settlement- und Bridge-Contracts, Proxy-Implementierungen, Proof- oder Game-Typ, Datenverfügbarkeitsmodus, Sequenzer und Blockreferenzen. Website-Name und Begriff L2 sind Suchmetadaten, keine Authentifizierung.
  2. Klassifizieren Sie die Architektur auf getrennten Achsen. Erfassen Sie Ausführungsumgebung, Ordnungsmodell, Zustandsvalidierung, Datenort, Settlement-Chain und Verwahrungspfad. Optimistic und Validity Rollups, Validiums, Channels und Sidechains kombinieren diese Achsen unterschiedlich; eine EVM-kompatible Ausführungsumgebung macht ihre Sicherheit nicht gleichwertig.
  3. Rekonstruieren Sie die Zustandspipeline. Verfolgen Sie Nutzereinreichung, Sequenzer-Reihenfolge, L2-Ausführung, Batch-Codierung, Datenveröffentlichung, State Commitment, Fault-Proof-Challenge oder Prüfung des Gültigkeitsnachweises, L1-Aufnahme und L1-Finalität. Prüfen Sie, ob unabhängige Software den behaupteten L2-Zustand aus den protokolldefinierten Eingaben ableiten kann.
  4. Trennen Sie Verfügbarkeit und Liveness. Bestimmen Sie, ob Daten in L1-Calldata oder -Blobs, einem externen DA-System oder bei einem Komitee liegen, und ermitteln Sie Annahmen zu Aufbewahrung und Wiederherstellung. Testen Sie Sequenzer-Ausfall, Forced Inclusion, alternative Einreichung, Ausfall von Proposer oder Prover, Nachrichtenweiterleitung und den genauen Escape- oder Auszahlungspfad.
  5. Trennen Sie Zeitachsen und Statusbezeichnungen. Ein vom Sequenzer bestätigter oder unsafe Block kann vor der Datenveröffentlichung liegen; ein safe Block kann der L1-Finalität vorausgehen; Proof-Akzeptanz, Streitbeilegung, Auszahlungsreife und Bridge-Freigabe können unabhängige Schranken bilden. Verwenden Sie die Definitionen des Deployments statt einer universellen Bestätigungszahl oder Sieben-Tage-Regel.
  6. Erfassen Sie Kontrolle und Ökonomie. Prüfen Sie Proxy-Administratoren, Upgrade-Verzögerungen, Befugnisse von Security Council und Guardian, Pausenstatus, Gebührenskalare, Gas-Token, Batch-Kapazität und Gebührenempfänger. Führen Sie getrennte Bücher für L2-Ausführung, L1- oder DA-Veröffentlichung, Betreiberentgelte, Bridge-Gebühren, Ziel-Gas und Wartekosten; eine Quote ist keine Ausführungsgarantie.
  7. Stimmen Sie das Nutzerergebnis ab. Prüfen Sie den genauen Token-Contract und seine Repräsentation, Quelldebit, Zielgutschrift, Receipt-Status, Zustands- und Nachrichtenwurzeln, safe und finalized Block-Hashes, verbleibende Approvals und eine ausführbare Rückzahlung oder Marktveräußerung. Prüfen Sie die Konfiguration nach jedem Upgrade erneut und leiten Sie Bridge-Sicherheit nicht aus dem Beweissystem des Rollups ab.

Durchgerechnete Beispiele

  • Batch-Ökonomie. Ein Batch enthält 2,000 Transaktionen mit durchschnittlich 160 bytes nach Komprimierung sowie 20,000 bytes festem Framing, insgesamt 340,000 bytes. Bei $0.00002/byte kosten die Daten $6.80; zuzüglich $4.00 fixer Proof- und Settlement-Kosten ergeben sich $10.80 oder $0.0054/transaction. Bei nur 200 Transaktionen ergeben dieselben Annahmen 52,000 bytes, $1.04 Datenkosten und $5.04 Gesamtkosten oder $0.0252/transaction. Batching senkt die Durchschnittskosten nur unter den angegebenen Größen-, Auslastungs- und Gebührenannahmen.
  • Kapazität gegenüber realisiertem Durchsatz. Eine hypothetische L2 erlaubt 60,000,000 gas alle 2 seconds, ihre Gaskapazität beträgt somit 30,000,000 gas/second. Bei 120,000 gas je Nutzeroperation liegt die mechanische Obergrenze bei 250 operations/second; bei 72% realisierter Auslastung sind es 180 operations/second. Das misst weder Finalität noch Dezentralisierung oder End-to-End-Durchsatz; Daten-, Proof- oder Sequenzergrenzen können zuerst binden.
  • Drei Statuszeitachsen und eine Auszahlungsschranke. In einer OP-artigen Lehrzeitachse wird eine Transaktion um 12:00 UTC vom Sequenzer bestätigt, ihr Batch nach L1-Veröffentlichung um 12:07 safe und der enthaltende L1-Block um 12:20 finalized. Wird eine Bridge-Auszahlung um 14:00 nachgewiesen und hat sie eine illustrative Reife von 7-day, erfolgt die frühestmögliche Freigabe in der Folgewoche um 14:00, vorbehaltlich Game-, Pausen- und L1-Bedingungen. Die L2-Transaktionsfinalität um 12:20 ist nicht dasselbe Ereignis wie die Bridge-Freigabe.
  • Ausführbarer Wert nach einer Bridge-Übertragung. Ein Nutzer zahlt 1,000 USDC ein; eine Protokollgebühr von 2 USDC lässt 998 USDC auf L2, während das Quell-Gas separat $7.50 kostet. Der empfangene Token hat einen ausführbaren Geldkurs von $0.995, 0.20% Preiseffekt und $3 Exit-Gas; der Nettoausstiegswert beträgt daher 998 * 0.995 * (1 - 0.002) - 3 = $988.02398. Gegenüber $1,000 beträgt der Fehlbetrag $11.97602 oder 1.197602%; Token-Identität, Bridge-Anspruch und Liquidität sind neben der L2-Bezeichnung entscheidend.

Risiken

  • Falsche L1, L2, Chain-ID, Deployment-, Fork- oder Protokollversion.
  • Behandlung einer L2-Marketingbezeichnung als standardisierte Sicherheitsklassifizierung.
  • Verwechslung von Sidechain, Validium, Channel oder Verwahrbuch mit einem Rollup.
  • Nutzung gefälschter RPCs, Explorer, Bridges, Token oder Contract-Adressen.
  • Zensur, widersprüchliche Zusagen, Ausfall oder Missbrauch privater Reihenfolge durch den Sequenzer.
  • Fehlende oder verspätete Batch- und Ableitungsdaten.
  • Zurückhaltung, Ausfall oder Kollusion eines externen DA-Systems oder Komitees.
  • Ungültige State Commitments oder Fehler im Proof-System, Game oder Verifier.
  • Liveness-Ausfall von Proposer, Prover, Challenger oder Relayer.
  • L1-Überlastung, Zensur, Reorganisation oder verzögerte Finalität.
  • Verwechslung der Zustände unsafe, safe, finalized, proven und withdrawable.
  • Pausierte, teure oder unbrauchbare Forced-Inclusion- oder Escape-Pfade.
  • Sofortige Proxy-Upgrades oder unzureichende Ausstiegsfenster.
  • Kompromittierte Schlüssel von Administrator, Guardian oder Security Council.
  • Fehler bei Bridge-Escrow, Token-Mapping, Dezimalstellen oder Repräsentation.
  • In Quotes fehlende Daten-, Ausführungs-, Betreiber-, Bridge- oder Zielgebühren.
  • Kapazitäts- und Ratenlimits, Überlastung, Slippage oder Gas-Token-Mangel.
  • Verwechslung von EVM-Kompatibilität mit identischen Opcode-, Precompile- oder Sicherheitsregeln.
  • Cross-L2-Nachrichten, die schwächere Finalitäts-, Bridge- oder Abhängigkeitsannahmen kombinieren.
  • Verwechslung von Wallet-Erfolg, hohem TPS oder niedrigen Gebühren mit Sicherheit und ökonomischer Finalität.

Häufige Irrtümer

  • Jedes als Layer 2 bezeichnete Netzwerk erbt die gesamte Sicherheit von Ethereum.
  • Eine Sequenzerbestätigung entspricht L1-gestützter Finalität.
  • Gültigkeitsnachweise oder Fault Proofs lösen automatisch Datenverfügbarkeit und Zensur.
  • Das Rollup-Beweissystem garantiert auch jeden überbrückten Token und jede Anwendung.
  • Niedrigere Gebühren oder höherer TPS belegen Dezentralisierung, Solvenz und einen ausführbaren Ausstieg.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...