Optimism Technische Dokumentation

Analysis and Comparison between Optimism and StarkNet

저자 Optimism Collective · 2021

Optimism에는 전통적인 백서가 없습니다. 이더리움 Layer 2 옵티미스틱 롤업으로서, 설계 및 사양은 단일 공식 학술 논문이 아닌 기술 문서, OP Stack 사양, 연구 게시물을 통해 문서화되어 있습니다.

🇺🇸 English (원문)

🇩🇪 Deutsch (번역)

Abstract

The paper addresses the problem of scalability in decentralized blockchains by analyzing the trade-off between transaction throughput and hardware requirements to run a node. Rollups, i.e. technologies for on-chain verification of blocks executed off-chain, are presented in the form of fault or validity proofs. We compare Optimistic Rollups and Validity Rollups with respect to withdrawal time, transaction costs, optimization techniques, and compatibility with the Ethereum ecosystem. Our analysis reveals that Optimism Bedrock currently has a gas compression rate of approximately 20:1, while StarkNet achieves a storage write cost compression rate of around 24:1. We also discuss techniques to further optimize these rates, such as the use of cache contracts and Bloom filters. Ultimately, our conclusions highlight the trade-offs between complexity and agility in the choice between Optimistic and Validity Rollups. Keywords Blockchain, Scalability, Rollup 1. Introduction Blockchain technology has gained significant attention due to its potential to revolutionize various industries. However, scalability remains a major challenge, as most blockchains face a trade-off between scalability, decentralization, and security, commonly referred to as the Scalability Trilemma [1, 2]. To increase the throughput of a blockchain, a trivial solution is to increase its block size. In the context of Ethereum, this means increasing the maximum amount of gas a block can hold. As each full node must validate every transaction of every block, as the throughput increases, the hardware requirements also increase, leading to a greater centralization of the network. Some blockchains, such as Bitcoin and Ethereum, optimize their design to maximize their architectural decentralization, while others, such as the Binance Smart Chain and Solana, are designed to be as fast and cheap as possible. Decentralized networks artificially limit the throughput of the blockchain to lower the hardware requirements to participate in the network. Over the years, attempts have been made to find a solution to the Trilemma, such as state channels [3] and Plasma [4, 5]. These solutions have the characteristic of moving some activity off-chain, linking on-chain activity to off-chain activity using smart contracts, and verifying DLT 2023: 5th Distributed Ledger Technology Workshop, May 25-26, 2023, Bologna, Italy $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) on-chain what is happening off-chain. However, both Plasma and state channels are limited in their support of general smart contracts. Rollups are blockchains (called Layer 2 or L2) that publish their blocks on another blockchain (Layer 1 or L1) and therefore inherit its consensus, data availability and security properties. They, unlike other solutions, support arbitrary computation. Rollups have three main components: • Sequencers: nodes that receive Rollup transactions from users and combine them into a block that is sent to Layer 1. The block consists of at least the state root (e.g. a Merkle root) and the data needed to reconstruct and validate the state. The Layer 1 defines the...

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...

Introduction

Introduction Blockchain technology has gained significant attention due to its potential to revolutionize various industries. However, scalability remains a major challenge, as most blockchains face a trade-off between scalability, decentralization, and security, commonly referred to as the Scalability Trilemma [1, 2]. To increase the throughput of a blockchain, a trivial solution is to increase its block size. In the context of Ethereum, this means increasing the maximum amount of gas a block can hold. As each full node must validate every transaction of every block, as the throughput increases, the hardware requirements also increase, leading to a greater centralization of the network. Some blockchains, such as Bitcoin and Ethereum, optimize their design to maximize their architectural decentralization, while others, such as the Binance Smart Chain and Solana, are designed to be as fast and cheap as possible. Decentralized networks artificially limit the throughput of the blockchain to lower the hardware requirements to participate in the network. Over the years, attempts have been made to find a solution to the Trilemma, such as state channels [3] and Plasma [4, 5]. These solutions have the characteristic of moving some activity off-chain, linking on-chain activity to off-chain activity using smart contracts, and verifying DLT 2023: 5th Distributed Ledger Technology Workshop, May 25-26, 2023, Bologna, Italy $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)

on-chain what is happening off-chain. However, both Plasma and state channels are limited in their support of general smart contracts. Rollups are blockchains (called Layer 2 or L2) that publish their blocks on another blockchain (Layer 1 or L1) and therefore inherit its consensus, data availability and security properties. They, unlike other solutions, support arbitrary computation. Rollups have three main components: • Sequencers: nodes that receive Rollup transactions from users and combine them into a block that is sent to Layer 1. The block consists of at least the state root (e.g. a Merkle root) and the data needed to reconstruct and validate the state. The Layer 1 defines the canonical blockchain of the L2 by establishing the ordering of the published data. • Rollup full nodes: nodes that obtain, process and validate Rollup blocks from Layer 1 by verifying that the root is correct. If a block contains invalid transactions it is then discarded, which prevents Sequencers from creating valid blocks that include invalid transactions. • Rollup light nodes: nodes that obtain Rollup blocks from Layer 1 but do not compute the new state themselves. They verify that the new state root is valid using techniques such as fault or validity proofs. Rollups achieve scalability by decreasing the amortized cost of transactions as the number of users increases. This is because the cost of ensuring blockchain validity grows sub-linearly with respect to the cost of verifying transactions individually. Rollups differ according to the mechanism by which they ensure the validity of transaction execution at light nodes: in Optimistic Rollups it is ensured by an economic model and by fault proofs, while in Validity Rollups it is cryptographically ensured using validity proofs. Light nodes can be implemented as smart contracts on Layer 1. They accept the root of the new state and verify validity or fault proofs: these Rollup are therefore called Smart Contract Rollups. If light nodes are independent, they are called Sovereign Rollups [6]. The advantage of using a Smart Contract Rollup is to be able to build a trust-minimized bridge between the two blockchains: since the validity of the L2 state is proven to L1, a system of transactions from L2 to L1 can be implemented, allowing withdrawals. The disadvantage is that the cost of the transactions depends on the cost of verifying the state on L1: if the base layer is saturated by other activities, the cost of transactions on the Rollup also increases. The data and consensus layers are the ones that determine the security of the system as they define the ordering of transactions, prevent attacks and make data available to prove state validity. Paper contribution In this paper, we study Optimistic and Validity Rollups, two innovative solutions to the Scalability Trilemma, with a focus on notable implementations, such as Optimism Bedrock and StarkNet. Our contributions include a comprehensive comparison of these solutions, an analysis of withdrawal times, and a discussion of a possible attack on Optimism Bedrock. Additionally, we calculate their gas compression ratios, provide application-specific optimizations, and present the advantages and disadvantages of moving away from the Ethereum Virtual Machine (EVM).

Paper structure The paper is organized as follows. In section 2 Optimistic Rollups are introduced by analyzing Optimism Bedrock. In section 3 Validity Rollups are introduced by analyzing StarkNet. In section 4 we compare the two solutions. Finally, in section 5 we draw some conclusions.

Einführung

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.

Optimistic Rollups

Optimistic Rollups The idea of accepting optimistically the output of blocks without verifying their execution is already present in the Bitcoin whitepaper [7], discussing light nodes. These nodes only follow the header chain by verifying the consensus rule, making them vulnerable to accept blocks containing invalid transactions in the event of a 51% attack. Nakamoto proposes to solve this problem by using an “alert" system to warn light nodes that a block contains invalid transactions. This mechanism is first implemented by Al-Bassam, Sonnino and Buterin [8] in which a fault proof system based on error correction codes [9] is used. In order to enable the creation of fault proofs, it is necessary that the data from all blocks, including invalid blocks, is available to the network: this is the Data Availability Problem, which is solved using a probabilistic data sampling mechanism. The first Optimistic Rollup design was presented by John Adler and Mikerah Quintyne-Collins in 2019 [10], in which blocks are published on another blockchain that defines their consensus on ordering. 2.1. Optimism Bedrock Bedrock [11] is the latest version of Optimism, a Smart Contract Rollup. The previous version, the Optimistic Virtual Machine (OVM) required an ad hoc compiler to compile Solidity into its own bytecode: in contrast, Bedrock is fully equivalent to the EVM in that the execution engine follows the Ethereum Yellow Paper specification [12]. 2.1.1. Deposits Users can deposit transactions through a contract on Ethereum, the Optimism Portal, by calling the depositTransaction function. When a transaction is executed, a TransactionDeposited event is emitted, which each node in the Rollup listens for to process deposits. A deposited transaction is a L2 transaction that is derived from L1. If the caller of the function is a contract, the address is transformed by adding a constant value to it: this prevents attacks in which a contract on L1 has the same address as a contract on L2 but a different code. The inclusion on L2 of a deposited transaction is ensured by specification within a sequencing window. Deposited transactions are a new EIP-2718 compatible transaction type [13] with prefix 0x7E, where the rlp-encoded fields are: • bytes32 sourceHash: hash that uniquely identifies the source of the transaction. • address from: the address of the sender. • address to: the receiver address, or the zero address if the deposited transaction is a contract creation.

• uint256 mint: the value to be created on L2. • uint256 value: the value to be sent to the recipient. • bytes data: the input data. • bytes gasLimit: the gas limit of the transaction. The sourceHash is computed as the keccak256 hash of the L1 block hash and the L1 log index, uniquely identifying an event in a block. Since deposited transactions are initiated on L1 but executed on L2, the system needs a mechanism to pay on L1 for the gas spent on L2. One solution is to send ETH through the Portal, but this implies that every caller (even indirect callers) must be marked as payable, and this is not possible for many existing projects. The alternative is to burn the corresponding gas on L1. The gas 𝑔allocated to deposited transaction is called guaranteed gas. The L2 gas price on L1 is not automatically synchronized but is estimated using a mechanism similar to EIP-1559 [14]. The maximum amount of gas guaranteed per Ethereum block is 8 million, with a target of 2 million. The quantity 𝑐of ETH required to pay for gas on L2 is 𝑐= 𝑔𝑏L2 where 𝑏L2 is the basefee on L2. The contract on L1 burns an amount of gas equal to 𝑐/𝑏L2. The gas spent to call depositTransaction is reimbursed on L2: if this amount is greater than the guaranteed gas, no gas is burned. The first transaction of a rollup block is a L1 attributes deposited transaction, used to register on a L2 predeploy the attributes of Ethereum blocks. The attributes that the predeploy gives access to are the block number, the timestamp, the basefee, the block hash and the sequence number, which is the block number of L2 relative to the associated L1 block (also called epoch); this number is reset when a new epoch starts. 2.1.2. Sequencing The Rollup nodes derive the Optimism chain entirely from Ethereum. This chain is extended each time new transactions are published on L1, and its blocks are reorganized each time Ethereum blocks are reorganized. The Rollup blockchain is divided into epochs. For each 𝑛 block number of Ethereum, there is a corresponding 𝑛epoch. Each epoch contains at least one block, and each block in an epoch contains a L1 attributes deposited transaction. The first block in an epoch contains all transactions deposited through the Portal. Layer 2 blocks may also contained sequenced transactions, i.e. transactions sent directly to the Sequencer. The Sequencer accepts transactions from users and builds blocks. For each block, it constructs a batch to be published on Ethereum. Several batches can be published in a compressed manner, taking the name channel. A channel can be divided into several frames, in case it is too large for a single transaction. A channel is defined as the compression with ZLIB [15] of rlp-encoded batches. The fields of a batch are the epoch number, the epoch hash, the parent hash, the timestamp and the transaction list. A sequencing window, identified by an epoch, contains a fixed number 𝑤of consecutive L1 blocks that a derivation step takes as input to construct a variable number of L2 blocks. For epoch 𝑛, the sequencing window 𝑛includes the blocks [𝑛, 𝑛+𝑤). This implies that the ordering of L2 transactions and blocks within a sequencing window is not fixed until the window ends. A rollup transaction is called safe if the batch containing it has been confirmed on L1. Frames

are read from L1 blocks to reconstruct batches. The current implementation does not allow the decompression of a channel to begin until all corresponding frames have been received. Invalid batches are ignored. Individual block transactions are obtained from the batches, which are used by the execution engine to apply state transitions and obtain the Rollup state. 2.1.3. Withdrawals In order to process withdrawals, an L2-to-L1 messaging system is implemented. Ethereum needs to know the state of L2 in order to accept withdrawals, and this is done by publishing on the L2 Output Oracle smart contract on L1 the state root of each L2 block. These roots are optimistically accepted as valid (or finalized) if no fault proof is performed during the dispute period. Only addresses designated as Proposers can publish output roots. The validity of output roots is incentivized by having Proposers deposit a stake that is slashed if they are shown to have proposed an invalid root. Transactions are initiated by calling the function initiateWithdrawal on a predeploy on L2 and then finalized on L1 by calling the function finalizeWithdrawalTransaction on the previously mentioned Optimism Portal. The output root corresponding to the L2 block is obtained from the L2 Output Oracle; it is verified that it is finalized, i.e. that the dispute period has passed; it is verified that the Output Root Proof matches the Oracle Proof; it is verified that the hash of the withdrawal is included in it using a Withdrawal Proof; that the withdrawal has not already been finalized; and then the call to the target address is executed, with the specified gas limit, amount of Ether and data. 2.1.4. Cannon: the fault proof system If a Rollup Full Node, by locally executing batches and deposited transactions, discovers that the Layer 2 state does not match the state root published on-chain by a Proposer, it can execute a fault proof on L1 to prove that the result of the block transition is incorrect. Because of the overhead, processing an entire Rollup block on L1 is too expensive. The solution implemented by Bedrock is to execute on-chain only the first instruction of disagreement of minigeth, compiling it into a MIPS architecture that is executed on an on-chain interpreter and published on L1. minigeth is a simplified version of geth 1 in which the consensus, RPC and database have been removed. To find the first instruction of disagreement, an interactive binary search is conducted between the one who initiated the fault proof and the one who published the output root. When the proof starts, both parties publish the root of the MIPS memory state halfway through the execution of the block on the Challenge contract: if the hash matches it means that both parties agree on the first half of the execution thus publishing the root of half of the second half, otherwise the half of the first half is published and so on. Doing so achieves the first instruction of disagreement in a logarithmic number of steps compared to the original execution. If one of the two stops interacting, at the end of the dispute period the other participant automatically wins. To process the instruction, the MIPS interpreter needs access to its memory: since the root is available, the necessary memory cells can be published by proving their inclusion. To access the state of the EVM, use is made of the Preimage Oracle: given the hash of a block it returns 1https://geth.ethereum.org/docs

the block header, from which one can get the hash of the previous block and go back in the chain, or get the hash of the state and logs from which one can get the preimage. The oracle is implemented by minigeth and replaces the database. Queries are made to other nodes to obtain the preimages.

Optimistische Rollups

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.

Validity Rollups

Validity Rollups The goal of a Validity Rollup is to cryptographically prove the validity of the state transition given the sequence of transactions with a short proof that can be verified sub-linearly compared to the time of the original computations. These kind of certificates are called computational integrity proofs and are practically implemented with SNARKs (Succint Non-interactive ARgument of Knowledge), which use arithmetic circuits as their computational model. Different SNARK implementations differ in proving time, verification time, the need of a trusted setup and quantum resistance [16, 17]. STARKs (Scalable Transparent ARgument of Knowledge) [18] are a type of SNARKs that does not require a trusted setup and are quantum resistant, while giving up some efficiency on proving and verification compared to other solutions. 3.1. StarkNet StarkNet is a Smart Contract Validity Rollup developed by StarkWare that uses the STARK proof system to validate its state to Ethereum. To facilitate the construction of validity proofs, a virtual machine different than the EVM is used, whose high-level language is Cairo. 3.1.1. Deposits Users can deposit transactions via a contract on Ethereum by calling the sendMessageToL2 function. The message is recorded by computing its hash and increasing a counter. Sequencers listen for the LogMessageToL2 event and encode the information in a StarkNet transaction that calls a function of a contract that has the l1_handler decorator. At the end of execution, when the proof of state transition is produced, the consumption of the message is attached to it and it is deleted by decreasing its counter. The inclusion of deposited transactions is not required by the StarkNet specification, so a gas market is needed to incentivize Sequencers to publish them on L2. In the current version, because the Sequencer is centralized and managed by StarkWare, the cost of deposited transactions is only determined by the cost of executing the deposit. This cost is paid by sending ETH to sendMessageToL2. These Ethers remain locked on L1 and are transferred to the Sequencer on L1, when the deposited transaction is included in a state transition. The amount of ETH sent, if the deposited transaction is included, is fully spent, regardless of the amount of gas consumed on L2. StarkNet does not have a system that makes L1 block attributes available automatically. Alternatively, Fossil is a protocol developed by Oiler Network 2 that allows, given a hash of a block, any information to be obtained from Ethereum by publishing preimages. 2https://www.oiler.network/

3.1.2. Sequencing The current state of StarkNet can be derived entirely from Ethereum. Any state difference between transitions is published on L1 as calldata. Differences are published for each contract and are saved as uint256[] with the following encoding: • Number of field concerning contract deployments. • For each published contract: – The address of the published contract. – The hash of the published contract. – The number of arguments of the contract constructor. – The list of constructor arguments • Number of contract whose storage has been modified. • For each contract that has been modified: – The address of the modified contract. – The number of storage updates. – The key-value pairs of the storage addresses with the new values. The state differences are published in order, so it is sufficient to read them sequentially to reconstruct the state. 3.1.3. Withdrawals To send a message from L2 to L1, the syscall send_message_to_L1 is used. The message is published to L1 by increasing its hash counter along with the proof and finalized by calling the function consumeMessageFromL2 on the StarkGate smart contract on L1, which decrements the counter. Anyone can finalize any withdrawal. 3.1.4. Validity proofs The Cairo Virtual Machine [19] is designed to facilitate the construction of STARK proofs. The Cairo language allows the computation to be described with a high-level programming language, and not directly as a circuit. This is accomplished by a system of polynomial equations 3 representing a single computation: the FDE cycle of a von Neumann architecture. The number of constraints is thus fixed and independent of the type of computation, allowing for only one Verifier program for every program whose computation needs to be proved. StarkNet aggregates multiple transactions into a single STARK proof using a shared prover named SHARP. The proofs are sent to a smart contract on Ethereum, which verifies their validity and updates the Merkle root corresponding to the new state. The sub-linear cost of verifying a validity proof allows its cost to be amortized over multiple transactions. 3called Algebraic Intermediate Representation (AIR)

Gültigkeits-Rollups

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

Comparison

Comparison 4.1. Withdrawal time The most important aspect that distinguishes Optimistic Rollups from Validity Rollups is the time that elapses between the initialization of a withdrawal and its finalization. In both cases, withdrawals are initialized on L2 and finalized on L1. On StarkNet, finalization is possible as soon as the validity proof of the new state root is accepted on Ethereum: theoretically, it is possible to withdraw funds in the first block of L1 following initialization. In practice, the frequency of sending validity proofs on Ethereum is a trade-off between the speed of block finalization and proof aggregation. Currently StarkNet provides validity proofs for verification every 10 hours 4, but it is intended to be decreased as transaction activity increases. On Optimism Bedrock it is possible to finalize a withdrawal only at the end of the dispute period (currently 7 days), after which a root is automatically considered valid. The length of this period is mainly determined by the fact that fault proofs can be censored on Ethereum until its end. The success probability of this type of attack decreases exponentially as time increases: E[subtracted value] = 𝑉𝑝𝑛 where 𝑛is the number of blocks in an interval, 𝑉is the amount of funds that can be subtracted by publishing an invalid root, and 𝑝is the probability of successfully performing a censorship attack in a single block. Suppose that this probability is 99%, that the value locked in the Rollup is one million Ether, and that the blocks in an interval are 1800 (6 hours of blocks with a 12 seconds interval): the expected value is about 0.01391 Ether. The system is made secure by asking Proposers to stake a much larger amount of Ether than the expected value. Winzer et al. showed how to carry out a censorship attack using a simple smart contract that ensures that certain areas of memory in the state do not change [20]. Modeling the attack as a Markov game, the paper shows that censoring is the dominant strategy for a rational block producer if they receive more compensation than including the transaction that changes the memory. The 𝑝value discussed above can be viewed as the percentage of rational block producers in the network, where “rational” does not take into account possibly penalizing externalities, such as less trust in the blockchain that decreases its cryptocurrency value. The following code presents a smart contract that can be used to perform a censorship attack on Bedrock. The attack exploits the incentives of block producers by offering them a bribe to censor the transactions that would modify specific parts of the state. The contract’s main function, claimBribe, allows block producers to claim the bribe if they successfully censor the targeted transaction by checking that the invalid output root is not touched. function claimBribe(bytes memory storageProof) external { require(!claimed[block.number], "bribe already claimed"); OutputProposal memory current = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, storageProof); require(invalidOutputRoot == current.outputRoot, "attack failed"); claimed[block.number] = true; (bool sent, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4

require(sent, "failed to send ether"); } Listing 1: Example of a contract that incentivizes a censorship attack on Bedrock. The length of the dispute period must also take into account the fact that the fault proof is an interactive proof and therefore enough time must be provided for participants to interact and that any interaction could be censored. If the last move occurs at a time very close to the end of the dispute period, the cost of censoring is significantly less. Although censoring is the dominant strategy, the likelihood of success is lower because censoring nodes are vulnerable to Denial of Service attacks: an attacker can generate very complex transactions that end with the publication of a fault proof at no cost, as no fees would be paid. In extreme cases, a long dispute period allows coordination in the event of a successful censorship attack to organize a fork and exclude the attacking block producers. Another possible attack consists in publishing more state root proposals than disputants can verify, which can be avoided using a frequency limit. 4.1.1. Fast optimistic withdrawals Since the validity of an Optimistic Rollup can be verified at any time by any Full Node, a trusted oracle can be used to know on L1 whether the withdrawal can be finalized safely. This mechanism was first proposed by Maker [21]: an oracle verifies the withdrawal, publishes the result on L1 on which an interest-bearing loan is assigned to the user, which is automatically closed at the end of 7 days, i.e. when the withdrawal can actually be finalized. This solution introduces a trust assumption, but in the case of Maker it is minimized since the oracle operator is managed by the same organization that assumes the risk by providing the loan. 4.2. Transaction costs The cost of L2 transactions is mostly determined by the interaction with the L1. In both solutions the computational cost of transactions is very cheap as it is executed entirely off-chain. Optimism publishes L2 transactions calldata as calldata and rarely (or never) executes fault proofs, therefore calldata is the most expensive resource. On January 12, 2022 a Bedrock network has been launched on the Ethereum’s Goerli testnet. A gas compression rate can be calculated by tracking the amount of gas used on Bedrock in a certain period and by comparing it to the amount of gas spent on L1 for the corresponding blocks. Using this method a gas compression rate of ∼20 : 1 is found, but this figure may differ with real activity on mainnet. StarkNet publishes on Ethereum every change in L2 state as calldata, therefore storage is the most expensive resource. Since the network does not use the EVM, the transaction cost compression cannot be trivially estimated. By assuming the cost of execution and calldata to be negligible, it is possible to calculate the compression ratio of storage writes compared to L1. Assuming no contract is deployed and 10 cells not previously accessed on StarkNet are modified, a storage write cost compression rate of ∼24 : 1 is found. If a cell is overwritten 𝑛times between data publications, the cost of each write will be 1/𝑛compared to the cost of a single write, since only the last one is published. The cost can be further minimized by

compressing frequently used values. The cost of validity proof verification is divided among the transactions it refers to: for example, StarkNet block 4779 contains 200 transactions and its validity proof consumes 267830 units of gas, or 1339.15 gas for each transaction. 4.2.1. Optimizing calldata: cache contract Presented below is a smart contract that implements an address cache for frequently used addresses by taking advantage of the fact that storage and execution are much less expensive resources, along with a Friends contract that demonstrates its use. The latter keeps track of the “friends” of an address that can be registered by calling the addFriend function. If an address has already been used at least once, it can be added by calling the addFriendWithCache function: the cache indices are 4-byte integers while the addresses are represented by 20 bytes, so there is a 5:1 saving on the function argument. The same logic can be used for other data types such as integers or more generally bytes. contract AddressCache { mapping(address => uint32) public address2key; address[] public key2address; function cacheWrite(address _address) internal returns (uint32) { require(key2address.length < type(uint32).max, "AddressCache: cache is full"); require(address2key[_address] == 0, "AddressCache: address already cached"); // keys must start from 1 because 0 means "not found" uint32 key = uint32(key2address.length + 1); address2key[_address] = key; key2address.push(_address); return key; } function cacheRead(uint32 _key) public view returns (address) { require(_key <= key2address.length && _key > 0, "AddressCache: key not found"); return key2address[_key - 1]; } } Listing 2: Address cache contract. contract Friends is AddressCache { mapping(address => address[]) public friends; function addFriend(address _friend) public { friends[msg.sender].push(_friend); cacheWrite(_friend); } function addFriendWithCache(uint32 _friendKey) public { friends[msg.sender].push(cacheRead(_friendKey)); } function getFriends() public view returns (address[] memory) { return friends[msg.sender];

} } Listing 3: Example of a contract that inherits the address cache. The contract supports in cache about 4 billion (232) addresses, and adding one byte gives about 1 trillion (240). 4.2.2. Optimizing storage: Bloom’s filters On StarkNet there are several techniques for minimizing storage usage. If it is not necessary to guarantee the availability of the original data then it is sufficient to save on-chain its hash: this is the mechanism used to save data for an ERC-721 (NFT) [22], i.e., an IPFS link that resolves the hash of the data if available. For data that is stored multiple times, it is possible to use a look-up table similar to the caching system introduced for Optimism, requiring all values to be saved at least once. For some applications, saving all the values can be avoided by using a Bloom filter [23, 24, 25], i.e., a probabilistic data structure that allows one to know with certainty whether an element does not belong to a set but admits a small but non-negligible probability of false positives. A Bloom filter is initialized as an array of 𝑚bits at zero. To add an element, 𝑘hash functions with a uniform random distribution are used, each one mapping to a bit of the array that is set to 1. To check whether an element belongs to the set we run the 𝑘hash functions and verify that the 𝑘bits are set to 1. In a simple Bloom’s filter there is no way to distinguish whether an element actually belongs to the set or is a false positive, a probability that grows as the number of entries increases. After inserting 𝑛elements: P[false positive] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 assuming independence of the probability of each bit set. If 𝑛elements (of arbitrary size!) are expected to be included and the probability of a false positive tolerated is 𝑝, the size of the array can be calculated as: 𝑚= −𝑛ln 𝑝 (ln 2)2 While the optimal number of hash functions is: 𝑘= 𝑚 𝑛ln 2 If we assume to insert 1000 elements with a tolerance of 1%, the size of the array is 9585 bits with 𝑘= 6, while for a tolerance of 0.1% it becomes 14377 bits with 𝑘= 9. If a million elements are expected to be inserted, the size of the array becomes about 1170 kB for 1% and 1775 kB for 0.1%, with the same values of 𝑘, since it depends only on 𝑝[26]. In a game where players must not be assigned to an opponent they have already challenged, instead of saving in storage for each player the list of past opponents one can use a Bloom filter. The risk of not challenging some players is often acceptable, and the filter can be reset periodically.

4.3. Ethereum compatibility The main advantage of being compatible with EVM and Ethereum is the reuse of all the available tools. Ethereum smart contracts can be published on Optimism without any modification nor new audits. Wallets remain compatible, development and static analysis tools, general analysis tools, indexing tools and oracles. Ethereum and Solidity have a long history of well-studied vulnerabilities, such as reentrancy attacks, overflows and underflows, flash loans, and oracle manipulations. Because of this, Optimism was able to capture a large amount of value in a short time. Choosing to adopt a different virtual machine implies having to rebuild an entire ecosystem, with the advantage of a greater implementation freedom. StarkNet natively implements account abstraction, which is a mechanism whereby each account is a smart contract that can implement arbitrary logic as long as it complies with an interface (hence the term abstraction): this allows the use of different digital signature schemes, the ability to change the private key using the same address, or use a multisig. The Ethereum community proposed the introduction of this mechanism with EIP-2938 in 2020, but the proposal has remained stale for more than a year as other updates have been given more priority [27]. Another important benefit gained from compatibility is the reuse of existing clients: Optimism uses a version of geth for its own node with only ∼800 lines of difference, which has been developed, tested, and maintained since 2014. Having a robust client is crucial as it defines what is accepted as valid or not in the network. A bug in the implementation of the fault proof system could cause an incorrect proof to be accepted as correct or a correct proof for an invalid block to be accepted as incorrect, compromising the system. The likelihood of this type of attack can be limited with a wider client diversity: Optimism can reuse in addition to geth the other Ethereum clients already maintained, and development of another Erigon-based client is already underway. In 2016 a problem in the memory management of geth was exploited for a DoS attack and the first line of defense was to recommend the use of Parity, the second most used client at the time 5. StarkNet faces the same problem with validity proofs, but the clients have to be written from scratch and the proof system is much more complex, and consequently it is also much more complex to ensure correctness.

Vergleich

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.

Conclusion

Conclusion Rollups are the most promising solution available today to solve the scalability problem in decentralized blockchains, paving the way for the era of modular blockchains as opposed to monolithic blockchains. The choice of developing either an Optimistic Rollup or a Validity Rollup is mainly shown as a trade-off between complexity and agility. StarkNet has numerous advantages such as fast withdrawals, structural inability to have invalid state transitions, lower transaction cost at the expense of a longer development period and incompatibility with EVM, while Optimism has leveraged the network economy to quickly gain a major share of the market. Optimism Bedrock, however, possesses a modular design that allows it to become a Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup in the future: Cannon currently uses minigeth compiled to MIPS for its fault proof system, but the same architecture can be used to obtain a circuit and produce validity proofs. Compiling a complex machine such as the EVM for a microarchitecture results in a simpler circuit that does not need to be modified and re-verified in case of upgrades. RISC Zero is a verifiable microarchitecture with STARK proofs already in development based on RISC-V that can be used for this purpose as an alternative to MIPS [28]. One aspect that should not be underestimated is the complexity in understanding how the technology works. A strength of traditional blockchains is to be able to verify the state of the blockchain without trusting any third party entity. However, in the case of StarkNet, it is necessary to trust the implementation when it is not possible to verify the various components based on cryptography and advanced mathematics. This may initially create friction for the adoption of the technology, but as the tools and the usage of integrity proofs advance even outside the blockchain field this problem will be hopefully solved.

Abschluss

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.