Sách trắng Bài viết Hình ảnh Thuật ngữ đồ thị Tìm kiếm

Optimism 技術文書

Tác giả Optimism Collective · 2021

Chế độ một trang community.optimism.io

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

🇺🇸 English (Bản gốc)
🇯🇵 日本語 (Bản dịch)

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

概要

この論文では、トランザクション スループットとノードを実行するためのハードウェア要件との間のトレードオフを分析することで、分散型 blockchain のスケーラビリティの問題に対処しています。ロールアップ、つまりオフチェーンで実行されるブロックをオンチェーンで検証するテクノロジーは、障害証明または有効性証明の形式で提供されます。出金時間、取引コスト、最適化手法、Ethereum エコシステムとの互換性に関して、オプティミスティック ロールアップと有効性ロールアップを比較します。私たちの分析により、Optimism Bedrock の現在のガス圧縮率は約 20:1 であるのに対し、StarkNet は約 24:1 のストレージ書き込みコスト圧縮率を達成していることがわかりました。また、キャッシュ コントラクトやブルーム フィルターの使用など、これらのレートをさらに最適化する手法についても説明します。最終的に、私たちの結論は、楽観的ロールアップと妥当性ロールアップの選択における複雑さと機敏性の間のトレードオフを浮き彫りにします。キーワード ブロックチェーン、スケーラビリティ、ロールアップ 1. はじめに ブロックチェーン技術は、さまざまな業界に革命を起こす可能性があるため、大きな注目を集めています。ただし、ほとんどの blockchain は、一般にスケーラビリティのトリレンマと呼ばれる、スケーラビリティ、分散化、セキュリティの間のトレードオフに直面しているため、スケーラビリティは依然として大きな課題です。 blockchain のスループットを向上させる簡単な解決策は、ブロック サイズを増やすことです。 Ethereum のコンテキストでは、これはブロックが保持できるガスの最大量を増やすことを意味します。各フルノードはすべてのブロックのすべてのトランザクションを検証する必要があるため、スループットが増加するにつれてハードウェア要件も増加し、ネットワークの集中化が進みます。 Bitcoin や Ethereum などの一部の blockchain は、アーキテクチャの分散化を最大化するために設計を最適化しますが、Binance Smart Chain や Solana などの他のものは、可能な限り高速かつ安価になるように設計されています。分散型ネットワークは、blockchain のスループットを人為的に制限して、ネットワークに参加するためのハードウェア要件を下げます。長年にわたり、状態チャネル [3] やプラズマ [4、5] など、トリレンマの解決策を見つける試みが行われてきました。これらのソリューションには、一部のアクティビティをオフチェーンに移動し、smart contracts を使用してオンチェーンのアクティビティをオフチェーンのアクティビティにリンクし、DLT 2023 を検証するという特徴があります: 第 5 回分散台帳技術ワークショップ、2023 年 5 月 25 ～ 26 日、イタリア、ボローニャ $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 この論文の著作権は著者にあります。クリエイティブ コモンズ ライセンス表示 4.0 インターナショナル (CC BY 4.0) に基づいて使用が許可されています。 CEUR ワークショップ議事録 http://ceur-ws.org ISSN 1613-0073 CEUR ワークショップ議事録 (CEUR-WS.org) オンチェーンとオフチェーンで何が起こっているか。ただし、プラズマ チャネルと状態チャネルの両方は、一般的な smart contract のサポートに制限があります。ロールアップは、ブロックを別の blockchain (Layer 1 または L1) に公開する blockchain (Layer 2 または L2 と呼ばれます) であり、そのため、そのコンセンサス、データの可用性、およびセキュリティのプロパティを継承します。他のソリューションとは異なり、これらは任意の計算をサポートします。ロールアップには 3 つの主なコンポーネントがあります。 • シーケンサー: ユーザーからロールアップ トランザクションを受け取り、それらを Layer 1 に送信されるブロックに結合するノード。ブロックは、少なくとも状態ルート (マークル ルートなど) と、状態を再構築して検証するために必要なデータで構成されます。 Layer 1 は...を定義します。

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.

導入

  1. はじめに ブロックチェーン技術は革命を起こす可能性があるため大きな注目を集めています さまざまな業界。ただし、ほとんどの blockchain が直面しているように、スケーラビリティは依然として大きな課題です。 スケーラビリティ、分散化、セキュリティの間のトレードオフ。一般に スケーラビリティのトリレンマ [1、2]。 blockchain のスループットを向上させるための簡単な解決策は次のとおりです。 ブロックサイズを大きくします。 Ethereum のコンテキストでは、これは最大値を増やすことを意味します。 ブロックが保持できるガスの量。各フルノードはすべてのトランザクションを検証する必要があるため、 ブロックのスループットが増加すると、ハードウェア要件も増加し、 ネットワークの一元化。 Bitcoin や Ethereum などの一部の blockchain は、 アーキテクチャの分散化を最大限に高めるように設計されている一方で、Binance Smart などの他の製品は Chain と Solana は、できるだけ速く、そして安価になるように設計されています。分散型ネットワーク blockchain のスループットを人為的に制限して、ハードウェア要件を下げる ネットワークに参加します。 長年にわたり、トリレンマの解決策を見つける試みがなされてきました。 チャネル [3] およびプラズマ [4、5]。これらのソリューションには、何らかのアクティビティを移動するという特徴があります。 オフチェーン、smart contracts を使用してオンチェーン アクティビティをオフチェーン アクティビティにリンクし、検証する DLT 2023: 第 5 回分散台帳テクノロジー ワークショップ、2023 年 5 月 25 ～ 26 日、イタリア、ボローニャ $ [email protected] (L. ドノ) https://lucadonnoh.github.io/ (L. ドノ) 0000-0001-9221-3529 (L. ドンノ) © 2023 この論文の著作権は著者にあります。クリエイティブ コモンズ ライセンス表示 4.0 インターナショナル (CC BY 4.0) に基づいて使用が許可されています。 クール ワークショップ 議事録 http://ceur-ws.org ISSN 1613-0073 CEUR ワークショップ議事録 (CEUR-WS.org)オフチェーンで起こっていることをオンチェーンで。ただし、プラズマ チャネルと状態チャネルの両方が制限されています。 一般的な smart contract のサポート。 ロールアップは、別の blockchain でブロックを公開する blockchain (Layer 2 または L2 と呼ばれます) です。 (Layer 1 または L1) なので、そのコンセンサス、データの可用性、およびセキュリティのプロパティを継承します。彼らは、 他のソリューションとは異なり、任意の計算をサポートします。ロールアップには 3 つの主要なコンポーネントがあります。 • シーケンサー: ユーザーからロールアップ トランザクションを受け取り、それらを結合してトランザクションを作成するノード。 Layer 1 に送信されるブロック。ブロックは少なくとも状態ルート (マークルなど) で構成されます。 root) と、状態を再構築して検証するために必要なデータ。 Layer 1 は、 公開されたデータの順序を確立することにより、L2 の正規 blockchain を取得します。 • ロールアップフルノード: レイヤーからロールアップブロックを取得、処理、検証するノード 1 ルートが正しいことを確認します。ブロックに無効なトランザクションが含まれている場合、 破棄され、シーケンサーが無効なブロックを含む有効なブロックを作成できなくなります。 取引。 • ロールアップ ライト ノード: Layer 1 からロールアップ ブロックを取得しますが、計算は行わないノード 新しい状態そのもの。彼らは、新しい状態のルートが有効であることを技術を使用して検証します。 欠陥証明や有効性証明など。 ロールアップは、トランザクションの償却コストを数値として削減することでスケーラビリティを実現します。 ユーザー数が増加します。これは、blockchain の有効性を確保するコストが非線形的に増加するためです。 取引を個別に検証するコストに関して。ロールアップは次のように異なります。 ライトノードでのトランザクション実行の正当性を保証するメカニズム: 楽観的なロールアップは、有効期間中、経済モデルとフォールトプルーフによって保証されます。 ロールアップは、有効性証明を使用して暗号的に保証されます。 ライト ノードは、Layer 1 上の smart contract として実装できます。彼らはその根を受け入れます 新しい状態を確認し、有効性または障害の証明を検証します。したがって、これらのロールアップはスマート コントラクトと呼ばれます。 ロールアップ。ライト ノードが独立している場合、それらはソブリン ロールアップ [6] と呼ばれます。の利点 スマート コントラクト ロールアップを使用すると、両者の間に信頼を最小限に抑えたブリッジを構築できるようになります。 blockchains: L2 状態の正当性が L1 に証明されたため、L1 からのトランザクションのシステムが L2からL1まで実装可能で引き出しも可能です。デメリットとしては、費用がかかることです トランザクションは、L1 の状態を検証するコストに依存します。ベース層が飽和している場合、 他のアクティビティに伴い、ロールアップのトランザクションのコストも増加します。 データ層とコンセンサス層は、システムのセキュリティを決定するものです。 トランザクションの順序を定義し、攻撃を防ぎ、状態を証明するためにデータを利用できるようにします。 有効性。 論文寄稿 このペーパーでは、2 つの革新的なオプティミスティック ロールアップと妥当性ロールアップについて研究します。 Optimism Bedrock や StarkNet などの注目すべき実装に焦点を当てた、スケーラビリティのトリレンマに対するソリューション。私たちの貢献には、これらの包括的な比較が含まれます 解決策、引き出し時間の分析、Optimism に対する攻撃の可能性についての議論 岩盤。さらに、ガス圧縮比を計算し、アプリケーション固有の最適化を提供し、Ethereum からの移行の長所と短所を示します。 仮想マシン (EVM)。

紙の構造 論文は以下のように構成されている。セクション 2 では、楽観的なロールアップについて説明します。 Optimism 岩盤を分析することで導入されました。セクション 3 では、有効性ロールアップが導入されています。 StarkNet を分析しています。セクション 4 では、2 つのソリューションを比較します。最後に、セクション 5 で描画します。 いくつかの結論。

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

楽観的なロールアップ

  1. 楽観的なロールアップ ブロックの実行を検証せずに、ブロックの出力を楽観的に受け入れるというアイデアは次のとおりです。 ライト ノードについて説明している Bitcoin ホワイトペーパー [7] にすでに記載されています。これらのノードは後続するだけです コンセンサス ルールを検証してヘッダー チェーンをブロックし、ブロックを受け入れやすくする 51% 攻撃が発生した場合に無効なトランザクションが含まれる。ナカモトはこれを解決することを提案します 「アラート」システムを使用して、ブロックに無効なトランザクションが含まれていることをライトノードに警告することで、この問題を解決します。 このメカニズムは、Al-Bassam、Sonnino、Buterin [8] によって最初に実装されました。 誤り訂正符号[9]に基づく証明システムが使用されます。の作成を可能にするために、 フォールトプルーフのためには、無効なブロックを含むすべてのブロックのデータが利用可能である必要があります。 ネットワーク: これはデータ可用性問題であり、確率的データを使用して解決されます。 サンプリング機構。最初のオプティミスティック ロールアップ デザインは、ジョン アドラーと 2019 年 [10] の Mikerah Quintyne-Collins、ブロックは別の blockchain で公開されています それが注文に関する彼らの合意を定義します。 2.1. Optimism 岩盤 Bedrock [11] は、スマート コントラクト ロールアップである Optimism の最新バージョンです。以前のバージョンでは、 Optimistic Virtual Machine (OVM) では、Solidity をコンパイルするためにアドホック コンパイラーが必要でした。 独自のバイトコード: 対照的に、Bedrock は実行エンジンという点で EVM と完全に同等です。 Ethereum イエロー ペーパー仕様 [12] に従います。 2.1.1.預金 ユーザーは、depositTransaction 関数を呼び出すことで、Ethereum、Optimism ポータル上のコントラクトを通じてトランザクションをデポジットできます。 トランザクションが実行されると、 TransactionDeposited イベントが発行され、ロールアップ内の各ノードが処理をリッスンします。 預金。入金されたトランザクションは、L1 から派生した L2 トランザクションです。の発信者が 関数がコントラクトである場合、アドレスはそれに定数値を追加することによって変換されます。これにより、 L1 のコントラクトが L2 のコントラクトと同じアドレスを持つが、コードが異なる攻撃。 入金されたトランザクションが L2 に含まれることは、シーケンス内の仕様によって保証されます。 窓。 入金されたトランザクションは、プレフィックス 0x7E を持つ新しい EIP-2718 互換トランザクション タイプ [13] です。 ここで、rlp エンコードされたフィールドは次のとおりです。 • bytes32 sourceHash: トランザクションのソースを一意に識別する hash。 • address from: 送信者のアドレス。 • address to: 受信者のアドレス、または入金されたトランザクションが 契約書の作成。• uint256 mint: L2 で作成される値。 • uint256 値: 受信者に送信される値。 • バイトデータ: 入力データ。 • バイトの GasLimit: トランザクションのガス制限。 sourceHash は、L1 ブロック hash および L1 ログの keccak256 hash として計算されます。 インデックス。ブロック内のイベントを一意に識別します。 入金されたトランザクションは L1 で開始されますが、L2 で実行されるため、システムには L2 で消費されたガスの対価を L1 で支払うメカニズム。解決策の 1 つは、ポータル経由で ETH を送信することです。 しかしこれは、すべての呼び出し元 (間接的な呼び出し元も含む) が支払い可能としてマークされなければならないことを意味します。 多くの既存プロジェクトでは不可能です。別の方法は、L1 で対応するガスを燃焼させることです。 入金されたトランザクションに割り当てられるガス𝑔を保証ガスと呼びます。 L2ガスの価格は L1 は自動的には同期されませんが、EIP-1559 と同様のメカニズムを使用して推定されます。 [14]。 Ethereum ブロックごとに保証されるガスの最大量は 800 万であり、目標は 200万の。 L2 でガスの支払いに必要な ETH の量 𝑐 は 𝑐= 𝑔𝑏L2 です。ここで、𝑏L2 は L2 の基本料金。 L1 のコントラクトでは、𝑐/𝑏L2 に等しい量のガスが燃焼します。通話に費やしたガソリン デポジットトランザクションは L2 で払い戻されます。この金額が保証されたガスより大きい場合、 ガスは燃焼しません。 rollup ブロックの最初のトランザクションは、L1 属性が登録されたトランザクションであり、登録に使用されます。 L2 では、Ethereum ブロックの属性を事前展開します。事前デプロイによって与えられる属性 アクセスできるのは、ブロック番号、タイムスタンプ、基本料金、ブロック hash、およびシーケンスです。 番号。これは、関連する L1 ブロックに対する相対的な L2 のブロック番号 (エポックとも呼ばれます)。 この番号は、新しいエポックが開始されるとリセットされます。 2.1.2.シーケンス ロールアップ ノードは、Optimism チェーンを完全に Ethereum から派生させます。このチェーンは延長されます 新しいトランザクションが L1 で公開されるたびに、そのブロックはそのたびに再編成されます Ethereum ブロックが再編成されます。ロールアップ blockchain はエポックに分割されています。 𝑛ごとに ブロック番号 Ethereum には、対応する 𝑛エポックがあります。各エポックには少なくとも 1 つが含まれます ブロックであり、エポック内の各ブロックには、L1 属性がデポジットされたトランザクションが含まれます。最初のブロック エポックには、ポータルを通じて入金されたすべてのトランザクションが含まれます。 Layer 2 ブロックは、 シーケンスされたトランザクション、つまりシーケンサーに直接送信されるトランザクションが含まれていました。 シーケンサーはユーザーからトランザクションを受け入れ、ブロックを構築します。ブロックごとに、 Ethereum に公開されるバッチ。複数のバッチを圧縮して公開できます。 名前チャンネルを取得します。チャネルが大きすぎる場合に備えて、チャネルを複数のフレームに分割できます。 単一のトランザクション。チャネルは、rlp エンコードされた ZLIB [15] による圧縮として定義されます。 バッチ。バッチのフィールドは、エポック番号、エポック hash、親 hash、 タイムスタンプとトランザクションリスト。 エポックによって識別されるシーケンス ウィンドウには、連続する L1 の固定数 𝑤 が含まれます。 導出ステップが可変数の L2 ブロックを構築するために入力として受け取るブロック。のために エポック 𝑛 では、シーケンス ウィンドウ 𝑛 にはブロック [𝑛, 𝑛+𝑤) が含まれます。これは、順序付けが シーケンス ウィンドウ内の L2 トランザクションとブロックの数は、ウィンドウが終了するまで修正されません。 rollup トランザクションは、それを含むバッチが L1 で確認された場合、安全であると呼ばれます。フレームバッチを再構築するために L1 ブロックから読み取られます。現在の実装では許可されていません 対応するすべてのフレームが受信されるまで、チャネルの圧縮解除が開始されます。無効です バッチは無視されます。個々のブロック トランザクションはバッチから取得されます。 状態遷移を適用し、ロールアップ状態を取得するために実行エンジンによって使用されます。 2.1.3.出金 出金を処理するために、L2-to-L1 メッセージング システムが実装されています。 Ethereum 出金を受け入れるためには L2 の状態を知る必要があり、これはパブリッシングによって行われます。 L2 の出力 Oracle smart contract L1 の各 L2 ブロックのステート ルート。これらの根 実行中にフォールトプルーフが実行されなければ、有効（または確定）として楽観的に受け入れられます。 争議期間。プロポーザとして指定されたアドレスのみが出力ルートを公開できます。有効性 提案者に賭け金を預けてもらうことで、出力ルートの割合が奨励されます。 無効なルートを提案したことが示されています。トランザクションは関数を呼び出すことで開始されます L2 での事前デプロイでのInitialWithdrawal と、関数の呼び出しによる L1 での終了 前述の Optimism ポータルでのfinalizeWithdrawalTransaction。 L2 ブロックに対応する出力ルートは、L2 Output Oracle から取得されます。それはです それが最終決定されたこと、つまり紛争期間が経過したことを確認しました。出力が検証される Root Proof は Oracle Proof と一致します。出金のhashが含まれていることを確認します その中で引き出し証明を使用します。撤退がまだ完了していないこと。そして、 指定されたガス制限、イーサの量、およびデータを使用して、ターゲット アドレスへの呼び出しが実行されます。 2.1.4.大砲: 故障防止システム ロールアップ フル ノードがバッチとデポジットされたトランザクションをローカルで実行することによって、次のことを発見した場合 Layer 2 状態は、プロポーザーによってオンチェーンで公開された状態ルートと一致しないため、実行できます ブロック遷移の結果が正しくないことを証明するための L1 のフォールトプルーフ。のせいで オーバーヘッドのため、L1 でロールアップ ブロック全体を処理するのにコストがかかりすぎます。実装されたソリューション Bedrock によると、minigeth の不一致の最初の命令のみがオンチェーンで実行されます。 それを MIPS アーキテクチャにコンパイルし、オンチェーン インタプリタ上で実行して公開します。 L1で。 minigeth は、コンセンサス、RPC、およびデータベースを備えた geth 1 の簡易バージョンです。 は削除されています。 不一致の最初の命令を見つけるために、対話型バイナリ検索が次の間で実行されます。 フォールトプルーフを開始した者と出力ルートを公開した者です。証明のとき が開始されると、両方の当事者が実行の途中で MIPS メモリ状態のルートを公開します。 チャレンジ契約のブロック: hash が一致する場合、両当事者が 実行の前半は、後半の半分のルートを公開し、それ以外の場合は半分を公開します。 前半部分などを公開します。そうすることで、意見の不一致の最初の指示が達成されます 元の実行と比較して、対数的なステップ数で実行されます。 2台のうちどちらかが止まったら 対話すると、紛争期間の終了時に他の参加者が自動的に勝ちます。 命令を処理するには、MIPS インタプリタはそのメモリにアクセスする必要があります。 必要なメモリセルが利用可能であれば、そのメモリセルが含まれていることを証明することで公開できます。アクセスするには EVM の状態では、Preimage Oracle が使用されます。返されるブロックの hash が与えられると、 1https://geth.ethereum.org/docs

ブロックヘッダー。そこから前のブロックの hash を取得して、そのブロックに戻ることができます。 チェーンするか、プリイメージを取得できる状態とログの hash を取得します。 oracle minigeth によって実装され、データベースを置き換えます。他のノードに対してクエリが実行され、 プリイメージを取得します。

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)

有効性ロールアップ

  1. 有効性ロールアップ Validity Rollup の目的は、状態遷移の有効性を暗号的に証明することです。 準線形的に比較できる検証可能な短い証明を伴うトランザクションのシーケンスが与えられたとします。 元の計算の時点まで。 この種の証明書は計算整合性証明と呼ばれ、実際には算術演算を使用する SNARK (Succint Non-interactive ARgument of Knowledge) で実装されます。 回路を計算モデルとして使用します。 SNARK 実装が異なれば証明時間も異なります。 検証時間、信頼できるセットアップの必要性、および量子耐性 [16、17]。 STARK (スケーラブル) 透明な知識引数) [18] は、信頼できる認証を必要としない SNARK の一種です。 証明と検証の効率をある程度犠牲にする一方で、量子耐性を備えています。 他のソリューションと比較して。 3.1. StarkNet StarkNet は、Starkware によって開発された、STARK を使用するスマート コントラクト有効性ロールアップです。 Ethereum までの状態を検証する証明システム。有効性証明の構築を容易にするために、 EVM とは異なる仮想マシンが使用されており、その高級言語は Cairo です。 3.1.1.預金 ユーザーは、sendMessageToL2 を呼び出すことで、Ethereum のコントラクトを介してトランザクションを入金できます。 機能。メッセージは、hash を計算し、カウンターを増やすことによって記録されます。シーケンサー LogMessageToL2 イベントをリッスンし、StarkNet トランザクションで情報をエンコードします。 l1_handler デコレータを持つコントラクトの関数を呼び出します。実行の最後に、 状態遷移の証明が生成されると、メッセージの消費がそれに添付されます そしてカウンターを減らすことで削除されます。 StarkNet 仕様では、入金されたトランザクションを含めることは必須ではないため、 シーケンサーが L2 で公開するよう奨励するには、市場が必要です。現在のバージョンでは、 シーケンサーは StarkWare によって集中管理され、入金されたトランザクションのコストは はデポジットの実行コストによってのみ決定されます。この費用はETHを送金することで支払われます。 L2 にメッセージを送信します。これらのイーサは L1 でロックされたままになり、L1 でシーケンサに転送されます。 L1、入金されたトランザクションが状態遷移に含まれる場合。送金されたETHの量（場合） ガスの消費量に関係なく、入金されたトランザクションは含まれており、全額使用されます。 L2で。 StarkNet には、L1 ブロック属性を自動的に使用可能にするシステムがありません。 また、Fossil は、Oiler Network 2 によって開発されたプロトコルであり、hash を指定すると、 ブロック、プレイメージを公開することによって Ethereum から取得される情報。 2https://www.oiler.network/3.1.2.シーケンス StarkNet の現在の状態は、すべて Ethereum から派生できます。あらゆる状態の違い トランジション間はコールデータとして L1 に公開されます。差異は契約ごとに公開されます 次のエンコードを使用して uint256[] として保存されます。 • 契約展開に関するフィールドの数。 • 公開された各契約について: – 公開された契約書の住所。 – 公開された契約の hash。 – コントラクト コンストラクターの引数の数。 – コンストラクター引数のリスト • ストレージが変更された契約の数。 • 変更された各契約について: – 変更された契約の住所。 – ストレージ更新の数。 – 新しい値を含むストレージ アドレスのキーと値のペア。 状態の違いは順番に公開されているため、順番に読んでいけば十分です。 状態を再構築します。 3.1.3.出金 L2 から L1 にメッセージを送信するには、syscall send_message_to_L1 を使用します。メッセージは 証明とともに hash カウンタを増やすことで L1 に公開され、 L1 の StarkGate smart contract の関数 ConsumerMessageFromL2 (デクリメント) カウンター。誰でも出金を完了できます。 3.1.4.有効性の証明 Cairo 仮想マシン [19] は、STARK 証明の構築を容易にするように設計されています。 Cairo 言語を使用すると、高レベルのプログラミングで計算を記述することができます。 言語であり、直接回路としてではありません。これは多項方程式系によって実現されます。 図３は、単一の計算、すなわちフォン・ノイマン・アーキテクチャのＦＤＥサイクルを表す。番号 したがって、制約の数は固定され、計算の種類に依存せず、1 つだけが許可されます。 計算を証明する必要があるすべてのプログラムの検証プログラム。 StarkNet は、共有証明者を使用して複数のトランザクションを単一の STARK 証明に集約します シャープという名前。証明は Ethereum の smart contract に送信され、その有効性が検証されます。 そして、新しい状態に対応するマークル ルートを更新します。検証にかかるサブリニアコスト 有効性の証明により、そのコストを複数のトランザクションにわたって償却することができます。 3代数中間表現 (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.

比較

  1. 比較 4.1.出金時間 楽観的ロールアップと妥当性ロールアップを区別する最も重要な側面は、 出金の開始から完了までに経過する時間。どちらの場合も、 出金は L2 で初期化され、L1 で完了します。 StarkNet では、次のようにファイナライズが可能です 新しい状態ルートの有効性証明が Ethereum で受け入れられ次第、理論的には次のようになります。 初期化後の L1 の最初のブロックで資金を引き出すことが可能です。実際には、 Ethereum で有効性証明を送信する頻度は、ブロックの速度とのトレードオフです ファイナライゼーションと証明の集約。現在、StarkNet は検証のための有効性証明を提供しています 10 時間ごと 4 ですが、トランザクション アクティビティが増加するにつれて減少することが意図されています。 Optimism Bedrock では、紛争の終了時にのみ撤回を完了することができます。 期間 (現在は 7 日) が経過すると、ルートは自動的に有効とみなされます。長さ この期間は主に、Ethereum に欠陥証明が検閲されるまでの期間によって決定されます。 その終わり。このタイプの攻撃の成功確率は、時間の経過とともに指数関数的に減少します。 E[減算値] = 𝑉𝑝𝑛 ここで、𝑛は間隔内のブロック数、𝑉は差し引くことができる資金の量です 無効なルートを公開することによって、𝑝は検閲が正常に実行される確率です 単一ブロックで攻撃します。この確率が 99% で、値がロールアップにロックされていると仮定します。 は 100 万イーサ、間隔内のブロックは 1800 (12 個のブロックで 6 時間) 秒間隔): 期待値は約 0.01391 Ether です。システムの安全性は次のとおりです。 提案者に、期待値よりもはるかに大量のイーサをステーキングするよう求めます。 ウィンザーら。単純な smart contract を使用して検閲攻撃を実行する方法を示しました。 これにより、状態内のメモリの特定の領域が [20] 変更されないことが保証されます。攻撃のモデル化 この論文は、マルコフゲームとして、検閲が合理的なアプローチの支配的な戦略であることを示しています。 変更を伴うトランザクションを含めるよりも多くの報酬を受け取った場合、プロデューサーをブロックする 記憶。上で説明した 𝑝 値は、有理ブロックのパーセンテージとして見ることができます。 ネットワーク内のプロデューサー。「合理的」とは、ペナルティを与える可能性を考慮していない blockchain に対する信頼が低下し、暗号通貨の価値が低下するなどの外部性。 次のコードは、検閲攻撃の実行に使用できる smart contract を示しています。 岩盤の上。この攻撃は、ブロックプロデューサーに賄賂を提供することで、ブロックプロデューサーのインセンティブを悪用します。 州の特定の部分を変更する取引を検閲するため。契約の主な内容 関数、claimBribe を使用すると、ブロックプロデューサーが検閲に成功した場合に賄賂を請求できるようになります。 無効な出力ルートが触れられていないことを確認して、ターゲットのトランザクションを処理します。 functionclaimBribe(バイトメモリ storageProof) 外部 { require(!claimed[block.number], "賄賂はすでに請求されています"); OutputProposal メモリの現在 = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, ストレージプルーフ); require(invalidOutputRoot == current.outputRoot, "攻撃は失敗しました"); 主張[ブロック番号] = true; (ブール送信、 ) = block.coinbase.call{値: 賄賂金額}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, "イー​​サの送信に失敗しました"); } リスト 1: Bedrock に対する検閲攻撃を奨励する契約の例。 紛争期間の長さには、過失の証明が不十分であるという事実も考慮する必要があります。 インタラクティブな証明であるため、参加者が対話するのに十分な時間を提供する必要があります そして、あらゆるやり取りが検閲される可能性があるということです。最後の移動が直前に行われた場合、 紛争期間が終了すると、検閲のコストは大幅に減少します。検閲はあるものの、 ドミナント戦略では、検閲ノードが次の攻撃に対して脆弱であるため、成功の可能性は低くなります。 サービス拒否攻撃: 攻撃者は、次のような非常に複雑なトランザクションを生成する可能性があります。 手数料は支払われないため、欠陥証明の発行は無料で行われます。 極端な場合には、紛争期間が長ければ、解決に成功した場合の調整が可能になります。 フォークを組織し、攻撃しているブロックプロデューサーを排除するための検閲攻撃。もう一つ 攻撃の可能性としては、議論者が検証できる以上に多くのステートルート提案を公開することが挙げられます。 これは周波数制限を使用することで回避できます。 4.1.1.素早い楽観的な出金 オプティミスティック ロールアップの有効性はフル ノードでいつでも検証できるため、 信頼できる oracle を使用すると、出金が安全に完了できるかどうかを L1 で知ることができます。これ このメカニズムは Maker [21] によって最初に提案されました。oracle は引き出しを検証し、 ユーザーに有利子ローンが割り当てられる L1 の結果。これは自動的に実行されます。 7 日間の終わり、つまり実際に出金が完了した時点で締め切りとなります。この解決策 信頼の仮定が導入されていますが、Maker の場合、oracle 演算子があるため最小化されています。 は、融資を提供することでリスクを引き受けるのと同じ組織によって管理されます。 4.2.取引コスト L2 トランザクションのコストは、主に L1 との対話によって決まります。どちらのソリューションでも トランザクションは完全にオフチェーンで実行されるため、トランザクションの計算コストは非常に安価です。 Optimism は、L2 トランザクションの呼び出しデータを呼び出しデータとして公開し、フォルトをほとんど (またはまったく) 実行しません。 したがって、calldata は最も高価なリソースです。 2022 年 1 月 12 日、Bedrock ネットワーク Ethereum の Goerli テストネットで開始されました。ガスの圧縮率を計算できます 一定期間に岩盤上で使用されたガスの量を追跡し、それを過去のガスの量と比較することによって、 対応するブロックの L1 で費やされるガスの量。この方法を使用してガス圧縮 〜20 : 1 の割合が見つかりますが、この数値はメインネット上の実際のアクティビティとは異なる可能性があります。 StarkNet は、L2 状態のすべての変更を呼び出しデータとして Ethereum に公開するため、ストレージは 最も高価なリソース。ネットワークは EVM を使用しないため、トランザクション コストは 圧縮率を自明に見積もることはできません。実行コストと呼び出しデータを想定すると、 無視できるほど、ストレージ書き込みの圧縮率を計算することができます。 L1。コントラクトが展開されておらず、StarkNet で以前にアクセスされていない 10 個のセルが存在すると仮定します。 変更すると、ストレージ書き込みコスト圧縮率は約 24:1 であることがわかります。セルが上書きされた場合 データ公開間の𝑛回、各書き込みのコストは、以前のコストと比較して 1/𝑛 になります。 最後の書き込みのみが公開されるため、1 回の書き込みで済みます。コストをさらに抑えることができるのは、頻繁に使用される値を圧縮します。有効性証明検証の費用は次のとおりに分割されます。 参照するトランザクション: たとえば、StarkNet ブロック 4779 には 200 個のトランザクションが含まれており、その 有効性証明には 267830 ユニットのガス、つまりトランザクションごとに 1339.15 ガスが消費されます。 4.2.1.コールデータの最適化: キャッシュ コントラクト 以下に示すのは、頻繁に使用されるアドレス キャッシュを実装する smart contract です。 ストレージと実行のコストがはるかに低いという事実を利用して対処します リソースとその使用法を示す Friends 契約。後者は、 addFriend関数を呼び出すことで登録できるアドレスの「友達」。住所の場合 すでに少なくとも 1 回使用されている場合は、addFriendWithCache を呼び出すことで追加できます。 機能: キャッシュ インデックスは 4 バイトの整数ですが、アドレスは 20 バイトで表されます。 したがって、関数の引数は 5:1 で節約されます。同じロジックを他のデータにも使用できます 整数やより一般的にはバイトなどの型。 コントラクト AddressCache { マッピング(アドレス => uint32) パブリックアドレス2キー; アドレス[]公開鍵2アドレス; 関数cacheWrite(address _address)内部戻り値(uint32) { require(key2address.length < type(uint32).max, "AddressCache: キャッシュがいっぱいです"); require(address2key[_address] == 0, "AddressCache: アドレスはすでにキャッシュされています"); // 0 は「見つからない」ことを意味するため、キーは 1 から開始する必要があります uint32 キー = uint32(key2address.length + 1); address2key[_address] = キー; key2address.push(_address); リターンキー; } 関数cacheRead(uint32 _key)パブリックビューは(アドレス)を返します{ require(_key <= key2address.length && _key > 0, "アドレスキャッシュ: キーが見つかりません"); キー 2 アドレスを返します [_key - 1]; } } リスト 2: アドレス キャッシュ コントラクト。 コントラクトフレンドはAddressCache { マッピング(アドレス => アドレス[]) 公開友達; 関数 addFriend(アドレス _friend) public { friends[msg.sender].push(_friend); キャッシュ書き込み(_friend); } 関数 addFriendWithCache(uint32 _friendKey) public { friends[msg.sender].push(cacheRead(_friendKey)); } function getFriends() public view returns (address[]memory) { 友達を返す[msg.sender];} } リスト 3: アドレス キャッシュを継承するコントラクトの例。 この契約はキャッシュ内で約 40 億 (232) のアドレスをサポートしており、1 バイトを追加すると次のようになります。 約1兆（240）個。 4.2.2.ストレージの最適化: Bloom のフィルター StarkNet には、ストレージの使用量を最小限に抑えるための手法がいくつかあります。必要がない場合は、 元のデータの可用性を保証する場合は、その hash をオンチェーンに保存するだけで十分です。 ERC-721 (NFT) [22] のデータを保存するために使用されるメカニズムです。つまり、 利用可能な場合はデータの hash。複数回保存されたデータの場合は、ルックアップを使用できます。 Optimism に導入されたキャッシュ システムに似たテーブル。すべての値を次の場所に保存する必要があります。 少なくとも一度は。一部のアプリケーションでは、ブルーム フィルターを使用することですべての値の保存を回避できます。 [23, 24, 25]、つまり、次のことを確実に知ることができる確率的データ構造。 要素はセットに属していませんが、小さいながらも無視できない false の確率を許容します。 ポジティブ。 ブルーム フィルターは、ゼロの 𝑚 ビットの配列として初期化されます。要素を追加するには、𝑘hash 関数を使用します 一様なランダム分布を持つものが使用され、それぞれが設定された配列のビットにマッピングされます。 要素がセットに属しているかどうかを確認するには、𝑘hash 関数を実行して検証します。 単純なブルームフィルターでは、𝑘ビットが1に設定されているかどうかを区別する方法はありません。 要素が実際にセットに属しているか、偽陽性であるか、その確率は数に応じて増加します。 エントリ数が増加します。 𝑛要素を挿入した後: P[偽陽性] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 各ビットセットの確率が独立していると仮定します。 𝑛要素 (任意のサイズ!) が が含まれることが期待され、許容される偽陽性の確率は配列のサイズ 𝑝 です。 は次のように計算できます。 𝑚= −𝑛ln 𝑝 (ln 2)2 hash 関数の最適な数は次のとおりです。 𝑘= 𝑚 𝑛ln 2 許容誤差 1% で 1000 個の要素を挿入すると仮定すると、配列のサイズは 9585 ビットになります。 𝑘= 6 の場合、0.1% の許容誤差の場合、𝑘= 9 では 14377 ビットになります。要素が 100 万個の場合 が挿入されることが予想される場合、配列のサイズは 1% の場合は約 1170 KB、1% の場合は 1775 KB になります。 𝑝[26] のみに依存するため、𝑘 の値が同じ場合は 0.1%。 すでに挑戦した相手にプレイヤーを割り当ててはいけないゲームでは、 各プレイヤーの過去の対戦相手のリストをストレージに保存する代わりに、ブルームを使用できます。 フィルター。一部のプレイヤーに挑戦しないリスクは多くの場合許容され、フィルターはリセットできます。 定期的に。4.3. Ethereum 互換性 EVM および Ethereum と互換性があることの主な利点は、利用可能なすべてのコンポーネントを再利用できることです。 ツール。 Ethereum smart contract は、変更を加えずに Optimism で公開できます。 新しい監査。ウォレットの互換性維持、開発および静的分析ツール、一般的な分析 ツール、インデックス作成ツール、oracle。 Ethereum と Solidity には、十分に研究されてきた長い歴史があります。 再入攻撃、オーバーフローとアンダーフロー、フラッシュ ローン、oracle などの脆弱性 操作。このため、Optimism は短期間で大量の価値を獲得することができました。 時間。 別の仮想マシンを採用するという選択は、エコシステム全体を再構築する必要があることを意味します。 実装の自由度が高まるという利点があります。 StarkNet アカウントをネイティブに実装します 抽象化。各アカウントを smart contract として実装できるメカニズムです。 インターフェイスに準拠している限り、任意のロジック (したがって抽象化という用語が使われます): これにより、 さまざまなデジタル署名スキームの使用、秘密キーを使用して秘密キーを変更する機能 同じアドレスを使用するか、マルチシグを使用します。 Ethereum コミュニティがこれの導入を提案しました 2020 年に EIP-2938 のメカニズムが確立されましたが、この提案は 1 年以上古いままでした。 他の更新には、[27] の方が優先されます。 互換性から得られるもう 1 つの重要な利点は、既存のクライアントの再利用です: Optimism は、わずか約 800 行の違いがある独自のノードに geth のバージョンを使用します。 2014 年以来、開発、テスト、保守が行われています。堅牢なクライアントを持つことが重要です。 ネットワーク内で何が有効か無効として受け入れられるか。フォールトプルーフの実装におけるバグ システムにより、間違った証明が正しい証明として受け入れられたり、無効な証明が正しい証明として受け入れられたりする可能性があります。 ブロックが不正なものとして受け入れられ、システムが危険にさらされる可能性があります。このタイプの可能性は より幅広いクライアントの多様性により攻撃を制限できます: Optimism は取得に加えて再利用できます。 他の Ethereum クライアントはすでに保守されており、別の Erigon ベースのクライアントの開発が行われています。 すでに進行中です。 2016 年に、geth のメモリ管理の問題が悪用されました。 DoS 攻撃と防御の第一線は、2 番目に多いパリティの使用を推奨することでした。 当時使用されていたクライアント 5. StarkNet は有効性証明に関して同じ問題に直面していますが、クライアントは スクラッチから作成する必要があり、証明システムははるかに複雑になり、その結果、 また、正確性を保証するのははるかに複雑です。

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.

結論

  1. 結論 ロールアップは、スケーラビリティの問題を解決するために現在利用できる最も有望なソリューションです。 分散型 blockchain は、モジュール型 blockchain の時代への道を開きます。 モノリシックblockchain。 主に、楽観的ロールアップまたは妥当性ロールアップのどちらを開発するかの選択が示されています。 複雑さと機敏性の間のトレードオフとして。 StarkNet には、高速などの多くの利点があります。 引き出し、無効な状態遷移が構造的に不可能であること、取引コストが低いこと 開発期間が長くなり、EVM との互換性がないため、Optimism は ネットワーク経済を活用して、市場で急速に大きなシェアを獲得しました。 Optimism ただし、Bedrock は、Validity になることを可能にするモジュラー設計を備えています。 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

将来のロールアップ: Cannon は現在、フォールトプルーフのために MIPS にコンパイルされた minigeth を使用しています システムですが、同じアーキテクチャを使用して回路を取得し、有効性証明を作成することができます。 EVM などの複雑なマシンをマイクロアーキテクチャ用にコンパイルすると、より単純になります。 アップグレードの場合に回路を変更したり再検証したりする必要がありません。 RISCゼロは、 RISC-V に基づいてすでに開発中の STARK 証明を備えた検証可能なマイクロアーキテクチャ MIPS [28] の代わりに、この目的に使用できます。 過小評価すべきではない側面の 1 つは、どのようにして、 テクノロジーは機能します。従来の blockchain の強みは、状態を確認できることです。 第三者エンティティを信頼せずに blockchain を実行します。ただし、StarkNet の場合は、 さまざまなコンポーネントを検証できない場合に実装を信頼する必要がある 暗号化と高度な数学に基づいています。これにより、最初は摩擦が生じる可能性があります。 テクノロジーの導入は進んでいますが、完全性証明のツールと使用法が進歩するにつれて、 blockchain フィールドの外では、この問題は解決されることが期待されます。