Tài liệu kỹ thuật Optimism

Analysis and Comparison between Optimism and StarkNet

Oleh Optimism Collective · 2021

Optimism tidak memiliki whitepaper tradisional. Sebagai optimistic rollup Ethereum Layer 2, desain dan spesifikasinya didokumentasikan melalui dokumentasi teknis, spesifikasi OP Stack, dan postingan riset, bukan satu makalah akademik formal tunggal.

🇺🇸 English (Asli)

🇻🇳 Tiếng Việt (Terjemahan)

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

Tóm tắt

Bài viết giải quyết vấn đề về khả năng mở rộng trong blockchain phi tập trung bằng cách phân tích sự cân bằng giữa thông lượng giao dịch và yêu cầu phần cứng để chạy một nút. Bản tổng hợp, tức là các công nghệ để xác minh trên chuỗi các khối được thực hiện ngoài chuỗi, được trình bày dưới dạng bằng chứng lỗi hoặc tính hợp lệ. Chúng tôi so sánh Tổng hợp lạc quan và Tổng hợp hợp lệ về thời gian rút tiền, chi phí giao dịch, kỹ thuật tối ưu hóa và khả năng tương thích với hệ sinh thái Ethereum. Phân tích của chúng tôi cho thấy rằng Optimism Bedrock hiện có tốc độ nén khí xấp xỉ 20:1, trong khi StarkNet đạt được tốc độ nén chi phí ghi lưu trữ vào khoảng 24:1. Chúng tôi cũng thảo luận về các kỹ thuật để tối ưu hóa hơn nữa các tỷ lệ này, chẳng hạn như việc sử dụng hợp đồng bộ đệm và bộ lọc Bloom. Cuối cùng, kết luận của chúng tôi nêu bật sự cân bằng giữa độ phức tạp và tính linh hoạt trong việc lựa chọn giữa Tổng hợp lạc quan và hợp lệ. Từ khóa Blockchain, Khả năng mở rộng, Rollup 1. Giới thiệu Công nghệ Blockchain đã thu hút được sự chú ý đáng kể nhờ tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn, vì hầu hết blockchain phải đối mặt với sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Bộ ba bất khả thi về khả năng mở rộng [1, 2]. Để tăng thông lượng của blockchain, một giải pháp đơn giản là tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng lượng gas tối đa mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối nên khi thông lượng tăng lên, các yêu cầu về phần cứng cũng tăng lên, dẫn đến tính tập trung cao hơn của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa thiết kế của họ để tối đa hóa khả năng phân cấp kiến trúc của họ, trong khi những blockchain khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn một cách giả tạo thông lượng của blockchain để giảm yêu cầu phần cứng để tham gia vào mạng. Trong những năm qua, nhiều nỗ lực đã được thực hiện để tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như các kênh trạng thái [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là chuyển một số hoạt động ra khỏi chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng cách sử dụng smart contracts và xác minh DLT 2023: Hội thảo công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền bài viết này thuộc về các tác giả. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). Kỷ yếu hội thảo CEUR http://ceur-ws.org ISSN 1613-0073 Kỷ yếu hội thảo CEUR (CEUR-WS.org) trên chuỗi những gì đang diễn ra ngoài chuỗi. Tuy nhiên, cả kênh Plasma và kênh trạng thái đều bị hạn chế trong việc hỗ trợ smart contract chung. Các bản tổng hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain (Layer 1 hoặc L1) khác và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Chúng, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Tập hợp có ba thành phần chính: • Trình sắp xếp thứ tự: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: gốc Merkle) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 định nghĩa...

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.

Giới thiệu

Giới thiệu Công nghệ chuỗi khối đã thu hút được sự chú ý đáng kể do tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn vì hầu hết blockchain đều gặp phải sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Khả năng mở rộng Trilemma [1, 2]. Để tăng thông lượng của blockchain, một giải pháp tầm thường là để tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng mức tối đa lượng khí mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối, khi thông lượng tăng lên thì các yêu cầu về phần cứng cũng tăng lên, dẫn đến yêu cầu lớn hơn tập trung của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa được thiết kế để tối đa hóa khả năng phân cấp kiến trúc của họ, trong khi những nền tảng khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn thông lượng của blockchain một cách giả tạo để hạ thấp yêu cầu phần cứng xuống tham gia vào mạng lưới. Trong những năm qua, người ta đã nỗ lực tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như nhà nước kênh [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là di chuyển một số hoạt động ngoài chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng smart contracts và xác minh DLT 2023: Hội thảo Công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền của bài viết này thuộc về tác giả của nó. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). CEUR Xưởng Thủ tục tố tụng http://ceur-ws.org ISSN 1613-0073 Kỷ yếu Hội thảo CEUR (CEUR-WS.org)trên chuỗi những gì đang xảy ra ngoài chuỗi. Tuy nhiên, cả hai kênh Plasma và trạng thái đều bị hạn chế về sự ủng hộ của họ đối với smart contracts chung. Các tập hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain khác (Layer 1 hoặc L1) và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Họ, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Bản tổng hợp có ba thành phần chính: • Trình sắp xếp: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: Merkle root) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 xác định chính tắc blockchain của L2 bằng cách thiết lập thứ tự của dữ liệu được xuất bản. • Nút cuộn đầy đủ: các nút lấy, xử lý và xác thực các khối Rollup từ Lớp 1 bằng cách xác minh rằng gốc là chính xác. Nếu một khối chứa các giao dịch không hợp lệ thì đó là bị loại bỏ, điều này ngăn cản Trình sắp xếp chuỗi tạo các khối hợp lệ bao gồm các khối không hợp lệ giao dịch. • Nút ánh sáng cuộn lên: các nút nhận khối cuộn lên từ Layer 1 nhưng không tính toán bản thân nhà nước mới. Họ xác minh rằng gốc trạng thái mới là hợp lệ bằng cách sử dụng các kỹ thuật chẳng hạn như bằng chứng lỗi hoặc tính hợp lệ. Bản tổng hợp đạt được khả năng mở rộng bằng cách giảm chi phí phân bổ của các giao dịch theo số lượng của người dùng tăng lên. Điều này là do chi phí đảm bảo tính hợp lệ của blockchain tăng tuyến tính liên quan đến chi phí xác minh các giao dịch riêng lẻ. Các bản cuộn khác nhau tùy theo cơ chế đảm bảo tính hợp lệ của việc thực hiện giao dịch tại các nút nhẹ: trong Optimistic Rollups nó được đảm bảo bởi một mô hình kinh tế và bằng chứng lỗi, trong khi Hiệu lực Rollups nó được đảm bảo bằng mật mã bằng cách sử dụng bằng chứng hợp lệ. Các nút ánh sáng có thể được triển khai dưới dạng smart contract trên Layer 1. Họ chấp nhận gốc rễ của trạng thái mới và xác minh tính hợp lệ hoặc bằng chứng lỗi: do đó, các bản tổng hợp này được gọi là Hợp đồng thông minh Bản cuộn. Nếu các nút nhẹ độc lập thì chúng được gọi là Bản tổng hợp có chủ quyền [6]. Ưu điểm của sử dụng Hợp đồng thông minh Rollup là để có thể xây dựng một cầu nối giảm thiểu sự tin cậy giữa hai bên blockchains: vì tính hợp lệ của trạng thái L2 được chứng minh cho L1, nên một hệ thống giao dịch từ L2 đến L1 có thể được thực hiện, cho phép rút tiền. Nhược điểm là chi phí của giao dịch phụ thuộc vào chi phí xác minh trạng thái trên L1: nếu lớp cơ sở bị bão hòa bởi các hoạt động khác, chi phí giao dịch trên Rollup cũng tăng lên. Các lớp dữ liệu và đồng thuận là những lớp quyết định tính bảo mật của hệ thống như họ xác định thứ tự của các giao dịch, ngăn chặn các cuộc tấn công và cung cấp dữ liệu để chứng minh trạng thái hiệu lực. Đóng góp giấy tờ Trong bài viết này, chúng tôi nghiên cứu Tổng hợp lạc quan và hợp lệ, hai cải tiến giải pháp cho Bộ ba bất khả thi về khả năng mở rộng, tập trung vào các triển khai đáng chú ý, chẳng hạn như Optimism Bedrock và StarkNet. Những đóng góp của chúng tôi bao gồm sự so sánh toàn diện về những giải pháp, phân tích thời gian rút tiền và thảo luận về cuộc tấn công có thể xảy ra vào Optimism Đá nền. Ngoài ra, chúng tôi tính toán tỷ lệ nén khí của chúng, cung cấp các tối ưu hóa dành riêng cho ứng dụng và trình bày những ưu điểm cũng như nhược điểm của việc loại bỏ Ethereum Máy ảo (EVM).

Cấu trúc giấy Bài viết được tổ chức như sau. Trong phần 2 Bản tổng hợp lạc quan là được giới thiệu bằng cách phân tích Optimism Bedrock. Trong phần 3 Bản tổng hợp hợp lệ được giới thiệu bởi phân tích StarkNet. Trong phần 4 chúng ta so sánh hai giải pháp. Cuối cùng, trong phần 5 chúng ta vẽ một số kết luận.

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.

Tổng hợp lạc quan

Bản tổng hợp lạc quan Ý tưởng chấp nhận một cách lạc quan đầu ra của các khối mà không cần xác minh việc thực hiện chúng là đã có mặt trong báo cáo chính thức Bitcoin [7], thảo luận về các nút ánh sáng. Các nút này chỉ theo sau chuỗi tiêu đề bằng cách xác minh quy tắc đồng thuận, khiến chúng dễ bị chấp nhận khối chứa các giao dịch không hợp lệ trong trường hợp bị tấn công 51%. Nakamoto đề xuất giải quyết việc này vấn đề bằng cách sử dụng hệ thống “cảnh báo” để cảnh báo các nút ánh sáng rằng một khối chứa các giao dịch không hợp lệ. Cơ chế này lần đầu tiên được thực hiện bởi Al-Bassam, Sonnino và Buterin [8] trong đó có lỗi hệ thống bằng chứng dựa trên mã sửa lỗi [9] được sử dụng. Để có thể tạo điều kiện cho bằng chứng lỗi, điều cần thiết là dữ liệu từ tất cả các khối, bao gồm cả các khối không hợp lệ, có sẵn để mạng: đây là Vấn đề về tính khả dụng của dữ liệu, được giải quyết bằng cách sử dụng dữ liệu xác suất cơ chế lấy mẫu Thiết kế Optimistic Rollup đầu tiên được trình bày bởi John Adler và Mikerah Quintyne-Collins vào năm 2019 [10], trong đó các khối được xuất bản trên blockchain khác điều đó xác định sự đồng thuận của họ về việc đặt hàng. 2.1. Optimism Đá gốc Bedrock [11] là phiên bản mới nhất của Optimism, một Bản tổng hợp hợp đồng thông minh. Phiên bản trước, Máy ảo Optimistic (OVM) yêu cầu một trình biên dịch đặc biệt để biên dịch Solidity thành mã byte riêng: ngược lại, Bedrock hoàn toàn tương đương với EVM ở chỗ công cụ thực thi tuân theo thông số kỹ thuật của Giấy vàng Ethereum [12]. 2.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch thông qua hợp đồng trên Ethereum, Cổng thông tin Optimism bằng cách gọi hàm DepositTransaction. Khi một giao dịch được thực hiện, một Sự kiện TransactionDeposited được phát ra, mỗi nút trong Rollup sẽ lắng nghe để xử lý tiền gửi. Giao dịch ký gửi là giao dịch L2 có nguồn gốc từ L1. Nếu người gọi của là một hợp đồng, địa chỉ được chuyển đổi bằng cách thêm một giá trị không đổi vào nó: điều này ngăn cản các cuộc tấn công trong đó hợp đồng trên L1 có cùng địa chỉ với hợp đồng trên L2 nhưng có mã khác. Việc đưa vào L2 của giao dịch gửi tiền được đảm bảo bằng thông số kỹ thuật trong trình tự cửa sổ. Giao dịch đã gửi là loại giao dịch tương thích EIP-2718 mới [13] với tiền tố 0x7E, trong đó các trường được mã hóa rlp là: • byte32 sourceHash: hash xác định duy nhất nguồn của giao dịch. • địa chỉ từ: địa chỉ của người gửi. • địa chỉ tới: địa chỉ người nhận hoặc địa chỉ 0 nếu giao dịch gửi tiền là việc tạo hợp đồng.• uint256 mint: giá trị được tạo trên L2. • Giá trị uint256: giá trị được gửi tới người nhận. • dữ liệu byte: dữ liệu đầu vào. • byte gasLimit: giới hạn gas của giao dịch. sourceHash được tính là keccak256 hash của khối L1 hash và nhật ký L1 chỉ mục, xác định duy nhất một sự kiện trong một khối. Vì các giao dịch ký gửi được bắt đầu trên L1 nhưng được thực hiện trên L2 nên hệ thống cần có cơ chế thanh toán L1 cho lượng gas sử dụng cho L2. Một giải pháp là gửi ETH qua Cổng thông tin, nhưng điều này ngụ ý rằng mọi người gọi (ngay cả những người gọi gián tiếp) đều phải được đánh dấu là phải trả tiền và đây là không thể thực hiện được đối với nhiều dự án hiện có. Cách khác là đốt khí tương ứng trên L1. Gas 𝑔được phân bổ cho giao dịch ký gửi được gọi là gas được đảm bảo. Giá khí L2 trên L1 không được đồng bộ hóa tự động mà được ước tính bằng cơ chế tương tự như EIP-1559 [14]. Lượng gas tối đa được đảm bảo cho mỗi khối Ethereum là 8 triệu, với mục tiêu là 2 triệu. Số lượng 𝑐 ETH cần thiết để thanh toán gas trên L2 là 𝑐= 𝑔𝑏L2 trong đó 𝑏L2 là phí cơ bản trên L2. Hợp đồng trên L1 đốt cháy một lượng khí bằng 𝑐/𝑏L2. Gas dành để gọi Giao dịch gửi tiền được hoàn trả trên L2: nếu số tiền này lớn hơn lượng gas được đảm bảo, không có khí đốt. Giao dịch đầu tiên của khối rollup là giao dịch ký gửi thuộc tính L1, được sử dụng để đăng ký trên L2 triển khai trước các thuộc tính của khối Ethereum. Các thuộc tính mà predeploy cung cấp quyền truy cập là số khối, dấu thời gian, phí cơ sở, khối hash và trình tự số, là số khối của L2 so với khối L1 được liên kết (còn gọi là epoch); con số này được đặt lại khi một kỷ nguyên mới bắt đầu. 2.1.2. Trình tự Các nút Tổng hợp lấy chuỗi Optimism hoàn toàn từ Ethereum. Chuỗi này được mở rộng mỗi khi giao dịch mới được xuất bản trên L1 và các khối của nó được tổ chức lại mỗi lần Ethereum khối được tổ chức lại. Bản tổng hợp blockchain được chia thành các kỷ nguyên. Đối với mỗi 𝑛 số khối của Ethereum thì có 𝑛epoch tương ứng. Mỗi kỷ nguyên chứa ít nhất một khối và mỗi khối trong một kỷ nguyên chứa một giao dịch được ký gửi thuộc tính L1. Khối đầu tiên trong một kỷ nguyên chứa tất cả các giao dịch được gửi qua Cổng thông tin. Layer 2 khối cũng có thể chứa các giao dịch được sắp xếp theo trình tự, tức là các giao dịch được gửi trực tiếp đến Bộ sắp xếp thứ tự. Trình sắp xếp chuỗi chấp nhận các giao dịch từ người dùng và xây dựng các khối. Với mỗi khối, nó xây dựng một đợt sẽ được xuất bản vào Ethereum. Một số lô có thể được xuất bản theo cách nén, lấy tên kênh. Một kênh có thể được chia thành nhiều khung, trong trường hợp nó quá lớn để một giao dịch duy nhất. Một kênh được định nghĩa là nén với ZLIB [15] của mã hóa rlp lô. Các trường của một lô là số kỷ nguyên, kỷ nguyên hash, kỷ nguyên gốc hash, kỷ nguyên dấu thời gian và danh sách giao dịch. Cửa sổ tuần tự, được xác định bằng một kỷ nguyên, chứa số cố định 𝑤 của L1 liên tiếp các khối mà bước phái sinh lấy làm đầu vào để xây dựng số lượng khối L2 thay đổi. cho kỷ nguyên 𝑛, cửa sổ tuần tự 𝑛bao gồm các khối [𝑛, 𝑛+𝑤). Điều này ngụ ý rằng việc đặt hàng các giao dịch và khối L2 trong cửa sổ tuần tự không được cố định cho đến khi cửa sổ kết thúc. Giao dịch rollup được gọi là an toàn nếu lô chứa nó đã được xác nhận trên L1. Khungđược đọc từ các khối L1 để xây dựng lại các lô. Việc triển khai hiện tại không cho phép quá trình giải nén kênh bắt đầu cho đến khi nhận được tất cả các khung tương ứng. không hợp lệ lô được bỏ qua. Các giao dịch khối riêng lẻ được lấy từ các đợt, được được công cụ thực thi sử dụng để áp dụng các chuyển đổi trạng thái và thu được trạng thái Tổng hợp. 2.1.3. Rút tiền Để xử lý việc rút tiền, hệ thống nhắn tin L2-to-L1 được triển khai. Ethereum cần biết trạng thái L2 để chấp nhận rút tiền và điều này được thực hiện bằng cách xuất bản trên L2 Đầu ra Oracle smart contract trên L1 gốc trạng thái của mỗi khối L2. Những rễ này được chấp nhận một cách lạc quan là hợp lệ (hoặc đã hoàn thiện) nếu không có bằng chứng lỗi nào được thực hiện trong quá trình thời gian tranh chấp. Chỉ những địa chỉ được chỉ định là Người đề xuất mới có thể xuất bản các gốc đầu ra. Hiệu lực nguồn gốc đầu ra được khuyến khích bằng cách yêu cầu Người đề xuất đặt cọc một khoản tiền sẽ bị cắt giảm nếu họ cho thấy đã đề xuất một gốc không hợp lệ. Giao dịch được bắt đầu bằng cách gọi hàm bắt đầu Rút tiền khi triển khai trước trên L2 và sau đó hoàn tất trên L1 bằng cách gọi hàm FinalizeWithdrawalTransaction trên Cổng thông tin Optimism đã đề cập trước đó. Gốc đầu ra tương ứng với khối L2 được lấy từ L2 Output Oracle; nó là xác minh rằng nó đã được hoàn tất, tức là thời gian tranh chấp đã trôi qua; nó được xác minh rằng đầu ra Bằng chứng gốc khớp với Bằng chứng của Oracle; đã xác minh rằng đã bao gồm hash số tiền rút trong đó sử dụng Bằng chứng rút tiền; việc rút tiền vẫn chưa được hoàn tất; và sau đó là cuộc gọi đến địa chỉ đích được thực hiện, với giới hạn gas, lượng Ether và dữ liệu được chỉ định. 2.1.4. Cannon: hệ thống chống lỗi Nếu một Rollup Full Node, bằng cách thực hiện cục bộ các lô và giao dịch được gửi, phát hiện ra rằng trạng thái Layer 2 không khớp với gốc trạng thái được Người đề xuất xuất bản trên chuỗi, nó có thể thực thi bằng chứng lỗi trên L1 để chứng minh rằng kết quả của quá trình chuyển khối là không chính xác. Bởi vì chi phí chung, việc xử lý toàn bộ khối Rollup trên L1 là quá tốn kém. Giải pháp đã thực hiện của Bedrock chỉ thực hiện trên chuỗi chỉ dẫn đầu tiên về sự bất đồng của minigeth, biên dịch nó thành kiến trúc MIPS được thực thi trên trình thông dịch trực tuyến và được xuất bản trên L1. minigeth là phiên bản đơn giản của geth 1 trong đó sự đồng thuận, RPC và cơ sở dữ liệu đã được gỡ bỏ. Để tìm hướng dẫn đầu tiên về sự bất đồng, tìm kiếm nhị phân tương tác được tiến hành giữa người khởi xướng bằng chứng lỗi và người xuất bản gốc đầu ra. Khi bằng chứng bắt đầu, cả hai bên xuất bản gốc của trạng thái bộ nhớ MIPS trong quá trình thực thi khối trong hợp đồng Thử thách: nếu hash khớp thì có nghĩa là cả hai bên đều đồng ý về nửa đầu của quá trình thực hiện do đó xuất bản phần gốc của nửa sau, nếu không thì nửa của nửa đầu được xuất bản, v.v. Làm như vậy đạt được chỉ dẫn đầu tiên về sự bất đồng theo số bước logarit so với lần thực hiện ban đầu. Nếu một trong hai điểm dừng tương tác, khi kết thúc thời gian tranh chấp, người tham gia kia sẽ tự động thắng. Để xử lý hướng dẫn, trình thông dịch MIPS cần truy cập vào bộ nhớ của nó: vì gốc là sẵn có, các ô nhớ cần thiết có thể được xuất bản bằng cách chứng minh sự bao gồm của chúng. Để truy cập trạng thái của EVM, việc sử dụng được tạo ra từ Preimage Oracle: đưa ra hash của một khối mà nó trả về 1https://geth.ethereum.org/docs

tiêu đề khối, từ đó người ta có thể lấy hash của khối trước đó và quay lại chuỗi hoặc lấy hash trạng thái và nhật ký mà từ đó người ta có thể lấy tiền ảnh. oracle được minigeth triển khai và thay thế cơ sở dữ liệu. Các truy vấn được thực hiện tới các nút khác để có được những hình ảnh tiền đề.

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)

Bản tổng hợp hiệu lực

Bản tổng hợp hiệu lực Mục tiêu của Tổng hợp tính hợp lệ là để chứng minh tính hợp lệ của quá trình chuyển đổi trạng thái bằng mật mã đưa ra chuỗi các giao dịch với bằng chứng ngắn có thể được xác minh dưới dạng so sánh tuyến tính đến thời điểm tính toán ban đầu. Các loại chứng chỉ này được gọi là bằng chứng toàn vẹn tính toán và được triển khai trên thực tế với SNARK (ARgument of Knowledge không tương tác ngắn gọn), sử dụng số học mạch làm mô hình tính toán của chúng. Việc triển khai SNARK khác nhau sẽ khác nhau về thời gian chứng minh, thời gian xác minh, nhu cầu thiết lập đáng tin cậy và khả năng kháng lượng tử [16, 17]. STARK (Có thể mở rộng Đối số kiến thức minh bạch) [18] là một loại SNARK không yêu cầu độ tin cậy thiết lập và có khả năng chống lượng tử, đồng thời mang lại một số hiệu quả trong việc chứng minh và xác minh so với các giải pháp khác. 3.1. StarkNet StarkNet là Bản tổng hợp hiệu lực hợp đồng thông minh được phát triển bởi StarkWare sử dụng STARK hệ thống bằng chứng để xác thực trạng thái của nó thành Ethereum. Để tạo thuận lợi cho việc xây dựng các bằng chứng có giá trị, một máy ảo khác với EVM được sử dụng, có ngôn ngữ cấp cao là Cairo. 3.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch qua hợp đồng vào Ethereum bằng cách gọi sendMessageToL2 chức năng. Thông báo được ghi lại bằng cách tính hash của nó và tăng bộ đếm. Trình sắp xếp chuỗi lắng nghe sự kiện LogMessageToL2 và mã hóa thông tin trong giao dịch StarkNet gọi một hàm của hợp đồng có trang trí l1_handler. Khi kết thúc quá trình thực hiện, khi bằng chứng về sự chuyển đổi trạng thái được tạo ra, việc tiêu thụ tin nhắn sẽ được đính kèm với nó và nó bị xóa bằng cách giảm bộ đếm của nó. Thông số kỹ thuật StarkNet không yêu cầu bao gồm các giao dịch ký gửi, do đó, gas cần có thị trường để khuyến khích Người sắp xếp chuỗi xuất bản chúng trên L2. Ở phiên bản hiện tại, vì Sequencer được tập trung và quản lý bởi StarkWare, chi phí của các giao dịch ký gửi chỉ được xác định bởi chi phí thực hiện khoản tiền gửi. Chi phí này được thanh toán bằng cách gửi ETH tới gửiMessageToL2. Các Ether này vẫn bị khóa trên L1 và được chuyển đến Bộ sắp xếp chuỗi vào ngày L1, khi giao dịch gửi tiền được đưa vào quá trình chuyển đổi trạng thái. Số lượng ETH được gửi, nếu giao dịch gửi tiền được bao gồm, được chi tiêu đầy đủ, bất kể lượng gas tiêu thụ trên L2. StarkNet không có hệ thống tự động cung cấp các thuộc tính khối L1. Ngoài ra, Fossil là một giao thức được phát triển bởi Oiler Network 2 cho phép, với hash của một chặn, mọi thông tin có được từ Ethereum bằng cách xuất bản các hình ảnh đầu tiên. 2https://www.oiler.network/3.1.2. Trình tự Trạng thái hiện tại của StarkNet có thể được bắt nguồn hoàn toàn từ Ethereum. Bất kỳ sự khác biệt trạng thái giữa các lần chuyển đổi được xuất bản trên L1 dưới dạng calldata. Sự khác biệt được công bố cho từng hợp đồng và được lưu dưới dạng uint256[] với mã hóa sau: • Số lĩnh vực liên quan đến triển khai hợp đồng. • Đối với từng hợp đồng được công bố: – Địa chỉ hợp đồng được công bố. – hash của hợp đồng đã công bố. – Số lượng đối số của người xây dựng hợp đồng. – Danh sách các đối số của hàm tạo • Số hợp đồng đã được sửa đổi lưu trữ. • Đối với mỗi hợp đồng được sửa đổi: – Địa chỉ của hợp đồng sửa đổi. – Số lượng cập nhật lưu trữ. – Cặp khóa-giá trị của địa chỉ lưu trữ với các giá trị mới. Sự khác biệt về trạng thái được công bố theo thứ tự, do đó chỉ cần đọc chúng một cách tuần tự là đủ xây dựng lại nhà nước. 3.1.3. Rút tiền Để gửi tin nhắn từ L2 đến L1, syscall send_message_to_L1 được sử dụng. Tin nhắn là được xuất bản lên L1 bằng cách tăng bộ đếm hash của nó cùng với bằng chứng và được hoàn thiện bằng cách gọi hàm tiêu thụMessageFromL2 trên StarkGate smart contract trên L1, hàm này giảm dần quầy. Bất kỳ ai cũng có thể hoàn tất việc rút tiền. 3.1.4. Bằng chứng hiệu lực Máy ảo Cairo [19] được thiết kế để hỗ trợ việc xây dựng các bằng chứng STARK. Ngôn ngữ Cairo cho phép mô tả tính toán bằng chương trình cấp cao ngôn ngữ, và không trực tiếp như một mạch. Điều này được thực hiện bằng hệ phương trình đa thức 3 thể hiện một phép tính đơn lẻ: chu trình FDE của kiến trúc von Neumann. số do đó, các ràng buộc là cố định và độc lập với loại tính toán, chỉ cho phép một Chương trình xác minh cho mọi chương trình có tính toán cần được chứng minh. StarkNet tổng hợp nhiều giao dịch thành một bằng chứng STARK duy nhất bằng cách sử dụng một bằng chứng được chia sẻ có tên là SHARP. Bằng chứng được gửi tới smart contract vào ngày Ethereum để xác minh tính hợp lệ của chúng và cập nhật gốc Merkle tương ứng với trạng thái mới. Chi phí tuyến tính để xác minh một bằng chứng hợp lệ cho phép chi phí của nó được khấu hao qua nhiều giao dịch. 3gọi là Biểu diễn trung gian đại số (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.

So sánh

So sánh 4.1. Thời gian rút tiền Khía cạnh quan trọng nhất giúp phân biệt Bản tổng hợp lạc quan với Bản tổng hợp hợp lệ là thời gian trôi qua kể từ khi bắt đầu rút tiền cho đến khi hoàn tất việc rút tiền. Trong cả hai trường hợp, việc rút tiền được khởi tạo trên L2 và hoàn tất trên L1. Vào StarkNet, việc quyết toán có thể thực hiện được vì ngay khi bằng chứng hợp lệ của gốc trạng thái mới được chấp nhận vào Ethereum: về mặt lý thuyết, đó là có thể rút tiền trong khối đầu tiên của L1 sau khi khởi tạo. Trong thực tế, tần suất gửi bằng chứng hợp lệ trên Ethereum là sự cân bằng giữa tốc độ chặn hoàn thiện và tổng hợp bằng chứng. Hiện StarkNet cung cấp bằng chứng hợp lệ để xác minh cứ sau 10 giờ 4, nhưng nó dự định sẽ giảm khi hoạt động giao dịch tăng lên. Trên Optimism Bedrock, chỉ có thể hoàn tất việc rút tiền khi tranh chấp kết thúc khoảng thời gian (hiện tại là 7 ngày), sau đó root sẽ tự động được coi là hợp lệ. Chiều dài của khoảng thời gian này chủ yếu được xác định bởi thực tế là các bằng chứng lỗi có thể được kiểm duyệt trên Ethereum cho đến khi sự kết thúc của nó. Xác suất thành công của kiểu tấn công này giảm theo cấp số nhân khi thời gian tăng lên: E[giá trị bị trừ] = 𝑉𝑝𝑛 trong đó 𝑛 là số khối trong một khoảng, 𝑉 là số tiền có thể bị trừ bằng cách xuất bản một gốc không hợp lệ và 𝑝là xác suất thực hiện kiểm duyệt thành công tấn công trong một khối duy nhất. Giả sử xác suất này là 99%, giá trị bị khóa trong Rollup là một triệu Ether và số khối trong một khoảng là 1800 (6 giờ khối với 12 giờ khoảng thời gian giây): giá trị dự kiến là khoảng 0,01391 Ether. Hệ thống được đảm bảo an toàn bởi yêu cầu Người đề xuất đặt cược số lượng Ether lớn hơn nhiều so với giá trị dự kiến. Winzer và cộng sự. đã chỉ ra cách thực hiện một cuộc tấn công kiểm duyệt bằng cách sử dụng smart contract đơn giản điều đó đảm bảo rằng các vùng bộ nhớ nhất định ở trạng thái không thay đổi [20]. Mô hình hóa cuộc tấn công như một trò chơi Markov, bài báo cho thấy rằng kiểm duyệt là chiến lược chủ đạo cho một nhà sản xuất khối nếu họ nhận được nhiều tiền bồi thường hơn mức bao gồm giao dịch thay đổi bộ nhớ. Giá trị 𝑝được thảo luận ở trên có thể được xem là phần trăm của khối hợp lý các nhà sản xuất trong mạng lưới, nơi “hợp lý” không tính đến việc có thể bị phạt các yếu tố bên ngoài, chẳng hạn như ít tin tưởng hơn vào blockchain làm giảm giá trị tiền điện tử của nó. Đoạn mã sau trình bày một smart contract có thể được sử dụng để thực hiện một cuộc tấn công kiểm duyệt trên Bedrock. Cuộc tấn công khai thác động cơ của các nhà sản xuất khối bằng cách đưa hối lộ cho họ để kiểm duyệt các giao dịch có thể sửa đổi các phần cụ thể của bang. Hợp đồng chính chức năng, requireBribe, cho phép các nhà sản xuất khối nhận hối lộ nếu họ kiểm duyệt thành công giao dịch được nhắm mục tiêu bằng cách kiểm tra xem gốc đầu ra không hợp lệ không được chạm vào. hàm requireBribe(byte bộ nhớ storageProof) bên ngoài { require(!claimed[block.number], "đã nhận hối lộ"); Dòng điện bộ nhớ đề xuất đầu ra = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, lưu trữProof); require(invalidOutputRoot == current.outputRoot, "tấn công thất bại"); đã xác nhận quyền sở hữu[block.number] = true; (bool đã gửi, ) = block.coinbase.call{value: hối lộAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(đã gửi, "không gửi được ether"); } Liệt kê 1: Ví dụ về một hợp đồng khuyến khích cuộc tấn công kiểm duyệt vào Bedrock. Độ dài của thời gian tranh chấp cũng phải tính đến thực tế là bằng chứng lỗi được bằng chứng tương tác và do đó phải cung cấp đủ thời gian để người tham gia tương tác và mọi tương tác đều có thể bị kiểm duyệt. Nếu nước đi cuối cùng xảy ra vào thời điểm rất gần với khi kết thúc thời gian tranh chấp, chi phí kiểm duyệt sẽ ít hơn đáng kể. Mặc dù kiểm duyệt là chiến lược thống trị, khả năng thành công sẽ thấp hơn vì các nút kiểm duyệt dễ bị tấn công Tấn công từ chối dịch vụ: kẻ tấn công có thể tạo ra các giao dịch rất phức tạp kết thúc bằng công bố bằng chứng lỗi miễn phí vì sẽ không phải trả phí. Trong những trường hợp đặc biệt, thời gian tranh chấp kéo dài cho phép phối hợp trong trường hợp giải quyết thành công. tấn công kiểm duyệt để tổ chức một fork và loại trừ các nhà sản xuất khối tấn công. Khác cuộc tấn công có thể xảy ra bao gồm việc xuất bản nhiều đề xuất gốc cấp bang hơn mức mà các bên tranh chấp có thể xác minh, có thể tránh được bằng cách sử dụng giới hạn tần số. 4.1.1. Rút tiền lạc quan nhanh chóng Vì tính hợp lệ của Tổng hợp lạc quan có thể được xác minh bất kỳ lúc nào bởi bất kỳ Nút đầy đủ nào, nên đáng tin cậy oracle có thể được sử dụng để biết trên L1 liệu việc rút tiền có thể được hoàn tất một cách an toàn hay không. Cái này cơ chế được đề xuất lần đầu tiên bởi Maker [21]: oracle xác minh việc rút tiền, xuất bản kết quả trên L1 trong đó khoản vay chịu lãi được gán cho người dùng, kết quả này được tự động đóng cửa sau 7 ngày, tức là khi việc rút tiền thực sự có thể được hoàn tất. Giải pháp này đưa ra một giả định về độ tin cậy, nhưng trong trường hợp của Maker, nó được giảm thiểu do toán tử oracle được quản lý bởi cùng một tổ chức chịu rủi ro bằng cách cung cấp khoản vay. 4.2. Chi phí giao dịch Chi phí của giao dịch L2 chủ yếu được xác định bởi sự tương tác với L1. Trong cả hai giải pháp chi phí tính toán của các giao dịch rất rẻ vì nó được thực hiện hoàn toàn ngoài chuỗi. Optimism xuất bản dữ liệu cuộc gọi giao dịch L2 dưới dạng dữ liệu cuộc gọi và hiếm khi (hoặc không bao giờ) thực hiện lỗi bằng chứng, do đó calldata là tài nguyên đắt nhất. Vào ngày 12 tháng 1 năm 2022, mạng Bedrock đã được khởi chạy trên mạng thử nghiệm Goerli của Ethereum. Có thể tính được tốc độ nén khí bằng cách theo dõi lượng gas được sử dụng trên Bedrock trong một khoảng thời gian nhất định và bằng cách so sánh nó với lượng gas tiêu tốn cho L1 cho các khối tương ứng. Sử dụng phương pháp này để nén khí tỷ lệ ∼20: 1 được tìm thấy, nhưng con số này có thể khác với hoạt động thực tế trên mạng chính. StarkNet xuất bản trên Ethereum mọi thay đổi ở trạng thái L2 dưới dạng dữ liệu cuộc gọi, do đó dung lượng lưu trữ sẽ bị hạn chế nguồn tài nguyên đắt giá nhất. Vì mạng không sử dụng EVM nên chi phí giao dịch nén không thể được ước tính tầm thường. Bằng cách giả định chi phí thực hiện và lệnh gọi tới không đáng kể, có thể tính được tỷ lệ nén của việc ghi lưu trữ so với L1. Giả sử không có hợp đồng nào được triển khai và 10 ô chưa được truy cập trước đó trên StarkNet được đã sửa đổi, tỷ lệ nén chi phí ghi lưu trữ là ∼24: 1. Nếu một ô bị ghi đè 𝑛lần giữa các lần xuất bản dữ liệu, chi phí cho mỗi lần ghi sẽ là 1/𝑛so với chi phí của một lần viết, vì chỉ có lần cuối cùng được xuất bản. Chi phí có thể được giảm thiểu hơn nữa bằng cáchnén các giá trị được sử dụng thường xuyên. Chi phí xác minh bằng chứng hợp lệ được chia cho các giao dịch mà nó đề cập đến: ví dụ: StarkNet khối 4779 chứa 200 giao dịch và bằng chứng hợp lệ tiêu tốn 267830 đơn vị gas hoặc 1339,15 gas cho mỗi giao dịch. 4.2.1. Tối ưu hóa dữ liệu cuộc gọi: hợp đồng bộ đệm Trình bày bên dưới là smart contract triển khai bộ nhớ đệm địa chỉ cho các địa chỉ được sử dụng thường xuyên địa chỉ bằng cách tận dụng thực tế là việc lưu trữ và thực thi ít tốn kém hơn nhiều tài nguyên, cùng với hợp đồng Bạn bè thể hiện việc sử dụng nó. Cái sau theo dõi “bạn bè” của một địa chỉ có thể được đăng ký bằng cách gọi hàm addFriend. Nếu một địa chỉ đã được sử dụng ít nhất một lần, nó có thể được thêm bằng cách gọi addFriendWithCache chức năng: các chỉ mục bộ đệm là số nguyên 4 byte trong khi địa chỉ được biểu thị bằng 20 byte, vì vậy có mức tiết kiệm 5:1 cho đối số hàm. Logic tương tự có thể được sử dụng cho dữ liệu khác các loại như số nguyên hoặc nói chung hơn là byte. hợp đồng Địa chỉCache { ánh xạ (địa chỉ => uint32) địa chỉ công cộng2key; địa chỉ[] public key2address; hàm cacheWrite(address _address) trả về nội bộ (uint32) { require(key2address.length < type(uint32).max, "AddressCache: bộ đệm đã đầy"); require(address2key[_address] == 0, "AddressCache: địa chỉ đã được lưu vào bộ nhớ đệm"); // khóa phải bắt đầu từ 1 vì 0 có nghĩa là "không tìm thấy" khóa uint32 = uint32(key2address.length + 1); address2key[_address] = khóa; key2address.push(_address); chìa khóa trả lại; } hàm cacheRead(uint32 _key) chế độ xem công khai trả về (địa chỉ) { require(_key <= key2address.length && _key > 0, "AddressCache: không tìm thấy khóa"); trả về key2address[_key - 1]; } } Liệt kê 2: Hợp đồng bộ nhớ đệm địa chỉ. hợp đồng Bạn bè là Địa chỉCache { ánh xạ (địa chỉ => địa chỉ []) bạn bè công khai; hàm addFriend(địa chỉ _friend) công khai { bạn bè[msg.sender].push(_friend); cacheWrite(_friend); } hàm addFriendWithCache(uint32 _friendKey) public { bạn bè[msg.sender].push(cacheRead(_friendKey)); } hàm getFriends() chế độ xem công khai trả về (địa chỉ [] bộ nhớ) { trả lại bạn bè[msg.sender];} } Liệt kê 3: Ví dụ về một hợp đồng kế thừa bộ đệm địa chỉ. Hợp đồng hỗ trợ trong bộ đệm khoảng 4 tỷ (232) địa chỉ và việc thêm một byte sẽ mang lại khoảng 1 nghìn tỷ (240). 4.2.2. Tối ưu hóa lưu trữ: Bộ lọc của Bloom Trên StarkNet có một số kỹ thuật để giảm thiểu mức sử dụng bộ nhớ. Nếu không cần thiết phải đảm bảo tính sẵn có của dữ liệu gốc thì chỉ cần lưu hash trên chuỗi của nó là đủ: cái này là cơ chế được sử dụng để lưu dữ liệu cho ERC-721 (NFT) [22], tức là liên kết IPFS giải quyết vấn đề hash dữ liệu nếu có. Đối với dữ liệu được lưu trữ nhiều lần, có thể sử dụng tra cứu bảng tương tự như hệ thống bộ nhớ đệm được giới thiệu cho Optimism, yêu cầu tất cả giá trị phải được lưu tại ít nhất một lần. Đối với một số ứng dụng, có thể tránh việc lưu tất cả các giá trị bằng cách sử dụng bộ lọc Bloom [23, 24, 25], tức là cấu trúc dữ liệu xác suất cho phép người ta biết chắc chắn liệu một phần tử không thuộc về một tập hợp nhưng thừa nhận một xác suất sai nhỏ nhưng không đáng kể tích cực. Bộ lọc Bloom được khởi tạo dưới dạng mảng 𝑚bit ở mức 0. Để thêm một phần tử, các hàm 𝑘hash với sự phân bố ngẫu nhiên đồng đều được sử dụng, mỗi ánh xạ tới một bit của mảng được đặt đến 1. Để kiểm tra xem một phần tử có thuộc tập hợp hay không, chúng tôi chạy các hàm 𝑘hash và xác minh rằng các 𝑘bit được đặt thành 1. Trong bộ lọc Bloom đơn giản, không có cách nào để phân biệt liệu một phần tử thực sự thuộc về tập hợp hoặc là dương tính giả, xác suất tăng theo số số mục tăng lên. Sau khi chèn phần tử 𝑛: P[dương tính giả] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 giả định tính độc lập của xác suất của mỗi tập hợp bit. Nếu 𝑛 phần tử (có kích thước tùy ý!) dự kiến sẽ được đưa vào và xác suất cho phép dương tính giả là 𝑝, kích thước của mảng có thể được tính như sau: 𝑚= −𝑛ln 𝑝 (ln 2)2 Trong khi số hàm hash tối ưu là: 𝑘= 𝑚 𝑛ln 2 Nếu chúng ta giả sử chèn 1000 phần tử với dung sai 1% thì kích thước của mảng là 9585 bit với 𝑘= 6, trong khi với dung sai 0,1%, nó trở thành 14377 bit với 𝑘= 9. Nếu một triệu phần tử dự kiến sẽ được chèn vào, kích thước của mảng sẽ trở thành khoảng 1170 kB cho 1% và 1775 kB cho 0,1%, có cùng giá trị 𝑘, vì nó chỉ phụ thuộc vào 𝑝[26]. Trong một trò chơi mà người chơi không được phân công vào đối thủ mà họ đã thách đấu, thay vì lưu vào bộ nhớ cho mỗi người chơi danh sách các đối thủ trong quá khứ, người ta có thể sử dụng Bloom bộ lọc. Rủi ro không thách thức một số người chơi thường có thể chấp nhận được và bộ lọc có thể được đặt lại định kỳ.4.3. Ethereum khả năng tương thích Ưu điểm chính của việc tương thích với EVM và Ethereum là sử dụng lại tất cả các tính năng có sẵn công cụ. Ethereum smart contracts có thể được xuất bản trên Optimism mà không cần sửa đổi hay các cuộc kiểm toán mới. Ví vẫn tương thích, các công cụ phát triển và phân tích tĩnh, phân tích chung công cụ, công cụ lập chỉ mục và oracle. Ethereum và Solidity có lịch sử lâu đời được nghiên cứu kỹ lưỡng các lỗ hổng bảo mật, chẳng hạn như các cuộc tấn công vào lại, tràn và tràn, flash loan và oracle thao tác. Vì điều này, Optimism đã có thể nắm bắt được một lượng lớn giá trị trong thời gian ngắn thời gian. Việc chọn sử dụng một máy ảo khác đồng nghĩa với việc phải xây dựng lại toàn bộ hệ sinh thái, với lợi thế là có quyền tự do thực hiện lớn hơn. StarkNet thực hiện tài khoản sự trừu tượng hóa, là một cơ chế trong đó mỗi tài khoản là một smart contract có thể triển khai logic tùy ý miễn là nó tuân thủ một giao diện (do đó có thuật ngữ trừu tượng): điều này cho phép việc sử dụng các sơ đồ chữ ký số khác nhau, khả năng thay đổi khóa riêng bằng cách sử dụng cùng một địa chỉ hoặc sử dụng multisig. Cộng đồng Ethereum đề xuất giới thiệu tính năng này cơ chế với EIP-2938 vào năm 2020, nhưng đề xuất này vẫn tồn tại hơn một năm vì các bản cập nhật khác được ưu tiên hơn [27]. Một lợi ích quan trọng khác thu được từ tính tương thích là khả năng sử dụng lại các ứng dụng khách hiện có: Optimism sử dụng một phiên bản geth cho nút riêng của nó chỉ với ∼800 dòng khác nhau, đã được được phát triển, thử nghiệm và duy trì từ năm 2014. Có một khách hàng mạnh mẽ là rất quan trọng vì nó xác định những gì được chấp nhận là hợp lệ hay không có trong mạng. Một lỗi trong việc thực hiện bằng chứng lỗi hệ thống có thể khiến bằng chứng không chính xác được chấp nhận là đúng hoặc bằng chứng chính xác cho một bằng chứng không hợp lệ khối được chấp nhận là không chính xác, làm tổn hại đến hệ thống. Khả năng xảy ra loại này cuộc tấn công có thể được hạn chế với sự đa dạng của khách hàng rộng hơn: Optimism có thể sử dụng lại ngoài việc lấy các ứng dụng khách Ethereum khác đã được duy trì và việc phát triển một ứng dụng khách khác dựa trên Erigon đang được tiến hành đã được tiến hành. Vào năm 2016, một vấn đề trong việc quản lý bộ nhớ của geth đã bị khai thác để Tấn công DoS và tuyến phòng thủ đầu tiên là khuyến nghị sử dụng Parity, tuyến phòng thủ thứ hai ứng dụng khách đã sử dụng tại thời điểm đó 5. StarkNet gặp phải vấn đề tương tự với bằng chứng hợp lệ, nhưng ứng dụng khách phải được viết từ đầu và hệ thống chứng minh phức tạp hơn nhiều, và do đó nó cũng phức tạp hơn nhiều để đảm bảo tính chính xác.

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.

Phần kết luận

Kết luận Rollups là giải pháp hứa hẹn nhất hiện nay để giải quyết vấn đề về khả năng mở rộng trong blockchains phi tập trung, mở đường cho kỷ nguyên blockchain mô-đun trái ngược với nguyên khối blockchains. Lựa chọn phát triển Tổng hợp lạc quan hoặc Tổng hợp hợp lệ chủ yếu được hiển thị như một sự đánh đổi giữa sự phức tạp và sự nhanh nhẹn. StarkNet có nhiều ưu điểm như nhanh rút tiền, cấu trúc không có khả năng chuyển đổi trạng thái không hợp lệ, chi phí giao dịch thấp hơn tại chi phí cho thời gian phát triển dài hơn và tính không tương thích với EVM, trong khi Optimism có tận dụng nền kinh tế mạng để nhanh chóng chiếm được thị phần lớn trên thị trường. Optimism Tuy nhiên, Bedrock sở hữu thiết kế mô-đun cho phép nó trở thành Hiệu lực 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Cập nhật trong tương lai: Cannon hiện đang sử dụng minigeth được biên dịch thành MIPS để kiểm tra lỗi của nó hệ thống, nhưng kiến trúc tương tự có thể được sử dụng để thu được một mạch điện và tạo ra các bằng chứng hợp lệ. Việc biên dịch một máy phức tạp như EVM cho một vi kiến trúc sẽ mang lại kết quả đơn giản hơn mạch không cần phải sửa đổi và xác minh lại trong trường hợp nâng cấp. RISC Zero là một vi kiến trúc có thể xác minh được với bằng chứng STARK đã được phát triển dựa trên RISC-V rằng có thể được sử dụng cho mục đích này thay thế cho MIPS [28]. Một khía cạnh không nên đánh giá thấp là sự phức tạp trong việc hiểu cách thức công nghệ hoạt động. Điểm mạnh của blockchain truyền thống là có thể xác minh trạng thái của blockchain mà không tin cậy bất kỳ thực thể bên thứ ba nào. Tuy nhiên, trong trường hợp StarkNet, đó là cần thiết phải tin tưởng vào việc triển khai khi không thể xác minh các thành phần khác nhau dựa trên mật mã và toán học nâng cao. Điều này ban đầu có thể tạo ra xích mích đối với việc áp dụng công nghệ, nhưng khi các công cụ và việc sử dụng bằng chứng về tính toàn vẹn ngày càng phát triển bên ngoài trường blockchain hy vọng vấn đề này sẽ được giải quyết.