Optimism 技術文書

概要

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

導入

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

楽観的なロールアップ

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. 有効性ロールアップ 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. 比較 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. 結論 ロールアップは、スケーラビリティの問題を解決するために現在利用できる最も有望なソリューションです。 分散型 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 フィールドの外では、この問題は解決されることが期待されます。