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

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

Giới thiệu

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

Tổng hợp lạc quan

1. 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 đề.

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

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

So sánh

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

Phần kết luận

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