Zum Inhalt springen
Financial Context Wiki

Modulare Blockchain-Architektur

Abhängigkeitsbasierter Leitfaden zur Trennung von Ausführung, Sequenzierung, Datenverfügbarkeit, Konsens, Abwicklung, Nachweisen, Bridges, Governance und Archivierung.

Aktualisiert

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

Direkte Antwort

Eine modulare Blockchain-Architektur ist ein Ansatz zur Analyse der Verantwortungsverteilung in einem System und keine standardisierte Produktkategorie. Ausführung, Transaktionsreihenfolge, State Commitments, Nachweise oder Streitverfahren, Datenveröffentlichung und deren Konsens, Abwicklung, Bridges, Governance und langfristige Archivierung können in einem Protokoll zusammengefasst, auf mehrere Systeme verteilt oder bei mehreren Anbietern dupliziert sein. Eine Schicht kann mehrere Aufgaben übernehmen und eine Aufgabe kann von mehreren Schichten abhängen.

Die nützliche Frage lautet daher nicht, ob ein Projekt „modular“ ist, sondern welche Komponente welches Objekt validiert, wer sie kontrolliert, was bei ihrem Stillstand geschieht und wie Nutzer Zustand oder Vermögenswerte unabhängig wiederherstellen. Ein Sequencer-Receipt ist weder Datenverfügbarkeit noch Finalität; ein Validity Proof stellt keine Daten bereit; ein Commitment auf einer Abwicklungskette belegt keine dauerhafte Abrufbarkeit; und gemeinsame Abwicklung schafft keine synchrone Cross-Rollup-Komponierbarkeit.

Funktionsweise

  1. Legen Sie das bereitgestellte System fest: Chain-IDs für Ausführung und Abwicklung, Protokollversion, virtuelle Maschine, Verträge, Bridge- und Asset-Adressen, DA-Modus, Betreiber, Administratoren sowie beobachteter Block oder Zeitpunkt. Marketing-Taxonomie ersetzt keine bereitgestellte Konfiguration.
  2. Erstellen Sie eine Verantwortungsmatrix. Trennen Sie Transaktionseingang und Sequenzierung, deterministische Ausführung, State Commitment und Nachweis oder Fault Dispute, DA-Veröffentlichung und ihren Konsens, Annahme und Finalität der Abwicklung, Bridge und Cross-Domain-Messaging, Upgrades und Pausen sowie historische Speicherung. Erfassen Sie Überschneidungen, statt jede Aufgabe einer einzelnen Schicht aufzuzwingen.
  3. Verfolgen Sie eine Transaktion und ihren Batch vollständig: signierte Eingabe, lokales oder Sequencer-Receipt, geordnete Ausführung, codierter und komprimierter Batch, Veröffentlichung als Calldata, Blob oder über externe DA, State Claim und Nachweis oder Streitverfahren, Abwicklungsfinalität, danach Nachrichten- oder Auszahlungsabwicklung. Bewahren Sie Hashes, Versionen, Receipts und Uhren an jeder Grenze auf.
  4. Bestimmen Sie jedes verifizierte Objekt und jede Vertrauensannahme. Unterscheiden Sie Data Commitment und Bytes, Verfügbarkeit im Protokollfenster und späteren Abruf, Ausführungsgültigkeit und Konsensfinalität sowie Bridge-Buchführung und Asset-Liquidität. Dokumentieren Sie, wer jedes Objekt reproduzieren, nachweisen, anfechten, zensieren, aktualisieren, pausieren oder zurückhalten kann.
  5. Rekonstruieren Sie Kapazitäts- und Gebührenbuch. Messen Sie rohe und komprimierte Bytes, Batch-Auslastung, DA-Preis, Nachweis- und Abwicklungsaufwand, Ausführungs- und Betreibergebühren, Bridge-Gas und Liquiditätsgebühren. Die durchschnittliche Batch-Zuteilung entspricht weder der tatsächlichen Nutzergebühr noch den Grenzkosten einer weiteren Transaktion.
  6. Testen Sie Ausfälle statt nur den normalen Durchsatz. Stoppen Sie Sequencer, Batch Poster, Prover, Challenger, DA-Dienst, Abwicklungs-RPC und Bridge-Relayer; testen Sie Forced Inclusion, unabhängige Derivation, Datenrekonstruktion, Nachweis oder Anfechtung, Wiederholung, Exit und Archivwiederherstellung unter Überlastung und Upgrade-Grenzen.
  7. Gleichen Sie mit kanonischer Evidenz ab. Ordnen Sie Ausführungs-Receipts und State Roots den Batch Commitments, der DA-Aufnahme, dem Nachweis- oder Game-Status, der Abwicklungsfinalität, Bridge-Nachrichten und endgültigen Asset-Salden zu. Wiederholen Sie die Abhängigkeitsprüfung nach Reorganisation, Parameteränderung, Vertragsupgrade oder DA-Migration.

Durchgerechnete Beispiele

  • Batch-Kosten und Kompression. Ein Batch enthält 5,000 Transaktionen, 2,400 KB rohe Eingaben und nach der Kompression 300 KB. Das Kompressionsverhältnis beträgt 2,400 / 300 = 8.0x, die Bytezahl sinkt um 87.5%. Kosten DA 0.020 ETH und gemeinsamer Nachweis plus Abwicklung 0.005 ETH, betragen die durchschnittlichen gemeinsamen Kosten (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. Mit 0.000020 ETH/tx für Ausführung und Betrieb ergeben sich 0.000025 ETH/tx. Dies ist eine Zuteilung, keine garantierte Rechnung.
  • Grenze eines Sampling-Modells. In einem Lehrmodell hält ein Angreifer 25% der Shares zurück und ein Client zieht 20 unabhängige gleichverteilte Stichproben mit Zurücklegen. Die Wahrscheinlichkeit, alle zurückgehaltenen Shares zu verfehlen, beträgt 0.75^20 = 0.003171211939 = 0.3171211939%; die Erkennungswahrscheinlichkeit beträgt 99.6828788061%. Korrelierte Peers, adaptives Serving, Erasure Coding und die tatsächliche Sampling-Regel des Protokolls können dieses einfache Modell ungültig machen.
  • Sicherheit und Verfügbarkeit eines Committees. Ein 5-of-7-DA-Committee kann mit höchstens 2 nicht verfügbaren Mitgliedern eine neue Threshold Attestation bilden; bei 3 Ausfällen verbleiben nur 4 < 5. Unter einer rein signaturbasierten Lehrregel kann die Kontrolle über 5 autorisierte Signer die Schwelle erfüllen. Ein Zertifikat beweist dennoch weder fünf dauerhafte Kopien noch die aktuelle Abrufbarkeit der Bytes oder die Gültigkeit von Ausführung und Abwicklung.
  • Mehrere Uhren und Fast Exit. Eine beispielhafte Soft Confirmation kommt nach 2 seconds, die Batch-Veröffentlichung nach 8 minutes und die Abwicklungsfinalität weitere 13 minutes später: exakt 21 minutes 2 seconds. Kommen bei einer optimistischen Auszahlung hypothetische 7 days hinzu, beträgt die Gesamtdauer 10,101 minutes 2 seconds. Eine Fast Bridge mit 0.15% auf 10,000 USDC behält 15 USDC und liefert 9,985 USDC; Geschwindigkeit ergänzt Bridge-, Liquiditätsanbieter- und Reorganisationsannahmen, statt die Protokolluhr zu verkürzen.

Risiken

  • Falsche Zuordnung tatsächlicher Verantwortlichkeiten oder Schichtgrenzen.
  • Zensur, Neuordnung oder Ausfall des Sequencers.
  • Nicht verfügbare, erlaubnispflichtige oder zu langsame Forced Inclusion.
  • Ausfall von Batch Poster oder State Proposer.
  • Ausfall des zentralisierten Provers oder Nachweisrückstand.
  • Kein aktiver, berechtigter oder finanzierter Fault Challenger.
  • Fehler bei Uhr, Bond, Oracle oder Verifier des Fault Games.
  • Fehler in Validity Circuit, Proving System oder Verification Key.
  • Zurückhalten von Daten während des erforderlichen Verfügbarkeitsfensters.
  • Korreliertes Sampling, Eclipse-Angriff oder Fehler der Netzwerksicht.
  • Threshold-Kollusion oder Schlüsselkompromittierung des DA-Committees.
  • Für das Protokoll verfügbare Daten ohne dauerhafte unabhängige Archive.
  • Reorganisation der Abwicklung oder Fehlklassifizierung der Finalität.
  • Fehler bei Bridge, Messenger, Replay-Schutz oder Zielausführung.
  • Insolvenz, Bestandsmangel oder nachteilige Preisstellung einer Fast Bridge.
  • Kompromittierung von Administrator, Multisig oder Security Council.
  • Sofortiges Upgrade, inkompatible Version oder unzureichende Exit-Verzögerung.
  • DA-Gebührensprung, Blob-Überlastung, kleinere Batches oder Subventionsende.
  • Versionskonflikt zwischen Zustand, Daten, Nachweis, Vertrag oder Client.
  • Asynchrone Cross-Domain-Reihenfolge, teilweise Ausführung oder Komponierbarkeitsfehler.

Häufige Missverständnisse

  • Eine modulare Architektur ist automatisch dezentraler als ein monolithisches Design.
  • Ein Validity Proof ersetzt Datenverfügbarkeit und historischen Abruf.
  • Abwicklung auf Ethereum überträgt jede Ethereum-Sicherheitseigenschaft auf jede Komponente.
  • Eine Erfolgsmeldung des Sequencers bedeutet finale Abwicklung und ausführbare Auszahlung.
  • Höhere TPS, gemeinsame DA oder gemeinsame Abwicklung garantieren niedrigere Kosten und synchrone Komponierbarkeit.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...