ホワイトペーパー ストーリー 図 用語集 グラフ 検索

Optimism 技术文档

著 Optimism Collective · 2021

単一表示 community.optimism.io

Optimismには従来のホワイトペーパーがありません。Ethereum Layer 2のオプティミスティックロールアップとして、その設計と仕様は単一の正式な学術論文ではなく、技術文書、OP Stack仕様書、リサーチ投稿を通じて文書化されています。

🇺🇸 English (原文)
🇨🇳 中文简体 (翻訳)

概要

この論文では、トランザクション スループットとノードを実行するためのハードウェア要件との間のトレードオフを分析することで、分散型 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 は...を定義します。

摘要

本文通过分析交易吞吐量和运行节点的硬件要求之间的权衡，解决了去中心化 blockchain 的可扩展性问题。 Rollups，即对链下执行的区块进行链上验证的技术，以故障或有效性证明的形式呈现。我们在提款时间、交易成本、优化技术以及与 Ethereum 生态系统的兼容性方面比较了乐观汇总和有效性汇总。我们的分析表明，Optimism Bedrock 目前的气体压缩率约为 20:1，而 StarkNet 的存储写入成本压缩率约为 24:1。我们还讨论了进一步优化这些速率的技术，例如缓存合约和布隆过滤器的使用。最终，我们的结论强调了在乐观汇总和有效性汇总之间选择时复杂性和敏捷性之间的权衡。关键词 区块链、可扩展性、Rollup 1. 简介 区块链技术因其彻底改变各个行业的潜力而受到广泛关注。然而，可扩展性仍然是一个重大挑战，因为大多数 blockchain 面临可扩展性、去中心化和安全性之间的权衡，通常称为可扩展性三难困境 [1, 2]。要增加 blockchain 的吞吐量，一个简单的解决方案是增加其块大小。在 Ethereum 的上下文中，这意味着增加一个区块可以容纳的最大气体量。由于每个全节点必须验证每个块的每笔交易，因此随着吞吐量的增加，硬件要求也会增加，从而导致网络更加集中。一些 blockchain，例如 Bitcoin 和 Ethereum，优化其设计以最大化其架构去中心化，而其他 blockchain，例如币安智能链和 Solana，则被设计为尽可能快速和便宜。去中心化网络人为地限制 blockchain 的吞吐量，以降低参与网络的硬件要求。多年来，人们一直在尝试寻找解决三难困境的方法，例如状态通道 [3] 和 Plasma [4, 5]。这些解决方案的特点是将一些活动移至链下，使用 smart contracts 将链上活动与链下活动链接起来，并验证 DLT 2023：第五届分布式账本技术研讨会，2023 年 5 月 25-26 日，意大利博洛尼亚 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) Donno) 0000-0001-9221-3529 (L. Donno) © 2023 本文版权归其作者所有。根据 Creative Commons License Attribution 4.0 International (CC BY 4.0) 允许使用。 CEUR 研讨会论文集 http://ceur-ws.org ISSN 1613-0073 CEUR 研讨会论文集 (CEUR-WS.org) 链上发生的事情链下。然而，Plasma 和状态通道对通用 smart contract 的支持都是有限的。 Rollup 是 blockchain（称为 Layer 2 或 L2），它们在另一个 blockchain （Layer 1 或 L1）上发布其块，因此继承其共识、数据可用性和安全属性。与其他解决方案不同，它们支持任意计算。 Rollups 具有三个主要组件： • 定序器：从用户接收 Rollup 交易并将其组合成一个块并发送到 Layer 1 的节点。该块至少由状态根（例如 Merkle 根）和重建和验证状态所需的数据组成。 Layer 1 定义...

導入

  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 で描画します。 いくつかの結論。

介绍

一、简介 区块链技术因其革命性的潜力而受到广泛关注 各个行业。然而，可扩展性仍然是一个重大挑战，因为大多数 blockchain 都面临着 可扩展性、去中心化和安全性之间的权衡，通常称为 可扩展性三难困境 [1, 2]。为了提高 blockchain 的吞吐量，一个简单的解决方案是 增加其块大小。在 Ethereum 的上下文中，这意味着增加最大值 一个区块可以容纳的气体量。由于每个全节点必须验证每个交易的每笔交易 块，随着吞吐量的增加，硬件要求也增加，导致更大的 网络的集中化。一些 blockchain，例如 Bitcoin 和 Ethereum，优化了它们的 设计以最大化其架构去中心化，而其他人，例如 Binance Smart Chain 和 Solana 的设计目标是尽可能快速且便宜。去中心化网络 人为地限制 blockchain 的吞吐量，以降低硬件要求 参与网络。 多年来，人们一直在尝试寻找解决三难困境的方法，例如国家 通道 [3] 和 Plasma [4, 5]。这些解决方案具有移动某些活动的特点 链下，使用 smart contracts 将链上活动链接到链下活动，并验证 DLT 2023：第五届分布式账本技术研讨会，2023 年 5 月 25-26 日，意大利博洛尼亚 $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529（L.唐诺） © 2023 本文版权归作者所有。根据 Creative Commons License Attribution 4.0 International (CC BY 4.0) 允许使用。 欧洲欧元区 车间 会议记录 http://ceur-ws.org ISSN 1613-0073 CEUR 研讨会论文集 (CEUR-WS.org)链上正在发生链下的事情。然而，Plasma 和状态通道都受到限制 他们对 smart contract 将军的支持。 Rollup 是 blockchain（称为 Layer 2 或 L2），它们在另一个 blockchain 上发布其块 （Layer 1 或 L1），因此继承其共识、数据可用性和安全属性。他们， 与其他解决方案不同，支持任意计算。 Rollup 具有三个主要组件： • 排序器：从用户接收 Rollup 交易并将其组合成一个 发送到 Layer 1 的块。该块至少包含状态根（例如 Merkle root）以及重建和验证状态所需的数据。 Layer 1 定义 通过建立已发布数据的排序来规范 L2 的 blockchain 。 • Rollup全节点：从Layer获取、处理和验证Rollup块的节点 1、验证root是否正确。如果一个区块包含无效交易，那么 丢弃，这会阻止定序器创建包含无效块的有效块 交易。 • Rollup轻节点：从Layer 1获取Rollup块但不计算的节点 新国家本身。他们使用技术验证新的状态根是否有效 例如错误或有效性证明。 Rollups 通过将交易的摊余成本降低为数量来实现可扩展性 用户数量增加。这是因为确保 blockchain 有效性的成本呈次线性增长 关于单独验证交易的成本。汇总根据不同而不同 他们确保轻节点交易执行有效性的机制： Optimistic Rollups 通过经济模型和故障证明来保证，同时保持有效性 Rollups 使用有效性证明以加密方式确保。 轻节点可以在 Layer 1 上实现为 smart contracts。他们接受事物的根源 新状态并验证有效性或故障证明：因此这些 Rollup 称为智能合约 卷起。如果轻节点是独立的，则它们被称为主权卷[6]。优点 使用智能合约 Rollup 是为了能够在两者之间建立信任最小化的桥梁 blockchains：由于 L2 状态的有效性已向 L1 证明，因此交易系统 可以实现L2到L1，允许提现。缺点是成本较高 交易取决于验证 L1 状态的成本：如果基础层饱和 其他活动中，Rollup 上的交易成本也会增加。 数据层和共识层决定了系统的安全性 他们定义交易的顺序，防止攻击并提供数据来证明状态 有效性。 论文贡献 在本文中，我们研究了乐观和有效性汇总，这两个创新 可扩展性难题的解决方案，重点关注值得注意的实现，例如 Optimism Bedrock 和 StarkNet。我们的贡献包括对这些的全面比较 解决方案、提现时间分析以及对 Optimism 可能的攻击的讨论 基岩。此外，我们还计算它们的气体压缩比，提供特定于应用的优化，并介绍放弃 Ethereum 的优点和缺点 虚拟机 (EVM)。

纸张结构 本文的结构如下。在第 2 节中，乐观汇总是 通过分析 Optimism 基岩引入。在第 3 节中，有效性汇总由 分析 StarkNet。在第 4 节中，我们比较了这两种解决方案。最后，在第 5 节中我们绘制 一些结论。

楽観的なロールアップ

  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 によって実装され、データベースを置き換えます。他のノードに対してクエリが実行され、 プリイメージを取得します。

乐观汇总

  1. 乐观汇总 乐观地接受块的输出而不验证其执行的想法是 已经出现在 Bitcoin 白皮书 [7] 中，讨论了轻节点。这些节点仅遵循 头链通过验证共识规则，使它们容易受到接受块的影响 包含发生 51% 攻击时无效的交易。中本聪提议解决这个问题 通过使用“警报”系统来警告轻节点某个区块包含无效交易来解决这个问题。 该机制首先由 Al-Bassam、Sonnino 和 Buterin [8] 实现，其中一个故障 使用基于纠错码[9]的证明系统。为了能够创建 故障证明，所有块（包括无效块）的数据都必须可用 网络：这是数据可用性问题，可以使用概率数据来解决 抽样机制。第一个 Optimistic Rollup 设计由 John Adler 提出， Mikerah Quintyne-Collins 在 2019 年 [10]，其中区块发布在另一个 blockchain 上 这定义了他们对订购的共识。 2.1. Optimism 基岩 Bedrock [11] 是 Optimism（智能合约汇总）的最新版本。之前的版本， 乐观虚拟机 (OVM) 需要一个临时编译器将 Solidity 编译到其 自己的字节码：相比之下，Bedrock 完全等同于 EVM ，因为执行引擎 遵循 Ethereum 黄皮书规范 [12]。 2.1.1.存款 用户可以通过调用depositTransaction函数，通过Ethereum（Optimism门户）上的合约存入交易。 当一笔交易被执行时， 发出 TransactionDeposited 事件，Rollup 中的每个节点都会监听该事件并进行处理 存款。存入交易是源自 L1 的 L2 交易。如果呼叫者 函数是一个合约，地址通过添加一个常量值来转换：这可以防止 L1 上的合约与 L2 上的合约具有相同地址但代码不同的攻击。 存储交易包含在 L2 中是通过排序中的规范来确保的 窗口。 存入交易是新的EIP-2718兼容交易类型[13]，前缀为0x7E， 其中 rlp 编码字段是： • bytes32 sourceHash：hash，唯一标识交易源。 • 地址来自：发件人的地址。 • 地址：接收者地址，或零地址（如果存入的交易是 合同创建。• uint256 mint：要在L2 上创建的值。 • uint256 值：要发送给接收者的值。 • 字节数据：输入数据。 • bytes GasLimit：交易的gas 限制。 sourceHash 计算为 L1 块 hash 的 keccak256 hash 和 L1 日志 索引，唯一标识块中的事件。 由于存入的交易是在L1上发起但在L2上执行的，所以系统需要一个 向 L1 支付 L2 所花费的 Gas 的机制。一种解决方案是通过门户发送 ETH， 但这意味着每个呼叫者（甚至间接呼叫者）都必须标记为应付，这是 对于许多现有项目来说这是不可能的。另一种方法是在 L1 上燃烧相应的气体。 分配给存入交易的gas𝑔称为保证gas。 L2 汽油价格 L1 不会自动同步，而是使用类似于 EIP-1559 的机制进行估计 [14]。每个 Ethereum 区块保证的最大 Gas 量为 800 万，目标 200万。在 L2 上支付 Gas 费用所需的 ETH 数量为 𝑐= 𝑔𝑏L2，其中 𝑏L2 是 L2 的基本费用。 L1 上的合约燃烧的 Gas 量等于 𝑐/𝑏L2。打电话所花费的gas 存款交易在 L2 上偿还：如果该金额大于保证气体， 没有气体被燃烧。 rollup区块的第一笔交易是L1属性存入交易，用于注册 在 L2 上预部署 Ethereum 块的属性。预部署提供的属性 访问的是区块号、时间戳、基本费用、区块 hash 和序列 number，L2 相对于关联的 L1 区块的区块编号（也称为纪元）； 当新纪元开始时，该数字会重置。 2.1.2.测序 Rollup 节点完全从 Ethereum 派生出 Optimism 链。这条链条被延长了 每次在 L1 上发布新交易时，每次都会重新组织其区块 Ethereum 块被重新组织。 Rollup blockchain 分为多个纪元。对于每个 𝑛 区块号为Ethereum，有对应的𝑛纪元。每个纪元至少包含一个 一个 epoch 中的每个区块都包含一个 L1 属性的存入交易。第一个区块 一个纪元包含通过门户存入的所有交易。 Layer 2 块也可能 包含排序交易，即直接发送到排序器的交易。 排序器接受用户的交易并构建区块。对于每个块，它构造 一批将在 Ethereum 上发布。可以以压缩方式发布多个批次， 采取名称频道。一个通道可以分成几个帧，以防通道太大 单笔交易。通道被定义为使用 RLP 编码的 ZLIB [15] 进行压缩 批次。批次的字段包括纪元号、纪元 hash、父代 hash、 时间戳和交易列表。 一个由 epoch 标识的排序窗口，包含固定数量 𝑤 的连续 L1 推导步骤将其作为输入来构造可变数量的 L2 块。对于 纪元𝑛，排序窗口𝑛包括块[𝑛，𝑛+𝑤）。这意味着排序 排序窗口内的 L2 事务和块的数量直到窗口结束才固定。 如果包含 rollup 的交易已在 L1 上得到确认，则该交易被称为安全交易。镜框从 L1 块中读取以重建批次。当前的实现不允许 开始对通道进行解压缩，直到接收到所有相应的帧。无效 批次被忽略。单个区块交易是从批次中获得的，这些交易是 执行引擎使用它来应用状态转换并获取 Rollup 状态。 2.1.3.提款 为了处理提款，实施了 L2 到 L1 消息传递系统。 Ethereum 需要知道 L2 的状态才能接受提款，这是通过发布来完成的 L2 输出 Oracle smart contract 在 L1 上每个 L2 块的状态根。这些根 如果在期间没有执行故障证明，则乐观地认为是有效的（或最终确定的） 争议期。只有指定为提议者的地址才能发布输出根。有效性 的输出根是通过让提案者存入股份来激励的，如果他们 显示提出了无效的根。交易是通过调用该函数发起的 在 L2 上的预部署上启动撤回，然后通过调用该函数在 L1 上完成 FinalizeWithdrawalTransaction 在前面提到的 Optimism 门户上。 从L2 Output Oracle中获取L2块对应的输出根；是的 核实已最终确定，即争议期已过；经验证，输出 根证明与预言机证明相匹配；经核实，已包含提款的hash 使用提款证明；撤回尚未最终确定；然后是 使用指定的气体限制、以太币数量和数据执行对目标地址的调用。 2.1.4. Cannon：防故障系统 如果 Rollup Full Node 通过本地执行批次和存入交易发现 Layer 2 状态与提议者在链上发布的状态根不匹配，它可以执行 L1 上的故障证明，证明块转换的结果不正确。因为 开销，在 L1 上处理整个 Rollup 块的成本太高。实施的解决方案 by Bedrock 的目的是仅在链上执行 minigeth 不一致的第一条指令， 将其编译成 MIPS 架构，在链上解释器上执行并发布 在 L1 上。 minigeth是geth 1的简化版本，其中共识、RPC和数据库 已被删除。 为了找到第一个不一致的指令，在之间进行交互式二分搜索 发起故障证明的人和发布输出根的人。当证明 开始，双方在执行中途发布 MIPS 内存状态的根 挑战合约上的区块：如果 hash 匹配，则意味着双方都同意 执行的前半部分，从而发布后半部分的根，否则一半 上半年已出版等等。这样做就实现了第一个分歧指令 与原始执行相比，步骤数为对数。如果两者之一停止 互动时，在争议期结束时，另一方自动获胜。 为了处理该指令，MIPS 解释器需要访问其内存：因为根是 可用时，可以通过证明其包含性来发布必要的存储单元。访问 EVM 的状态，使用原像 Oracle：给定它返回的块的 hash 1https://geth.ethereum.org/docs

块头，从中可以获取前一个块的 hash 并返回到 链，或者获取可以获取原像的状态和日志的 hash 。 oracle 由minigeth实现并取代数据库。向其他节点进行查询 获得原像。

有効性ロールアップ

  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) と呼ばれる

有效性汇总

  1. 有效性汇总 有效性汇总的目标是以密码方式证明状态转换的有效性 给定具有可进行亚线性比较验证的简短证明的交易序列 到原始计算的时间。 此类证书称为计算完整性证明，实际上是通过 SNARK（简洁非交互式知识论证）实现的，它使用算术 电路作为他们的计算模型。不同的 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 上发布它们。在当前版本中，因为 Sequencer 由 StarkWare 集中管理，存入交易的成本 仅由执行存款的成本决定。该费用通过将 ETH 发送至 发送消息到L2。这些以太币仍然锁定在 L1 上，并在 L1，当存入的交易包含在状态转换中时。发送的 ETH 数量，如果 无论消耗的 Gas 量如何，存入的交易都已包含在内并已全部花费 在 L2 上。 StarkNet 没有一个系统可以自动使 L1 块属性可用。 另外，Fossil 是由 Oiler Network 2 开发的协议，允许给定 hash 块，通过发布原像从 Ethereum 获得的任何信息。 2https://www.oiler.network/3.1.2.测序 StarkNet 的当前状态可以完全从 Ethereum 导出。任何状态差异 转换之间作为 calldata 在 L1 上发布。每个合同的差异均已公布 并保存为 uint256[]，编码如下： • 涉及合同部署的领域数量。 • 对于每份已发布的合同： – 已发布合约的地址。 – 已发布合同的 hash。 – 合约构造函数的参数数量。 – 构造函数参数列表 • 存储已修改的合约数量。 • 对于每份已修改的合同： – 修改后的合约的地址。 – 存储更新的数量。 – 存储地址与新值的键值对。 状态差异是按顺序发布的，因此按顺序读取它们就足够了 重建国家。 3.1.3.提款 要从 L2 向 L1 发送消息，请使用系统调用 send_message_to_L1。消息是 通过增加其 hash 计数器以及证明来发布到 L1，并通过调用 L1 上 StarkGate smart contract 上的函数 ConsumerMessageFromL2 会递减 柜台。任何人都可以完成任何提款。 3.1.4.有效性证明 Cairo 虚拟机 [19] 旨在促进 STARK 证明的构建。 开罗语言允许用高级编程来描述计算 语言，而不是直接作为电路。这是通过多项式方程组来完成的 3 代表单个计算：冯诺依曼架构的 FDE 循环。数量 因此，约束的数量是固定的，并且与计算类型无关，仅允许一个 每个需要证明其计算的程序的验证程序。 StarkNet 使用共享证明者将多个交易聚合到单个 STARK 证明中 名为夏普。证明将发送至 Ethereum 上的 smart contract，以验证其有效性 并更新与新状态对应的 Merkle 根。验证一个的次线性成本 有效性证明允许其成本在多个交易中摊销。 3称为代数中间表示（AIR）

比較

  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 は有効性証明に関して同じ問題に直面していますが、クライアントは スクラッチから作成する必要があり、証明システムははるかに複雑になり、その結果、 また、正確性を保証するのははるかに複雑です。

比较

  1. 比较 4.1.提款时间 区分乐观汇总和有效性汇总的最重要方面是 提款初始化和结束之间经过的时间。在这两种情况下， 提款在 L2 上初始化并在 L1 上完成。在 StarkNet 上，最终确定是可能的： 一旦新状态根的有效性证明在 Ethereum 上被接受：理论上，它是 初始化后可以在 L1 第一个区块中提取资金。在实践中， 在 Ethereum 上发送有效性证明的频率是区块速度之间的权衡 最终确定和证明聚合。目前StarkNet提供有效性证明以供验证 每 10 小时 4，但计划随着交易活动的增加而减少。 在 Optimism Bedrock 上，只有在争议结束时才有可能最终确定提款 期限（当前为 7 天），之后根自动被视为有效。长度为 这个时期主要是由以下事实决定的：故障证明可以在 Ethereum 上进行审查，直到 它的结束。随着时间的增加，此类攻击的成功概率呈指数下降： E[减去值] = 𝑉𝑝𝑛 其中𝑛是一个区间内的区块数量，𝑉是可以减去的资金量 通过发布无效根，𝑝是成功执行审查的概率 在单个块中进行攻击。假设这个概率是 99%，即 Rollup 中锁定的值 是一百万个以太币，一个时间间隔内的区块是 1800 个（6 小时的区块，12 个区块） 秒间隔）：预期值约为 0.01391 以太。该系统的安全性是通过 要求提案者抵押比预期值多得多的以太币。 温泽等人。展示了如何使用简单的 smart contract 进行审查攻击 确保状态中的某些内存区域不会更改 [20]。对攻击进行建模 作为马尔可夫博弈，本文表明审查是理性的占优策略 如果区块生产者获得的补偿多于包含更改的交易 记忆。上面讨论的𝑝值可以看作是有理块的百分比 网络中的生产者，其中“理性”没有考虑可能的惩罚 外部性，例如对 blockchain 的信任度降低，从而降低了其加密货币的价值。 以下代码呈现了可用于执行审查攻击的 smart contract 在基岩上。该攻击通过向区块生产者提供贿赂来利用他们的动机 审查会修改国家特定部分的交易。合同主要内容 ClaimBribe 函数允许区块生产者在成功审查后索取贿赂 通过检查是否未触及无效的输出根来确定目标交易。 函数 ClaimBribe(字节内存 storageProof) 外部 { require(!claimed[block.number], "已索取贿赂"); OutputProposal 内存当前 = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, 存储证明）； require(invalidOutputRoot == current.outputRoot, "攻击失败"); 声称[区块数] = true; (bool 发送, ) = block.coinbase.call{值: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, "发送以太币失败"); } 清单 1：激励对 Bedrock 进行审查攻击的合约示例。 争议期限的长短还必须考虑到过错证明是 交互式证明，因此必须为参与者提供足够的时间进行交互 并且任何互动都可能受到审查。如果最后一次移动发生的时间非常接近 争议期结束后，审查成本明显减少。虽然审查是 占优策略，成功的可能性较低，因为审查节点容易受到 拒绝服务攻击：攻击者可以生成非常复杂的交易，并以 免费发布故障证明，因为无需支付任何费用。 在极端情况下，较长的争议期可以在成功解决问题后进行协调 审查攻击，组织分叉并排除攻击区块生产者。另一个 可能的攻击在于发布比争议者可以验证的更多的国家根提案， 可以使用频率限制来避免这种情况。 4.1.1.快速乐观提款 由于任何全节点都可以随时验证 Optimistic Rollup 的有效性，因此 受信任的 oracle 可用于在 L1 上了解提款是否可以安全完成。这个 机制最初由 Maker [21] 提出：oracle 验证提现，发布 L1 上的结果，在该结果上将计息贷款分配给用户，该结果自动 7 天后关闭，即提款可以实际完成时。这个解决方案 引入了信任假设，但在 Maker 的情况下，由于 oracle 运算符，它被最小化 由通过提供贷款承担风险的同一组织管理。 4.2.交易成本 L2 交易的成本主要由与 L1 的交互决定。在两种解决方案中 交易的计算成本非常便宜，因为它完全在链下执行。 Optimism 将 L2 事务 calldata 发布为 calldata 并且很少（或从不）执行错误 证明，因此 calldata 是最昂贵的资源。 2022 年 1 月 12 日，基岩网络 已在 Ethereum 的 Goerli 测试网上启动。可以计算气体压缩率 通过跟踪特定时期内基岩上使用的气体量并将其与 相应区块的 L1 上花费的 Gas 量。使用这种方法进行气体压缩 发现比率为 ∼20 : 1，但该数字可能与主网上的实际活动有所不同。 StarkNet 在 Ethereum 上发布 L2 状态的每个更改作为 calldata，因此存储是 最昂贵的资源。由于网络不使用EVM，交易成本 压缩不能简单地估计。通过假设执行成本和调用数据 可以忽略不计，可以计算出存储写入的压缩比 L1。假设没有部署合约，并且之前未在 StarkNet 上访问过的 10 个单元格 修改后，发现存储写入成本压缩率为~24：1。如果单元格被覆盖 数据发布之间的𝑛次，每次写入的成本将是成本的1/𝑛 一次写入，因为仅发布了最后一个写入。成本可以通过以下方式进一步最小化压缩常用值。有效性证明验证的成本分为 它所指的交易：例如，StarkNet区块4779包含200笔交易及其 有效性证明消耗 267830 个单位的 Gas，即每笔交易消耗 1339.15 个 Gas。 4.2.1.优化calldata：缓存合约 下面介绍的是 smart contract，它实现了经常使用的地址缓存 通过利用存储和执行成本便宜得多的事实来解决问题 资源，以及演示其用途的 Friends 合约。后者跟踪 可以通过调用 addFriend 函数注册的地址的“好友”。如果一个地址 已经至少使用过一次，可以通过调用addFriendWithCache来添加 功能：缓存索引是4字节整数，而地址是20字节表示， 因此函数参数节省了 5:1。相同的逻辑可以用于其他数据 类型，例如整数或更一般的字节。 合约地址缓存 { 映射（地址=> uint32）公共地址2key； 地址[]公钥2地址； 函数cacheWrite（地址_地址）内部返回（uint32）{ require(key2address.length < type(uint32).max, "AddressCache: 缓存已满"); require(address2key[_address] == 0, "AddressCache: 地址已缓存"); // 键必须从 1 开始，因为 0 表示“未找到” uint32 key = uint32(key2address.length + 1); 地址2键[_地址] = 键； key2address.push(_address); 返回键； } 函数cacheRead(uint32 _key)公共视图返回(地址){ require(_key <= key2address.length && _key > 0, "AddressCache: 找不到密钥"); 返回 key2address[_key - 1]; } } 清单 2：地址缓存合约。 合约好友是AddressCache { 映射（地址=>地址[]）公众好友； 函数 addFriend(地址_friend) 公共 { 朋友[msg.sender].push(_friend); 缓存写入(_friend); } 函数 addFriendWithCache(uint32 _friendKey) 公共 { 朋友[msg.sender].push(cacheRead(_friendKey)); } 函数 getFriends() 公共视图返回 (address[] memory) { 返回好友[msg.sender];} } 清单 3：继承地址缓存的合约示例。 该合约在缓存中支持大约 40 亿（232）个地址，并且添加一个字节给出 约 1 万亿 (240)。 4.2.2.优化存储：Bloom 过滤器 在 StarkNet 上有多种技术可以最大限度地减少存储使用。如果没有必要的话 保证原始数据的可用性，那么将其 hash 保存在链上就足够了：this 是用于保存 ERC-721 (NFT) [22] 数据的机制，即解析 数据的 hash（如果有）。对于多次存储的数据，可以使用查找 表类似于 Optimism 引入的缓存系统，要求将所有值保存在 至少一次。对于某些应用程序，可以通过使用布隆过滤器来避免保存所有值 [23,24,25]，即一种概率数据结构，可以让人们确定地知道是否 一个元素不属于一个集合，但承认有很小但不可忽略的错误概率 积极的一面。 布隆过滤器被初始化为 𝑚 位为零的数组。要添加元素，𝑘hash 函数 使用均匀随机分布，每个映射到设置的数组的一位
  2. 要检查某个元素是否属于集合，我们运行 𝑘hash 函数并验证 𝑘位设置为 1。在简单的布卢姆过滤器中，无法区分是否是 元素实际上属于该集合或者是误报，概率随着数量而增长 条目数量增加。插入𝑛元素后： P[假阳性] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 假设每个位组的概率独立。如果 𝑛 元素（任意大小！）是 预期包含在内，并且容忍误报的概率是 𝑝，即数组的大小 可以计算为： 𝑚= −𝑛ln 𝑝 (ln 2)2 而 hash 函数的最佳数量是： 𝑘=𝑚 𝑛2 如果我们假设以 1% 的容差插入 1000 个元素，则数组的大小为 9585 位 𝑘= 6，而对于 0.1% 的容差，当 𝑘= 9 时，它变成 14377 位。如果一百万个元素 预计将被插入，数组的大小变为约 1170 kB（对于 1%）和 1775 kB（对于 1%） 0.1%，与 𝑘 的值相同，因为它仅取决于 𝑝[26]。 在游戏中，玩家不得被分配给他们已经挑战过的对手， 可以使用 Bloom 来保存过去对手的列表，而不是为每个玩家保存存储空间 过滤器。不挑战某些玩家的风险通常是可以接受的，并且可以重置过滤器 定期。4.3. Ethereum 兼容性 与 EVM 和 Ethereum 兼容的主要优点是重用所有可用的 工具。 Ethereum smart contracts 可以在 Optimism 上发布，无需任何修改，也不 新的审计。钱包保持兼容，开发和静态分析工具，一般分析 工具、索引工具和 oracles。 Ethereum 和 Solidity 有着悠久的深入研究历史 漏洞，例如重入攻击、溢出和下溢、闪贷和 oracle 操纵。正因为如此，Optimism 能够在短时间内获取大量价值 时间。 选择采用不同的虚拟机意味着必须重建整个生态系统， 具有更大的实施自由度的优点。 StarkNet 本机实现帐户 抽象，这是一种机制，每个帐户都是一个 smart contract ，可以实现 任意逻辑，只要它符合接口（因此称为抽象）：这允许 使用不同的数字签名方案，使用更改私钥的能力 相同的地址，或使用多重签名。 Ethereum 社区提议引入此功能 2020 年与 EIP-2938 的机制，但该提案已经过时了一年多，因为 其他更新已被赋予更高优先级[27]。 兼容性带来的另一个重要好处是现有客户端的重用：Optimism 使用 geth 版本作为自己的节点，只有 ∼800 行差异，这已被 自 2014 年以来开发、测试和维护。拥有强大的客户至关重要，因为它定义了 网络中哪些内容被认为有效，哪些内容无效。故障证明实施中的一个错误 系统可能会导致错误的证明被接受为正确的，或者正确的证明被无效的 块被认为不正确，从而损害系统。出现这种类型的可能性 可以通过更广泛的客户端多样性来限制攻击：Optimism 除了 geth 之外还可以重用 已维护其他 Ethereum 客户端，并且正在开发另一个基于 Erigon 的客户端 已经在进行中。 2016年，geth的内存管理问题被利用 DoS攻击的第一道防线是推荐使用Parity，第二道最 当时使用的客户端 5. StarkNet 面临同样的有效性证明问题，但是客户端 必须从头开始编写，证明系统要复杂得多，因此 确保正确性也要复杂得多。

結論

  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 フィールドの外では、この問題は解決されることが期待されます。

结论

  1. 结论 Rollups 是当今最有前途的解决方案，可解决可扩展性问题 去中心化的 blockchains，为模块化 blockchains 时代铺平了道路，而不是 整体 blockchains。 主要显示了开发 Optimistic Rollup 或 Validity Rollup 的选择 作为复杂性和敏捷性之间的权衡。 StarkNet 具有许多优点，例如速度快 提款、结构上无法进行无效的状态转换、较低的交易成本 开发周期较长且与 EVM 不兼容，而 Optimism 有 借助网络经济，迅速占领市场主要份额。 然而，Optimism Bedrock 拥有模块化设计，使其成为 Validity 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

未来的 Rollup：Cannon 目前使用编译为 MIPS 的 minigeth 来防止故障 系统，但可以使用相同的架构来获得电路并产生有效性证明。 为微架构编译复杂的机器（例如 EVM）会产生更简单的结果 升级时无需修改和重新验证电路。 RISC 零是 可验证的微架构，具有 STARK 证明，已基于 RISC-V 开发 可用于此目的作为 MIPS [28] 的替代。 不应低估的一个方面是理解如何实现这一目标的复杂性。 技术有效。传统 blockchains 的优点是能够验证 blockchain 而不信任任何第三方实体。然而，对于 StarkNet 来说，它是 当无法验证各个组件时，有必要信任实现 基于密码学和高等数学。这最初可能会产生摩擦 技术的采用，但随着工具和完整性证明的使用的进步，甚至 在 blockchain 字段之外，这个问题有望得到解决。