オプティミスティック・ロールアップ

オプティミスティック・ロールアップは、イーサリアム（ベースレイヤー）のスループットを拡張するために設計されたレイヤー2 (L2) プロトコルです。 トランザクションをオフチェーンで処理することで、イーサリアムメインネットの負荷を軽減するため、処理速度が大幅に改善されます。 オプティミスティック・ロールアップは、サイドチェーンのような他のスケーリング・ソリューションとは異なり、トランザクションの結果をオンチェーンで公開することによってメインネットからセキュリティを引き出します。プラズマチェーンも、不正証明を使用してイーサリアム上で検証しますが、トランザクションのデータをイーサリアムに保存しない点が異なります。

イーサリアムにおける処理は、速度が遅く高価であるという欠点がありますが、オプティミスティック・ロールアップを用いることでスケーラビリティを10〜100倍向上させることができます。 さらに、トランザクションをcalldataまたはブロブとしてイーサリアムに書き込むため、ユーザーが負担するガス代を低く抑えることができます。

前提知識

イーサリアムにおけるスケーリングとレイヤー2 のページを読み、理解しておくことをおすすめします。

オプティミスティック・ロールアップとは何か？

オプティミスティック・ロールアップとは、計算とステート保存をオフチェーンに移動させることで、スケーリングの問題を解決するアプローチです。 オプティミスティック・ロールアップでは、トランザクションをイーサリアムの外部で実行した上で、トランザクションデータをcalldataまたはブロブとしてメインネットに投稿します。

オプティミスティック・ロールアップのオペレータは、オフチェーンで実行された複数のトランザクションをバンドル化し、より大きなバッチとしてイーサリアムに送信します。 このアプローチでは、固定費を各バッチに含まれる複数のトランザクションに分散できるため、エンドユーザーの費用を軽減することができます。 さらに、データ圧縮技術を用いることで、イーサリアムに送信するデータ量を削減しています。

オプティミスティック・ロールアップが「楽観的」と呼ばれる理由は、オフチェーンのトランザクションが「有効」であると想定し、オンチェーンに送信されるバッチに含まれるトランザクションの有効性証明を公開しないからです。 これこそ、オフチェーンのトランザクションに対して暗号によるを発行するゼロ知識ロールアップと、オプティミスティック・ロールアップが異なるポイントです。

オプティミスティック・ロールアップでは、暗号による有効性証明の代わりに不正証明のスキームを用いて、正しく計算されていないトランザクションを検出します。 ロールアップされたバッチがイーサリアムに送信される際には、チャレンジ期間と呼ばれる一定の期間が設定されており、その期間内は誰もがを計算することで、ロールアップされたトランザクションの結果に異議を申し立てることができます。

不正証明が認められると、ロールアップのプロトコルにより当該のトランザクション（複数の場合あり）が再度計算され、その結果に基づきロールアップのステートが更新されます。 不正証明が認められた場合はさらに、不適切に実行されたトランザクションをブロックに追加したシーケンサーにペナルティが科されます。

チャンレンジ期間にロールアップされたバッチに対する異議申立が実行されない場合（つまり、すべてのトランザクションが正しく実行されている場合）、計算は正当と見なされ、イーサリアム上で承認されます。 他のユーザーは、未検証のロールアップブロックを引き続き使用することができますが、公開された実行済みのトランザクションが正しく計算されていない場合、それ以後のトランザクションの結果が取り消される点に注意が必要です。

オプティミスティック・ロールアップは、イーサリアムとどのようなやりとりを行うか？

オプティミスティック・ロールアップは、イーサリアム上で動作するように構築されたオフチェーンのスケーリング・ソリューションです。 個々のオプティミスティック・ロールアップは、イーサリアムメインネット上でデプロイされた一連のスマートコントラクトにより管理されます。 オプティミスティック・ロールアップでは、イーサリアムメインネットの外部でトランザクションを処理しますが、オフチェーンで処理したトランザクションを（バッチ化した上で）オンチェーンのロールアップ・コントラクトに送信します。 イーサリアムブロックチェーンと同様に、このトランザクション記録は改変不可であり、「オプティミスティック・ロールアップ・チェーン」を構築します。

オプティミスティック・ロールアップのアーキテクチャには、以下の構成要素が含まれています：

オンチェーンのコントラクト: オプティミスティック・ロールアップの動作は、イーサリアム上で実行されるスマートコントラクトにより制御されます。 具体的には、ロールアップされたブロックを保存するコントラクト、ロールアップの状態更新を監視するコントラクト、およびユーザーのデポジットを追跡するコントラクトが含まれます。 この意味で、イーサリアムは、オプティミスティック・ロールアップに対するベースレイヤー（つまり、「レイヤー1」）であると言うことができます。

オフチェーンの仮想マシン（VM）：オプティミスティック・ロールアップのプロトコルを管理するコントラクトはイーサリアム上で実行されますが、ロールアップのプロトコルにおける計算の実行と状態の保存はイーサリアム仮想マシンとは別の仮想マシン上で行われます。 このオフチェーンのVMは、アプリケーションが稼働し、状態変更が実行される場所であるため、オプティミスティック・ロールアップにおける上位レイヤー（つまり、「レイヤー2」）であると言えます。

オプティミスティック・ロールアップは、イーサリアム仮想マシン（EVM）用に開発／コンパイルされたプログラムを実行するように設計されているため、オフチェーンのVMはEVMの設計仕様の多くを踏襲しています。 また、イーサリアムネットワークは、オンチェーンで計算された不正証明を用いて、オフチェーンのVMで計算された状態変更の有効性を強制することができます。

オプティミスティック・ロールアップは、イーサリアムとは別個のプロトコルとして存在するものの、そのセキュリティ属性はイーサリアムに依存しているため、「ハイブリッド型のスケーリング・ソリューション」と呼ばれます。 特に、イーサリアムメインネットは、ロールアップにおけるオフチェーンでの計算の正しさと、この計算に用いられたデータの可用性を保証します。 このため、セキュリティをイーサリアムに依存しない、「純粋な」オフチェーンのスケーリング・プロトコル（例：サイドチェーン）と比較すると、オプティミスティック・ロールアップはよりセキュリティが堅牢であると言えます。

オプティミスティック・ロールアップでは、以下の事項につきイーサリアムメインネットのプロトコルに依存します：

データ可用性

すでに述べたように、オプティミスティック・ロールアップではトランザクションのデータをcalldataまたはブロブとしてイーサリアムに送信します。 ロールアップチェーンは送信されたトランザクションに基づき実行されるため、イーサリアムのベースレイヤーに含まれるコールデータの情報を用いて、どのユーザーでもロールアップのステートを実行し、状態遷移の正しさを検証することができます。

データ可用性が重要なのは、状態データにアクセスできないと、ロールアップにおける無効な操作に異議を申し立てる際に、必要な不正証明を作成することができたいからです。 イーサリアムがデータ可用性を保証するため、ロールアップのオペレータによる悪意の行動（例：無効なブロックの送信）が見過ごされる可能性が低くなります。

検閲耐性

オプティミスティック・ロールアップはさらに、検閲耐性についてもイーサリアムに依存します。 オプティミスティック・ロールアップでは、中央主権型のエンティティ (オペレーター) が、トランザクションの処理とイーサリアムへのロールアップブロックを送信する役割を担います。 これは、以下のような結果をもたらします：

• ロールアップのオペレーターは、自分が完全にオフライン化するか特定のトランザクションを含むブロックの作成を拒否することで、ユーザーを検閲 できる。

• ロールアップのオペレーターは、所有権のマークル証明に必要な状態データを隠匿することで、ロールアップのコントラクトに入金された資金の引き出しを停止することができる。 さらに、状態データを隠匿することでロールアップの状態を非公開にし、このロールアップとやりとりできないようにさせることができる。

オプティミスティック・ロールアップでは、オペレーターに対し、状態更新に関連したデータをイーサリアム上で公開するように強制することで、この問題を解消します。 ロールアップのデータをオンチェーンで公開させることで、以下のような利点が実現されます：

• オプティミスティック・ロールアップのオペレーターがオフラインになったりトランザクションのバッチ作成を停止した場合、他のノードは、利用可能なデータを用いてロールアップの最新状態を復元し、引き続きブロック作成を継続できる。

• 各ユーザーは、トランザクションデータを用いて資金の所有権を証明するマークル証明を作成できるため、ロールアップから各自の資産を引き出すことができる。

• 各ユーザーはさらに、トランザクションをシーケンサーに対してではなく、L1に送信できる。この場合シーケンサーは、正当なブロックを引き続き作成するために、一定期間内に送信されたトランザクションをブロックに追加する必要がある。

決済

オプティミスティック・ロールアップにおいてイーサリアムが担うもう一つの役割は、決済レイヤーとしての役割です。 決済レイヤーとは、ブロックチェーンのエコシステム全体の基礎となり、セキュリティを提供すると同時に、他のチェーン（本トピックにおいては、オプティミスティック・ロールアップ）における仲裁が必要な紛争に対して、客観的なファイナリティを提供します。

イーサリアムメインネットは、オプティミスティック・ロールアップにおいて不正証明を検証し、紛争を解消するハブの役割を担います。 さらに、ロールアップで実行されたトランザクションは、ロールアップのブロックがイーサリアム上で承認された後でなければ確定しません。 ロールアップのトランザクションは、イーサリアムのベースレイヤーで確定した後はロールバックできなくなります（チェーンの再編成というまれなケースを除く）。

オプティミスティック・ロールアップは、どのように実行されるのか？

トランザクションの実行と集約

各ユーザーは、オプティミスティック・ロールアップにおいてトランザクションの実行を担うノードである「オペレーター」にトランザクションを送信します。 オペレーターは、「バリデータ」あるいは「アグリゲータ」と呼ばれる場合もあり、複数のトランザクションを集約し、トランザクションのデータを圧縮した上で、イーサリアム上でブロックを公開します。

すべてのユーザーがバリデータを務めることができますが、オプティミスティック・ロールアップにおけるバリデータは、プルーフ・オブ・ステークのシステムと同様に、ブロックを作成する前にボンド（担保）を提供する必要があります。 このボンドは、バリデータが無効なブロックを送信したり、時間が経過しているが無効なブロックの上にブロックを構築した場合、（当該ブロック自体が有効であっても）没収されます。 オプティミスティック・ロールアップでは、このような暗号経済的なインセンティブを通じて、バリデータにおける正直な行動を保証しています。

オプティミスティック・ロールアップチェーン上の他のバリデータは、当該ロールアップの状態に対する各自のコピーを用いて、送信されたトランザクションを実行することが求められます。 バリデータにおける最終的な状態がオペレーターが提案した状態と異なる場合、オペレーターは不正証明の計算を開始することでチャレンジを申し立てることができます。

一部のオプティミスティック・ロールアップでは、パーミッションレスのバリデーター・システムを採用せず、単独の「シーケンサー」がチェーンを実行する場合もあります。 シーケンサーは、バリデータと同様に、トランザクションを処理し、ロールアップのブロックを作成した上で、ロールアップされたトランザクションをL1チェーン（イーサリアムメインネット）に送信します。

シーケンサーが通常のロールアップオペレーターと異なるのは、トランザクションの順序決定に対する権限がより大きいという点です。 さらに、シーケンサーはロールアップチェーンに対する優先アクセス権を持ち、オンチェーンのコントラクトにトランザクションを送信することができる唯一のエンティティとなります。 シーケンサー以外のノード、あるいは通常のユーザーが送信したトランザクションは、シーケンサーがそれらを新規バッチに追加するまでの間は、別個のインボックス上でキューに置かれた状態になります。

ロールアップブロックをイーサリアムに送信する

前述のように、オプティミスティック・ロールアップのオペレーターは、オフチェーンのトランザクションをバッチとしてバンドル化した上で、公証のためにイーサリアムに送信します。 このプロセスには、トランザクションの関連データを圧縮し、calldataまたはブロブとしてイーサリアム上で公開する作業が含まれます。

calldataは、スマートコントラクトにおける変更不可で非永続的な領域であり、ほぼメモリと同様に動作します。 calldataは、ブロックチェーンの履歴ログ(opens in a new tab)の一部としてオンチェーンで永続する一方で、イーサリアムの状態の一部としては保存されません。 calldataはイーサリアムの状態にまったく干渉しないので、状態よりもオンチェーンでのデータ保存に伴う費用が安価になります。

さらに、calldataのキーワードは、スマートコントラクトの実行時にSolidity上の関数に引数を渡す際にも用いられます。 calldataは、トランザクションにおいて呼び出された関数を特定し、この関数に対する入力を任意のバイト列として保持します。

オプティミスティック・ロールアップにおけるcalldataは、オンチェーンのコントラクトにトランザクションの圧縮データを送信するために使用されます。 ロールアップのオペレーターは、ロールアップのコントラクトに含まれる必須の関数を呼び出し、関数の引数として圧縮データを渡す方法によって新規バッチを追加します。 ロールアップに伴うコストの大部分はオンチェーン上でのデータ保存に伴うものであるため、calldataの使用はユーザーの手数料を軽減します。

この例(opens in a new tab)では、ロールアップのバッチ送信においてこのコンセプトがどのように機能するのかを確認できます。 シーケンサーがappendSequencerBatch()メソッドを呼び出し、calldataを用いて、トランザクションの圧縮データを入力として渡します。

一部のロールアップは現在、トランザクションのバッチをイーサリアムへ投稿するのにブロブを使っています。

ブロブは、変更不可能で非永続的(calldataと同様)ですが、約18日後に履歴から削除されます。 ブロブの詳細については、ダンクシャーディングをご覧ください。

状態コミットメント

オプティミスティック・ロールアップのステート（アカウント、残高、コントラクトのコード等）は常に、「ステートツリー」と呼ばれるマークルツリーとして構造化されます。 このマークルツリーのルート（ステートルート）は、ロールアップにおける最新の状態を参照しており、ロールアップのコントラクトにおいてハッシュ化されて保存されます。 ロールアップチェーンにおける状態遷移は常に新規のロールアップステートを生成し、オペレーターは新しいステートルートを計算することでこれにコミットします。

オペレーターは、バッチ送信時において、新旧両方のステートルートを送信する必要があります。 古い方のステートルートがオンチェーンのコントラクトにおける既存のステートルートと一致する場合、既存のステートルートを破棄し、新しいステートルートで置き換えます。

ロールアップのオペレーターはさらに、トランザクションバッチ自体のマークルルートに対してもコミットする必要があります。 これにより、どのユーザーも、マークル証明を提示することでL1上のバッチに当該トランザクションが追加されていることを証明することができます。

状態へのコミットメントは、特にステートルートの場合、オプティミスティック・ロールアップにおける状態遷移の正しさを証明するために必要です。 ロールアップのコントラクトは、オペレーターから送信された時点で新規のステートルートを受け入れますが、無効なステートルートを事後に削除し、ロールアップを正しい状態に復元することが可能です。

不正証明

前述のように、オプティミスティック・ロールアップでは、どのユーザーでも有効性証明を提供せずにブロックを公開することができます。 しかし、ロールアップチェーンの安全性を維持するために、どのユーザーも状態遷移に対する異議申立を行える期間が設定されています。 どのユーザーでもブロックの正当性に対して異議を申し立てられるため、ロールアップブロックは「アサーション」（主張）と呼ばれます。

アサーションに対して異議が申し立てられると、ロールアップ・プロトコルにより不正証明の計算が開始されます。 不正証明はその種類を問わず双方向性のやりとりを要するため、異議を申し立てるにはまず他のユーザーがアサーションを送信していなければなりません。 不正証明における各アプローチの違いは、その計算を行うにあたり何回のやりとりが必要とされるかです。

1回のやりとりを要求する証明スキームでは、異議申立の対象であるトランザクションをL1上で再生し、無効なアサーションを検出します。 ロールアップのプロトコルでは、異議申立の対象であるトランザクションに対するL1（イーサリアムメインネット）上での再実行につき、検証者のコントラクトを用いてエミュレートし、計算されたステートルートによりこの異議申立における勝者を決定します。 異議申立者によるロールアップの正しい状態についての主張が認められた場合、オペレーターに対してはボンドの没収（スラッシング）によるペナルティが科せられます。

ただし、不正検出のためにL1上でトランザクションを再実行するには、個別トランザクションに対する状態コミットメントを公開しなければならないため、ロールアップがオンチェーン上で公開しなければならないデータ量が増加します。 さらに、トランザクションの再実行はかなりのガス代を伴います。 これらの理由により、オプティミスティック・ロールアップでは複数回にわたるやりとりを通じた証明に移行中であり、これにより、無効なロールアップ操作を検出するという同じ目的をより効率的に実現できるようになるでしょう。

複数回のやりとりによる証明

複数回のやりとりによる証明では、L1上の検証者コントラクトがアサーター／チャレンジャー間のやりとりのプロトコルを監視し、このコントラクトが最終的に虚偽のユーザーを決定します。 L2上のノードが特定のアサーションに対してチャレンジを行うと、このアサーションを行ったアサーターは、異議申立のアサーションを二等分しなければなりません。 これにより、二等分されたアサーションは、それぞれがもう一方のアサーションと同数の計算ステップを含むことになります。

次にチャレンジャーが、どちらのアサーションに異議を申し立てるかを選択します。 この分割プロセス（「二分割プロトコル」と呼ぶ）は、両当事者による紛争の対象が単独の実行ステップに対するアサーションになるまで継続されます。 対象が単独の実行ステップになった時点で、L1上のコントラクトが不正な当事者を発見するための命令（および結果）を判定し、紛争が解決されます。

アサーターは、紛争の対象であるシングルステップ計算の正当性を証明するための「ワンステップ証明」を提供しなければなりません。 アサーターがこのワンステップ証明を提供できない場合、あるいはL1上の検証者により当該証明が無効であると判定された場合、アサーターの申立は棄却されます。

この種類の不正証明に関する注記：

1. 複数回のやりとりによる不正証明は、L1チェーン上における紛争仲裁の作業量を最小化できるために効率的だと考えられています。 L1チェーン上では、トランザクション全体を再生する必要はなく、ロールアップ実行における特定のステップのみを再実行すればよいからです。

2. 二分割プロトコルは、オンチェーンに送信するデータ量を軽減します（トランザクションごとに状態コミットメントを送信する必要がないためです）。 さらに、オプティミスティック・ロールアップのトランザクションは、イーサリアムのガス上限による制限を受けません。 反対にトランザクションを再実行するオプティミスティック・ロールアップの場合は、イーサリアムメインネット上の1回のトランザクションで実行をエミュレートできるように、L2のトランザクションにおいてガス上限がより低く設定されていることを確認する必要があります。

3. 悪意のアサーターが提供したボンドの一部はチャレンジャーに付与され、残りはバーンされます。 残余のボンドをバーンすることで、バリデータ間の共謀を防ぐことができます。2名のバリデータが共謀して虚偽のチャレンジを開始した場合、彼らがステーキングした資産のうちかなりの部分が没収されるからです。

4. 複数回のやりとりによる証明では、アサーターとチャレンジャーの両者は指定された期間内にアクションを実行する必要があります。 期限までにアクションを実行しない場合、不履行の当事者の主張が退けられます。

オプティミスティック・ロールアップにおいて不正証明が重要である理由

不正証明は、オプティミスティック・ロールアップにおいてトラストレスなファイナリティを強化する上で重要です。 トラストレスなファイナリティとは、有効なトランザクションは最終的に承認されるというオプティミスティック・ロールアップの特性を指す概念です。

悪意のノードは、正当なロールアップブロックに対して、虚偽のチャレンジを開始することでその正当性確認を遅延させることができます。 しかし最終的に、不正証明によりロールアップブロックの正当性が証明され、有効化されます。

この点は同時に、正直なノードが少なくとも1つ存在しなければロールアップチェーンの正当性を保持できないという、オプティミスティック・ロールアップにおけるもう一つのセキュリティ特性に関連しています。 正直なノードは、有効なアサーションを送信するか、無効なアサーションに対して異議申立を行うことで、チェーンを適切に前進させることができます。 いずれの場合でも、正直なノードに対して異議を申し立てる悪意のノードは、不正証明プロセスを通じてステークを失うことになります。

L1とL2の相互運用性

オプティミスティック・ロールアップは、イーサリアムメインネットとの相互運用性を念頭において開発されており、ユーザーはメッセージや任意のデータをL1／L2間でやりとりできます。 また、EVMとの互換性も提供されるため、既存のDappをオプティミスティック・ロールアップに移植したり、イーサリアム開発ツールを用いて新規のDappを開発することができます。

1. 資産の移動

ロールアップに参加する

オプティミスティック・ロールアップの利用を開始するには、当該ロールアップのL1上のブリッジコントラクトに対して、ETH、ERC-20トークン、あるいはその他の受け入れ可能な資産を入金します。 このブリッジコントラクトは、当該トランザクションをL2にリレーし、L2において同価値の資産をミントした上で、ユーザーがオプティミスティック・ロールアップで指定したアドレスにその資産を送信します。

ユーザーが作成したトランザクション（L1からL2への入金など）は通常、シーケンサーがロールアップのコントラクトに再提出するまではキュー上で保留されます。 ただし、検閲耐性を維持するために、キュー保留の上限期間を超えて遅延した場合は、トランザクションをオンチェーンのロールアップコントラクトに直接送信することが認められています。

一部のオプティミスティック・ロールアップでは、シーケンサーによるユーザーの検閲を防止するためにより明確なアプローチが採用されています。 このアプローチを採用したロールアップでは、ロールアップチェーン上で処理されたトランザクションに加えて、直前のブロック（例：入金）以降にL1上のコントラクトに送信されたすべてのトランザクションにより、ブロックが定義されます。 シーケンサーがL1上のトランザクションを無視する場合、（おそらく）正しくないステートルートを公開することになるため、シーケンサーは、ユーザーが作成したメッセージをL1に送信した以降にこれを遅延することが不可能になります。

ロールアップから出金する

不正証明スキームが存在するため、オプティミスティック・ロールアップからイーサリアムに出金するプロセスはより複雑になっています。 L1にエスクローされた資金を引き出すためにL2からL1へのトランザクションを開始する場合、ユーザーは約7日間のチャレンジ期間が経過するのを待つ必要があります。 それ以外の点では、出金プロセス自体は非常にシンプルです。

L2上のロールアップで出金リクエストを開始すると、当該トランザクションが次のバッチに追加され、ロールアップ上のユーザー資産がバーンされます。 このバッチがイーサリアム上で公開されると、ユーザーは、ブロックに出金トランザクションが含まれることを証明するマークル証明を計算できるようになります。 その上で、遅延期間の終了と共に、L1上でトランザクションが確定し、メインネットに資金を移動させることができます。

イーサリアムメインネットへの出金において要求される1週間の待機期間を回避するために、オプティミスティック・ロールアップのユーザーは流動性プロバイダー（LP）を利用することもできます。 流動性プロバイダーとは、手数料を代価として、保留されているL2からの出金に対して所有権を引き継ぎ、L1上でユーザーに資金を提供するサービスです。

流動性プロバイダーは、自ら当該チェーンを実行してユーザーの出金リクエストの正当性を確認した上で、資金を提供します。 これにより、流動性プロバイダーはこのトランザクションが最終的には承認されるとの保証（つまり、トラストレスなファイナリティ）を得ることができます。

2. EVMとの互換性

デベロッパーにとってのオプティミスティック・ロールアップの優位性は、イーサリアム仮想マシン（EVM）との互換性、あるいは等価性にあります。 EVM互換のロールアップは、イーサリアム・イエローペーパー(opens in a new tab)の仕様に準拠しており、バイトコードの水準でEVMをサポートします。

オプティミスティック・ロールアップのEVM互換性は、次のような利点を持ちます：

i. デベロッパーは、イーサリアム上の既存のスマートコントラクトにつき、コードベースを大幅に修正せずにオプティミスティック・ロールアップのチェーンに移植できます。 これにより、イーサリアムのスマートコントラクトをL2上でデプロイする時間を節約できます。

ii. オプティミスティック・ロールアップを使用するデベロッパーやプロジェクトチームは、イーサリアムメインネットのインフラを活用できます。 具体的には、プログラム言語、コードライブラリ、テストツール、クライアントソフトウェア、デプロイ用のインフラなどが活用できます。

すでに長年にわたり検証やデバッグを通じて改善されてきたこれらのツールを活用できる点は重要です。 さらに、まったく新しい開発スタックを使って開発方法を学ぶ必要もなくなります。

3. クロスチェーンにおけるコントラクトの呼び出し

ユーザー（外部所有アカウント）がL2上のコントラクトとやりとりを行うには、ロールアップ上のコントラクトにトランザクションを送信するか、あるいはこの作業をシーケンサーまたはバリデータに委任する必要があります。 オプティミスティック・ロールアップの場合はさらに、L1／L2間のメッセージのリレーやデータの受け渡しにブリッジコントラクトを使用して、L2上のコントラクトとのやりとりを行えます。 つまり、イーサリアムメインネット上のL1コントラクトにおいて、L2のオプティミスティック・ロールアップ上のコントラクトに含まれる機能を呼び出せるようにプログラムすることが可能です。

このようなクロスチェーンのコントラクトでは、呼び出しが非同期で実行されます。つまり、呼び出しと実行の間に一定の時間が経過します。 この点は、呼び出された時点でただちに実行されるイーサリアム上の2つのコントラクト間の呼び出しとは異なります。

クロスチェーンのコントラクト呼び出しの例としては、上述したトークンの入金が挙げられます。 L1上のコントラクトは、ユーザーのトークンをエスクローすると共に、L2の対応したコントラクトに対して、ロールアップ上で同額のトークンをミントするように指示するメッセージを送信します。

クロスチェーンのメッセージ呼び出しはコントラクトの実行を伴いますが、通常は、計算に伴い発生するガス代は送信元が負担する必要があります。 ターゲットのチェーンにおいてトランザクションが失敗するのを防ぐために、ガス代の上限を高く設定することが推奨されます。 この点については、トークンをブリッジングするシナリオを想起すればよいでしょう。トランザクションにおけるL1側の作業（トークンの入金）がうまく行っても、L2側の作業（新規トークンのミント）がガス代不足により実行されなければ、入金した資産は回収不能になります。

最後に、複数のコントラクト間におけるL2からL1へのメッセージ呼び出しにおいては、遅延の発生を考慮する必要があります（L1からL2への呼び出しは、通常数分後に実行されます）。 オプティミスティック・ロールアップからメインネットに送信されるメッセージは、チャレンジ期間が経過するまで実行できないためです。

オプティミスティック・ロールアップにおける手数料の仕組み

オプティミスティック・ロールアップでは、トランザクション1件ごとのユーザー手数料を表示するために、イーサリアムとほぼ同様のガス料金スキームを採用しています。 オプティミスティック・ロールアップで請求される手数料は、以下の要素により決定されます：

1. State write: オプティミスティック・ロールアップでは、トランザクションデータやブロックヘッダー (前のブロックヘッダーのハッシュ、ステートルート、バッチルートを含む) を、バイナリ大規模オブジェクト、すなわち ブロブ としてイーサリアムに公開します。 EIP-4844(opens in a new tab) は、データをオンチェーンに含めるための費用対効果の高い解決策を導入しました。 ブロブ は新しいトランザクションフィールドで、ロールアップが圧縮された状態遷移データをイーサリアムL1に送信することを可能にします。 永続的にオンチェーンに残るcalldataとは異なり、ブロブは短期的なもので、 4096エポック(opens in a new tab) (約18日) 後にはクライアントから削除できます。 圧縮されたトランザクションのバッチを、ブロブを使用して送信することで、オプティミスティック・ロールアップはL1へのトランザクション書き込みコストを大幅に削減することができます。

2. Blob gas used: ブロブを含むトランザクションは、EIP-1559(opens in a new tab)で導入された動的手数料メカニズムに類似した仕組みを採用しています。 タイプ3トランザクションのガス料金は、ブロブのベースフィーを考慮に入れて計算されます。この基本料金は、ブロブスペースの需要と、送信されるトランザクションのブロブスペース使用量に基づいて、ネットワークが決定します。

3. L2オペレーターに対する手数料: イーサリアムにおけるガス代と同様に、トランザクション処理において発生する計算コストの代価としてロールアップのノードに支払われる報酬です。 L2は処理能力が比較的高く、イーサリアムの場合のようにネットワークの混雑によりバリデータが高額な手数料を伴うトランザクションを優先的に処理するという状況が発生していないため、ロールアップのノードが請求するトランザクション手数料は比較的安価になっています。

オプティミスティック・ロールアップにおいてユーザー手数料を引き下げるために導入されているメカニズムとしては、トランザクションのバッチ処理や、データ公開コストを軽減するためのcalldataの圧縮などがあります。 L2手数料トラッカー(opens in a new tab)を使えば、イーサリアムベースのオプティミスティック・ロールアップで発生する使用手数料をリアルタイムで確認できます。

オプティミスティック・ロールアップは、どのようにイーサリアムのスケーラビリティを向上させるのか？

上述したように、オプティミスティック・ロールアップでは、圧縮したトランザクションデータをイーサリアムに送信して公開することで、データの可用性を保証します。 オンチェーン上で圧縮データを公開する機能は、オプティミスティック・ロールアップを通じてイーサリアムのスループットを拡大させる上で不可欠なものです。

メインのイーサリアムチェーンは、各ブロックが保持できるデータ量に制限があり、これはガス単位で表示されます（平均のブロックサイズは1,500万ガスです）。 これは、各トランザクションにおいて使用できるガスに上限があることを意味すると同時に、トランザクションデータの圧縮によりブロックごとに処理されるトランザクションの数を増やし、直接的にスケーラビリティを向上させられることを意味します。

オプティミスティック・ロールアップでは、トランザクションデータを圧縮し、TPSレートを向上させる上で、いくつかの手法を用いています。 例えば この記事(opens in a new tab)では、メインネット上の基本的なユーザートランザクション （Etherの送信）で生成されるデータ量と、ロールアップ上で同一のトランザクションが生成するデータ量を比較しています：

これらの数値を基にした大まかな計算により、オプティミスティック・ロールアップがどの程度スケーラビリティに貢献するのかを知ることができます：

1. 各ブロックのターゲットサーイズは1,500万ガスで、1バイトのデータ検証には16ガスが必要です。 平均ブロックサイズを16ガスで割ると (15,000,000/16) 、平均サイズのブロックは937,500バイトのデータを保持できることになります。
2. ロールアップにおける基本的なトランザクションが12バイトを使用する場合、イーサリアムの平均的なブロックは78,125件のロールアップ・トランザクションあるいは39件のロールアップバッチ（各バッチが平均2,000件のトランザクションを持つ場合）を処理できます。
3. イーサリアムで15秒ごとに新しいブロックが生成されるとすると、ロールアップの処理速度は、1秒間に約5,208件のトランザクションに相当します。 これは、イーサリアムにおける1つのブロックが保持できる基本的なロールアップのトランザクション数（78,125）を平均のブロック時間（15秒）で割ることで算出できます。

イーサリアム上のブロック全体がすべてオプティミスティック・ロールアップのトランザクションである可能性はないため、この数値はかなり楽観的な推測です。 しかし、オプティミスティック・ロールアップによってイーサリアムのユーザーどれだけスケーラビリティを獲得できるかについて、おおよその見当をつけることができます（現在の実装では最大2,000TPSを実現しています）。

イーサリアムにデータシャーディングが導入されると、オプティミスティック・ロールアップのスケーラビリティも向上すると期待されています。 ロールアップ上のトランザクションは、ロールアップ以外の他のトランザクションとブロックスペースを共有しなければならないため、メインのイーサリアムチェーンにおけるデータのスループットにより処理能力が制限されます。 ダンクシャーディングでは、高価で永続的なCALLDATAの代わりに、安価で非永続的な 「ブロブ」 ストレージを使用して、ブロックごとにデータを公開します。そのために、L2チェーンが利用できるスペースを増やします。

オプティミスティック・ロールアップの長所と短所

オプティミスティック・ロールアップに関する説明動画

映像で学びたい方は、 Finematicsによるオプティミスティック・ロールアップの説明をご覧ください：

オプティミスティック・ロールアップの使用方法

Dappに統合可能な、既存のオプティミスティック・ロールアップの実装が提供されています：

オプティミスティック・ロールアップに関する参考文献

• オプティミスティック・ロールアップの仕組み（完全ガイド）(opens in a new tab)
• ブロックチェーンにおけるロールアップとは何か？ 技術ガイド(opens in a new tab)
• Arbitrumの基本ガイド(opens in a new tab)
• Optimismのロールアップはどのように機能するのか？(opens in a new tab)
• OVMの詳細を学ぶ(opens in a new tab)
• オプティミスティック仮想マシンとは何か？(opens in a new tab)