Optimism Teknik Dokümantasyonu

Analysis and Comparison between Optimism and StarkNet

بقلم Optimism Collective · 2021

لا تمتلك Optimism ورقةً بيضاءَ تقليديةً. بوصفها rollup تفاؤلياً من الطبقة الثانية لـ Ethereum، يُوثَّق تصميمها ومواصفاتها من خلال الوثائق التقنية ومواصفات OP Stack ومنشورات البحث، بدلاً من ورقة أكاديمية رسمية واحدة.

🇺🇸 English (النص الأصلي)

🇹🇷 Türkçe (الترجمة)

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

Özet

Makale, bir düğümü çalıştırmak için işlem verimi ile donanım gereksinimleri arasındaki dengeyi analiz ederek merkezi olmayan blockchain'lerdeki ölçeklenebilirlik sorununu ele alıyor. Toplamalar, yani zincir dışında yürütülen blokların zincir üzerinde doğrulanmasına yönelik teknolojiler, hata veya geçerlilik kanıtları şeklinde sunulur. İyimser Toplamaları ve Geçerlilik Toplamalarını para çekme süresi, işlem maliyetleri, optimizasyon teknikleri ve Ethereum ekosistemiyle uyumluluk açısından karşılaştırıyoruz. Analizimiz, Optimism Bedrock'un şu anda yaklaşık 20:1'lik bir gaz sıkıştırma oranına sahip olduğunu, StarkNet'nın ise yaklaşık 24:1'lik bir depolama yazma maliyeti sıkıştırma oranına ulaştığını ortaya koyuyor. Ayrıca, önbellek sözleşmelerinin ve Bloom filtrelerinin kullanımı gibi bu oranları daha da optimize etmeye yönelik teknikleri de tartışıyoruz. Sonuç olarak, sonuçlarımız İyimser ve Geçerlilik Toplamaları arasındaki seçimde karmaşıklık ve çeviklik arasındaki dengeyi vurgulamaktadır. Anahtar Kelimeler Blockchain, Ölçeklenebilirlik, Toplama 1. Giriş Blockchain teknolojisi, çeşitli endüstrilerde devrim yaratma potansiyeli nedeniyle büyük ilgi görmüştür. Bununla birlikte, çoğu blockchain ölçeklenebilirlik, merkezi olmayan yönetim ve güvenlik arasında, genellikle Ölçeklenebilirlik Üçlemi olarak adlandırılan bir ödünleşimle karşı karşıya olduğundan, ölçeklenebilirlik büyük bir zorluk olmaya devam etmektedir [1, 2]. Bir blockchain'nin verimini artırmak için basit bir çözüm, blok boyutunu artırmaktır. Ethereum bağlamında bu, bir bloğun tutabileceği maksimum gaz miktarının arttırılması anlamına gelir. Her tam düğümün her bloğun her işlemini doğrulaması gerektiğinden, verim arttıkça donanım gereksinimleri de artar ve bu da ağın daha merkezi hale getirilmesine yol açar. Bitcoin ve Ethereum gibi bazı blockchain'ler, mimari merkeziyetsizliğini en üst düzeye çıkarmak için tasarımlarını optimize ederken, Binance Smart Chain ve Solana gibi diğerleri mümkün olduğu kadar hızlı ve ucuz olacak şekilde tasarlanmıştır. Merkezi olmayan ağlar, ağa katılım için donanım gereksinimlerini azaltmak amacıyla blockchain verimini yapay olarak sınırlandırır. Yıllar geçtikçe Trilemma'ya devlet kanalları [3] ve Plazma [4, 5] gibi bir çözüm bulmak için girişimlerde bulunuldu. Bu çözümler, bazı etkinlikleri zincir dışına taşıma, smart contracts kullanarak zincir içi etkinlikleri zincir dışı etkinliklere bağlama ve DLT 2023: 5th Distributed Ledger Technology Workshop, 25-26 Mayıs 2023, Bologna, İtalya $ [email protected] (L. Donno) https://lucadonnoh.github.io/ doğrulama özelliklerine sahiptir. (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bu makalenin telif hakkı yazarlarına aittir. Creative Commons Lisansı Atıf 4.0 Uluslararası (CC BY 4.0) kapsamında izin verilen kullanıma. CEUR Çalıştay Bildirileri http://ceur-ws.org ISSN 1613-0073 CEUR Çalıştay Bildirileri (CEUR-WS.org) zincir üzerinde, zincir dışında olup bitenler. Ancak hem Plazma hem de durum kanallarının genel smart contracts desteği sınırlıdır. Toplamalar, bloklarını başka bir blockchain (Layer 1 veya L1) üzerinde yayınlayan ve dolayısıyla onun fikir birliğini, veri kullanılabilirliğini ve güvenlik özelliklerini devralan blockchain'lardır (Layer 2 veya L2 olarak adlandırılır). Diğer çözümlerden farklı olarak keyfi hesaplamayı desteklerler. Toplamaların üç ana bileşeni vardır: • Sıralayıcılar: kullanıcılardan Toplama işlemlerini alan ve bunları Layer 1 adresine gönderilen bir blokta birleştiren düğümler. Blok en azından durum kökünden (örneğin Merkle kökü) ve durumu yeniden yapılandırmak ve doğrulamak için gereken verilerden oluşur. Layer 1 şunu tanımlar...

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.

giriiş

Giriş Blockchain teknolojisi, devrim yaratma potansiyeli nedeniyle büyük ilgi gördü çeşitli endüstriler. Ancak çoğu blockchain'nin karşılaştığı gibi ölçeklenebilirlik büyük bir zorluk olmaya devam ediyor ölçeklenebilirlik, merkezi olmayan yönetim ve güvenlik arasında bir değiş-tokuş Ölçeklenebilirlik Üçlemi [1, 2]. blockchain verimini artırmak için önemsiz bir çözüm blok boyutunu artırmak için. Ethereum bağlamında bu, maksimum değerin artırılması anlamına gelir Bir bloğun tutabileceği gaz miktarı. Her tam düğümün her işlemin her işlemini doğrulaması gerektiğinden blok, verim arttıkça donanım gereksinimleri de artar ve bu da daha büyük bir ağın merkezileştirilmesi. Bitcoin ve Ethereum gibi bazı blockchain'ler, mimari merkezsizleşmeyi en üst düzeye çıkaracak şekilde tasarlarken, Binance Smart gibi diğerleri Chain ve Solana mümkün olduğu kadar hızlı ve ucuz olacak şekilde tasarlandı. Merkezi olmayan ağlar donanım gereksinimlerini azaltmak için blockchain verimini yapay olarak sınırlandırın ağa katılın. Yıllar boyunca Trilemma'ya devlet gibi bir çözüm bulmak için girişimlerde bulunuldu. [3] ve Plazma [4, 5] kanalları. Bu çözümler bazı aktiviteleri hareket ettirme özelliğine sahiptir. zincir dışı, smart contracts kullanarak zincir içi aktiviteyi zincir dışı aktiviteye bağlama ve doğrulama DLT 2023: 5. Dağıtılmış Defter Teknolojisi Çalıştayı, 25-26 Mayıs 2023, Bologna, İtalya $ [email protected] (L.Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L.Donno) © 2023 Bu makalenin telif hakkı yazarlarına aittir. Creative Commons Lisansı Atıf 4.0 Uluslararası (CC BY 4.0) kapsamında izin verilen kullanıma. CEUR Atölye Bildiriler http://ceur-ws.org ISSN1613-0073 CEUR Çalıştay Bildirileri (CEUR-WS.org)zincir üzerinde, zincir dışında neler olup bittiğini. Ancak hem Plazma hem de durum kanalları sınırlıdır. genel smart contracts'yi destekliyorlar. Toplamalar, bloklarını başka bir blockchain üzerinde yayınlayan blockchain'lerdir (Layer 2 veya L2 olarak adlandırılır) (Layer 1 veya L1) ve dolayısıyla fikir birliğini, veri kullanılabilirliğini ve güvenlik özelliklerini devralır. Onlar, diğer çözümlerden farklı olarak keyfi hesaplamayı destekler. Toplamaların üç ana bileşeni vardır: • Sıralayıcılar: kullanıcılardan Toplama işlemlerini alan ve bunları bir araya getiren düğümler Layer 1 adresine gönderilen blok. Blok en azından durum kökünden oluşur (örneğin bir Merkle kök) ve durumu yeniden oluşturmak ve doğrulamak için gereken veriler. Layer 1 şunu tanımlar: yayınlanan verilerin sırasını belirleyerek L2'nin kanonik blockchain. • Toplama tam düğümleri: Katmandan Toplama bloklarını alan, işleyen ve doğrulayan düğümler 1 kökün doğru olduğunu doğrulayarak. Bir blok geçersiz işlemler içeriyorsa o zaman atılır; bu, Sıralayıcıların geçersiz bloklar içeren geçerli bloklar oluşturmasını engeller işlemler. • Toplama hafif düğümleri: Toplama bloklarını Layer 1 adresinden alan ancak hesaplama yapmayan düğümler yeni devletin kendisi. Teknikleri kullanarak yeni durum kökünün geçerli olduğunu doğrularlar Arıza veya geçerlilik delilleri gibi. Toplamalar, işlem sayısı arttıkça amortize edilmiş maliyetleri azaltarak ölçeklenebilirlik elde eder. kullanıcı sayısı artıyor. Bunun nedeni, blockchain geçerliliğini sağlamanın maliyetinin alt doğrusal olarak artmasıdır İşlemlerin bireysel olarak doğrulanmasının maliyeti ile ilgili olarak. Toplamalar şunlara göre farklılık gösterir: Hafif düğümlerde işlem yürütmenin geçerliliğini sağladıkları mekanizma: İyimser Toplamalar, Ekonomik bir model ve hata kanıtları ile sağlanırken, Geçerlilik Toplamalar, geçerlilik kanıtları kullanılarak kriptografik olarak sağlanır. Hafif düğümler Layer 1 üzerinde smart contracts olarak uygulanabilir. Kökünü kabul ediyorlar yeni durum ve geçerliliği veya hata kanıtlarını doğrulayın: bu Toplama bu nedenle Akıllı Sözleşme olarak adlandırılır Toplamalar. Işık düğümleri bağımsızsa bunlara Egemen Toplamalar [6] denir. Avantajı Akıllı Sözleşme Toplamasını kullanmak, ikisi arasında güveni en aza indirilmiş bir köprü kurabilmektir blockchains: L2 durumunun geçerliliği L1'e kanıtlandığından, bir işlemler sistemi L2'den L1'e kadar para çekme işlemlerine izin vererek uygulanabilir. Dezavantajı ise maliyetinin yüksek olmasıdır. işlemler L1'deki durumu doğrulamanın maliyetine bağlıdır: temel katman şu şekilde doyurulursa: diğer faaliyetlerde, Toplamadaki işlemlerin maliyeti de artar. Veri ve fikir birliği katmanları sistemin güvenliğini belirleyen katmanlardır. işlemlerin sırasını tanımlar, saldırıları önler ve durumu kanıtlamak için verileri kullanılabilir hale getirir geçerlilik. Bildiri katkısı Bu yazıda, iki yenilikçi olan İyimserlik ve Geçerlilik Toplamalarını inceliyoruz. Optimism Bedrock ve StarkNet gibi dikkate değer uygulamalara odaklanarak Ölçeklenebilirlik Üçlemine yönelik çözümler. Katkılarımız bunların kapsamlı bir karşılaştırmasını içermektedir. çözümler, geri çekilme sürelerinin analizi ve Optimism adresine olası bir saldırı hakkında tartışma Ana kaya. Ayrıca gaz sıkıştırma oranlarını hesaplıyor, uygulamaya özel optimizasyonlar sağlıyor ve Ethereum'den uzaklaşmanın avantaj ve dezavantajlarını sunuyoruz. Sanal Makine (EVM).

Kağıt yapısı Makale şu şekilde düzenlenmiştir. Bölüm 2'de İyimser Toplamalar Optimism Ana Kaya analiz edilerek tanıtıldı. Bölüm 3'te Geçerlilik Toplamaları şu şekilde tanıtılmaktadır: StarkNet analiz ediliyor. Bölüm 4'te iki çözümü karşılaştırıyoruz. Son olarak 5. bölümde çizim yapıyoruz bazı sonuçlar.

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.

İyimser Toplamalar

İyimser Toplamalar Yürütülmelerini doğrulamadan blokların çıktılarını iyimser bir şekilde kabul etme fikri ışık düğümlerini tartışan Bitcoin teknik incelemesi [7]'de zaten mevcuttur. Bu düğümler yalnızca takip eder konsensüs kuralını doğrulayarak başlık zincirini blokları kabul etmeye karşı savunmasız hale getirir %51 saldırısı durumunda geçersiz işlemler içeren. Nakamoto bunu çözmeyi öneriyor Light node'ları bir bloğun geçersiz işlemler içerdiği konusunda uyarmak için bir "uyarı" sistemi kullanarak sorunu çözebilirsiniz. Bu mekanizma ilk olarak Al-Bassam, Sonnino ve Buterin [8] tarafından uygulandı. [9] hata düzeltme kodlarına dayalı kanıt sistemi kullanılır. Oluşturulmasını sağlamak için Hata kanıtlarının sağlanması için geçersiz bloklar da dahil olmak üzere tüm bloklardaki verilerin mevcut olması gerekir. ağ: bu, olasılıksal veriler kullanılarak çözülen Veri Kullanılabilirliği Sorunudur örnekleme mekanizması. İlk İyimser Toplama tasarımı John Adler tarafından sunuldu ve Mikerah Quintyne-Collins, 2019 [10]'de, bloklar başka bir blockchain'de yayınlanıyor bu onların sıralama konusundaki fikir birliğini tanımlar. 2.1. Optimism Ana kaya Bedrock [11], bir Akıllı Sözleşme Toplama olan Optimism'nin en son sürümüdür. Önceki versiyon, Optimistic Virtual Machine (OVM), Solidity'yi kendi içinde derlemek için geçici bir derleyiciye ihtiyaç duyuyordu. kendi bayt kodu: aksine, Bedrock yürütme motoru açısından EVM ile tamamen eşdeğerdir Ethereum Sarı Kağıt spesifikasyonuna [12] uygundur. 2.1.1. Mevduat Kullanıcılar, Ethereum Portalı üzerindeki bir sözleşme aracılığıyla, mevduatTransaction işlevini çağırarak para yatırabilirler. Bir işlem yürütüldüğünde, bir Toplamadaki her düğümün işlemek için dinlediği TransactionDeposited olayı yayılır Mevduat. Yatırılan işlem, L1'den türetilen bir L2 işlemidir. Eğer arayan kişi işlev bir sözleşmedir, adres ona sabit bir değer eklenerek dönüştürülür: bu, L1'deki bir sözleşmenin L2'deki sözleşmeyle aynı adrese ancak farklı koda sahip olduğu saldırılar. Yatırılan bir işlemin L2'ye dahil edilmesi, bir sıralama içindeki spesifikasyonla sağlanır. pencere. Yatırılan işlemler, 0x7E ön ekine sahip yeni bir EIP-2718 uyumlu işlem türü [13]'dir, rlp kodlu alanlar burada: • bytes32 sourceHash: hash, işlemin kaynağını benzersiz şekilde tanımlar. • gelen adres: gönderenin adresi. • adres: alıcının adresi veya yatırılan işlem bir alıcı adresi ise sıfır adres sözleşme oluşturma.• uint256 mint: L2'de oluşturulacak değer. • uint256 değeri: alıcıya gönderilecek değer. • bayt verileri: giriş verileri. • bayt gasLimit: işlemin gas limiti. SourceHash, L1 bloğunun hash keccak256 hash ve L1 günlüğü olarak hesaplanır. Bir bloktaki bir olayı benzersiz şekilde tanımlayan indeks. Yatırılan işlemler L1'de başlatılıp L2'de yürütüldüğünden, sistemin bir L2'de harcanan gaz için L1'e ödeme yapma mekanizması. Çözümlerden biri ETH'yi Portal aracılığıyla göndermektir. ancak bu, her arayanın (dolaylı arayanlar bile) ödenecek olarak işaretlenmesi gerektiği anlamına gelir ve bu mevcut birçok proje için mümkün değildir. Alternatif, karşılık gelen gazı L1'de yakmaktır. Yatırılan işleme tahsis edilen gaza garantili gaz denir. L2 gaz fiyatı L1 otomatik olarak senkronize edilmez ancak EIP-1559'a benzer bir mekanizma kullanılarak tahmin edilir [14]. Ethereum blok başına garanti edilen maksimum gaz miktarı 8 milyondur ve hedef 2 milyon. L2'de gaz için ödeme yapmak için gereken ETH miktarı 𝑐= 𝑔𝑏L2'dir; burada 𝑏L2, L2'de taban ücreti. L1'deki kontrat 𝑐/𝑏L2'ye eşit miktarda gaz yakar. Aramak için harcanan gaz mevduatİşlemi L2'de geri ödenir: eğer bu miktar garanti edilen gazdan fazlaysa, gaz yakılmaz. Bir rollup bloğunun ilk işlemi, kaydolmak için kullanılan, L1 özniteliklerinde yatırılan bir işlemdir L2'de Ethereum bloklarının niteliklerini önceden konuşlandırın. Ön dağıtımın sağladığı özellikler erişim blok numarası, zaman damgası, taban ücreti, hash bloğu ve dizidir ilgili L1 bloğuna (aynı zamanda dönem olarak da adlandırılır) göre L2'nin blok numarası olan sayı; yeni bir dönem başladığında bu sayı sıfırlanır. 2.1.2. Sıralama Toplama düğümleri Optimism zincirini tamamen Ethereum'den türetir. Bu zincir uzatılır L1'de her yeni işlem yayınlandığında ve blokları her seferinde yeniden düzenlenir Ethereum bloklar yeniden düzenlendi. Toplama blockchain dönemlere bölünmüştür. Her biri için Ethereum blok numarasına karşılık gelen bir 𝑛epoch var. Her çağ en az bir tane içerir bloktur ve bir çağdaki her blok, L1 özniteliklerinde yatırılan işlemi içerir. İlk blok bir dönemde Portal aracılığıyla yatırılan tüm işlemleri içerir. Layer 2 bloklar da olabilir sıralı işlemleri, yani doğrudan Sıralayıcıya gönderilen işlemleri içeriyordu. Sıralayıcı, kullanıcılardan gelen işlemleri kabul eder ve bloklar oluşturur. Her blok için oluşturur Ethereum tarihinde yayınlanacak bir grup. Birkaç parti sıkıştırılmış bir şekilde yayınlanabilir, kanal adını alıyor. Çok büyük olması durumunda bir kanal birkaç kareye bölünebilir. tek bir işlem. Kanal, rlp kodlu ZLIB [15] ile sıkıştırma olarak tanımlanır gruplar. Bir grubun alanları dönem numarası, dönem hash, üst öğe hash, zaman damgası ve işlem listesi. Bir dönem tarafından tanımlanan bir sıralama penceresi, ardışık L1'in sabit bir 𝑤 sayısını içerir Değişken sayıda L2 bloğu oluşturmak için bir türetme adımının girdi olarak aldığı bloklar. için çağ 𝑛, sıralama penceresi 𝑛 blokları içerir [𝑛, 𝑛+𝑤). Bu, siparişin verildiği anlamına gelir Bir sıralama penceresi içindeki L2 işlemlerinin ve bloklarının sayısı, pencere bitene kadar sabitlenmez. Bir rollup işlemi, onu içeren parti L1'de onaylandıysa güvenli olarak adlandırılır. ÇerçevelerGrupları yeniden oluşturmak için L1 bloklarından okunur. Mevcut uygulama buna izin vermiyor karşılık gelen tüm çerçeveler alınana kadar kanalın sıkıştırmasını açma işlemi başlatılır. Geçersiz gruplar göz ardı edilir. Partilerden bireysel blok işlemleri elde edilir. yürütme motoru tarafından durum geçişlerini uygulamak ve Toplama durumunu elde etmek için kullanılır. 2.1.3. Para Çekme Para çekme işlemlerini gerçekleştirmek için L2'den L1'e bir mesajlaşma sistemi uygulanır. Ethereum Para çekme işlemlerini kabul etmek için L2'nin durumunu bilmesi gerekir ve bu, yayınlanarak yapılır L2 Çıkışında Oracle smart contract L1'de her L2 bloğunun durum kökü. Bu kökler sırasında herhangi bir arıza tespiti yapılmazsa iyimser bir şekilde geçerli (veya kesinleşmiş) olarak kabul edilir. anlaşmazlık dönemi. Yalnızca Teklif Veren olarak belirlenen adresler çıktı köklerini yayınlayabilir. Geçerlilik Çıktı köklerinin oranı, Teklif Sahiplerinin, eğer yatırılırlarsa kesilecek bir hisse yatırmaları sağlanarak teşvik edilir. geçersiz bir kök önerdiği gösterilmiştir. İşlemler, işlev çağrılarak başlatılır L2'de bir ön konuşlandırmada Withdrawal'ı başlatın ve ardından işlevi çağırarak L1'de sonlandırın Daha önce bahsedilen Optimism Portalında finalizeWithdrawalTransaction. L2 bloğuna karşılık gelen çıkış kökü, L2 Çıkış Oracle'ından elde edilir; öyle kesinleştiğinin, yani anlaşmazlık süresinin geçtiğinin doğrulanması; Çıkışın doğrulandığı doğrulandı Kök Kanıtı, Oracle Kanıtı ile eşleşir; Para çekme işleminin hash numarasının dahil edildiği doğrulandı bir Para Çekme Kanıtı kullanarak; geri çekilmenin henüz tamamlanmadığını; ve sonra Belirlenen gas limiti, Ether miktarı ve verilerle hedef adrese çağrı gerçekleştirilir. 2.1.4. Cannon: hatasız sistem Bir Toplama Tam Düğümü, toplu işlemleri ve yatırılan işlemleri yerel olarak yürüterek şunları keşfederse: Layer 2 durumu, Teklif Sahibi tarafından zincir üzerinde yayınlanan durum köküyle eşleşmiyor, yürütülebilir Blok geçişi sonucunun yanlış olduğunu kanıtlamak için L1'de bir arıza kanıtı. Çünkü ek yük, L1'de bir Toplama bloğunun tamamını işlemek çok pahalıdır. Uygulanan çözüm Bedrock tarafından zincir üzerinde minigeth anlaşmazlığının yalnızca ilk talimatını yürütmek, bunu zincir üstü bir yorumlayıcıda yürütülen ve yayınlanan bir MIPS mimarisine derlemek L1'de. minigeth, geth 1'in basitleştirilmiş bir versiyonudur; burada fikir birliği, RPC ve veritabanı bulunur. kaldırıldı. Anlaşmazlığın ilk talimatını bulmak için etkileşimli bir ikili arama gerçekleştirilir. Arıza kanıtını başlatan ve çıkış kökünü yayınlayan kişi. Kanıt ne zaman başladığında, her iki taraf da MIPS bellek durumunun kökünü yürütme işleminin yarısında yayınlar. Challenge sözleşmesindeki blok: hash eşleşirse bu, her iki tarafın da bu konuda anlaştığı anlamına gelir Uygulamanın ilk yarısı böylece ikinci yarının yarısının kökünü yayınlar, aksi takdirde yarısı ilk yarının yayınlanması vb. Bunu yapmak, ilk anlaşmazlık talimatını yerine getirir orijinal yürütmeye kıyasla logaritmik sayıda adımla. Eğer iki duraktan biri etkileşimli olarak, anlaşmazlık süresinin sonunda diğer katılımcı otomatik olarak kazanır. Talimatı işlemek için MIPS yorumlayıcısının belleğine erişmesi gerekir: kök olduğundan mevcut olması durumunda gerekli hafıza hücrelerinin dahil olduğu kanıtlanarak yayınlanabilecektir. Erişmek için EVM durumu, Preimage Oracle'dan yararlanılır: döndürdüğü bloğun hash değeri verildiğinde 1https://geth.ethereum.org/docs

önceki bloğun hash numarasını alıp geri dönebileceğiniz blok başlığı zincirini kullanın veya ön görüntünün alınabileceği durumun ve günlüklerin hash değerini alın. oracle minigeth tarafından uygulanır ve veritabanının yerini alır. Diğer düğümlere sorgular yapılır ön görüntüleri elde edin.

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)

Geçerlilik Toplamaları

Geçerlilik Toplamaları Geçerlilik Toplamasının amacı, durum geçişinin geçerliliğini kriptografik olarak kanıtlamaktır. alt doğrusal olarak karşılaştırılarak doğrulanabilen kısa bir kanıtla işlem sırası verildiğinde orijinal hesaplamaların yapıldığı zamana kadar. Bu tür sertifikalara hesaplama bütünlüğü kanıtları denir ve pratik olarak aritmetik kullanan SNARK'lar (Succint Non-interactive Argument of Knowledge) ile uygulanır. hesaplamalı modeli olarak devreler. Farklı SNARK uygulamaları kanıtlama süresi açısından farklılık gösterir, doğrulama süresi, güvenilir bir kurulum ihtiyacı ve kuantum direnci [16, 17]. STARK'lar (Ölçeklenebilir Şeffaf Bilgi Argümanı) [18], güvenilir bir ağ gerektirmeyen bir SNARK türüdür. kanıtlama ve doğrulamada verimlilikten biraz ödün verirken kuantum dirençlidir diğer çözümlerle karşılaştırıldığında. 3.1. StarkNet StarkNet, StarkWare tarafından geliştirilen ve STARK kullanan bir Akıllı Sözleşme Geçerlilik Toplamasıdır durumunu Ethereum olarak doğrulamak için kanıt sistemi. Geçerlilik kanıtlarının oluşturulmasını kolaylaştırmak için, Üst düzey dili Kahire olan EVM'den farklı bir sanal makine kullanılıyor. 3.1.1. Mevduat Kullanıcılar, sendMessageToL2'yi arayarak Ethereum adresindeki bir sözleşme aracılığıyla işlem yatırabilirler. işlev. Mesaj, hash değeri hesaplanarak ve bir sayaç artırılarak kaydedilir. Sıralayıcılar LogMessageToL2 olayını dinleyin ve bilgileri bir StarkNet işleminde kodlayın bu, l1_handler dekoratörüne sahip bir sözleşmenin işlevini çağırır. İcranın sonunda, Durum geçişinin kanıtı üretildiğinde, mesajın tüketimi buna eklenir ve sayacı azaltılarak silinir. Yatırılan işlemlerin dahil edilmesi StarkNet spesifikasyonu tarafından gerekli değildir, dolayısıyla bir gaz Sıralayıcıları L2'de yayınlamaya teşvik etmek için pazara ihtiyaç var. Mevcut sürümde, çünkü Sıralayıcı, yatırılan işlemlerin maliyeti olan StarkWare tarafından merkezileştirilir ve yönetilir yalnızca depozito işleminin maliyetine göre belirlenir. Bu maliyet ETH gönderilerek ödenir. sendMessageToL2. Bu Eterler L1'de kilitli kalır ve Sıralayıcıya aktarılır. L1, yatırılan işlem bir durum geçişine dahil edildiğinde. Gönderilen ETH miktarı yatırılan işlem dahildir, tüketilen gaz miktarına bakılmaksızın tamamen harcanır L2'de. StarkNet, L1 blok niteliklerinin otomatik olarak kullanılabilir olmasını sağlayan bir sisteme sahip değildir. Alternatif olarak Fossil, Oiler Network 2 tarafından geliştirilen ve hash verildiğinde izin veren bir protokoldür. blok, ön görüntülerin yayınlanmasıyla Ethereum adresinden elde edilecek her türlü bilgi. 2https://www.oiler.network/3.1.2. Sıralama StarkNet'nin mevcut durumu tamamen Ethereum'den türetilebilir. Herhangi bir durum farkı geçişler arasındaki veriler L1'de çağrı verileri olarak yayınlanır. Farklılıklar her sözleşme için yayınlanır ve aşağıdaki kodlamayla uint256[] olarak kaydedilir: • Sözleşme dağıtımlarıyla ilgili alan sayısı. • Yayınlanan her sözleşme için: – Yayınlanan sözleşmenin adresi. – Yayınlanan sözleşmenin hash numarası. – Sözleşmeyi yapanın argümanlarının sayısı. – Yapıcı argümanlarının listesi • Deposu değiştirilen sözleşme sayısı. • Değiştirilen her sözleşme için: – Değiştirilen sözleşmenin adresi. – Depolama güncellemelerinin sayısı. – Yeni değerlere sahip depolama adreslerinin anahtar/değer çiftleri. Durum farklılıkları sırasıyla yayınlandığı için sırasıyla okunması yeterlidir. devleti yeniden inşa edelim. 3.1.3. Para Çekme L2'den L1'e mesaj göndermek için send_message_to_L1 sistem çağrısı kullanılır. Mesaj şu: hash sayacını kanıtla birlikte artırarak L1'de yayınlandı ve çağrılarak sonlandırıldı. L1'deki StarkGate smart contract üzerindeki consumMessageFromL2 işlevi, bu işlevi azaltır sayaç. Herkes para çekme işlemini tamamlayabilir. 3.1.4. Geçerlilik kanıtları Kahire Sanal Makinesi [19], STARK kanıtlarının oluşturulmasını kolaylaştırmak için tasarlanmıştır. Kahire dili, hesaplamanın üst düzey bir programlamayla tanımlanmasına olanak tanır dil ve doğrudan bir devre olarak değil. Bu, bir polinom denklem sistemi ile gerçekleştirilir. Şekil 3 tek bir hesaplamayı temsil etmektedir: von Neumann mimarisinin FDE döngüsü. Sayı Kısıtlamaların sayısı bu nedenle sabittir ve hesaplama türünden bağımsızdır ve yalnızca bir tanesine izin verir. Hesaplanmasının kanıtlanması gereken her program için doğrulama programı. StarkNet, paylaşılan bir kanıtlayıcı kullanarak birden fazla işlemi tek bir STARK kanıtı halinde toplar SHARP'ın adı. Kanıtlar, geçerliliklerini doğrulayan Ethereum tarihinde smart contract adresine gönderilir. ve yeni duruma karşılık gelen Merkle kökünü günceller. Bir doğrulamanın alt doğrusal maliyeti Geçerlilik kanıtı, maliyetinin birden fazla işlem üzerinden amortismana tabi tutulmasına olanak tanır. 3Cebirsel Ara Gösterim (AIR) olarak adlandırılır

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.

Karşılaştırmak

Karşılaştırma 4.1. Para çekme süresi İyimser Toplamaları Geçerlilik Toplamalarından ayıran en önemli husus, Caymanın başlatılması ile sonuçlanması arasında geçen süre. Her iki durumda da Para çekme işlemleri L2'de başlatılır ve L1'de sonlandırılır. StarkNet tarihinde sonlandırma şu şekilde mümkündür: Yeni durum kökünün geçerlilik kanıtı Ethereum tarihinde kabul edilir edilmez: teorik olarak Başlatmanın ardından L1'in ilk bloğundaki fonları çekmek mümkündür. Uygulamada, Ethereum üzerinde geçerlilik kanıtları gönderme sıklığı, blok hızı arasında bir dengedir sonuçlandırma ve kanıt toplama. Şu anda StarkNet doğrulama için geçerlilik kanıtları sağlıyor her 10 saatte bir 4, ancak işlem aktivitesi arttıkça azaltılması amaçlanıyor. Optimism Bedrock'ta para çekme işlemini yalnızca anlaşmazlığın sonunda sonuçlandırmak mümkündür süre (şu anda 7 gün), bu sürenin sonunda kök otomatik olarak geçerli kabul edilir. uzunluğu bu süre temel olarak hata kanıtlarının Ethereum tarihine kadar sansürlenebileceği gerçeğiyle belirlenir. onun sonu. Bu tür saldırıların başarı olasılığı zaman arttıkça katlanarak azalır: E[çıkarılan değer] = 𝑉𝑝𝑛 burada 𝑛bir aralıktaki blok sayısıdır, 𝑉çıkarılabilecek fon miktarıdır geçersiz bir kök yayınlayarak ve 𝑝 başarılı bir sansür gerçekleştirme olasılığıdır tek blokta saldırın. Bu olasılığın %99 olduğunu, değerin Toplama'da kilitlendiğini varsayalım. bir milyon Ether'dir ve bir aralıktaki bloklar 1800'dür (12 saatlik bloklar ile 6 saatlik bloklar). saniye aralığı): beklenen değer yaklaşık 0,01391 Ether'dir. Sistem şu şekilde güvenli hale getirilmiştir: Teklif Sahiplerinden beklenen değerden çok daha büyük miktarda Ether yatırmalarını istemek. Winzer ve ark. basit bir smart contract kullanarak sansür saldırısının nasıl gerçekleştirileceğini gösterdi bu, durumdaki belirli bellek alanlarının [20] değişmemesini sağlar. Saldırının modellenmesi Bir Markov oyunu olarak makale, sansürün rasyonel bir yaklaşım için baskın strateji olduğunu göstermektedir. değişen işlemin dahil edilmesinden daha fazla tazminat alırlarsa üreticiyi bloke edin hafıza. Yukarıda tartışılan 𝑝değeri rasyonel bloğun yüzdesi olarak görülebilir. ağdaki üreticiler, “rasyonel”in muhtemelen cezalandırmayı hesaba katmadığı durumlarda blockchain'ye olan güvenin azalması gibi dışsallıklar, onun kripto para birimi değerini düşürür. Aşağıdaki kod, sansür saldırısı gerçekleştirmek için kullanılabilecek bir smart contract değerini sunar Bedrock'ta. Saldırı, blok üreticilerine rüşvet teklif ederek teşviklerinden yararlanıyor devletin belirli kısımlarını değiştirecek işlemleri sansürlemek. Sözleşmenin ana ClaimBribe işlevi, blok üreticilerinin başarılı bir şekilde sansürlemeleri halinde rüşveti talep etmelerine olanak tanır Geçersiz çıkış köküne dokunulmadığını kontrol ederek hedeflenen işlemi gerçekleştirin. function requestBribe(bayt bellek depolamaProof) harici { require(!talep edilen[blok.numarası], "rüşvet zaten talep edildi"); OutputProposal bellek akımı = depolamaOracle.getStorage(L2_ORACLE, blok.number, SLOT, depolama Kanıtı); require(invalidOutputRoot == current.outputRoot, "saldırı başarısız oldu"); talep edilen[blok.numarası] = doğru; (bool gönderildi, ) = Block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(gönderildi, "ether gönderilemedi"); } Liste 1: Bedrock'a sansür saldırısını teşvik eden bir sözleşme örneği. Uyuşmazlık süresinin uzunluğu aynı zamanda kusurun kanıtlandığı gerçeğini de dikkate almalıdır. etkileşimli bir kanıttır ve bu nedenle katılımcıların etkileşime girmesi için yeterli zaman sağlanmalıdır ve herhangi bir etkileşimin sansürlenebileceğini. Son hamle çok yakın bir zamanda gerçekleşirse Uyuşmazlık döneminin sonunda sansürün maliyeti önemli ölçüde azalır. Her ne kadar sansür baskın strateji, sansür düğümlerinin saldırıya açık olması nedeniyle başarı olasılığı daha düşüktür Hizmet Reddi saldırıları: Bir saldırgan, aşağıdakilerle biten çok karmaşık işlemler oluşturabilir: Hiçbir ücret ödenmeyeceği için arıza kanıtının ücretsiz olarak yayınlanması. Olağanüstü durumlarda, uzun bir anlaşmazlık süresi, başarılı bir anlaşma durumunda koordinasyona olanak sağlar. Bir çatal düzenlemek ve saldıran blok üreticilerini dışlamak için sansür saldırısı. Başka bir Olası saldırı, ihtilaflı tarafların doğrulayabileceğinden daha fazla durum kök teklifinin yayınlanmasından ibarettir, bir frekans limiti kullanılarak bunun önüne geçilebilir. 4.1.1. Hızlı iyimser para çekme işlemleri İyimser Toplamanın geçerliliği herhangi bir zamanda herhangi bir Tam Düğüm tarafından doğrulanabileceğinden, güvenilir oracle, L1'de para çekme işleminin güvenli bir şekilde tamamlanıp tamamlanmayacağını bilmek için kullanılabilir. Bu mekanizma ilk olarak Maker [21] tarafından önerildi: bir oracle para çekme işlemini doğrular, kullanıcıya otomatik olarak faiz getiren bir kredinin atandığı L1'deki sonuç 7 günün sonunda, yani para çekme işleminin fiilen sonuçlandırılabileceği tarihte kapatılır. Bu çözüm bir güven varsayımı getirir, ancak Maker durumunda bu, oracle operatöründen bu yana en aza indirilmiştir. krediyi sağlayarak riski üstlenen aynı kuruluş tarafından yönetilmektedir. 4.2. İşlem maliyetleri L2 işlemlerinin maliyeti çoğunlukla L1 ile olan etkileşime göre belirlenir. Her iki çözümde İşlemlerin hesaplama maliyeti, tamamen zincir dışında yürütüldüğü için çok ucuz. Optimism L2 işlemleri çağrı verilerini çağrı verileri olarak yayınlar ve nadiren (veya hiçbir zaman) hata yürütmez kanıtlar, bu nedenle çağrı verileri en pahalı kaynaktır. 12 Ocak 2022'de bir Bedrock ağı Ethereum'nin Goerli test ağında başlatıldı. Bir gaz sıkıştırma oranı hesaplanabilir Belli bir periyotta Ana Kaya üzerinde kullanılan gaz miktarını takip ederek ve bunu mevcut gaz miktarı ile karşılaştırarak karşılık gelen bloklar için L1'de harcanan gaz miktarı. Bu yöntemi kullanarak gaz sıkıştırma ∼20 : 1 oranı bulunur, ancak bu rakam ana ağdaki gerçek aktiviteye göre farklılık gösterebilir. StarkNet, L2 durumundaki her değişikliği Ethereum tarihinde çağrı verileri olarak yayınlar, bu nedenle depolama en pahalı kaynak. Ağ EVM kullanmadığından işlem maliyeti sıkıştırma önemsiz bir şekilde tahmin edilemez. Yürütme maliyetini ve çağrı verilerini varsayarak ihmal edilebilir düzeydeyse, depolama yazma işlemlerinin sıkıştırma oranını aşağıdakilerle karşılaştırmalı olarak hesaplamak mümkündür: L1. Hiçbir sözleşmenin dağıtılmadığını ve StarkNet üzerinde daha önce erişilmeyen 10 hücrenin değiştirildiğinde, ∼24 : 1'lik bir depolama yazma maliyeti sıkıştırma oranı bulunur. Bir hücrenin üzerine yazılırsa 𝑛veri yayınları arasında her yazmanın maliyeti, maliyete kıyasla 1/𝑛 olacaktır Yalnızca sonuncusu yayınlandığından tek bir yazma işlemi yapılır. Maliyet daha da azaltılabilirSık kullanılan değerlerin sıkıştırılması. Geçerlilik kanıt doğrulamasının maliyeti aşağıdakiler arasında paylaştırılır: atıfta bulunduğu işlemler: örneğin, StarkNet blok 4779 200 işlem içerir ve geçerlilik kanıtı her işlem için 267830 birim gaz veya 1339,15 gaz tüketir. 4.2.1. Çağrı verilerini optimize etme: önbellek sözleşmesi Aşağıda, sık kullanılanlar için bir adres önbelleği uygulayan bir smart contract gösterilmektedir. depolama ve yürütmenin çok daha ucuz olması gerçeğinden yararlanarak adresler kaynakları ve bunların kullanımını gösteren bir Friends sözleşmesi. İkincisi takip ediyor addFriend işlevi çağrılarak kaydedilebilecek bir adresin "arkadaşları". Eğer bir adres zaten en az bir kez kullanılmışsa, addFriendWithCache çağrılarak eklenebilir işlev: önbellek endeksleri 4 baytlık tamsayılardır, adresler ise 20 baytla temsil edilir, yani fonksiyon argümanında 5:1 oranında tasarruf vardır. Aynı mantık diğer veriler için de kullanılabilir tamsayılar veya daha genel olarak baytlar gibi türler. sözleşme Adres Önbelleği { eşleme(adres => uint32) genel adres2key; adres[] genel anahtar2adres; function önbellekWrite(adres _address) dahili dönüşler (uint32) { require(key2address.length < type(uint32).max, "AddressCache: önbellek dolu"); require(address2key[_address] == 0, "AddressCache: adres zaten önbelleğe alınmış"); // anahtarlar 1'den başlamalıdır çünkü 0 "bulunamadı" anlamına gelir uint32 anahtar = uint32(anahtar2adresi.uzunluk + 1); adres2anahtar[_adres] = anahtar; key2address.push(_address); dönüş anahtarı; } function cacheRead(uint32 _key) genel görünüm şunu döndürür (adres) { require(_key <= key2address.length && _key > 0, "AddressCache: anahtar bulunamadı"); dönüş anahtarı2adresi[_anahtar - 1]; } } Liste 2: Adres önbellek sözleşmesi. sözleşme Arkadaşlar AdresCache'dir { haritalama(adres => adres[]) genel arkadaşlar; function addFriend(adres _friend) public { arkadaşlar[msg.sender].push(_friend); önbellekWrite(_arkadaş); } function addFriendWithCache(uint32 _friendKey) public { arkadaşlar[msg.sender].push(cacheRead(_friendKey)); } function getFriends() genel görünüm şunu döndürür (adres[] belleği) { arkadaşlara geri dönün[msg.sender];} } Liste 3: Adres önbelleğini devralan bir sözleşme örneği. Sözleşme önbellekte yaklaşık 4 milyar (232) adresi destekliyor ve bir bayt eklemek şunu sağlıyor: yaklaşık 1 trilyon (240). 4.2.2. Depolamayı optimize etme: Bloom filtreleri StarkNet üzerinde depolama kullanımını en aza indirmeye yönelik çeşitli teknikler vardır. Eğer gerekli değilse orijinal verilerin kullanılabilirliğini garanti ederse, hash zincirine kaydedilmesi yeterlidir: bu ERC-721 (NFT) [22], yani sorunu çözen bir IPFS bağlantısı için verileri kaydetmek için kullanılan mekanizmadır. Varsa verilerin hash. Birden çok kez saklanan veriler için bir arama kullanmak mümkündür. Optimism için tanıtılan önbelleğe alma sistemine benzer, tüm değerlerin şu adrese kaydedilmesini gerektiren tablo en az bir kez. Bazı uygulamalarda Bloom filtresi kullanılarak tüm değerlerin kaydedilmesi önlenebilir. [23, 24, 25], yani birinin kesin olarak bilmesini sağlayan olasılıksal bir veri yapısı bir öğe bir kümeye ait değildir ancak küçük ama göz ardı edilemeyecek bir yanlış olasılığını kabul eder pozitifler. Bir Bloom filtresi sıfırda 𝑚bit dizisi olarak başlatılır. Bir öğe eklemek için 𝑘hash işlevleri düzgün bir rastgele dağılım kullanılır, her biri belirlenen dizinin bir bitiyle eşleşir 1'e kadar. Bir öğenin kümeye ait olup olmadığını kontrol etmek için 𝑘hash işlevlerini çalıştırırız ve doğrularız. 𝑘bit'lerin 1'e ayarlandığını. Basit bir Bloom filtresinde, bir öğe aslında kümeye aittir veya yanlış pozitiftir; sayı arttıkça artan bir olasılık girişlerin sayısı artıyor. 𝑛 elemanlarını ekledikten sonra: P[yanlış pozitif] = (︃ 1 – [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 her bit kümesinin olasılığından bağımsız olduğu varsayılarak. Eğer 𝑛elemanları (isteğe bağlı boyutta!) dahil edilmesi bekleniyor ve yanlış pozitifin tolere edilme olasılığı 𝑝, dizinin boyutu şu şekilde hesaplanabilir: 𝑚= −𝑛ln 𝑝 (2'de)2 hash işlevlerinin optimum sayısı şu şekildedir: 𝑘= 𝑚 𝑛ln 2 %1 toleransla 1000 eleman eklediğimizi varsayarsak dizinin boyutu 9585 bit olur. 𝑘= 6 ile %0,1 tolerans için 𝑘= 9 ile 14377 bit olur. Bir milyon eleman ise Eklenmesi bekleniyorsa dizinin boyutu %1 için yaklaşık 1170 kB, %1 için ise 1775 kB olur. %0,1, aynı 𝑘 değerleriyle, çünkü yalnızca 𝑝[26]'ye bağlıdır. Oyuncuların daha önce meydan okudukları bir rakibe atanmaması gereken bir oyunda, Her oyuncu için geçmiş rakiplerin listesini depoya kaydetmek yerine Bloom kullanılabilir. filtre. Bazı oyunculara meydan okumama riski genellikle kabul edilebilir ve filtre sıfırlanabilir periyodik olarak.4.3. Ethereum uyumluluk EVM ve Ethereum ile uyumlu olmanın temel avantajı, mevcut tüm uygulamaların yeniden kullanılmasıdır araçlar. Ethereum smart contracts herhangi bir değişiklik yapılmadan Optimism üzerinde yayınlanabilir veya yeni denetimler. Cüzdanlar uyumlu kalır, geliştirme ve statik analiz araçları, genel analiz araçlar, indeksleme araçları ve oracles. Ethereum ve Solidity'nin iyi çalışılmış uzun bir geçmişi var Yeniden giriş saldırıları, taşmalar ve yetersiz akışlar, flaş krediler ve oracle gibi güvenlik açıkları manipülasyonlar. Bu nedenle Optimism kısa sürede büyük miktarda değer yakalayabildi zaman. Farklı bir sanal makineyi benimsemeyi seçmek, tüm ekosistemi yeniden inşa etme zorunluluğu anlamına gelir. daha fazla uygulama özgürlüğü avantajına sahiptir. StarkNet hesabı yerel olarak uyguluyor her hesabın uygulayabildiği bir smart contract olduğu bir mekanizma olan soyutlama bir arayüze uyduğu sürece keyfi mantık (bu nedenle soyutlama terimi): bu, farklı dijital imza şemalarının kullanımı, özel anahtarı kullanarak değiştirme yeteneği aynı adresi kullanın veya çoklu imza kullanın. Ethereum topluluğu bunun tanıtımını önerdi 2020'de EIP-2938 ile mekanizma, ancak teklif bir yıldan fazla bir süredir bayat kaldı diğer güncellemelere daha fazla öncelik verildi [27]. Uyumluluktan elde edilen bir diğer önemli fayda da mevcut istemcilerin yeniden kullanılmasıdır: Optimism Kendi düğümü için geth'in yalnızca ∼800 satırlık farka sahip bir versiyonunu kullanır. 2014'ten bu yana geliştiriliyor, test ediliyor ve bakımı yapılıyor. Güçlü bir müşteriye sahip olmak, tanımlandığı üzere çok önemlidir. ağda neyin geçerli olarak kabul edildiği veya edilmediği. Arıza kanıtlamanın uygulanmasında bir hata Sistem yanlış bir ispatın doğru kabul edilmesine veya doğru bir ispatın geçersiz olmasına neden olabilir. bloğun yanlış kabul edilmesi, sistemi tehlikeye atıyor. Bu tür bir olasılık saldırı daha geniş bir müşteri çeşitliliği ile sınırlandırılabilir: Optimism ayrıca yeniden kullanılabilir diğer Ethereum istemcilerin bakımı zaten yapılıyor ve başka bir Erigon tabanlı istemcinin geliştirilmesi de sürüyor zaten devam ediyor. 2016 yılında geth'in hafıza yönetimindeki bir sorundan yararlanıldı. DoS saldırısı ve ilk savunma hattı, en çok ikinci olan Parity'nin kullanılmasını önermekti. o sırada kullanılan istemci 5. StarkNet geçerlilik kanıtlarıyla aynı sorunla karşı karşıyadır, ancak istemciler sıfırdan yazılması gerekir ve ispat sistemi çok daha karmaşıktır ve dolayısıyla doğruluğu sağlamak da çok daha karmaşıktır.

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.

Çözüm

Sonuç Toplamalar, ölçeklenebilirlik sorununu çözmek için günümüzde mevcut olan en umut verici çözümdür. merkezi olmayan blockchain'ler, modüler blockchain'lerin aksine modüler blockchain'lerin yolunu açıyor yekpare blockchains. İyimser Toplama veya Geçerlilik Toplama geliştirme seçeneği temel olarak gösterilmektedir karmaşıklık ve çeviklik arasında bir denge olarak. StarkNet hızlı gibi çok sayıda avantaja sahiptir para çekme işlemleri, geçersiz durum geçişlerine sahip olunmaması, yapısal olarak yetersizlik, daha düşük işlem maliyeti daha uzun bir geliştirme süresi ve EVM ile uyumsuzluk nedeniyle, Optimism ise hızla pazardan büyük bir pay elde etmek için ağ ekonomisinden yararlandı. Optimism Ancak Bedrock, Geçerlilik haline gelmesini sağlayan modüler bir tasarıma sahiptir. 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Gelecekteki toplama: Cannon şu anda hata koruması için MIPS'ye derlenmiş minigeth kullanıyor Sistem, ancak aynı mimari bir devre elde etmek ve geçerlilik kanıtları üretmek için kullanılabilir. EVM gibi karmaşık bir makinenin bir mikro mimari için derlenmesi daha basit bir sonuç verir. Yükseltme durumunda değiştirilmesine ve yeniden doğrulanmasına gerek olmayan devre. RISC Sıfır bir RISC-V temel alınarak halihazırda geliştirilmekte olan STARK kanıtlarına sahip doğrulanabilir mikro mimari bu amaçla MIPS [28]'ye alternatif olarak kullanılabilir. Göz ardı edilmemesi gereken bir husus, teknoloji çalışıyor. Geleneksel blockchain'lerin güçlü yanı, durumunu doğrulayabilmesidir. blockchain hiçbir üçüncü taraf varlığına güvenmeden. Ancak StarkNet durumunda, Çeşitli bileşenleri doğrulamak mümkün olmadığında uygulamaya güvenmek gerekir kriptografiye ve ileri matematiğe dayalıdır. Bu başlangıçta sürtünme yaratabilir. teknolojinin benimsenmesi, ancak araçlar ve dürüstlük kanıtlarının kullanımı ilerledikçe blockchain alanının dışında bu sorunun çözüleceğini umuyoruz.