التوثيق الفني لـ Optimism

Zusammenfassung

Das Papier befasst sich mit dem Problem der Skalierbarkeit in dezentralen blockchains, indem es den Kompromiss zwischen Transaktionsdurchsatz und Hardwareanforderungen zum Betrieb eines Knotens analysiert. Rollups, also Technologien zur On-Chain-Verifizierung von außerhalb der Kette ausgeführten Blöcken, werden in Form von Fehler- oder Gültigkeitsnachweisen dargestellt. Wir vergleichen Optimistic Rollups und Validity Rollups im Hinblick auf Auszahlungszeit, Transaktionskosten, Optimierungstechniken und Kompatibilität mit dem Ethereum-Ökosystem. Unsere Analyse zeigt, dass Optimism Bedrock derzeit eine Gaskomprimierungsrate von etwa 20:1 aufweist, während StarkNet eine Speicherschreibkosten-Komprimierungsrate von etwa 24:1 erreicht. Wir diskutieren auch Techniken zur weiteren Optimierung dieser Raten, wie zum Beispiel die Verwendung von Cache-Verträgen und Bloom-Filtern. Letztendlich verdeutlichen unsere Schlussfolgerungen die Kompromisse zwischen Komplexität und Agilität bei der Wahl zwischen Optimistic Rollups und Validity Rollups. Schlüsselwörter Blockchain, Skalierbarkeit, Rollup 1. Einführung Die Blockchain-Technologie hat aufgrund ihres Potenzials, verschiedene Branchen zu revolutionieren, große Aufmerksamkeit erlangt. Allerdings bleibt die Skalierbarkeit eine große Herausforderung, da die meisten blockchains mit einem Kompromiss zwischen Skalierbarkeit, Dezentralisierung und Sicherheit konfrontiert sind, der allgemein als Skalierbarkeitstrilemma bezeichnet wird [1, 2]. Um den Durchsatz eines blockchain zu erhöhen, besteht eine triviale Lösung darin, seine Blockgröße zu erhöhen. Im Zusammenhang mit Ethereum bedeutet dies eine Erhöhung der maximalen Gasmenge, die ein Block aufnehmen kann. Da jeder vollständige Knoten jede Transaktion jedes Blocks validieren muss, steigen mit zunehmendem Durchsatz auch die Hardwareanforderungen, was zu einer stärkeren Zentralisierung des Netzwerks führt. Einige blockchains, wie zum Beispiel Bitcoin und Ethereum, optimieren ihr Design, um ihre architektonische Dezentralisierung zu maximieren, während andere, wie zum Beispiel die Binance Smart Chain und Solana, so konzipiert sind, dass sie so schnell und günstig wie möglich sind. Dezentrale Netzwerke begrenzen künstlich den Durchsatz des blockchain, um die Hardwareanforderungen für die Teilnahme am Netzwerk zu senken. Im Laufe der Jahre wurden Versuche unternommen, eine Lösung für das Trilemma zu finden, beispielsweise mit den staatlichen Kanälen [3] und Plasma [4, 5]. Diese Lösungen zeichnen sich dadurch aus, dass sie einige Aktivitäten außerhalb der Kette verlagern, On-Chain-Aktivitäten mit Off-Chain-Aktivitäten mithilfe von smart contracts verknüpfen und DLT 2023 verifizieren: 5. Distributed Ledger Technology Workshop, 25.–26. Mai 2023, Bologna, Italien $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Das Urheberrecht für dieses Papier liegt bei den Autoren. Die Nutzung ist unter der Creative Commons-Lizenz Namensnennung 4.0 International (CC BY 4.0) gestattet. CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) On-Chain, was außerhalb der Chain passiert. Sowohl Plasma- als auch Staatskanäle unterstützen jedoch nur begrenzt allgemeine smart contracts. Rollups sind blockchains (genannt Layer 2 oder L2), die ihre Blöcke auf einem anderen blockchain (Layer 1 oder L1) veröffentlichen und daher dessen Konsens-, Datenverfügbarkeits- und Sicherheitseigenschaften erben. Im Gegensatz zu anderen Lösungen unterstützen sie willkürliche Berechnungen. Rollups bestehen aus drei Hauptkomponenten: • Sequenzer: Knoten, die Rollup-Transaktionen von Benutzern empfangen und sie in einem Block zusammenfassen, der an Layer 1 gesendet wird. Der Block besteht mindestens aus der Statuswurzel (z. B. einer Merkle-Wurzel) und den Daten, die zur Rekonstruktion und Validierung des Status erforderlich sind. Der Layer 1 definiert die...

Einführung

1. Einführung Aufgrund ihres revolutionären Potenzials hat die Blockchain-Technologie große Aufmerksamkeit erlangt verschiedene Branchen. Allerdings bleibt die Skalierbarkeit eine große Herausforderung, vor der die meisten blockchains stehen ein Kompromiss zwischen Skalierbarkeit, Dezentralisierung und Sicherheit, der allgemein als bezeichnet wird Skalierbarkeitstrilemma [1, 2]. Um den Durchsatz eines blockchain zu erhöhen, gibt es eine triviale Lösung um seine Blockgröße zu erhöhen. Im Kontext von Ethereum bedeutet dies eine Erhöhung des Maximums Menge an Gas, die ein Block aufnehmen kann. Da jeder vollständige Knoten jede Transaktion von jedem validieren muss Block: Mit zunehmendem Durchsatz steigen auch die Hardwareanforderungen, was zu einem höheren Durchsatz führt Zentralisierung des Netzwerks. Einige blockchains, wie Bitcoin und Ethereum, optimieren ihre Design, um ihre architektonische Dezentralisierung zu maximieren, während andere, wie der Binance Smart Chain und Solana sind darauf ausgelegt, so schnell und günstig wie möglich zu sein. Dezentrale Netzwerke Beschränken Sie den Durchsatz von blockchain künstlich, um die Hardwareanforderungen zu senken am Netzwerk teilnehmen. Im Laufe der Jahre wurde versucht, eine Lösung für das Trilemma zu finden, beispielsweise staatliche Kanäle [3] und Plasma [4, 5]. Diese Lösungen haben die Eigenschaft, bestimmte Aktivitäten zu verschieben Off-Chain, Verknüpfung von On-Chain-Aktivitäten mit Off-Chain-Aktivitäten mithilfe von smart contracts und Überprüfung DLT 2023: 5. Distributed Ledger Technology Workshop, 25.–26. Mai 2023, Bologna, Italien $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Das Urheberrecht für dieses Papier liegt bei den Autoren. Die Nutzung ist unter der Creative Commons-Lizenz Namensnennung 4.0 International (CC BY 4.0) gestattet. CEUR Werkstatt Verfahren http://ceur-ws.org ISSN 1613-0073 CEUR-Workshop-Beiträge (CEUR-WS.org)On-Chain, was außerhalb der Kette passiert. Allerdings sind sowohl Plasma- als auch Zustandskanäle begrenzt ihre Unterstützung allgemeiner smart contracts. Rollups sind blockchains (genannt Layer 2 oder L2), die ihre Blöcke auf einem anderen blockchain veröffentlichen. (Layer 1 oder L1) und erben daher dessen Konsens-, Datenverfügbarkeits- und Sicherheitseigenschaften. Sie, Im Gegensatz zu anderen Lösungen unterstützen sie beliebige Berechnungen. Rollups bestehen aus drei Hauptkomponenten: • Sequenzer: Knoten, die Rollup-Transaktionen von Benutzern empfangen und diese zu einem zusammenfassen Block, der an Layer 1 gesendet wird. Der Block besteht mindestens aus der Staatswurzel (z. B. einem Merkle root) und die Daten, die zur Rekonstruktion und Validierung des Status erforderlich sind. Der Layer 1 definiert die kanonischer blockchain des L2 durch Festlegen der Reihenfolge der veröffentlichten Daten. • Vollständige Rollup-Knoten: Knoten, die Rollup-Blöcke vom Layer abrufen, verarbeiten und validieren 1, indem Sie überprüfen, ob der Stamm korrekt ist. Wenn ein Block ungültige Transaktionen enthält, ist dies der Fall verworfen, was verhindert, dass Sequenzer gültige Blöcke erstellen, die ungültige enthalten Transaktionen. • Rollup-Light-Knoten: Knoten, die Rollup-Blöcke von Layer 1 erhalten, aber keine Berechnungen durchführen der neue Staat selbst. Mithilfe von Techniken überprüfen sie, ob die neue Statuswurzel gültig ist wie etwa Fehler- oder Gültigkeitsnachweise. Rollups erreichen Skalierbarkeit, indem sie die fortgeführten Anschaffungskosten der Transaktionen als Anzahl verringern der Nutzer steigt. Dies liegt daran, dass die Kosten für die Sicherstellung der Gültigkeit von blockchain sublinear ansteigen in Bezug auf die Kosten für die individuelle Überprüfung von Transaktionen. Rollups unterscheiden sich je nach der Mechanismus, mit dem sie die Gültigkeit der Transaktionsausführung an Light Nodes sicherstellen: in Optimistische Rollups werden durch ein Wirtschaftsmodell und durch Fehlernachweise gewährleistet, während die Gültigkeit gewährleistet ist Bei Rollups erfolgt die kryptografische Absicherung durch Gültigkeitsnachweise. Leichte Knoten können als smart contracts auf Layer 1 implementiert werden. Sie akzeptieren die Wurzel des neuen Zustand und überprüfen Gültigkeit oder Fehlernachweise: Diese Rollups werden daher Smart Contract genannt Rollups. Wenn Light Nodes unabhängig sind, werden sie Sovereign Rollups [6] genannt. Der Vorteil von Die Verwendung eines Smart Contract Rollups besteht darin, eine vertrauensminimierte Brücke zwischen beiden bauen zu können blockchains: Da die Gültigkeit des L2-Zustands auf L1 bewiesen ist, entsteht ein System von Transaktionen L2 bis L1 können implementiert werden, was Abhebungen ermöglicht. Der Nachteil besteht darin, dass die Kosten dafür Transaktionen hängen von den Kosten für die Überprüfung des Status auf L1 ab: wenn die Basisschicht gesättigt ist Bei anderen Aktivitäten steigen auch die Kosten für Transaktionen im Rollup. Die Daten- und Konsensebene bestimmt die Sicherheit des Systems Sie legen die Reihenfolge von Transaktionen fest, verhindern Angriffe und stellen Daten zum Nachweis des Staates zur Verfügung Gültigkeit. Papierbeitrag In diesem Artikel untersuchen wir Optimistic und Validity Rollups, zwei innovative Lösungen für das Skalierbarkeitstrilemma, mit Schwerpunkt auf bemerkenswerten Implementierungen wie Optimism Bedrock und StarkNet. Unsere Beiträge beinhalten einen umfassenden Vergleich dieser Lösungen, eine Analyse der Auszahlungszeiten und eine Diskussion eines möglichen Angriffs auf Optimism Grundgestein. Darüber hinaus berechnen wir deren Gasverdichtungsverhältnisse, liefern anwendungsspezifische Optimierungen und stellen die Vor- und Nachteile einer Abkehr vom Ethereum dar. Virtuelle Maschine (EVM).

Papierstruktur Der Aufsatz ist wie folgt aufgebaut. In Abschnitt 2 sind optimistische Rollups eingeführt durch die Analyse von Optimism Grundgestein. In Abschnitt 3 werden Validity Rollups vorgestellt Analyse von StarkNet. In Abschnitt 4 vergleichen wir die beiden Lösungen. Abschließend zeichnen wir in Abschnitt 5 einige Schlussfolgerungen.

Optimistische Rollups

1. Optimistische Rollups Die Idee, die Ausgabe von Blöcken optimistisch zu akzeptieren, ohne ihre Ausführung zu überprüfen, ist bereits im Whitepaper Bitcoin [7] enthalten, in dem es um Lichtknoten geht. Diese Knoten folgen nur die Header-Kette durch Überprüfung der Konsensregel, wodurch sie anfällig für die Annahme von Blöcken werden enthält ungültige Transaktionen im Falle eines 51 %-Angriffs. Nakamoto schlägt vor, dieses Problem zu lösen Problem, indem ein „Warnsystem“ verwendet wird, um Light-Knoten zu warnen, dass ein Block ungültige Transaktionen enthält. Dieser Mechanismus wurde erstmals von Al-Bassam, Sonnino und Buterin [8] in dem ein Fehler implementiert wurde Es wird ein Proofsystem verwendet, das auf den Fehlerkorrekturcodes [9] basiert. Um die Erstellung von zu ermöglichen Für Fehlernachweise ist es erforderlich, dass die Daten aller Blöcke, einschließlich ungültiger Blöcke, verfügbar sind das Netzwerk: Dies ist das Datenverfügbarkeitsproblem, das mithilfe probabilistischer Daten gelöst wird Probenahmemechanismus. Das erste Optimistic Rollup-Design wurde von John Adler und vorgestellt Mikerah Quintyne-Collins im Jahr 2019 [10], in dem Blöcke auf einem anderen blockchain veröffentlicht werden Das definiert ihren Konsens über die Bestellung. 2.1. Optimism Grundgestein Bedrock [11] ist die neueste Version von Optimism, einem Smart Contract Rollup. Die vorherige Version, Für die Optimistic Virtual Machine (OVM) war ein Ad-hoc-Compiler erforderlich, um Solidity in sie zu kompilieren Eigener Bytecode: Im Gegensatz dazu entspricht Bedrock in Bezug auf die Ausführungs-Engine vollständig dem EVM folgt der Ethereum Yellow Paper-Spezifikation [12]. 2.1.1. Einlagen Benutzer können Transaktionen über einen Vertrag auf Ethereum, dem Optimism-Portal, einzahlen, indem sie die Funktion „depositTransaction“ aufrufen. Wenn eine Transaktion ausgeführt wird, a Das TransactionDeposited-Ereignis wird ausgegeben, auf dessen Verarbeitung jeder Knoten im Rollup wartet Einlagen. Eine hinterlegte Transaktion ist eine L2-Transaktion, die von L1 abgeleitet ist. Wenn der Anrufer der Funktion ist ein Vertrag, die Adresse wird transformiert, indem ihr ein konstanter Wert hinzugefügt wird: Dies verhindert Angriffe, bei denen ein Vertrag auf L1 dieselbe Adresse wie ein Vertrag auf L2, aber einen anderen Code hat. Die Aufnahme einer hinterlegten Transaktion auf L2 wird durch die Spezifikation innerhalb einer Sequenzierung sichergestellt Fenster. Hinterlegte Transaktionen sind ein neuer EIP-2718-kompatibler Transaktionstyp [13] mit dem Präfix 0x7E. wobei die RLP-codierten Felder sind: • bytes32 sourceHash: hash, der die Quelle der Transaktion eindeutig identifiziert. • Adresse von: die Adresse des Absenders. • Adresse an: die Empfängeradresse oder die Nulladresse, wenn es sich bei der hinterlegten Transaktion um eine handelt Vertragserstellung.• uint256 mint: der Wert, der auf L2 erstellt werden soll. • uint256-Wert: der an den Empfänger zu sendende Wert. • Byte-Daten: die Eingabedaten. • Bytes gasLimit: das Gaslimit der Transaktion. Der sourceHash wird als keccak256 hash des L1-Blocks hash und des L1-Protokolls berechnet Index, der ein Ereignis in einem Block eindeutig identifiziert. Da hinterlegte Transaktionen auf L1 initiiert, aber auf L2 ausgeführt werden, benötigt das System eine Mechanismus, um L1 für das auf L2 ausgegebene Gas zu bezahlen. Eine Lösung besteht darin, ETH über das Portal zu senden. Dies bedeutet jedoch, dass jeder Anrufer (auch indirekte Anrufer) als zahlbar gekennzeichnet werden muss, und das ist auch der Fall ist bei vielen bestehenden Projekten nicht möglich. Die Alternative besteht darin, das entsprechende Gas auf L1 zu verbrennen. Das der hinterlegten Transaktion zugewiesene Gas wird als garantiertes Gas bezeichnet. Der L2-Gaspreis an L1 wird nicht automatisch synchronisiert, sondern mithilfe eines Mechanismus ähnlich EIP-1559 geschätzt [14]. Die maximale garantierte Gasmenge pro Ethereum-Block beträgt 8 Millionen, mit einem Ziel von 2 Millionen. Die Menge 𝑐an ETH, die zum Bezahlen von Gas auf L2 erforderlich ist, beträgt 𝑐= 𝑔𝑏L2, wobei 𝑏L2 ist Grundgebühr auf L2. Der Vertrag auf L1 verbrennt eine Gasmenge, die 𝑐/𝑏L2 entspricht. Das ausgegebene Gas zum Anrufen EinzahlungTransaktion wird auf L2 erstattet: Wenn dieser Betrag größer ist als das garantierte Gas, Es wird kein Gas verbrannt. Die erste Transaktion eines rollup-Blocks ist eine hinterlegte Transaktion mit L1-Attributen, die zur Registrierung verwendet wird Stellen Sie auf einem L2 die Attribute von Ethereum-Blöcken vorab bereit. Die Attribute, die das Predeploy bereitstellt Zugriff auf sind die Blocknummer, der Zeitstempel, die Grundgebühr, der Block hash und die Reihenfolge Zahl, die die Blocknummer von L2 relativ zum zugehörigen L1-Block (auch Epoche genannt) ist; Diese Zahl wird zurückgesetzt, wenn eine neue Epoche beginnt. 2.1.2. Sequenzierung Die Rollup-Knoten leiten die Kette Optimism vollständig von Ethereum ab. Diese Kette wird verlängert Jedes Mal, wenn neue Transaktionen auf L1 veröffentlicht werden, werden die Blöcke jedes Mal neu organisiert Ethereum Blöcke werden neu organisiert. Der Rollup blockchain ist in Epochen unterteilt. Für jeden 𝑛 Blocknummer Ethereum, es gibt eine entsprechende 𝑛Epoche. Jede Epoche enthält mindestens eine Block, und jeder Block in einer Epoche enthält eine hinterlegte Transaktion mit L1-Attributen. Der erste Block in einer Epoche enthält alle über das Portal hinterlegten Transaktionen. Layer 2-Blöcke können ebenfalls vorhanden sein enthielt sequenzierte Transaktionen, d. h. Transaktionen, die direkt an den Sequencer gesendet wurden. Der Sequencer akzeptiert Transaktionen von Benutzern und erstellt Blöcke. Für jeden Block wird konstruiert ein Stapel, der am Ethereum veröffentlicht werden soll. Mehrere Chargen können komprimiert veröffentlicht werden, den Namenskanal übernehmen. Ein Kanal kann in mehrere Frames unterteilt werden, falls er zu groß ist eine einzelne Transaktion. Ein Kanal wird als Komprimierung mit ZLIB [15] von rlp-encoded definiert Chargen. Die Felder eines Stapels sind die Epochennummer, die Epoche hash, die übergeordnete hash, die Zeitstempel und die Transaktionsliste. Ein durch eine Epoche identifiziertes Sequenzierungsfenster enthält eine feste Anzahl aufeinanderfolgender L1 Blöcke, die ein Ableitungsschritt als Eingabe verwendet, um eine variable Anzahl von L2-Blöcken zu erstellen. Für Epoche 𝑛, das Sequenzierungsfenster 𝑛enthält die Blöcke [𝑛, 𝑛+𝑤). Dies impliziert, dass die Bestellung Die Anzahl der L2-Transaktionen und -Blöcke innerhalb eines Sequenzierungsfensters wird erst am Ende des Fensters festgelegt. Eine rollup-Transaktion wird als sicher bezeichnet, wenn der Batch, der sie enthält, auf L1 bestätigt wurde. Rahmenwerden aus L1-Blöcken gelesen, um Stapel zu rekonstruieren. Die aktuelle Implementierung erlaubt dies nicht Die Dekomprimierung eines Kanals beginnt, bis alle entsprechenden Frames empfangen wurden. Ungültig Chargen werden ignoriert. Aus den Batches werden einzelne Blocktransaktionen gewonnen Wird von der Ausführungs-Engine verwendet, um Statusübergänge anzuwenden und den Rollup-Status zu erhalten. 2.1.3. Auszahlungen Um Abhebungen zu verarbeiten, ist ein L2-zu-L1-Nachrichtensystem implementiert. Ethereum muss den Status von L2 kennen, um Abhebungen zu akzeptieren, und dies geschieht durch Veröffentlichung auf der L2-Ausgabe Oracle smart contract auf L1 die Statuswurzel jedes L2-Blocks. Diese Wurzeln werden optimistisch als gültig (oder abgeschlossen) akzeptiert, wenn währenddessen kein Fehlernachweis durchgeführt wird Streitzeitraum. Nur als Antragsteller gekennzeichnete Adressen können Ausgabe-Roots veröffentlichen. Die Gültigkeit von Output-Wurzeln wird dadurch angeregt, dass Antragsteller einen Einsatz hinterlegen, der gekürzt wird, wenn sie es tun hat nachweislich eine ungültige Wurzel vorgeschlagen. Transaktionen werden durch den Aufruf der Funktion initiiert initialisieren Sie Withdrawal bei einer Vorbereitstellung auf L2 und finalisieren Sie es dann auf L1 durch Aufrufen der Funktion finalizeWithdrawalTransaction auf dem zuvor erwähnten Optimism-Portal. Die dem L2-Block entsprechende Ausgabewurzel wird vom L2-Ausgabe-Oracle abgerufen. es ist überprüft, dass es abgeschlossen ist, d. h. dass die Streitfrist abgelaufen ist; Es wird überprüft, ob die Ausgabe erfolgt Root Proof entspricht dem Oracle Proof; Es wird überprüft, dass der hash der Auszahlung enthalten ist darin unter Verwendung eines Auszahlungsnachweises; dass der Rückzug noch nicht abgeschlossen ist; und dann die Der Anruf an die Zieladresse wird mit dem angegebenen Gaslimit, der angegebenen Ethermenge und den angegebenen Daten ausgeführt. 2.1.4. Cannon: das fehlersichere System Wenn ein Rollup Full Node dies durch die lokale Ausführung von Batches und hinterlegten Transaktionen erkennt Wenn der Status Layer 2 nicht mit dem Statusstamm übereinstimmt, der von einem Antragsteller in der Kette veröffentlicht wurde, kann er ausgeführt werden ein Fehlernachweis auf L1, um zu beweisen, dass das Ergebnis des Blockübergangs falsch ist. Aufgrund der Aufgrund des Overheads ist die Verarbeitung eines gesamten Rollup-Blocks auf L1 zu teuer. Die Lösung umgesetzt von Bedrock besteht darin, in der Kette nur die erste Anweisung der Meinungsverschiedenheit von Minigeth auszuführen, Kompilieren in eine MIPS-Architektur, die auf einem On-Chain-Interpreter ausgeführt und veröffentlicht wird auf L1. Minigeth ist eine vereinfachte Version von Geth 1, in der Konsens, RPC und Datenbank enthalten sind wurden entfernt. Um die erste Anweisung der Meinungsverschiedenheit zu finden, wird eine interaktive binäre Suche zwischen durchgeführt derjenige, der den Fehlernachweis initiiert hat und derjenige, der den Ausgabestamm veröffentlicht hat. Wenn der Beweis Beginnt, veröffentlichen beide Parteien die Wurzel des Speicherstatus MIPS in der Mitte der Ausführung von der Block im Challenge-Vertrag: Wenn hash übereinstimmt, bedeutet dies, dass sich beide Parteien darauf einigen Die erste Hälfte der Ausführung veröffentlicht somit die Wurzel der Hälfte der zweiten Hälfte, andernfalls die Hälfte der ersten Hälfte veröffentlicht wird und so weiter. Dadurch wird die erste Anweisung zur Meinungsverschiedenheit erreicht in einer logarithmischen Anzahl von Schritten im Vergleich zur ursprünglichen Ausführung. Wenn einer der beiden stehen bleibt Durch die Interaktion gewinnt am Ende des Streitzeitraums automatisch der andere Teilnehmer. Um die Anweisung zu verarbeiten, benötigt der Interpreter MIPS Zugriff auf seinen Speicher: da der Root vorhanden ist Sind die notwendigen Speicherzellen vorhanden, können sie durch den Nachweis ihrer Einbindung veröffentlicht werden. Zugreifen B. den Status von EVM, wird das Preimage-Orakel verwendet: Angesichts des hash eines Blocks wird es zurückgegeben 1https://geth.ethereum.org/docs

der Blockheader, aus dem man den hash des vorherigen Blocks abrufen und in den zurückkehren kann Kette, oder rufen Sie den hash des Status und der Protokolle ab, von denen man das Vorbild erhalten kann. Der oracle wird von minigeth implementiert und ersetzt die Datenbank. Es werden Anfragen an andere Knoten gestellt Holen Sie sich die Vorbilder.

Gültigkeits-Rollups

1. Gültigkeits-Rollups Das Ziel eines Validity Rollups besteht darin, die Gültigkeit des Zustandsübergangs kryptografisch nachzuweisen Angesichts der Abfolge von Transaktionen mit einem kurzen Beweis, der sublinear verglichen werden kann zum Zeitpunkt der ursprünglichen Berechnungen. Solche Zertifikate werden als Computational Integrity Proofs bezeichnet und werden praktisch mit SNARKs (Succint Non-interactive ARgument of Knowledge) umgesetzt, die Arithmetik verwenden Schaltkreise als ihr Rechenmodell. Verschiedene SNARK-Implementierungen unterscheiden sich in der Prüfzeit, Verifizierungszeit, die Notwendigkeit eines vertrauenswürdigen Aufbaus und Quantenwiderstand [16, 17]. STARKs (Skalierbar Transparentes ARgument des Wissens) [18] sind eine Art von SNARKs, für die kein vertrauenswürdiges Dokument erforderlich ist aufgebaut und sind quantenresistent, geben aber beim Nachweis und der Verifizierung etwas Effizienz ein im Vergleich zu anderen Lösungen. 3.1. StarkNet StarkNet ist ein von StarkWare entwickeltes Smart Contract Validity Rollup, das STARK verwendet Proof-System, um seinen Status auf Ethereum zu validieren. Um die Konstruktion von Gültigkeitsnachweisen zu erleichtern, a Es wird eine andere virtuelle Maschine als EVM verwendet, deren Hochsprache Cairo ist. 3.1.1. Einlagen Benutzer können Transaktionen über einen Vertrag auf Ethereum einzahlen, indem sie sendMessageToL2 aufrufen Funktion. Die Nachricht wird aufgezeichnet, indem ihr hash berechnet und ein Zähler erhöht wird. Sequenzer Warten Sie auf das LogMessageToL2-Ereignis und kodieren Sie die Informationen in einer StarkNet-Transaktion Das ruft eine Funktion eines Vertrags auf, der über den l1_handler-Dekorator verfügt. Am Ende der Ausführung, Wenn der Nachweis des Zustandsübergangs erbracht wird, wird der Verbrauch der Nachricht daran angehängt und es wird gelöscht, indem sein Zähler verringert wird. Die Einbeziehung hinterlegter Transaktionen ist in der StarkNet-Spezifikation nicht erforderlich, also ein Gas Der Markt ist erforderlich, um Sequenzern einen Anreiz zu geben, sie auf L2 zu veröffentlichen. In der aktuellen Version, weil Der Sequencer wird von StarkWare zentralisiert und verwaltet die Kosten der hinterlegten Transaktionen wird nur durch die Kosten für die Ausführung der Anzahlung bestimmt. Diese Kosten werden durch die Überweisung der ETH an bezahlt sendMessageToL2. Diese Ether bleiben auf L1 gesperrt und werden weiter an den Sequenzer übertragen L1, wenn die hinterlegte Transaktion in einen Zustandsübergang einbezogen wird. Der Betrag der gesendeten ETH, falls Die eingezahlte Transaktion ist im Preis enthalten und wird vollständig ausgegeben, unabhängig von der Menge des verbrauchten Gases auf L2. StarkNet verfügt nicht über ein System, das L1-Blockattribute automatisch verfügbar macht. Alternativ ist Fossil ein von Oiler Network 2 entwickeltes Protokoll, das bei gegebenem hash von a Block, alle Informationen, die von Ethereum durch Veröffentlichung von Vorbildern erhalten werden. 2https://www.oiler.network/3.1.2. Sequenzierung Der aktuelle Stand von StarkNet kann vollständig von Ethereum abgeleitet werden. Irgendein Zustandsunterschied zwischen Übergängen werden auf L1 als Anrufdaten veröffentlicht. Unterschiede werden für jeden Vertrag veröffentlicht und werden als uint256[] mit der folgenden Kodierung gespeichert: • Nummer des Feldes bezüglich Vertragsbereitstellungen. • Für jeden veröffentlichten Vertrag: – Die Adresse des veröffentlichten Vertrags. – Der hash des veröffentlichten Vertrags. – Die Anzahl der Argumente des Vertragskonstruktors. – Die Liste der Konstruktorargumente • Nummer des Vertrags, dessen Speicherung geändert wurde. • Für jeden Vertrag, der geändert wurde: – Die Adresse des geänderten Vertrags. – Die Anzahl der Speicheraktualisierungen. – Die Schlüssel-Wert-Paare der Speicheradressen mit den neuen Werten. Die Zustandsunterschiede werden der Reihe nach veröffentlicht, daher reicht es aus, sie nacheinander zu lesen den Staat neu aufbauen. 3.1.3. Auszahlungen Um eine Nachricht von L2 nach L1 zu senden, wird der Systemaufruf send_message_to_L1 verwendet. Die Botschaft ist auf L1 veröffentlicht, indem der Zähler hash zusammen mit dem Beweis erhöht und durch Aufrufen von abgeschlossen wird Funktion „consumeMessageFromL2“ auf dem StarkGate smart contract auf L1, die dekrementiert der Zähler. Jeder kann eine Auszahlung abschließen. 3.1.4. Gültigkeitsnachweise Die Cairo Virtual Machine [19] soll die Erstellung von STARK-Beweisen erleichtern. Die Kairo-Sprache ermöglicht die Beschreibung der Berechnung mit einer High-Level-Programmierung Sprache und nicht direkt als Schaltkreis. Dies wird durch ein System polynomialer Gleichungen erreicht 3 stellt eine einzelne Berechnung dar: den FDE-Zyklus einer von Neumann-Architektur. Die Nummer Die Anzahl der Einschränkungen ist somit fest und unabhängig von der Art der Berechnung, sodass nur eine zulässig ist Prüfprogramm für jedes Programm, dessen Berechnung bewiesen werden muss. StarkNet fasst mehrere Transaktionen mithilfe eines gemeinsamen Prüfers zu einem einzigen STARK-Beweis zusammen mit dem Namen SHARP. Die Nachweise werden an smart contract am Ethereum gesendet, der ihre Gültigkeit überprüft und aktualisiert die Merkle-Wurzel, die dem neuen Status entspricht. Die sublinearen Kosten für die Überprüfung von a Durch den Gültigkeitsnachweis können die Kosten über mehrere Transaktionen amortisiert werden. 3Algebraische Zwischendarstellung (AIR) genannt

Vergleich

1. Vergleich 4.1. Auszahlungszeit Der wichtigste Aspekt, der optimistische Rollups von Validity Rollups unterscheidet, ist der Zeit, die zwischen der Initialisierung einer Auszahlung und ihrem Abschluss vergeht. In beiden Fällen Auszahlungen werden auf L2 initialisiert und auf L1 abgeschlossen. Am StarkNet ist die Finalisierung möglich als Sobald der Gültigkeitsnachweis der neuen Statuswurzel am Ethereum akzeptiert wird: Theoretisch ist dies der Fall Es ist möglich, nach der Initialisierung Geld im ersten Block von L1 abzuheben. In der Praxis ist die Die Häufigkeit des Sendens von Gültigkeitsnachweisen auf Ethereum ist ein Kompromiss zwischen der Blockgeschwindigkeit Finalisierung und Proof-Aggregation. Derzeit stellt StarkNet Gültigkeitsnachweise zur Überprüfung bereit alle 10 Stunden 4, soll aber mit zunehmender Transaktionsaktivität verringert werden. Auf Optimism Bedrock ist es möglich, eine Auszahlung erst am Ende des Streits abzuschließen Zeitraum (derzeit 7 Tage), nach dem ein Root automatisch als gültig gilt. Die Länge von Dieser Zeitraum wird hauptsächlich dadurch bestimmt, dass Fehlernachweise bis zum Ethereum zensiert werden können sein Ende. Die Erfolgswahrscheinlichkeit dieser Art von Angriff nimmt mit zunehmender Zeit exponentiell ab: E[subtrahierter Wert] = 𝑉𝑝𝑛 Dabei ist 𝑛 die Anzahl der Blöcke in einem Intervall und 𝑉 der Betrag, der abgezogen werden kann durch Veröffentlichung einer ungültigen Wurzel, und 𝑝ist die Wahrscheinlichkeit, eine Zensur erfolgreich durchzuführen Angriff in einem einzigen Block. Angenommen, diese Wahrscheinlichkeit beträgt 99 %, sodass der Wert im Rollup gesperrt ist eine Million Ether beträgt und dass die Blöcke in einem Intervall 1800 sind (6 Stunden Blöcke mit einer 12 Sekundenintervall): Der erwartete Wert liegt bei etwa 0,01391 Ether. Das System wird durch gesichert Bitten Sie die Antragsteller, eine viel größere Menge Ether als den erwarteten Wert einzusetzen. Winzer et al. zeigte, wie man einen Zensurangriff mit einem einfachen smart contract durchführt Dadurch wird sichergestellt, dass sich bestimmte Speicherbereiche im Status [20] nicht ändern. Den Angriff modellieren Als Markov-Spiel zeigt der Artikel, dass Zensur die vorherrschende Strategie für ein Rationales ist Blockproduzenten, wenn sie mehr Entschädigung erhalten, als die Transaktion, die sich ändert, einschließen die Erinnerung. Der oben besprochene 𝑝Wert kann als Prozentsatz der rationalen Blockade angesehen werden Produzenten im Netzwerk, wobei „rational“ mögliche Strafen nicht berücksichtigt Externalitäten, wie z. B. weniger Vertrauen in blockchain, das seinen Kryptowährungswert verringert. Der folgende Code stellt einen smart contract dar, der für einen Zensurangriff verwendet werden kann auf Grundgestein. Der Angriff nutzt die Anreize der Blockproduzenten aus, indem er ihnen Bestechungsgelder anbietet um die Transaktionen zu zensieren, die bestimmte Teile des Staates verändern würden. Der Hauptvertrag Mit der Funktion ClaimBribe können Blockproduzenten Bestechungsgelder einfordern, wenn sie erfolgreich zensieren die Zieltransaktion, indem überprüft wird, ob der ungültige Ausgabestamm nicht berührt wird. Funktion ClaimBribe(Bytes Speicher StorageProof) external { require(!claimed[block.number], „Bestechung bereits eingefordert“); OutputProposal-Speicherstrom = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, storageProof); require(invalidOutputRoot == current.outputRoot, "Angriff fehlgeschlagen"); beansprucht[block.nummer] = true; (bool sent, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, „Ether konnte nicht gesendet werden“); } Listing 1: Beispiel eines Vertrags, der einen Anreiz für einen Zensurangriff auf Bedrock bietet. Bei der Länge der Streitfrist ist auch die Tatsache zu berücksichtigen, dass der Beweis des Verschuldens vorliegt ein interaktiver Beweis und daher muss den Teilnehmern genügend Zeit zur Interaktion zur Verfügung gestellt werden und dass jede Interaktion zensiert werden könnte. Wenn der letzte Zug zu einem Zeitpunkt sehr nahe am erfolgt Am Ende des Streitzeitraums sind die Zensurkosten deutlich geringer. Obwohl Zensur das ist Bei einer dominanten Strategie ist die Erfolgswahrscheinlichkeit geringer, da zensierende Knoten anfällig dafür sind Denial-of-Service-Angriffe: Ein Angreifer kann sehr komplexe Transaktionen generieren, die mit dem enden Die Veröffentlichung eines Fehlernachweises ist kostenfrei, da keine Gebühren anfallen. Im Extremfall ermöglicht eine lange Streitdauer eine Abstimmung im Erfolgsfall Zensurangriff, um einen Fork zu organisieren und die angreifenden Blockproduzenten auszuschließen. Ein anderer Ein möglicher Angriff besteht darin, mehr staatliche Stammvorschläge zu veröffentlichen, als die Streitparteien überprüfen können. was durch eine Frequenzbegrenzung vermieden werden kann. 4.1.1. Schnelle optimistische Abhebungen Da die Gültigkeit eines Optimistic Rollups jederzeit von jedem Full Node überprüft werden kann, a vertrauenswürdig oracle kann verwendet werden, um auf L1 zu erfahren, ob die Auszahlung sicher abgeschlossen werden kann. Dies Der Mechanismus wurde zuerst vom Hersteller [21] vorgeschlagen: Ein oracle überprüft die Auszahlung und veröffentlicht die Ergebnis auf L1, auf dem dem Benutzer automatisch ein verzinsliches Darlehen zugewiesen wird nach Ablauf von 7 Tagen geschlossen, d. h. wenn die Auszahlung tatsächlich abgeschlossen werden kann. Diese Lösung führt eine Vertrauensannahme ein, die im Fall von Maker jedoch durch den Operator oracle minimiert wird wird von derselben Organisation verwaltet, die das Risiko durch die Bereitstellung des Darlehens übernimmt. 4.2. Transaktionskosten Die Kosten von L2-Transaktionen werden hauptsächlich durch die Interaktion mit L1 bestimmt. In beiden Lösungen Der Rechenaufwand für Transaktionen ist sehr gering, da sie vollständig außerhalb der Kette ausgeführt werden. Optimism veröffentlicht L2-Transaktionsanrufdaten als Anrufdaten und führt selten (oder nie) einen Fehler aus Beweise, daher sind Anrufdaten die teuerste Ressource. Am 12. Januar 2022 ein Bedrock-Netzwerk wurde im Goerli-Testnetz von Ethereum gestartet. Es kann eine Gaskompressionsrate berechnet werden indem die in einem bestimmten Zeitraum auf Bedrock verbrauchte Gasmenge verfolgt und mit der Menge verglichen wird Menge an Gas, die für L1 für die entsprechenden Blöcke ausgegeben wird. Mit dieser Methode wird eine Gaskompression durchgeführt Es wurde eine Rate von ∼20 : 1 gefunden, diese Zahl kann jedoch je nach tatsächlicher Aktivität im Mainnet abweichen. StarkNet veröffentlicht am Ethereum jede Änderung im L2-Status als Aufrufdaten, daher erfolgt die Speicherung die teuerste Ressource. Da das Netzwerk EVM nicht verwendet, betragen die Transaktionskosten Die Komprimierung kann nicht trivial abgeschätzt werden. Durch die Übernahme der Ausführungskosten und der Anrufdaten vernachlässigbar sein, ist es möglich, das Komprimierungsverhältnis von Speicherschreibvorgängen im Vergleich zu zu berechnen L1. Es wird davon ausgegangen, dass kein Vertrag bereitgestellt wird und 10 Zellen, auf die zuvor nicht auf StarkNet zugegriffen wurde, vorhanden sind modifiziert, wird eine Komprimierungsrate der Speicherschreibkosten von ∼24:1 gefunden. Wenn eine Zelle überschrieben wird 𝑛Zeiten zwischen Datenveröffentlichungen betragen die Kosten für jeden Schreibvorgang 1/𝑛im Vergleich zu den Kosten eines einzelnen Schreibvorgangs, da nur der letzte veröffentlicht wird. Die Kosten können dadurch weiter minimiert werdenKomprimierung häufig verwendeter Werte. Die Kosten für die Überprüfung des Gültigkeitsnachweises werden aufgeteilt die Transaktionen, auf die es sich bezieht: zum Beispiel enthält StarkNet Block 4779 200 Transaktionen und seine Der Gültigkeitsnachweis verbraucht 267830 Gaseinheiten oder 1339,15 Gas pro Transaktion. 4.2.1. Anrufdaten optimieren: Cache-Vertrag Nachfolgend wird ein smart contract vorgestellt, der einen Adresscache für häufig verwendete Adressen implementiert Adressen unter Ausnutzung der Tatsache, dass Speicherung und Ausführung wesentlich kostengünstiger sind Ressourcen, zusammen mit einem Friends-Vertrag, der ihre Verwendung belegt. Letzterer behält den Überblick „Freunde“ einer Adresse, die durch Aufruf der Funktion addFriend registriert werden können. Wenn eine Adresse bereits mindestens einmal verwendet wurde, kann es durch den Aufruf von addFriendWithCache hinzugefügt werden Funktion: Die Cache-Indizes sind 4-Byte-Ganzzahlen, während die Adressen durch 20 Bytes dargestellt werden. es gibt also eine 5:1-Ersparnis beim Funktionsargument. Die gleiche Logik kann für andere Daten verwendet werden Typen wie Ganzzahlen oder allgemeiner Bytes. Vertrag AddressCache { Mapping(address => uint32) public address2key; Adresse[] öffentlicher Schlüssel2Adresse; Funktion CacheWrite(Adresse _Adresse) interne Rückgabe (uint32) { require(key2address.length < type(uint32).max, "AddressCache: Cache ist voll"); require(address2key[_address] == 0, "AddressCache: Adresse bereits zwischengespeichert"); // Schlüssel müssen bei 1 beginnen, da 0 „nicht gefunden“ bedeutet uint32 key = uint32(key2address.length + 1); address2key[_address] = Schlüssel; key2address.push(_address); Eingabetaste; } Funktion „cacheRead(uint32 _key)“ öffentliche Ansicht gibt (Adresse) { zurück require(_key <= key2address.length && _key > 0, "AddressCache: Schlüssel nicht gefunden"); return key2address[_key - 1]; } } Listing 2: Adress-Cache-Vertrag. Vertrag Freunde ist AddressCache { Mapping(Adresse => Adresse[]) öffentliche Freunde; Funktion addFriend(address _friend) public { friends[msg.sender].push(_friend); CacheWrite(_friend); } function addFriendWithCache(uint32 _friendKey) public { friends[msg.sender].push(cacheRead(_friendKey)); } Funktion getFriends() öffentliche Ansicht gibt (Adresse[] Speicher) { return friends[msg.sender];} } Listing 3: Beispiel für einen Vertrag, der den Adress-Cache erbt. Der Vertrag unterstützt im Cache etwa 4 Milliarden (232) Adressen, und das Hinzufügen eines Bytes ergibt etwa 1 Billion (240). 4.2.2. Speicher optimieren: Filter von Bloom Auf StarkNet gibt es mehrere Techniken zur Minimierung der Speichernutzung. Wenn es nicht nötig ist Um die Verfügbarkeit der Originaldaten zu gewährleisten, reicht es aus, deren hash: this in der Kette zu speichern ist der Mechanismus zum Speichern von Daten für einen ERC-721 (NFT) [22], d. h. eine IPFS-Verbindung, die das auflöst hash der Daten, sofern verfügbar. Bei mehrfach gespeicherten Daten besteht die Möglichkeit, eine Nachschlagefunktion zu nutzen Tabelle ähnlich dem für Optimism eingeführten Caching-System, bei dem alle Werte gespeichert werden müssen mindestens einmal. Bei einigen Anwendungen kann das Speichern aller Werte durch die Verwendung eines Bloom-Filters vermieden werden [23, 24, 25], d. h. eine probabilistische Datenstruktur, die es einem ermöglicht, mit Sicherheit zu wissen, ob Ein Element gehört nicht zu einer Menge, lässt aber eine kleine, aber nicht vernachlässigbare Wahrscheinlichkeit zu, dass es falsch ist Positives. Ein Bloom-Filter wird als Array von 𝑚Bits bei Null initialisiert. Um ein Element hinzuzufügen, funktioniert 𝑘hash mit einer gleichmäßigen Zufallsverteilung werden verwendet, die jeweils einem Bit des festgelegten Arrays zugeordnet sind zu 1. Um zu überprüfen, ob ein Element zur Menge gehört, führen wir die Funktionen 𝑘hash aus und überprüfen dass die 𝑘bits auf 1 gesetzt sind. In einem einfachen Bloom-Filter gibt es keine Möglichkeit zu unterscheiden, ob ein Das Element gehört tatsächlich zur Menge oder ist falsch positiv, eine Wahrscheinlichkeit, die mit der Zahl wächst der Einträge steigt. Nach dem Einfügen von 𝑛Elementen: P[falsch positiv] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 unter der Annahme, dass die Wahrscheinlichkeit jedes Bitsatzes unabhängig ist. Wenn 𝑛Elemente (beliebiger Größe!) sind Es wird erwartet, dass enthalten ist, und die Wahrscheinlichkeit eines tolerierten falschen Positivs beträgt 𝑝, die Größe des Arrays kann berechnet werden als: 𝑚= −𝑛ln 𝑝 (ln 2)2 Während die optimale Anzahl von hash-Funktionen ist: 𝑘= 𝑚 𝑛ln 2 Wenn wir davon ausgehen, dass 1000 Elemente mit einer Toleranz von 1 % eingefügt werden, beträgt die Größe des Arrays 9585 Bit mit 𝑘= 6, während es bei einer Toleranz von 0,1 % mit 𝑘= 9 zu 14377 Bits wird. Wenn eine Million Elemente erwartet werden, dass eingefügt wird, beträgt die Größe des Arrays etwa 1170 kB für 1 % und 1775 kB für 0,1 %, mit den gleichen Werten von 𝑘, da es nur von 𝑝[26] abhängt. In einem Spiel, in dem Spieler keinem Gegner zugewiesen werden dürfen, den sie bereits herausgefordert haben, Anstatt die Liste der früheren Gegner für jeden Spieler im Speicher zu speichern, kann man einen Bloom verwenden Filter. Das Risiko, einige Spieler nicht herauszufordern, ist oft akzeptabel und der Filter kann zurückgesetzt werden periodisch.4.3. Ethereum Kompatibilität Der Hauptvorteil der Kompatibilität mit EVM und Ethereum ist die Wiederverwendung aller verfügbaren Werkzeuge. Ethereum smart contracts können ohne jegliche Änderung auf Optimism veröffentlicht werden neue Prüfungen. Wallets bleiben kompatibel, Entwicklungs- und statische Analysetools, allgemeine Analyse Tools, Indizierungstools und oracles. Ethereum und Solidity haben eine lange, gut erforschte Geschichte Schwachstellen wie Wiedereintrittsangriffe, Über- und Unterläufe, schnelle Kredite und oracle Manipulationen. Aus diesem Grund konnte Optimism in kurzer Zeit einen großen Wert erzielen Zeit. Die Entscheidung für die Einführung einer anderen virtuellen Maschine bedeutet, dass ein gesamtes Ökosystem neu aufgebaut werden muss. mit dem Vorteil einer größeren Umsetzungsfreiheit. StarkNet implementiert das Konto nativ Abstraktion, ein Mechanismus, bei dem jedes Konto ein smart contract ist, das implementiert werden kann beliebige Logik, solange sie einer Schnittstelle entspricht (daher der Begriff Abstraktion): Dies ermöglicht die Verwendung verschiedener digitaler Signaturschemata, die Möglichkeit, den privaten Schlüssel mithilfe des zu ändern dieselbe Adresse oder verwenden Sie ein Multisig. Die Ethereum-Community hat die Einführung vorgeschlagen Mechanismus mit EIP-2938 im Jahr 2020, aber der Vorschlag ist seit mehr als einem Jahr veraltet Andere Updates haben höhere Priorität erhalten [27]. Ein weiterer wichtiger Vorteil der Kompatibilität ist die Wiederverwendung vorhandener Clients: Optimism verwendet eine Version von Geth für seinen eigenen Knoten mit nur ∼800 Zeilen Unterschied, was bisher der Fall war entwickelt, getestet und gewartet seit 2014. Ein robuster Client ist ausschlaggebend was im Netzwerk als gültig akzeptiert wird oder nicht. Ein Fehler in der Implementierung des Fehlernachweises Das System könnte dazu führen, dass ein falscher Beweis als richtig oder ein korrekter Beweis als ungültig akzeptiert wird Der Block wird als falsch akzeptiert und gefährdet das System. Die Wahrscheinlichkeit dieser Art von Der Angriff kann mit einer größeren Client-Vielfalt eingeschränkt werden: Optimism kann zusätzlich zu geth wiederverwendet werden andere Ethereum-Clients wurden bereits gepflegt, und die Entwicklung eines weiteren Erigon-basierten Clients ist im Gange bereits im Gange. Im Jahr 2016 wurde ein Problem in der Speicherverwaltung von Geth ausgenutzt DoS-Angriff und die erste Verteidigungslinie bestand darin, die Verwendung von Parity zu empfehlen, die zweithäufigste verwendeter Client zu der Zeit 5. StarkNet steht vor dem gleichen Problem mit Gültigkeitsnachweisen, aber die Clients müssen von Grund auf neu geschrieben werden und das Beweissystem ist viel komplexer und folglich Es ist auch viel komplexer, die Korrektheit sicherzustellen.

Abschluss

1. Fazit Rollups sind heute die vielversprechendste Lösung zur Lösung des Skalierbarkeitsproblems dezentrale blockchains, die den Weg für die Ära der modularen blockchains ebnen monolithische blockchains. Hauptsächlich wird die Wahl zwischen der Entwicklung eines Optimistic Rollup oder eines Validity Rollup gezeigt als Kompromiss zwischen Komplexität und Agilität. StarkNet bietet zahlreiche Vorteile wie z. B. schnell Abhebungen, strukturelle Unfähigkeit, ungültige Zustandsübergänge durchzuführen, niedrigere Transaktionskosten bei Kosten einer längeren Entwicklungszeit und Inkompatibilität mit EVM, während dies bei Optimism der Fall ist nutzte die Netzwerkwirtschaft, um schnell einen großen Marktanteil zu erobern. Optimism Bedrock verfügt jedoch über einen modularen Aufbau, der es ermöglicht, zu einer Gültigkeit zu werden 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup in der Zukunft: Cannon verwendet derzeit Minigeth, kompiliert zu MIPS, für seinen Fehlernachweis System, aber dieselbe Architektur kann verwendet werden, um eine Schaltung zu erhalten und Gültigkeitsnachweise zu erstellen. Das Kompilieren einer komplexen Maschine wie EVM für eine Mikroarchitektur führt zu einer einfacheren Lösung Schaltkreis, der im Falle von Upgrades nicht geändert und erneut überprüft werden muss. RISC Zero ist ein überprüfbare Mikroarchitektur mit STARK-Beweisen, die sich bereits in der Entwicklung befinden, basierend auf RISC-V kann hierfür alternativ zu MIPS [28] verwendet werden. Ein nicht zu unterschätzender Aspekt ist die Komplexität des Verständnisses, wie das funktioniert Technik funktioniert. Eine Stärke herkömmlicher blockchains besteht darin, den Status von überprüfen zu können den blockchain, ohne einer Drittpartei zu vertrauen. Im Fall von StarkNet ist dies jedoch der Fall Es ist notwendig, der Implementierung zu vertrauen, wenn es nicht möglich ist, die verschiedenen Komponenten zu überprüfen basierend auf Kryptographie und fortgeschrittener Mathematik. Dies kann zunächst zu Reibungen führen Einführung der Technologie, aber da die Tools und die Verwendung von Integritätsnachweisen immer weiter voranschreiten Außerhalb des Feldes blockchain wird dieses Problem hoffentlich gelöst.