Dokumentasi Teknis Optimism

Analysis and Comparison between Optimism and StarkNet

Tác giả Optimism Collective · 2021

Optimism không có whitepaper truyền thống. Là một optimistic rollup Ethereum Layer 2, thiết kế và thông số kỹ thuật của nó được ghi lại qua tài liệu kỹ thuật, đặc tả OP Stack và các bài đăng nghiên cứu thay vì một bài báo học thuật chính thức duy nhất.

🇺🇸 English (Bản gốc)

🇮🇩 Bahasa Indonesia (Bản dịch)

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

Abstrak

Makalah ini membahas masalah skalabilitas dalam blockchains yang terdesentralisasi dengan menganalisis trade-off antara throughput transaksi dan persyaratan perangkat keras untuk menjalankan sebuah node. Rollup, yaitu teknologi untuk verifikasi on-chain dari blok yang dieksekusi secara off-chain, disajikan dalam bentuk bukti kesalahan atau validitas. Kami membandingkan Rollup Optimis dan Rollup Validitas sehubungan dengan waktu penarikan, biaya transaksi, teknik pengoptimalan, dan kompatibilitas dengan ekosistem Ethereum. Analisis kami menunjukkan bahwa Optimism Batuan Dasar saat ini memiliki laju kompresi gas sekitar 20:1, sementara StarkNet mencapai laju kompresi biaya tulis penyimpanan sekitar 24:1. Kami juga membahas teknik untuk lebih mengoptimalkan tarif ini, seperti penggunaan kontrak cache dan filter Bloom. Pada akhirnya, kesimpulan kami menyoroti trade-off antara kompleksitas dan kelincahan dalam pilihan antara Optimistic dan Validity Rollup. Kata Kunci Blockchain, Skalabilitas, Rollup 1. Pendahuluan Teknologi Blockchain telah mendapatkan perhatian yang signifikan karena potensinya untuk merevolusi berbagai industri. Namun, skalabilitas tetap menjadi tantangan besar, karena sebagian besar blockchain menghadapi trade-off antara skalabilitas, desentralisasi, dan keamanan, yang biasa disebut sebagai Trilema Skalabilitas [1, 2]. Untuk meningkatkan throughput blockchain, solusi sederhana adalah dengan meningkatkan ukuran bloknya. Dalam konteks Ethereum, hal ini berarti meningkatkan jumlah maksimum gas yang dapat ditampung suatu blok. Karena setiap node penuh harus memvalidasi setiap transaksi di setiap blok, seiring dengan peningkatan throughput, kebutuhan perangkat keras juga meningkat, sehingga menyebabkan sentralisasi jaringan yang lebih besar. Beberapa blockchain, seperti Bitcoin dan Ethereum, mengoptimalkan desainnya untuk memaksimalkan desentralisasi arsitekturnya, sementara yang lain, seperti Binance Smart Chain dan Solana, dirancang agar secepat dan semurah mungkin. Jaringan terdesentralisasi secara artifisial membatasi throughput blockchain untuk menurunkan persyaratan perangkat keras untuk berpartisipasi dalam jaringan. Selama bertahun-tahun, upaya telah dilakukan untuk menemukan solusi terhadap Trilema, seperti saluran negara [3] dan Plasma [4, 5]. Solusi ini memiliki karakteristik memindahkan beberapa aktivitas di luar rantai, menghubungkan aktivitas di dalam rantai dengan aktivitas di luar rantai menggunakan smart contracts, dan memverifikasi DLT 2023: Lokakarya Teknologi Buku Besar Terdistribusi ke-5, 25-26 Mei 2023, Bologna, Italia $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Hak cipta untuk makalah ini oleh penulisnya. Penggunaan diizinkan berdasarkan Creative Commons License Attribution 4.0 International (CC BY 4.0). Prosiding Lokakarya CEUR http://ceur-ws.org ISSN 1613-0073 Prosiding Lokakarya CEUR (CEUR-WS.org) on-chain apa yang terjadi di luar rantai. Namun, saluran Plasma dan negara terbatas dalam mendukung smart contracts umum. Rollup adalah blockchain (disebut Layer 2 atau L2) yang memublikasikan bloknya di blockchain lain (Layer 1 atau L1) dan oleh karena itu mewarisi properti konsensus, ketersediaan data, dan keamanannya. Berbeda dengan solusi lainnya, solusi ini mendukung komputasi arbitrer. Rollup memiliki tiga komponen utama: • Sequencer: node yang menerima transaksi Rollup dari pengguna dan menggabungkannya ke dalam blok yang dikirim ke Layer 1. Blok tersebut setidaknya terdiri dari root negara (misalnya root Merkle) dan data yang diperlukan untuk merekonstruksi dan memvalidasi negara. Layer 1 mendefinisikan...

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.

Perkenalan

Pendahuluan Teknologi Blockchain telah mendapatkan perhatian yang signifikan karena potensinya untuk melakukan revolusi berbagai industri. Namun, skalabilitas tetap menjadi tantangan besar, seperti yang dihadapi sebagian besar blockchain trade-off antara skalabilitas, desentralisasi, dan keamanan, yang biasa disebut sebagai Trilema Skalabilitas [1, 2]. Untuk meningkatkan throughput blockchain, solusi yang sepele adalah untuk meningkatkan ukuran bloknya. Dalam konteks Ethereum, ini berarti meningkatkan secara maksimal jumlah gas yang dapat ditampung suatu blok. Karena setiap node penuh harus memvalidasi setiap transaksi blok, seiring dengan peningkatan throughput, kebutuhan perangkat keras juga meningkat, sehingga menyebabkan lebih besar sentralisasi jaringan. Beberapa blockchain, seperti Bitcoin dan Ethereum, mengoptimalkannya desain untuk memaksimalkan desentralisasi arsitekturnya, sementara yang lain, seperti Binance Smart Chain dan Solana, dirancang secepat dan semurah mungkin. Jaringan terdesentralisasi membatasi throughput blockchain secara artifisial untuk menurunkan persyaratan perangkat keras berpartisipasi dalam jaringan. Selama bertahun-tahun, upaya telah dilakukan untuk menemukan solusi terhadap Trilema, seperti negara saluran [3] dan Plasma [4, 5]. Solusi-solusi ini mempunyai ciri-ciri menggerakkan suatu aktivitas off-chain, menghubungkan aktivitas on-chain ke aktivitas off-chain menggunakan smart contracts, dan memverifikasi DLT 2023: Lokakarya Teknologi Buku Besar Terdistribusi ke-5, 25-26 Mei 2023, Bologna, Italia $ [email protected] (L.Donno) https://lucadonnoh.github.io/ (L.Donno) 0000-0001-9221-3529 (L.Donno) © 2023 Hak cipta untuk makalah ini oleh penulisnya. Penggunaan diizinkan berdasarkan Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Bengkel Proses http://ceur-ws.org ISSN 1613-0073 Prosiding Lokakarya CEUR (CEUR-WS.org)on-chain apa yang terjadi di off-chain. Namun, saluran Plasma dan negara terbatas dukungan mereka terhadap smart contracts umum. Rollup adalah blockchain (disebut Layer 2 atau L2) yang memublikasikan bloknya di blockchain lain (Layer 1 atau L1) dan karenanya mewarisi properti konsensus, ketersediaan data, dan keamanannya. Mereka, tidak seperti solusi lain, mendukung komputasi sewenang-wenang. Rollup memiliki tiga komponen utama: • Sequencer: node yang menerima transaksi Rollup dari pengguna dan menggabungkannya menjadi a blok yang dikirim ke Layer 1. Blok tersebut setidaknya terdiri dari root negara (misalnya Merkle root) dan data yang diperlukan untuk merekonstruksi dan memvalidasi keadaan. Layer 1 mendefinisikan kanonik blockchain dari L2 dengan menetapkan urutan data yang dipublikasikan. • Rollup full node: node yang memperoleh, memproses dan memvalidasi blok Rollup dari Layer 1 dengan memverifikasi bahwa root sudah benar. Jika sebuah blok berisi transaksi yang tidak valid, maka itu adalah blok tersebut dibuang, yang mencegah Sequencer membuat blok valid yang menyertakan blok tidak valid transaksi. • Rollup light node: node yang memperoleh blok Rollup dari Layer 1 tetapi tidak melakukan komputasi negara baru itu sendiri. Mereka memverifikasi bahwa root negara baru valid menggunakan teknik seperti bukti kesalahan atau keabsahan. Rollup mencapai skalabilitas dengan mengurangi biaya transaksi yang diamortisasi sebagai jumlahnya jumlah pengguna meningkat. Hal ini karena biaya untuk memastikan validitas blockchain meningkat secara sub-linear sehubungan dengan biaya verifikasi transaksi secara individual. Rollup berbeda menurut mekanisme yang digunakan untuk memastikan validitas eksekusi transaksi pada node ringan: in Rollup Optimis itu dijamin oleh model ekonomi dan bukti kesalahan, sementara dalam Validitas Rollup itu dipastikan secara kriptografis menggunakan bukti validitas. Node cahaya dapat diimplementasikan sebagai smart contracts pada Layer 1. Mereka menerima akar dari keadaan baru dan verifikasi validitas atau bukti kesalahan: Oleh karena itu, Rollup ini disebut Kontrak Cerdas Rollup. Jika light node bersifat independen, maka disebut Sovereign Rollup [6]. Keuntungan dari menggunakan Smart Contract Rollup adalah untuk dapat membangun jembatan kepercayaan yang diminimalkan antara keduanya blockchains : karena keabsahan status L2 terbukti hingga L1, maka sistem transaksi dari L2 hingga L1 dapat diterapkan, memungkinkan penarikan. Kerugiannya adalah biaya transaksi tergantung pada biaya verifikasi keadaan pada L1: jika lapisan dasar jenuh aktivitas lainnya, biaya transaksi pada Rollup juga meningkat. Lapisan data dan konsensus inilah yang menentukan keamanan sistem mereka menentukan urutan transaksi, mencegah serangan, dan menyediakan data untuk membuktikan keadaan validitas. Kontribusi kertas Dalam makalah ini, kami mempelajari Optimistic dan Validity Rollup, dua yang inovatif solusi Trilema Skalabilitas, dengan fokus pada implementasi penting, seperti Optimism Batuan Dasar dan StarkNet. Kontribusi kami mencakup perbandingan komprehensif mengenai hal-hal tersebut solusi, analisis waktu penarikan, dan diskusi tentang kemungkinan serangan terhadap Optimism Batuan dasar. Selain itu, kami menghitung rasio kompresi gasnya, memberikan pengoptimalan khusus aplikasi, dan menyajikan keuntungan dan kerugian jika beralih dari Ethereum Mesin Virtual (EVM).

Struktur kertas Makalah ini disusun sebagai berikut. Di bagian 2 Rollup Optimis adalah diperkenalkan dengan menganalisis Optimism Batuan Dasar. Di bagian 3 Validitas Rollup diperkenalkan oleh menganalisis StarkNet. Di bagian 4 kami membandingkan kedua solusi. Terakhir, di bagian 5 kita menggambar beberapa kesimpulan.

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.

Rollup Optimis

Rollup Optimis Gagasan untuk menerima keluaran blok secara optimis tanpa memverifikasi eksekusinya adalah sudah ada di whitepaper Bitcoin [7], membahas tentang light node. Node-node ini hanya mengikuti rantai header dengan memverifikasi aturan konsensus, membuat mereka rentan untuk menerima pemblokiran berisi transaksi yang tidak valid jika terjadi serangan 51%. Nakamoto mengusulkan untuk memecahkan masalah ini masalah dengan menggunakan sistem "peringatan" untuk memperingatkan node ringan bahwa suatu blok berisi transaksi yang tidak valid. Mekanisme ini pertama kali diterapkan oleh Al-Bassam, Sonnino dan Buterin [8] dimana terjadi kesalahan sistem pembuktian berdasarkan kode koreksi kesalahan [9] digunakan. Untuk memungkinkan pembuatan bukti kesalahan, data dari semua blok, termasuk blok yang tidak valid, harus tersedia jaringan: ini adalah Masalah Ketersediaan Data, yang diselesaikan dengan menggunakan data probabilistik mekanisme pengambilan sampel. Desain Optimistic Rollup pertama dipresentasikan oleh John Adler dan Mikerah Quintyne-Collins pada tahun 2019 [10], di mana blok diterbitkan pada blockchain lain yang mendefinisikan konsensus mereka tentang pemesanan. 2.1. Optimism Batuan Dasar Batuan Dasar [11] adalah versi terbaru dari Optimism, Smart Contract Rollup. Versi sebelumnya, Mesin Virtual Optimis (OVM) memerlukan kompiler ad hoc untuk mengkompilasi Soliditas ke dalamnya bytecode sendiri: sebaliknya, Bedrock sepenuhnya setara dengan EVM di mesin eksekusi mengikuti spesifikasi Ethereum Kertas Kuning [12]. 2.1.1. Deposito Pengguna dapat menyetorkan transaksi melalui kontrak di Ethereum, Portal Optimism, dengan memanggil fungsi depositTransaction. Pada saat transaksi dijalankan, a Peristiwa TransactionDeposited dipancarkan, yang didengarkan oleh setiap node di Rollup untuk diproses deposito. Transaksi yang disimpan adalah transaksi L2 yang berasal dari L1. Jika penelepon dari fungsinya adalah kontrak, alamat diubah dengan menambahkan nilai konstan ke dalamnya: ini mencegah serangan di mana kontrak di L1 memiliki alamat yang sama dengan kontrak di L2 tetapi kodenya berbeda. Dimasukkannya L2 dari transaksi yang disimpan dijamin oleh spesifikasi dalam suatu urutan jendela. Transaksi yang disimpan adalah jenis transaksi baru yang kompatibel dengan EIP-2718 [13] dengan awalan 0x7E, di mana bidang yang dikodekan rlp adalah: • bytes32 sourceHash: hash yang secara unik mengidentifikasi sumber transaksi. • alamat dari : alamat pengirim. • alamat ke : alamat penerima, atau alamat nol jika transaksi yang disetor adalah a pembuatan kontrak.• uint256 mint: nilai yang akan dibuat pada L2. • nilai uint256: nilai yang akan dikirim ke penerima. • byte data: data masukan. • bytes gasLimit: batas gas transaksi. sourceHash dihitung sebagai keccak256 hash dari blok L1 hash dan log L1 indeks, secara unik mengidentifikasi suatu peristiwa dalam sebuah blok. Karena transaksi yang disimpan dimulai pada L1 tetapi dieksekusi pada L2, sistem memerlukan a mekanisme untuk membayar L1 untuk gas yang dihabiskan untuk L2. Salah satu solusinya adalah dengan mengirimkan ETH melalui Portal, tapi ini menyiratkan bahwa setiap penelepon (bahkan penelepon tidak langsung) harus ditandai sebagai orang yang harus dibayar, dan memang demikian tidak mungkin untuk banyak proyek yang ada. Alternatifnya adalah dengan membakar gas yang sesuai pada L1. Gas yang 𝑔dialokasikan untuk transaksi yang disetor disebut gas terjamin. Harga gas L2 aktif L1 tidak disinkronkan secara otomatis tetapi diperkirakan menggunakan mekanisme yang mirip dengan EIP-1559 [14]. Jumlah maksimum gas yang dijamin per blok Ethereum adalah 8 juta, dengan target dari 2 juta. Kuantitas 𝑐ETH yang dibutuhkan untuk membayar gas pada L2 adalah 𝑐= 𝑔𝑏L2 dimana 𝑏L2 adalah biaya dasar pada L2. Kontrak pada L1 membakar sejumlah gas yang sama dengan 𝑐/𝑏L2. Gas dihabiskan untuk menelepon depositTransaksi diganti pada L2: jika jumlah ini lebih besar dari gas yang dijamin, tidak ada gas yang terbakar. Transaksi pertama dari blok rollup adalah transaksi yang disimpan dengan atribut L1, digunakan untuk mendaftar pada L2 pra-deploy atribut blok Ethereum. Atribut yang diberikan oleh pra-penerapan aksesnya adalah nomor blok, stempel waktu, biaya dasar, blok hash dan urutannya number, yang merupakan nomor blok L2 relatif terhadap blok L1 terkait (juga disebut epoch); nomor ini disetel ulang ketika zaman baru dimulai. 2.1.2. Urutan Node Rollup memperoleh rantai Optimism seluruhnya dari Ethereum. Rantai ini diperpanjang setiap kali transaksi baru dipublikasikan di L1, dan bloknya direorganisasi setiap kali Ethereum blok ditata ulang. Rollup blockchain dibagi menjadi beberapa zaman. Untuk setiap 𝑛 nomor blok Ethereum, ada 𝑛epoch yang sesuai. Setiap zaman berisi setidaknya satu blok, dan setiap blok dalam suatu zaman berisi transaksi penyimpanan atribut L1. Blok pertama dalam suatu zaman berisi semua transaksi yang disimpan melalui Portal. Layer 2 blok juga bisa berisi transaksi berurutan, yaitu transaksi yang dikirim langsung ke Sequencer. Sequencer menerima transaksi dari pengguna dan membangun blok. Untuk setiap blok, itu dibangun kumpulan yang akan diterbitkan pada Ethereum. Beberapa batch dapat diterbitkan secara terkompresi, mengambil nama saluran. Sebuah saluran dapat dibagi menjadi beberapa bingkai, jika terlalu besar satu transaksi. Saluran didefinisikan sebagai kompresi dengan ZLIB [15] yang dikodekan rlp batch. Bidang batch adalah nomor zaman, zaman hash, induk hash, stempel waktu dan daftar transaksi. Jendela pengurutan, yang diidentifikasi berdasarkan suatu zaman, berisi bilangan tetap 𝑤dari L1 yang berurutan blok yang diambil langkah derivasi sebagai masukan untuk membangun sejumlah variabel blok L2. Untuk Epoch 𝑛, jendela pengurutan 𝑛 mencakup blok [𝑛, 𝑛+𝑤). Ini menyiratkan bahwa pemesanan transaksi dan blok L2 dalam jendela sequencing tidak diperbaiki sampai jendela berakhir. Transaksi rollup disebut aman jika batch yang memuatnya telah dikonfirmasi di L1. Bingkaidibaca dari blok L1 untuk merekonstruksi batch. Implementasi saat ini tidak memungkinkan dekompresi saluran dimulai sampai semua frame yang sesuai telah diterima. Tidak valid batch diabaikan. Transaksi blok individu diperoleh dari batch, yaitu digunakan oleh mesin eksekusi untuk menerapkan transisi status dan mendapatkan status Rollup. 2.1.3. Penarikan Untuk memproses penarikan, sistem pesan L2-ke-L1 diterapkan. Ethereum perlu mengetahui status L2 untuk menerima penarikan, dan ini dilakukan dengan menerbitkan pada Output L2 Oracle smart contract pada L1 state root setiap blok L2. Akar ini secara optimis diterima sebagai valid (atau diselesaikan) jika tidak ada bukti kesalahan yang dilakukan selama proses periode perselisihan. Hanya alamat yang ditunjuk sebagai Pengusul yang dapat mempublikasikan akar keluaran. Validitas akar keluaran diberi insentif dengan meminta Pengusul menyetorkan taruhan yang akan dipotong jika memang demikian terbukti telah mengusulkan root yang tidak valid. Transaksi dimulai dengan memanggil fungsi tersebut inisiasi Penarikan pada pra-penerapan di L2 dan kemudian diselesaikan di L1 dengan memanggil fungsi tersebut finalizeWithdrawalTransaction pada Portal Optimism yang disebutkan sebelumnya. Root keluaran yang sesuai dengan blok L2 diperoleh dari L2 Output Oracle; itu diverifikasi bahwa perselisihan tersebut telah selesai, yaitu bahwa jangka waktu perselisihan telah berlalu; telah diverifikasi bahwa Output Bukti Root cocok dengan Bukti Oracle; telah diverifikasi bahwa hash penarikan disertakan di dalamnya menggunakan Bukti Penarikan; bahwa penarikan tersebut belum diselesaikan; dan kemudian panggilan ke alamat target dieksekusi, dengan batas gas, jumlah Ether, dan data yang ditentukan. 2.1.4. Cannon: sistem bukti kesalahan Jika Rollup Full Node, dengan mengeksekusi batch dan transaksi yang disimpan secara lokal, menemukannya status Layer 2 tidak cocok dengan root status yang diterbitkan secara on-chain oleh Pengusul, ia dapat mengeksekusi bukti kesalahan pada L1 untuk membuktikan bahwa hasil transisi blok salah. Karena overhead, memproses seluruh blok Rollup di L1 terlalu mahal. Solusinya diterapkan oleh Bedrock adalah mengeksekusi on-chain hanya instruksi pertama dari ketidaksepakatan minigeth, mengkompilasinya menjadi arsitektur MIPS yang dieksekusi pada penerjemah on-chain dan diterbitkan di L1. minigeth adalah versi sederhana dari geth 1 yang berisi konsensus, RPC, dan database telah dihapus. Untuk menemukan instruksi ketidaksepakatan pertama, dilakukan pencarian biner interaktif antar orang yang memulai bukti kesalahan dan orang yang menerbitkan akar keluaran. Ketika buktinya dimulai, kedua belah pihak mempublikasikan root dari status memori MIPS di tengah-tengah eksekusi blok pada kontrak Tantangan: jika hash cocok berarti kedua belah pihak menyetujui paruh pertama eksekusi sehingga menerbitkan akar setengah dari paruh kedua, jika tidak, setengahnya babak pertama diterbitkan dan seterusnya. Melakukan hal itu akan menghasilkan instruksi ketidaksepakatan yang pertama dalam jumlah langkah logaritmik dibandingkan dengan eksekusi aslinya. Jika salah satu dari keduanya berhenti berinteraksi, di akhir masa perselisihan peserta lain otomatis menang. Untuk memproses instruksi, penerjemah MIPS memerlukan akses ke memorinya: karena root adalah tersedia, sel memori yang diperlukan dapat dipublikasikan dengan membuktikan penyertaannya. Untuk mengakses keadaan EVM, penggunaan dibuat dari Preimage Oracle: mengingat hash dari blok yang dikembalikannya 1https://geth.ethereum.org/docs

header blok, dari mana seseorang bisa mendapatkan hash dari blok sebelumnya dan kembali ke rantai, atau dapatkan hash status dan log dari mana seseorang bisa mendapatkan gambar awal. oracle diimplementasikan oleh minigeth dan menggantikan database. Kueri dibuat ke node lain untuk mendapatkan gambar awal.

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)

Rollup Validitas

Pembatalan Validitas Tujuan dari Validity Rollup adalah untuk membuktikan secara kriptografis validitas transisi keadaan diberikan urutan transaksi dengan bukti singkat yang dapat diverifikasi dibandingkan secara sub-linear ke waktu perhitungan aslinya. Sertifikat semacam ini disebut bukti integritas komputasi dan secara praktis diimplementasikan dengan SNARK (Succint Non-interactive ARgument of Knowledge), yang menggunakan aritmatika sirkuit sebagai model komputasinya. Implementasi SNARK yang berbeda berbeda dalam waktu pembuktian, waktu verifikasi, kebutuhan pengaturan yang tepercaya dan ketahanan kuantum [16, 17]. STARK (Dapat diskalakan ARgumen Pengetahuan Transparan) [18] adalah jenis SNARK yang tidak memerlukan kepercayaan pengaturannya dan tahan terhadap kuantum, namun mengurangi efisiensi dalam pembuktian dan verifikasi dibandingkan dengan solusi lain. 3.1. StarkNet StarkNet adalah Rollup Validitas Kontrak Cerdas yang dikembangkan oleh StarkWare yang menggunakan STARK sistem bukti untuk memvalidasi statusnya ke Ethereum. Untuk memudahkan konstruksi bukti keabsahan, a mesin virtual berbeda dari EVM yang digunakan, yang bahasa tingkat tingginya adalah Kairo. 3.1.1. Deposito Pengguna dapat menyetor transaksi melalui kontrak di Ethereum dengan menghubungi sendMessageToL2 fungsi. Pesan dicatat dengan menghitung hash dan menambah penghitung. Pengurut mendengarkan acara LogMessageToL2 dan menyandikan informasi dalam transaksi StarkNet yang memanggil fungsi kontrak yang memiliki dekorator l1_handler. Di akhir eksekusi, ketika bukti transisi keadaan dihasilkan, konsumsi pesan dilampirkan padanya dan itu dihapus dengan mengurangi penghitungnya. Pencantuman transaksi yang disimpan tidak diwajibkan oleh spesifikasi StarkNet, jadi gas pasar diperlukan untuk memberi insentif kepada Sequencer untuk mempublikasikannya di L2. Dalam versi saat ini, karena Sequencer dipusatkan dan dikelola oleh StarkWare, biaya transaksi yang disimpan hanya ditentukan oleh biaya pelaksanaan titipan. Biaya ini dibayar dengan mengirimkan ETH ke kirimMessageToL2. Eter ini tetap terkunci di L1 dan ditransfer ke Sequencer aktif L1, apabila transaksi yang disetorkan termasuk dalam keadaan transisi. Jumlah ETH yang dikirim, jika transaksi yang disimpan sudah termasuk, dihabiskan sepenuhnya, berapa pun jumlah gas yang dikonsumsi di L2. StarkNet tidak memiliki sistem yang membuat atribut blok L1 tersedia secara otomatis. Alternatifnya, Fossil adalah protokol yang dikembangkan oleh Oiler Network 2 yang memungkinkan, dengan hash dari a blok, informasi apa pun yang dapat diperoleh dari Ethereum dengan menerbitkan gambar awal. 2https://www.oiler.network/3.1.2. Urutan Keadaan StarkNet saat ini dapat diturunkan seluruhnya dari Ethereum. Perbedaan negara bagian apa pun antar transisi dipublikasikan di L1 sebagai data panggilan. Perbedaan dipublikasikan untuk setiap kontrak dan disimpan sebagai uint256[] dengan pengkodean berikut: • Jumlah bidang mengenai penerapan kontrak. • Untuk setiap kontrak yang diterbitkan: – Alamat kontrak yang diterbitkan. – hash dari kontrak yang dipublikasikan. – Jumlah argumen pembuat kontrak. – Daftar argumen konstruktor • Jumlah kontrak yang penyimpanannya telah diubah. • Untuk setiap kontrak yang telah diubah: – Alamat kontrak yang diubah. – Jumlah pembaruan penyimpanan. – Pasangan nilai kunci dari alamat penyimpanan dengan nilai baru. Perbedaan negara diterbitkan secara berurutan, sehingga cukup membacanya secara berurutan merekonstruksi negara. 3.1.3. Penarikan Untuk mengirim pesan dari L2 ke L1 digunakan syscall send_message_to_L1. Pesannya adalah diterbitkan ke L1 dengan menambah counter hash-nya beserta buktinya dan diselesaikan dengan memanggil fungsi mengkonsumsiMessageFromL2 di StarkGate smart contract di L1, yang mengurangi konter. Siapa pun dapat menyelesaikan penarikan apa pun. 3.1.4. Bukti validitas Mesin Virtual Kairo [19] dirancang untuk memfasilitasi pembuatan bukti STARK. Bahasa Kairo memungkinkan komputasi dijelaskan dengan pemrograman tingkat tinggi bahasa, dan tidak secara langsung sebagai sirkuit. Hal ini dicapai dengan sistem persamaan polinomial 3 mewakili komputasi tunggal: siklus FDE dari arsitektur von Neumann. Nomornya batasannya tetap dan tidak bergantung pada jenis komputasi, sehingga hanya memungkinkan satu komputasi Program verifikator untuk setiap program yang perhitungannya perlu dibuktikan. StarkNet menggabungkan beberapa transaksi menjadi satu bukti STARK menggunakan pembuktian bersama bernama SHARP. Buktinya dikirim ke smart contract pada Ethereum, yang memverifikasi keabsahannya dan memperbarui akar Merkle yang sesuai dengan status baru. Biaya sub-linier untuk verifikasi a bukti validitas memungkinkan biayanya diamortisasi dalam beberapa transaksi. 3disebut Representasi Menengah Aljabar (AIR)

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.

Perbandingan

Perbandingan 4.1. Waktu penarikan Aspek terpenting yang membedakan Optimistic Rollup dengan Validity Rollup adalah waktu yang berlalu antara inisialisasi penarikan dan penyelesaiannya. Dalam kedua kasus tersebut, penarikan diinisialisasi pada L2 dan diselesaikan pada L1. Pada StarkNet, finalisasi dapat dilakukan sebagai segera setelah bukti validitas root negara baru diterima pada Ethereum: secara teoritis, itu adalah mungkin untuk menarik dana di blok pertama L1 setelah inisialisasi. Dalam praktiknya, frekuensi pengiriman bukti validitas pada Ethereum merupakan trade-off antara kecepatan blok finalisasi dan agregasi bukti. Saat ini StarkNet memberikan bukti validitas untuk verifikasi setiap 10 jam 4, namun dimaksudkan untuk dikurangi seiring dengan meningkatnya aktivitas transaksi. Di Optimism Batuan Dasar, penarikan hanya dapat diselesaikan di akhir perselisihan periode (saat ini 7 hari), setelah itu root secara otomatis dianggap valid. Panjangnya periode ini terutama ditentukan oleh fakta bahwa bukti kesalahan dapat disensor pada Ethereum hingga akhirnya. Kemungkinan keberhasilan serangan jenis ini menurun secara eksponensial seiring bertambahnya waktu: E[nilai yang dikurangi] = 𝑉𝑝𝑛 dimana 𝑛adalah jumlah blok dalam suatu interval, 𝑉adalah jumlah dana yang dapat dikurangi dengan menerbitkan root yang tidak valid, dan 𝑝adalah kemungkinan berhasil melakukan penyensoran menyerang dalam satu blok. Misalkan probabilitas ini adalah 99%, nilai terkunci di Rollup adalah satu juta Eter, dan blok dalam suatu interval adalah 1800 (6 jam blok dengan 12 interval detik): nilai yang diharapkan adalah sekitar 0,01391 Eter. Sistem dibuat aman oleh meminta Pengusul untuk mempertaruhkan jumlah Ether yang jauh lebih besar dari nilai yang diharapkan. Winzer dkk. menunjukkan cara melakukan serangan sensor menggunakan smart contract sederhana yang memastikan bahwa area memori tertentu di negara bagian tidak berubah [20]. Memodelkan serangan sebagai permainan Markov, makalah ini menunjukkan bahwa penyensoran adalah strategi dominan yang rasional produsen blok jika mereka menerima kompensasi lebih dari memasukkan transaksi yang berubah memori. Nilai 𝑝 yang dibahas di atas dapat dipandang sebagai persentase blok rasional produsen dalam jaringan, di mana “rasional” tidak memperhitungkan kemungkinan pemberian sanksi eksternalitas, seperti berkurangnya kepercayaan pada blockchain yang menurunkan nilai mata uang kripto. Kode berikut menyajikan smart contract yang dapat digunakan untuk melakukan serangan sensor di Batuan Dasar. Serangan tersebut mengeksploitasi insentif produsen blok dengan menawarkan suap untuk menyensor transaksi yang akan mengubah bagian tertentu negara. Kontrak utama fungsi,claimBribe, memungkinkan produsen blok untuk mengklaim suap jika mereka berhasil menyensor transaksi yang ditargetkan dengan memeriksa bahwa akar keluaran yang tidak valid tidak disentuh. fungsi klaim Suap (byte memori penyimpanan Bukti) eksternal { require(!claimed[block.number], "suap sudah diklaim"); Memori OutputProposal saat ini = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, penyimpananBukti); require(invalidOutputRoot == current.outputRoot, "serangan gagal"); diklaim[block.number] = true; (bool terkirim, ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(terkirim, "gagal mengirim ether"); } Listing 1: Contoh kontrak yang memberikan insentif untuk serangan sensor terhadap Bedrock. Lamanya jangka waktu perselisihan juga harus mempertimbangkan fakta bahwa bukti kesalahannya bukti interaktif dan oleh karena itu waktu yang cukup harus disediakan bagi peserta untuk berinteraksi dan bahwa interaksi apa pun dapat disensor. Jika pergerakan terakhir terjadi pada waktu yang sangat dekat dengan Pada akhir periode perselisihan, biaya penyensoran jauh lebih sedikit. Meskipun penyensoran adalah hal yang paling penting strategi dominan, kemungkinan keberhasilannya lebih rendah karena node penyensoran rentan terhadapnya Serangan Denial of Service: penyerang dapat menghasilkan transaksi yang sangat kompleks yang diakhiri dengan publikasi bukti kesalahan tanpa biaya, karena tidak ada biaya yang akan dibayarkan. Dalam kasus ekstrim, periode perselisihan yang panjang memungkinkan terjadinya koordinasi jika terjadi keberhasilan serangan sensor untuk mengatur percabangan dan mengecualikan produsen blok yang menyerang. Lainnya kemungkinan serangan terdiri dari menerbitkan lebih banyak proposal dasar negara bagian daripada yang dapat diverifikasi oleh pihak yang berselisih, yang dapat dihindari dengan menggunakan batas frekuensi. 4.1.1. Penarikan optimis yang cepat Karena validitas Optimistic Rollup dapat diverifikasi kapan saja oleh Full Node mana pun, a oracle tepercaya dapat digunakan untuk mengetahui di L1 apakah penarikan dapat diselesaikan dengan aman. Ini mekanisme pertama kali diusulkan oleh Pembuat [21]: oracle memverifikasi penarikan, menerbitkan hasil pada L1 di mana pinjaman berbunga diberikan kepada pengguna, yang secara otomatis ditutup pada akhir 7 hari, yaitu saat penarikan benar-benar dapat diselesaikan. Solusi ini memperkenalkan asumsi kepercayaan, tetapi dalam kasus Maker, asumsi ini diminimalkan karena operator oracle dikelola oleh organisasi yang sama yang menanggung risiko dengan memberikan pinjaman. 4.2. Biaya transaksi Biaya transaksi L2 sebagian besar ditentukan oleh interaksi dengan L1. Dalam kedua solusi biaya komputasi transaksi sangat murah karena dijalankan sepenuhnya secara off-chain. Optimism menerbitkan data panggilan transaksi L2 sebagai data panggilan dan jarang (atau tidak pernah) mengeksekusi kesalahan buktinya, oleh karena itu calldata adalah sumber daya yang paling mahal. Pada 12 Januari 2022 jaringan Bedrock telah diluncurkan di testnet Goerli Ethereum. Tingkat kompresi gas dapat dihitung dengan melacak jumlah gas yang digunakan pada Batuan Dasar dalam periode tertentu dan membandingkannya dengan jumlah gas yang dihabiskan pada L1 untuk blok terkait. Menggunakan metode ini kompresi gas tingkat ∼20 : 1 ditemukan, namun angka ini mungkin berbeda dengan aktivitas nyata di mainnet. StarkNet diterbitkan pada Ethereum setiap perubahan status L2 sebagai data panggilan, oleh karena itu penyimpanan adalah sumber daya yang paling mahal. Karena jaringan tidak menggunakan EVM, biaya transaksinya kompresi tidak dapat diperkirakan dengan mudah. Dengan mengasumsikan biaya eksekusi dan data panggilan dapat diabaikan, dimungkinkan untuk menghitung rasio kompresi penulisan penyimpanan dibandingkan dengan L1. Dengan asumsi tidak ada kontrak yang diterapkan dan 10 sel yang sebelumnya tidak diakses di StarkNet adalah dimodifikasi, ditemukan tingkat kompresi biaya tulis penyimpanan ∼24 : 1. Jika sel ditimpa 𝑛waktu antar publikasi data, biaya setiap penulisan akan menjadi 1/𝑛dibandingkan dengan biayanya dari satu tulisan, karena hanya yang terakhir yang diterbitkan. Biaya dapat diminimalkan lebih lanjut denganmengompresi nilai yang sering digunakan. Biaya verifikasi bukti keabsahan dibagi diantara transaksi yang dimaksud: misalnya, StarkNet blok 4779 berisi 200 transaksi dan bukti validitas mengkonsumsi 267830 unit gas atau 1339,15 gas untuk setiap transaksi. 4.2.1. Mengoptimalkan data panggilan: kontrak cache Disajikan di bawah ini adalah smart contract yang mengimplementasikan cache alamat yang sering digunakan alamat dengan memanfaatkan fakta bahwa penyimpanan dan eksekusi jauh lebih murah sumber daya, bersama dengan kontrak Teman yang menunjukkan penggunaannya. Yang terakhir melacak “teman” dari suatu alamat yang dapat didaftarkan dengan memanggil fungsi addFriend. Jika sebuah alamat telah digunakan minimal satu kali, dapat ditambahkan dengan memanggil addFriendWithCache fungsi: indeks cache adalah bilangan bulat 4-byte sedangkan alamat diwakili oleh 20 byte, jadi ada penghematan 5:1 pada argumen fungsi. Logika yang sama dapat digunakan untuk data lain jenis seperti bilangan bulat atau lebih umum byte. kontrak AlamatCache { pemetaan(alamat => uint32) alamat2 kunci publik; alamat[] kunci2 publik; fungsi cacheWrite(alamat _alamat) pengembalian internal (uint32) { require(key2address.length < type(uint32).max, "AddressCache: cache penuh"); require(address2key[_address] == 0, "AddressCache: alamat sudah di-cache"); // kunci harus dimulai dari 1 karena 0 berarti "tidak ditemukan" kunci uint32 = uint32(alamat kunci2.panjang + 1); alamat2kunci[_alamat] = kunci; key2address.push(_address); kunci kembali; } fungsi cacheRead(uint32 _key) tampilan publik kembali (alamat) { require(_key <= key2address.length && _key > 0, "AddressCache: kunci tidak ditemukan"); kembalikan alamat kunci2[_kunci - 1]; } } Daftar 2: Kontrak cache alamat. kontrak Teman adalah AddressCache { pemetaan(alamat => alamat[]) teman umum; fungsi addFriend(alamat _teman) publik { teman[pesan.pengirim].push(_teman); cacheWrite(_teman); } fungsi addFriendWithCache(uint32 _friendKey) publik { teman[pesan.pengirim].push(cacheRead(_friendKey)); } function getFriends() tampilan publik kembali (alamat[] memori) { kembalikan teman[pesan.pengirim];} } Listing 3: Contoh kontrak yang mewarisi cache alamat. Kontrak tersebut mendukung cache sekitar 4 miliar (232) alamat, dan menambahkan satu byte akan menghasilkan sekitar 1 triliun (240). 4.2.2. Mengoptimalkan penyimpanan: filter Bloom Pada StarkNet ada beberapa teknik untuk meminimalkan penggunaan penyimpanan. Jika tidak perlu menjamin ketersediaan data asli maka cukup untuk menyimpan hash on-chain-nya: ini adalah mekanisme yang digunakan untuk menyimpan data untuk ERC-721 (NFT) [22], yaitu tautan IPFS yang menyelesaikan hash data jika tersedia. Untuk data yang disimpan berkali-kali, dimungkinkan untuk menggunakan pencarian tabel serupa dengan sistem cache yang diperkenalkan untuk Optimism, yang mengharuskan semua nilai disimpan setidaknya sekali. Untuk beberapa aplikasi, menyimpan semua nilai dapat dihindari dengan menggunakan filter Bloom [23, 24, 25], yaitu struktur data probabilistik yang memungkinkan seseorang mengetahui dengan pasti apakah suatu elemen tidak termasuk dalam suatu himpunan tetapi memiliki kemungkinan salah yang kecil namun tidak dapat diabaikan positif. Filter Bloom diinisialisasi sebagai array 𝑚bit di nol. Untuk menambahkan elemen, 𝑘hash berfungsi dengan distribusi acak seragam digunakan, masing-masing memetakan ke sedikit array yang diatur ke 1. Untuk memeriksa apakah suatu elemen termasuk dalam himpunan, kita jalankan fungsi 𝑘hash dan verifikasi bahwa 𝑘bit disetel ke 1. Dalam filter Bloom yang sederhana, tidak ada cara untuk membedakan apakah suatu elemen sebenarnya termasuk dalam himpunan atau merupakan positif palsu, probabilitas yang bertambah seiring dengan bertambahnya angka entri meningkat. Setelah memasukkan 𝑛elemen: P[positif palsu] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 dengan asumsi independensi probabilitas setiap set bit. Jika 𝑛elemen (dengan ukuran sembarang!) adalah diharapkan untuk disertakan dan probabilitas toleransi positif palsu adalah 𝑝, ukuran array dapat dihitung sebagai: 𝑚= −𝑛ln 𝑝 (dalam 2)2 Sedangkan jumlah fungsi hash yang optimal adalah: 𝑘= 𝑚 𝑛ln 2 Jika kita berasumsi untuk memasukkan 1000 elemen dengan toleransi 1%, ukuran array adalah 9585 bit dengan 𝑘= 6, sedangkan untuk toleransi 0.1% menjadi 14377 bit dengan 𝑘= 9. Jika sejuta elemen diharapkan untuk dimasukkan, ukuran array menjadi sekitar 1170 kB untuk 1% dan 1775 kB untuk 0,1%, dengan nilai 𝑘 yang sama, karena hanya bergantung pada 𝑝[26]. Dalam permainan di mana pemain tidak boleh ditugaskan ke lawan yang telah mereka tantang, alih-alih menyimpan daftar lawan masa lalu di penyimpanan untuk setiap pemain, kita dapat menggunakan Bloom menyaring. Risiko tidak menantang beberapa pemain seringkali dapat diterima, dan filter dapat diatur ulang secara berkala.4.3. Ethereum kompatibilitas Keuntungan utama karena kompatibel dengan EVM dan Ethereum adalah penggunaan kembali semua yang tersedia alat. Ethereum smart contracts dapat dipublikasikan di Optimism tanpa modifikasi apa pun atau audit baru. Dompet tetap kompatibel, alat pengembangan dan analisis statis, analisis umum alat, alat pengindeksan, dan oracles. Ethereum dan Soliditas memiliki sejarah panjang yang dipelajari dengan baik kerentanan, seperti serangan masuk kembali, luapan dan arus bawah, pinjaman kilat, dan oracle manipulasi. Oleh karena itu, Optimism mampu memperoleh sejumlah besar nilai dalam waktu singkat waktu. Memilih untuk mengadopsi mesin virtual yang berbeda berarti harus membangun kembali seluruh ekosistem, dengan keuntungan dari kebebasan implementasi yang lebih besar. StarkNet mengimplementasikan akun secara asli abstraksi, yang merupakan mekanisme dimana setiap akun adalah smart contract yang dapat diimplementasikan logika sewenang-wenang asalkan sesuai dengan antarmuka (maka istilah abstraksi): ini memungkinkan penggunaan skema tanda tangan digital yang berbeda, kemampuan untuk mengubah kunci pribadi menggunakan alamat yang sama, atau gunakan multisig. Komunitas Ethereum mengusulkan pengenalan ini mekanisme dengan EIP-2938 pada tahun 2020, tetapi proposal tersebut tetap basi selama lebih dari satu tahun karena pembaruan lainnya telah diberi prioritas lebih [27]. Manfaat penting lainnya yang diperoleh dari kompatibilitas adalah penggunaan kembali klien yang sudah ada: Optimism menggunakan versi geth untuk simpulnya sendiri dengan hanya ∼800 baris perbedaan, yang telah terjadi dikembangkan, diuji, dan dipelihara sejak tahun 2014. Memiliki klien yang kuat sangatlah penting dalam definisinya apa yang diterima valid atau tidak dalam jaringan. Bug dalam penerapan bukti kesalahan sistem dapat menyebabkan bukti yang salah diterima sebagai benar atau bukti yang benar untuk tidak valid blok untuk diterima sebagai salah, membahayakan sistem. Kemungkinan seperti ini serangan dapat dibatasi dengan keragaman klien yang lebih luas: Optimism dapat digunakan kembali selain mendapatkan klien Ethereum lainnya telah dikelola, dan pengembangan klien berbasis Erigon lainnya sedang dilakukan sudah berlangsung. Pada tahun 2016 masalah dalam manajemen memori geth dieksploitasi untuk a Serangan DoS dan garis pertahanan pertama adalah merekomendasikan penggunaan Parity, yang kedua terbanyak klien yang digunakan pada saat itu 5. StarkNet menghadapi masalah yang sama dengan bukti validitas, tetapi klien harus ditulis dari awal dan sistem pembuktiannya jauh lebih kompleks, dan akibatnya itu juga jauh lebih kompleks untuk memastikan kebenarannya.

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.

Kesimpulan

Kesimpulan Rollup adalah solusi paling menjanjikan yang tersedia saat ini untuk memecahkan masalah skalabilitas blockchains yang terdesentralisasi, membuka jalan bagi era blockchains yang modular dibandingkan dengan monolitik blockchains. Pilihan untuk mengembangkan Optimistic Rollup atau Validity Rollup terutama ditampilkan sebagai trade-off antara kompleksitas dan ketangkasan. StarkNet memiliki banyak keunggulan seperti cepat penarikan, ketidakmampuan struktural untuk memiliki transisi negara yang tidak valid, biaya transaksi yang lebih rendah biaya periode pengembangan yang lebih lama dan ketidakcocokan dengan EVM, sedangkan Optimism memiliki memanfaatkan ekonomi jaringan untuk dengan cepat memperoleh pangsa pasar yang besar. Optimism Batuan dasar, bagaimanapun, memiliki desain modular yang memungkinkannya menjadi Validitas 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Rollup di masa mendatang: Cannon saat ini menggunakan minigeth yang dikompilasi ke MIPS sebagai bukti kesalahannya sistem, tetapi arsitektur yang sama dapat digunakan untuk memperoleh rangkaian dan menghasilkan bukti validitas. Mengkompilasi mesin yang kompleks seperti EVM untuk mikroarsitektur menghasilkan cara yang lebih sederhana sirkuit yang tidak perlu dimodifikasi dan diverifikasi ulang jika terjadi peningkatan. RISC Nol adalah a mikroarsitektur yang dapat diverifikasi dengan bukti STARK sudah dalam pengembangan berdasarkan RISC-V yang dapat digunakan untuk tujuan ini sebagai alternatif untuk MIPS [28]. Salah satu aspek yang tidak boleh dianggap remeh adalah kompleksitas dalam memahami cara kerja teknologi bekerja. Kekuatan blockchain tradisional adalah mampu memverifikasi keadaan blockchain tanpa mempercayai entitas pihak ketiga mana pun. Namun, dalam kasus StarkNet, itu benar perlu untuk mempercayai implementasi ketika tidak mungkin untuk memverifikasi berbagai komponen berdasarkan kriptografi dan matematika tingkat lanjut. Hal ini pada awalnya dapat menimbulkan gesekan bagi adopsi teknologi, namun seiring kemajuan alat dan penggunaan bukti integritas di luar bidang blockchain semoga masalah ini dapat teratasi.