Am 10. Oktober um 14:00 Uhr generierte das Scroll-Mainnet der Ethereum-Layer-2-Lösung seinen ersten Block und markierte damit den erfolgreichen Start des Scroll-Mainnets. Bis zum 25. Oktober wurden über 7600 ETH über Cross-Chain-Brücken in das Scroll-Netzwerk eingebunden, und 24 dezentrale Handelsplattformen sind im Scroll-Mainnet in Betrieb gegangen, mit einem Gesamt-TVL von etwa 10 Millionen US-Dollar.

Am 17. Oktober gab Scroll offiziell den Start seines Mainnets bekannt und hielt gleichzeitig an seinem Engagement für Open Source und Dezentralisierung fest. In der nächsten Phase wird sich Scroll auf den Aufbau eines dezentralen Proof-of-Stake-Netzwerks und -Sortierers konzentrieren. In diesem Artikel werden wir eine detaillierte Analyse der Architektur und Technologie von Scroll bereitstellen, um jedem zu helfen, den aktuellen Netzwerkstatus und die zukünftige Entwicklungsrichtung von Scroll zu verstehen. Wir werden auch Scrolls zkEVM-Schaltkreis- und Audit-Wissen erläutern, um die Sicherheitsmaßnahmen für zk-Projekte zu stärken.

Wer ist Scroll, die treibende Kraft der Layer2-Welle?

Scroll ist eine Ethereum Layer 2-Skalierungslösung, die auf wissensfreier Technologie basiert und darauf abzielt, den Transaktionsdurchsatz und die Geschwindigkeit des Ethereum-Netzwerks zu verbessern. Im Vergleich zu Optimistic Rollup erreicht Scroll Skalierbarkeit durch wissensfreie Beweise und beschleunigt die Generierung und Überprüfung von wissensfreien Beweisen durch Hardwarebeschleunigung. Es ist bestrebt, EVM-Kompatibilität auf Bytecode-Ebene zu erreichen. Dies bedeutet, dass Entwickler Solidity- und Ethereum-bezogene Entwicklungstools direkt verwenden können, um intelligente Verträge zu erstellen und diese ohne Änderungen auf Scroll bereitzustellen.

Laut der offiziellen Website von Scroll besteht das Scroll-Team derzeit aus 10 Kernmitgliedern, die über Asien, Amerika und Europa verteilt sind. Die Teammitglieder verfügen über umfangreiche Erfahrung in der zkRollup-Entwicklung und im Branchenbetrieb, wobei die meisten von ihnen einen Abschluss an renommierten Universitäten und einen Doktortitel haben.

Derzeit ist das Scroll-Ökosystem sehr reichhaltig, mit Infrastrukturprojekten wie Wallets, Entwicklungstools, Sicherheitseinrichtungen und mehr. Ziel ist die umfassende Betreuung von Projekten über den gesamten Lebenszyklus, vom Design über die Entwicklung, den Betrieb bis hin zur Sicherheitsüberprüfung. Derzeit gibt es über 180 Ökosystemprojekte im Scroll-Mainnet.

1. Geldbörse
   Scroll unterstützt derzeit fast alle gängigen Wallets: Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet. Darüber hinaus umfasst das Scroll-Ökosystem-Wallet auch OKX Wallet, Versa Wallet usw.

2. Cross-Chain-Brücke
   Zur offiziellen Cross-Chain-Infrastruktur von Scroll gehören Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext usw. Darüber hinaus umfasst es auch das kettenübergreifende Liquiditätsprotokoll Synapse Protocol, Owlto Finance mit Schwerpunkt auf Layer-2-Cross-Chain-Brücken, Ethereum Layer 1 und Layer 2 Cross-Chain-Bridge Pheasant Network, Symbiosis, Catalyst usw.

3. DeFi
   Im Scroll-Ökosystem gibt es mehrere etablierte DeFi-Projekte, darunter das Kreditprotokoll Aave, den Multi-Chain-DEX-Aggregator DODO, DEX SushiSwap, den DEX-Aggregator OpenOcean, das Multi-Chain-DeFi-Protokoll iZUMi Finance, DEX Syncswap, das Yield-Protokoll Pendle Finance und Lending Protokoll dForce und Leverage Trading Aggregator MUX Protocol. Es gibt auch innovative Projekte wie GMX, die keine breite Akzeptanz gefunden haben.

4. Andere
   In Bezug auf NFT, Spiele und soziale Aspekte umfassen weitere Projekte im Scroll-Ökosystem NFTScan, die Web3-Aufgabenplattform QuestN, TaskOn, die elektronische Protokollsignaturplattform EthSign, Galaxy Blitz, OmniKingdoms und andere Online-Blockchain-Spiele.

Was unterscheidet die Scroll-Technologie von anderen?

1. Gesamtarchitektur

Die Architektur von Scroll besteht aus drei Komponenten:

Scroll-Knoten: Er generiert Blöcke im Scroll-Netzwerk basierend auf Benutzertransaktionen, übermittelt diese Transaktionen an die Ethereum-Basisschicht und verwaltet den Nachrichtenaustausch zwischen Ethereum und Scroll.

Roller: Der Roller ist für die Umwandlung intelligenter Verträge in zkEVM-Schaltkreise verantwortlich und generiert dann Beweise, um die Richtigkeit der Transaktionen zu beweisen. Im Scroll-Netzwerk gibt es mehrere Roller, die Transaktionen parallel verarbeiten und die Beweiserstellung durch Hardware beschleunigen. Scroll erreicht die Kompatibilität auf Bytecode-Ebene mit EVM, indem es die Korrektheit der EVM-Bytecode-Verarbeitung direkt nachweist.

Rollup- und Bridge-Vertrag: Diese Verträge stellen die Datenverfügbarkeit für Scroll-Transaktionen bereit und überprüfen die von zkEVM generierten Gültigkeitsnachweise. Man kann sagen, dass Scroll über Rollup- und Bridge-Verträge mit der Ethereum-Basisschicht verbunden ist. Durch diese Verträge können Benutzer beliebige Nachrichten zwischen Ethereum und Scroll austauschen und mithilfe von Gateway-Verträgen ERC-20-Assets in beide Richtungen übertragen.

Quelle: https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k

Scroll ist der Hauptvertrag, der auf der Ethereum-Blockchain bereitgestellt wird:

Gateway-Routing-Proxy-Vertrag (Gewährleistung der korrekten Zuordnung von Token bei kettenübergreifenden Vorgängen): 0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6

Nachrichten-Proxy-Vertrag (Übertragung von Nachrichten zwischen L1 und L2): 0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367

Es ist zu beachten, dass diese Verträge vom Proxy-Administrator und -Eigentümer geändert werden können. Darüber hinaus hat Scroll eine Whitelist-Funktion integriert, die die Anpassung der Gasgebühren für bestimmte Adressen innerhalb von Scroll ermöglicht. Derzeit arbeitet der Scroll-Sequenzer zentralisiert, was die Überprüfung von Nachrichten und Transaktionen im Scroll-Netzwerk ermöglicht. Darüber hinaus besteht die Möglichkeit, jede Nachricht in der Nachrichtenwarteschlange zu umgehen und eine bestimmte Nachricht direkt zu bestätigen.

2. Scrollen Sie durch den zkEVM-Workflow

Nachdem Scroll einen Block generiert hat, durchläuft er einen Koordinator und mehrere Prüfer (Roller), um aggregierte Beweise zu generieren. Diese Nachweise werden dann dem Ethereum Rollup-Vertrag zur Überprüfung vorgelegt. Der detaillierte Ablauf ist wie folgt:

1、Der Sequenzer empfängt neue Transaktionen. Die virtuelle Maschine liest den jeder Transaktion zugeordneten Bytecode, generiert einen Ausführungs-Trace und sendet ihn an den Koordinator. Gleichzeitig übermittelt der Sequenzer Transaktionsdaten an den Rollup-Vertrag.

2、Rollers wandeln die vom Koordinator empfangenen Ausführungsspuren in zkEVM-Schaltkreise um. Jeder Schritt im Ausführungs-Trace entspricht einer zkEVM-Schaltung. Für Funktionen, die nicht zk-freundlich sind (wie Hash und Keccak), erstellt Scroll Nachschlagetabellen, um die Ein- und Ausgänge dieser Funktionen im Ausführungs-Trace der Nachschlagetabelle zuzuordnen. Zusätzliche Schaltkreise werden verwendet, um die Richtigkeit der Nachschlagetabelle zu überprüfen. Roller generieren dann Beweise für diese zkEVM-Schaltkreise.

3、Nachdem die Beweise erstellt wurden, sendet Rollers sie an den Koordinator zurück. Alle paar Blöcke weist der Koordinator zufällig einem Roller Aggregationsaufgaben zu. Der zugewiesene Roller fasst dann Beweise für mehrere Blöcke in einem einzigen Beweis zusammen.

4、Zuletzt reicht der Koordinator den aggregierten Nachweis für den Rollup-Vertrag ein. Der Rollup-Vertrag verwendet diesen Beweis, um die Richtigkeit der zuvor übermittelten Status- und Transaktionsdaten zu überprüfen und damit die Richtigkeit des Blocks zu bestätigen.

Scrollen Sie durch zkEVM-Schaltkreise und Audit

1. Hauptstromkreise

zkEVM besteht aus mehreren Schaltkreisen, von denen jeder die Aufgabe hat, einen bestimmten Aspekt der EVM (Ethereum Virtual Machine) zu überprüfen. Diese Schaltkreise werden schließlich kombiniert oder aggregiert, um einen Nachweis der Transaktionsausführung zu erstellen. Das folgende Diagramm veranschaulicht die Beziehung zwischen diesen Schaltkreisen und den Tabellen.

Es gibt kleinere Unterschaltkreise, wie den ECDSA-Schaltkreis und Opcode-bezogene Unterschaltkreise, die nicht in einer Weise mit anderen Tabellen und Schaltkreisen interagieren, die sich auf die Kombination des Schaltkreises auswirken. Der Übersichtlichkeit halber sind diese Unterschaltkreise im Diagramm weggelassen.

EVM-Schaltung

Die Ethereum Virtual Machine (EVM) ist eine Zustandsmaschine, die die Regeln für gültige Zustandsübergänge innerhalb des Ethereum-Protokolls festlegt. Es führt Anweisungen (Opcodes) aus, um diese Übergänge zu erreichen, und generiert einen Ausführungs-Trace. Das Ziel der EVM-Schaltung besteht darin, ein Einschränkungssystem zu erstellen, das die Ausführungsverfolgung darstellt und mithilfe eines wissensfreien Proof-Systems überprüft werden kann.

Das High-Level-Design der EVM-Schaltung ähnelt in gewisser Weise dem Design des EVM selbst, wie etwa bei Go-Ethereum. In Go-Ethereum durchläuft der Interpreter alle Befehls-Opcodes im Ausführungs-Trace. Für jede Anweisung überprüft der Interpreter relevante Kontextinformationen wie Gas, Stapel und Speicher und sendet dann den Opcode an die JumpTable, die detaillierte Anweisungen zur Ausführung des Opcodes bereitstellt.

In ähnlicher Weise erstellt Scroll in EVM-Schaltkreisen Ausführungsschritte basierend auf dem Ausführungs-Trace und liefert Beweise für Opcodes und Ausführungskontexte. Für jeden Ausführungsschritt wird eine Reihe von Einschränkungen angewendet, um die Kontextinformationen zu überprüfen. Für jeden Opcode wird eine Reihe von Einschränkungen angewendet, um sein Verhalten zu überprüfen. Innerhalb des Ausführungs-Trace sollte derselbe Opcode dieselben Einschränkungen haben. Scroll verwendet Selektoren, um alle Schritte mit demselben Opcode im Ausführungs-Trace zu „öffnen“ und nutzt das Backend-Proof-System, um ihr Verhalten zu beweisen.

Staatskreis

Während der Ausführung werden alle Lese- und Schreibvorgänge des EVM in der rw_table aufgezeichnet und nach der Variablen rw_counter sortiert. Der Zweck der Zustandsschaltung besteht darin, die genaue Generierung der rw_table zu demonstrieren.

MPT-Schaltung

Der Merkle Patricia Tree (MPT) ist eine Schlüsseldatenstruktur, die in der Ethereum-Speicherschicht verwendet wird. In Scrolls zkevm-Circuits wird der MPT in zkTrie geändert, was im Wesentlichen ein spärlicher binärer Merkle Patricia Trie ist. In zkevm-Circuits nutzt Scroll die MPT-Tabelle, um die Zustandsübergänge von MPT-Operationen Schritt für Schritt zu verfolgen. Die MPT-Tabelle hat das folgende Layout:

Das Ziel der MPT-Schaltung besteht darin, die Genauigkeit der oben erwähnten MPT-Tabelle zu überprüfen. Dadurch wird sichergestellt, dass jede in der MPT-Tabelle aufgezeichnete Aktualisierung zu einer korrekten Änderung führt. Das bedeutet, dass die MPT-Schaltung bei jedem Update garantiert, dass es nur eine Möglichkeit gibt, Änderungen vorzunehmen. Dies verhindert versehentliche oder unbefugte Änderungen und gewährleistet die Integrität und Genauigkeit des MPT. Insbesondere wenn das MPT aufgrund von Aktualisierungen in Konten oder Speicher Änderungen erfährt, muss der MPT-Schaltkreis nachweisen, dass diese Aktualisierungen gemäß den festgelegten Regeln durchgeführt werden. Darüber hinaus muss nachgewiesen werden, dass der Root-Hash die Ergebnisse aller Änderungen genau widerspiegelt.

Keccak-Rennstrecke

Scroll hat eine eigene Version von Keccak256 implementiert und folgt dabei der NIST-Keccak-Spezifikation und der Spezifikation des Keccak-Teams.

Und die Keccak-Schaltung wird verwendet, um die Richtigkeit der Keccak256-Operation zu beweisen. Die Implementierung dieser Schaltung ist komplex, vor allem weil der keccak256-Algorithmus selbst zk-unfreundlich ist.

Tx-Schaltung

Der Tx-Schaltkreis bietet Einschränkungen zur Validierung der Richtigkeit einer Transaktion. Dabei werden vor allem folgende Aspekte der Transaktion geprüft:

1. Die Richtigkeit von CallDataLength und kumulativem CallDataGasCost: Bestimmen Sie das benutzerdefinierte Gate und suchen Sie die letzte Zeile der Anrufdatenbytes in der TX-Tabelle.

2. Die Richtigkeit der TxSign- und TxHash-bezogenen Daten: Durchsuchen Sie die RLP-Tabelle und die Keccak-Tabelle.

3. Beweisen Sie die Richtigkeit von „Wenn tx_type L1Msg ist, dann msg_hash“: Überprüfen Sie dies, indem Sie die RLP-Tabelle durchsuchen.

4. Führen Sie die Sendesignatur mit ECDSA korrekt aus und stellen Sie die Adresse des Anrufers korrekt aus der ECDSA-Signatur wieder her: Überprüfen Sie dies, indem Sie die Signaturtabelle durchsuchen.

5. Das korrekte Übergangsverhalten von tx id, cum_num_txs und call_data_length;

6. Einige grundlegende Einschränkungen, wie zum Beispiel boolesche Werte bestimmter Indikatorvariablen.

Bytecode-Schaltung

EVM-Schaltkreise müssen nach einer Bytecode-Tabelle suchen, die die richtigen Bytecode-Informationen enthält. Dadurch wird sichergestellt, dass die im Vertrag gespeicherten Bytes mit den aus der Tabelle geladenen Bytes übereinstimmen. Der Zweck der Bytecode-Schaltung besteht darin, die Richtigkeit der Bytecode-Tabelle sicherzustellen. Das beinhaltet:

1. Einschränkungen im Zusammenhang mit dem Grenzverhalten bei Tags (Tag): Einschränkungen in der ersten und letzten Zeile, Konvertierung von Tag == Byte in Header und umgekehrt, Konvertierung von Header in Header;

2. Einschränkungen der Codegröße: Einschließlich der Berechnung der Bytecode-Länge durch die Einschränkung des Index des letzten Bytes des Bytecodes;

3. Einschränkungen für den Code-Hash: Korrekte Einschränkung des RLC-Verhaltens von Bytes im Code-Hash und Überprüfung des Code-Hashs durch Nachschlagen in der Keccak-Tabelle;

4. Sicherstellung der Korrektheit des PUSH-Verhaltens: is_code = push_data_left == 0 (muss ein boolescher Wert sein) und Überprüfung der Größe der gepushten Daten für PUSH1-PUSH32 durch Nachschlagen der push_table;

5. Sicherstellung der korrekten Weitergabe in jeder Zeile eines Bytecodes.

2. Sicherheitsaudit

Verschiedene Ketten verfügen über eigene benutzerdefinierte Geschäftsmodulfunktionen, die normalerweise die vorkompilierten Verträge und Opcodes im EVM ändern. Unter ihnen ist Scroll zkEVM eine Skalierungslösung der zweiten Ebene, die auf wissensfreien Beweisen basiert. Diese Lösung rekonstruiert die relevanten Opcodes mithilfe von Schaltkreisen und generiert Beweise basierend auf Ausführungsspuren. Diese komplexe Implementierung erhöht die Schwierigkeit der Prüfung erheblich. Nach der Bewertung durch Beosin-Sicherheitsexperten konzentriert sich das Sicherheitsaudit von zkEVM hauptsächlich auf die folgenden Aspekte:

1. GAS: Bei der Erstellung von Nachweisen für die Ausführungsverfolgung der zkEVM-Schaltung wird auch die Richtigkeit des Gasverbrauchs für Transaktionen überprüft. Wenn in der Implementierungsschaltung der Opcodes häufig uneingeschränkte freie Variablen verwendet werden, kann dies zu einem Fehler bei der Beweiserstellung oder anderen unbekannten Fehlern führen.

2. Speichersicherheit: Einige zkEVM-Schaltkreise basieren auf Polynom-Commitments, wie zum Beispiel das von Scroll verwendete KZG-Commitment. Polynomberechnungen stimmen jedoch nicht automatisch überein. Fehlen also in der Schaltung Einschränkungen, kann dies zu einem Wertebereich führen, der nicht mit dem Bytebereich in Computerprogrammen übereinstimmt. In einigen Fällen, wenn Vertragsentwickler die Gasoptimierung ermöglichen, kann die kompakte Anordnung der Daten zu Problemen mit der Speichersicherheit führen, wie beispielsweise das konstante Polynom BYTE_C4096 in Polygon zkEVM. Durch Polynome können Parameterwerte den maximalen Byte-Wertebereich von 255 überschreiten, was es böswilligen Sequenzern möglicherweise ermöglichen kann, Parameter auf einigen Börsenplattformen, die das AMM-Modell verwenden, gewinnbringend zu manipulieren. Im Wesentlichen entstehen diese Arten von Schwachstellen durch Inkonsistenzen zwischen dem numerischen Gültigkeitsbereich, der durch die Schaltung dargestellt wird, und dem variablen Wertebereich des Programms. Ein Beispiel ist die von Beosin-Sicherheitsforschern entdeckte Schwachstelle CVE-2023-33252 in der Snarkjs-Bibliothek.

3. Opcode-Sicherheit: Bei der Implementierung von zkEVM-Opcodes gibt es häufig Sicherheitsprobleme, insbesondere hinsichtlich der Präzision. Wenn beispielsweise beim Vergleich zweier Zahlen in der zugrunde liegenden Schaltung die Genauigkeit der Vergleichsoperation im Programm 1 Byte beträgt, müssen die Schaltungsbeschränkungen den Wertebereich angeben. Andernfalls übersteigt die Genauigkeit der Operationen in der Schaltung die Genauigkeit des Programms, was zu falschen Ergebnissen führt.

4. Unterstützung für sichere EIPs: Unterstützung für sicherheitsorientierte EIPs wie EIP-2 und EIP-155.

5. Zentralisierungsproblem im Sequencer: Derzeit hängen alle von Scroll generierten Beweise von der vom Sequencer generierten Ausführungsverfolgung ab. Wenn sich Sequencer böswillig verhält, kann zkEVM die Sicherheit der Benutzerressourcen nicht garantieren.

6. Kompatibilitätsproblem: zkEVM generiert Schaltungsnachweise basierend auf der Ausführungsverfolgung und überprüft sie im Vertrag. Selbst geringfügige Upgrades im Sequencer können zu erheblichen Unterschieden im Ausführungs-Trace führen, der auf der zugrunde liegenden Sprachebene generiert wird.

Scrolls Zukunftsaussichten

1. Scroll verwendet derzeit eine zweischichtige KZG-Version des Halo2-Proof-Systems und nutzt die GPU-Hardwarebeschleunigung, um die Proof-Generierung zu beschleunigen. Der Engpass hat sich nun auf die Zeugengenerierung und Datenreplikation verlagert. Darüber hinaus sind der Zentralisierungsgrad und die Hardware-Betriebskosten von Roller Aspekte, die Scroll bei der zukünftigen Entwicklung mehrstufiger Proofsysteme berücksichtigen muss.

2. Da sich der EVM-Ausführungs-Trace dynamisch ändert, gibt es verschiedene Schaltungseinschränkungen und -skalen. Um dem sich dynamisch ändernden Ausführungs-Trace gerecht zu werden, muss derzeit jeder Schritt des Ausführungs-Trace den größten Schaltungsumfang erfüllen, was zu zusätzlicher Speicherverschwendung führt.

3. Es wird derzeit erwartet, dass Scroll's Roller von Netzwerktransaktionsgebühren profitiert. Allerdings können die aktuellen Nutzerzahlen und Transaktionsgebühren im Scroll-Netzwerk die Betriebskosten von Roller und dem Sequenzer nicht decken. In Zukunft muss darüber nachgedacht werden, wie das Scroll-Netzwerk wirtschaftliche Anreize bietet, um Benutzer anzulocken und einen stabilen Netzwerkbetrieb aufrechtzuerhalten.

Derzeit unterstützt Beosin auch die Prüfung des zk-Projekts. Für Hardcore-Sicherheitsrecherchen zu zk können Sie die folgenden Artikel lesen: 1. Transaction Malleability Attack of Groth16 Proof; 2. Eingehende Untersuchung von Tornado Cash, um Formbarkeitsangriffe in ZKP-Projekten aufzudecken.

Beosin hat als weltweit führendes Blockchain-Sicherheitsunternehmen Niederlassungen in mehr als 10 Ländern und Regionen weltweit gegründet. Unsere Dienstleistungen umfassen Code-Sicherheitsaudits vor Projektstart, Überwachung von Sicherheitsrisiken, Frühwarnung und Prävention während des Projektbetriebs, Vermögenswiederherstellung für gestohlene virtuelle Währungen und sichere Compliance-Dienste wie KYT/AML. Wir bieten eine Komplettlösung für Blockchain-Sicherheitsprodukte und -dienstleistungen. Derzeit haben wir Sicherheitstechnologiedienstleistungen für über 3.000 Blockchain-Unternehmen weltweit bereitgestellt und mehr als 3.000 Smart Contracts geprüft. Fühlen Sie sich frei uns zu kontaktieren.

Haftungsausschluss:

1. Dieser Artikel ist ein Nachdruck von [Beosin]. Alle Urheberrechte liegen beim ursprünglichen Autor [Beosin]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.