ロールアップ技術とは？

イーサリアムのメインネット（L1）は、秒間トランザクション処理件数（TPS）が約12〜15件に制限されています。この制限により、ネットワークの混雑時にはガス代（取引手数料）が急騰し、Uniswapでの単純なトークンスワップ1回に対して数十ドル相当のETHが要求される事態が頻発してきました。この深刻なスケーラビリティ問題を克服するため、イーサリアムのロードマップは「ロールアップ中心（Rollup-centric Roadmap）」へと大きくシフトしました。L1の分散性と高度なセキュリティを犠牲にすることなく、実行処理をオフチェーンで行う「レイヤー2（L2）」が必要とされた背景には、このような処理能力とコストの限界が存在します。

イーサリアムのスケーラビリティ問題を解決する「ロールアップ」の構造とL1/L2のデータ連携メカニズム

イーサリアムL1の強固な分散性とセキュリティを継承しつつ、安価で高速な取引環境を提供する技術がロールアップです。その基本構造は、ユーザーが発行したトランザクションの「実行」処理をオフチェーン（L2）で行い、その結果と検証に必要なデータをL1に集約して記録する仕組みにあります。

サイドチェーンとの決定的な違い（オンチェーン・データ・アベイラビリティ：Data Availability）

レイヤー2（L2）であるロールアップと、Polygon PoSに代表される「サイドチェーン」の決定的な違いは、トランザクションデータの検証および復元に必要なデータがどこに存在するのか、すなわち「データ可用性（Data Availability: DA）」の確保場所にあります。

サイドチェーンは、イーサリアムとは異なる独自のバリデーターセットとコンセンサスアルゴリズム（PoSなど）によってセキュリティを担保しています。そのため、サイドチェーンのバリデーターの過半数が結託して不正を働いた場合、イーサリアムL1側からその不正を検知・拒否することは不可能です。ユーザーの資産はサイドチェーンのバリデーターの誠実性に完全に依存することになります。

これに対し、ロールアップは実行処理こそオフチェーンで行うものの、すべてのトランザクションデータ（または状態遷移の差分データ）をイーサリアムL1に直接書き込みます。これにより、L2のオペレーター（シーケンサー）が万が一、すべてのシステムを停止したり不正を働いたりした場合でも、イーサリアムL1上に記録されたデータを遡ることで、誰でもL2の最新状態（ステート）を完全に再構成し、資産をL1へ安全に引き出す（エグジットする）ことができます。つまり、ロールアップはL1の強固なセキュリティを直接継承しているのです。

2024年3月に実施されたイーサリアムのアップグレード「Dencun」に導入された「EIP-4844（Proto-Danksharding）」は、このデータ可用性のコストを劇的に引き下げました。従来の「calldata」領域ではなく、L1の実行レイヤーから直接アクセスできない「Blob（Binary Large Objects）」と呼ばれる一時的なデータストレージにL2データを書き込むことで、L1に支払うデータ保存コストは最大で90%以上削減されました。これにより、BaseやArbitrumといったL2の平均取引手数料は0.1ドル未満から、場合によっては0.01ドル以下へと下落しています。

トランザクションを束ねる（ロールアップする）実行プロセスと圧縮の仕組み

ロールアップがスケーラビリティを向上させる核心は、オフチェーンでの「実行」と、オンチェーンでの「検証・記録」を分離し、L1に書き込むデータを極限まで圧縮するプロセスにあります。

L2上でユーザーがトランザクションを発行すると、シーケンサーと呼ばれるL2のノードがこれらを受信・順序付けし、オフチェーンの仮想マシン（EVMなど）で処理を実行します。その後、シーケンサーは多数のトランザクションを1つのバッチとして束ね（ロールアップし）、L1へ送信します。

この際、L1のストレージコストを抑えるために、徹底的なデータ圧縮が行われます。例えば、通常のL1トランザクションは約110バイト以上のサイズがあり、送信者の署名（ECDSA署名、約65バイト）が大きな割合を占めます。ロールアップでは、複数のトランザクションの署名を1つに集約（アグリゲーション）する技術や、アドレス情報をインデックス番号に置き換える技術などを活用することで、1トランザクションあたりのデータサイズを十数バイト程度まで削減します。これにより、L1の限られたブロック容量の中に、数千件規模のL2トランザクションを収めることが可能になります。

L1へのデータ書き込み時に、トランザクションの正当性をどのように検証・保証するかによって、ロールアップは大きく「Optimistic Rollup」と「ZK-Rollup」の2種類に分類されます。前者は「全てのトランザクションは正しい」という前提のもと、事後的に不正を検証するゲーム理論的なアプローチであり、後者は高度な暗号学を用いて「最初から全ての正当性を証明する」数学的なアプローチです。これら2つの技術的アプローチの違いと具体的な検証メカニズムについては、次章で詳細に比較・検証します。

「Optimistic Rollup」と「ZK-Rollup」を徹底解剖：不正証明と妥当性証明の技術的相違点

イーサリアムL1に対してトランザクションの正当性を検証・保証するプロセスにおいて、Optimistic RollupとZK-Rollupは根本的に異なる設計思想を持っています。この検証プロセスの違いは、トランザクションが確定するまでの時間、計算負荷、そしてユーザー体験（UX）に直接影響を与えます。

比較項目	Optimistic Rollup	ZK-Rollup
検証アプローチ	不正証明（Fraud Proof）による事後検証	妥当性証明（Validity Proof）による事前・即時検証
資金引き出し期間	約7日間（チャレンジ期間が必要）	即時（L1での検証完了後、数分〜数時間）
証明生成コスト（Prover）	極めて低い（通常のシーケンサー実行のみ）	極めて高い（高度な暗号計算と高性能ハードウェアが必要）
EVM互換性	極めて高い（既存のSolidityコードをそのまま実行可能）	対応中（zkEVMの設計・最適化が必要）
データ可用性 (Data Availability)	すべてのステート変更データをL1に記録（EIP-4844による恩恵大）	ステート変更データと証明データをL1に記録（圧縮率が高い）

Optimistic Rollup：ゲーム理論に基づく「不正証明（Fraud Proof）」とチャレンジ期間

Optimistic Rollupは、その名の通り「オプティミスティック（楽観的）」にトランザクションを処理します。L2のシーケンサーが処理したトランザクションデータは、詳細な検証を経ずにL1へ直接書き込まれます。この仕組みは、L1側のガス代高騰を回避しつつ、高速なスループットを実現するのに適しています。

しかし、不正なトランザクションが書き込まれるリスクに対処するため、ゲーム理論に基づいた「不正証明（Fraud Proof）」のロジックが組み込まれています。L2のバリデーター（検証者）は、シーケンサーが提出したデータに不正がないかを監視します。もし不正を発見した場合、L1のスマートコントラクトに対して「不正の申し立て」を行います。

この相互監視システムを機能させるため、Optimistic RollupではL2からL1へ資金を引き出す（ブリッジバックする）際に、約7日間の「チャレンジ期間（Challenge Period）」が設けられています。これは、誠実なバリデーターが不正を検知し、L1に不正証明を提出して検証を完了させるために物理的に必要な時間です。例えば、Arbitrum OneやOptimism（OP Mainnet）から公式ブリッジを用いてイーサリアム L1にETHを引き出す場合、この7日間のロック期間を避けることはできません。

この7日間という制約は、流動性の効率を低下させます。DeFiでの迅速な資金移動を求めるプロダクトにおいて、この遅延は大きなボトルネックとなります。実務上は、サードパーティのクロスチェーンブリッジ（Hop ProtocolやAcrossなど）が手数料を徴収してL1側の資金を即時立て替える形で解決されていますが、これには追加のスマートコントラクトリスクと資本コストが伴います。

データ可用性 (Data Availability)に関しては、Optimistic RollupはすべてのトランザクションデータをL1に格納する必要があるため、L1のブロック容量を圧迫しやすいという特徴があります。この課題は、イーサリアムの「EIP-4844（プロト・ダンクシャーディング）」の実装により、データを「blob」と呼ばれる一時的な領域に保存することで、L2からL1へのデータ記録コストが従来の約10分の1に削減され、ガス代の劇的な低下をもたらしました。

ZK-Rollup：暗号学的な「妥当性証明（Validity Proof：ゼロ知識証明）」と即時検証

一方、ZK-Rollupは、ゲーム理論や「人間（バリデーター）の監視」に依存しません。トランザクションが発生するたびに、L2側でその正当を示す数学的な「妥当性証明（Validity Proof）」を生成し、トランザクションデータとともにL1へ提出します。この証明には、高度な暗号学技術である「ゼロ知識証明（Zero-Knowledge Proofs：主にzk-SNARKsまたはzk-STARKs）」が用いられます。

L1のスマートコントラクトは、提出された証明（Proof）が数学的に正しいかどうかのみを検証します。この検証プロセスは極めて低コストかつ高速に行われるため、L1で検証が完了した時点で、L2のトランザクションはファイナリティ（最終確定）を得ます。結果として、ZK-RollupではOptimistic Rollupのような7日間のチャレンジ期間が不要となり、L2からL1への資金引き出しは数分から数時間（L1のブロック生成と証明提出の間隔）で即時に完了します。

しかし、この即時検証性と引き換えに、ZK-Rollupには「証明生成（Prover）における膨大な計算コスト」というトレードオフが存在します。ゼロ知識証明を生成するプロセスは極めて複雑な数学的演算を必要とし、一般的なCPUでは処理が追いつきません。例えば、1秒間に数百件のトランザクションの証明をリアルタイムに生成するためには、専用の高性能GPUやFPGA、ASICといった特殊なハードウェアクラスターが必要となります。この「Prover」の運用コストの高さが、シーケンサー側の手数料構造やバリデーターの中央集権化リスクとして作用しています。

さらに、開発における大きな障壁となっていたのが「EVM（イーサリアム仮想マシン）との互換性」です。ゼロ知識証明は本来、スマートコントラクトのような複雑なステート遷移を証明するようには設計されていませんでした。これを解決するために開発されたのが「zkEVM」です。zkSync EraやPolygon zkEVM、Lineaなどのプロジェクトは、Solidityで書かれたコントラクトをゼロ知識証明に適した回路にコンパイル、あるいは実行環境そのものをzkEVM化する技術を実用化しました。これにより、開発者は既存のスマートコントラクトのコードを変更することなく、ZK-Rollupの恩恵を受けられるようになりつつあります。

データ可用性 (Data Availability)の観点でも、ZK-Rollupは優位性を持っています。L1に書き込むのはトランザクションの最終的なステート変更データと妥当性証明のみであるため、記録に必要なデータ量が極めて小さく抑えられます。EIP-4844の導入後は、この証明データ自体もblob領域に格納されるため、スケーラビリティ問題に対する根本的な解決策として、イーサリアム ロードマップにおける最終的な到達点と位置付けられています。

主要L2プロジェクトの実装状況と技術スタックの比較：ArbitrumからzkSyncまで

イーサリアムのロードマップにおいて、スケーラビリティ問題を解決する主軸として位置づけられるL2技術。主要なL2プロジェクトにおける技術スタック、検証方式、データ可用性 (Data Availability)、EVM互換性、およびL2BEAT（2024年5月時点）のデータに基づく実数値を一覧で比較します。

プロジェクト名	ロールアップ種別	検証方式	EVM互換性レベル	データ可用性 (DA) 先	TVL（市場シェア）
Arbitrum One (Nitro)	Optimistic Rollup	マルチラウンド対話型不正証明	EVM等価 (EVM-Equivalent)	Ethereum L1 (EIP-4844 Blob)	約162.3億ドル (約41.5%)
OP Mainnet (OP Stack)	Optimistic Rollup	シングル/マルチラウンド不正証明 (Cannon)	EVM等価 (EVM-Equivalent)	Ethereum L1 (EIP-4844 Blob)	約76.5億ドル (約19.5%)
zkSync Era	ZK-Rollup	妥当性証明 (PLONK / SNARK)	Type-4 (高レベル言語互換)	Ethereum L1 (EIP-4844 Blob)	約8.2億ドル (約2.1%)
Polygon zkEVM	ZK-Rollup	妥当性証明 (STARK / SNARK)	Type-2 (完全EVM互換)	Ethereum L1 (EIP-4844 Blob)	約1.6億ドル (約0.4%)
Starknet	ZK-Rollup	妥当性証明 (STARK)	非互換 (Cairo VMからトランスパイル)	Ethereum L1 (EIP-4844 Blob)	約10.5億ドル (約2.7%)

Optimistic系代表格：ArbitrumとOptimismのマルチラウンド対シングルラウンド不正証明

Optimistic Rollupの二大巨頭であるArbitrum（Arbitrum One）とOptimism（OP Mainnet）は、不正証明の検証プロセスにおいて異なる技術的最適化を選択しています。

Arbitrum（Nitroアーキテクチャ）が採用する「マルチラウンド対話型不正証明」は、L1チェーン上の手数料（ガス代）を極限まで抑える設計です。L2のシーケンサーが提出したアサーション（状態変化の主張）に対してバリデータが異議を唱えた場合、両者はL1を介してインタラクティブな二分探索（バイナリサーチ）を行います。不一致の原因となっている命令ステップを1つ（WebAssemblyの1命令レベル）に絞り込むまで検証プロセスを細分化し、最終的にL1上のスマートコントラクトが実行するのはこの1命令の検証のみであるため、オンチェーンの検証ガス代を最小限に抑えられます。この効率的な不正証明メカニズムによる低コスト環境が、Arbitrum OneがTVL約162.3億ドルという市場シェア首位を獲得している大きな要因です。

一方、Optimism（OP Stack）は歴史的に、不一致のあるトランザクション全体をL1オンチェーン上で丸ごと再実行し、結果の妥当性を検証する「シングルラウンド不正証明」を志向していました。しかし、イーサリアムのブロックガスリミットを超えるトランザクションはL1上で再実行できないという構造的な限界や、L1のガス代高騰を直接受けるという課題を抱えていました。この課題を解決するため、現在のOptimismは「Cannon」と呼ばれるインタラクティブな紛争解決エンジンを導入し、MIPSアーキテクチャ上で動くEVMをエミュレートするマルチラウンド不正証明への移行を進めています。この共通規格化された「OP Stack」は、BaseやModeといった他のL2プロジェクトにも採用されており、エコシステム全体で技術標準の共通化が図られています。

ZK-Rollup最前線：zkSync Era、Polygon zkEVM、StarknetのEVM互換性（zkEVM）へのアプローチ

ゼロ知識証明を用いた「妥当性証明」を伴うZK-Rollupは、スケーラビリティと高速な確定性を両立させますが、EVM（イーサリアム仮想マシン）との非互換性が長年の課題でした。主要プロジェクトはこの問題に対し、異なる「zkEVM」の設計アプローチを採っています。

イーサリアム創設者であるVitalik Buterinが提唱した「zkEVMの分類（Type-1からType-4）」に基づき、各プロジェクトのアプローチを分解します。

Polygon zkEVMは「Type-2（完全EVM互換）」を目指す設計です。これはイーサリアムのコンパイル済みバイトコードレベルで互換性を持たせるアプローチであり、開発者は既存のSolidityコードを一行も変更することなく、同一のツールチェーン（Hardhat、Foundryなど）をそのまま利用できます。しかし、イーサリアムのデータ構造（KeccakハッシュやPatriciaツリーなど）をゼロ知識証明で証明するのは計算負荷が極めて高く、証明の作成時間（Proving Time）とコストのバランスに課題を残しています。そのため、TVLは約1.6億ドルに留まり、主にエンタープライズやDeFiの特定の高セキュリティユースケースに焦点を当てています。

これに対し、zkSync Eraは「Type-4（高レベル言語互換）」を採用しました。EVMのバイトコードを直接エミュレートするのではなく、SolidityやVyperといった高レベルのスマートコントラクト言語を、LLVM（Low Level Virtual Machine）ベースのコンパイラを用いて、ZK専用に最適化されたカスタムVM（EraVM）のバイトコードへと変換します。このアプローチにより、証明生成のプロセスが極めて高速かつ安価に処理されるため、一般的なDeFiプロトコルなどの大量トランザクションが発生するユースケースに適合します。zkSync EraのエコシステムTVLが約8.2億ドルとZK系でトップクラスのシェアを誇る背景には、このType-4アプローチによる実用性の高さがあります。

さらに独自路線を進むのがStarknetです。StarknetはEVMとの直接的な互換性を排除し、ゼロ知識証明（特にスケーラビリティに優れたSTARKs）のパフォーマンスを最大限に引き出すために設計された専用言語「Cairo」と、その実行環境「Cairo VM」を使用します。EVMとの互換性は、コンパイラを介した「Kakarot」（SolidityをCairoにトランスパイルするプロジェクト）などの外部ツールによって部分的に提供されます。StarknetのTVLは約10.5億ドル規模となっており、アカウント抽象化（Account Abstraction）の標準実装や高スループットなオンチェーンゲームの開発環境として、独自の開発者コミュニティを形成しています。

技術選定・投資判断のためのロールアップ評価マトリクスと今後のロードマップ影響

アプリケーション特性に応じたL2選定（DeFi、GameFi、エンタープライズ）のチェックリスト

Web3プロダクトの設計や投資判断において、どのL2技術を選択すべきかは、ビジネス要件と直結します。プロダクトマネージャーや投資家が技術スタックを評価する際の具体的な判断基準として、アプリケーションの特性に応じた最適なL2選定マトリクスを以下に示します。

ユースケース	最重要要件	推奨技術	代表的なプロジェクト	選定基準と技術的裏付け
DeFi（分散型金融） / 高頻度取引	資本効率、即時ファイナリティ、流動性の集約	ZK-Rollup（zkEVM搭載型）	zkSync Era, Scroll, Linea	ゼロ知識証明に基づく「妥当性証明」を用いるため、L1への出金（ファイナリティ）が数分〜数時間で完了し、資金効率が最大化されます。Optimistic Rollupのように不正証明のための7日間のチャレンジ期間（資金ロック）が発生しません。
GameFi / NFTマーケットプレイス	超低ガス代、高いスループット（TPS）、既存EVM資産との相互運用性	Optimistic Rollup または 専用AppL2	Arbitrum One, OP Mainnet, Base	開発コミュニティが成熟しており、スマートコントラクトの互換性が極めて高いため、既存のdAppsを迅速にデプロイできます。EIP-4844適用後のトランザクションコストが低く、大量のマイクロトランザクションを許容できます。
エンタープライズ / 規制対応金融	データのプライバシー保護、厳格なコンプライアンス、KYC/AMLの統合	ハイブリッド型 ZK-Rollup / 専用Validium	Starknet, ApeX Protocol (StarkEx)	ゼロ知識証明技術を応用することで、取引の妥当性を証明しつつ、オンチェーン上に顧客の取引履歴などのプライベートな生データを公開しないシステム設計が可能です。

このマトリクスをプロダクト開発に適用する際、以下の3つの基準をチェックリストとして評価します。

• 出金遅延の許容度：L2からL1に資金を引き出す際、ユーザーに7日間の待機を強いることが許容できるか。許容できない金融サービスであれば、妥当性証明を利用して即座に引き出しが可能なZK-Rollupの採用が必須となります。
• EVM互換性の水準：既存のSolidityコードをそのまま移植したいか。Arbitrum等のOptimistic Rollupは「EVM等価性」が高くスムーズに移行できますが、zkEVMを採用するZK-Rollupでは、一部のオペコードや暗号プリミティブの互換性制限により、コントラクトの書き直しが必要になる場合があります。
• データ可用性 (Data Availability) のコスト：トランザクションの生データをすべてイーサリアム上に置く必要があるか。セキュリティを極限まで高めるならオンチェーン（ロールアップ）ですが、コストを優先するならばデータをオフチェーンで管理する「Validium」や、データ可用性専用の外部レイヤー（Celestiaなど）の活用を検討する必要があります。

EIP-4844（Proto-Danksharding）がもたらす「Blobデータ」導入によるガス代削減効果の実証

イーサリアム ロードマップ『The Surge』の第一段階として2024年3月に実施されたDencunアップグレード（EIP-4844）は、L2のスケーラビリティ問題を解決する上で極めて大きな節目となりました。EIP-4844の実装によって導入された「Blob（Binary Large Object）データ」は、L2のトランザクションデータを一時的（約18日間）に保持するためだけに設計された専用のストレージ領域です。このBlobは、L1の実行レイヤーからはアクセスできない仕様にすることで、イーサリアムノードのストレージ負荷を抑え、データ可用性コストを圧倒的に引き下げることに成功しました。

このアップグレード前後における、主要L2での実測トランザクションコスト（ガス代）の変化は以下の通りです。データはブロックチェーン分析ツール「L2BEAT」および「Growthepie」の実測平均値に基づいています。

L2ネットワーク名	EIP-4844以前の平均送金手数料 (USD)	EIP-4844以後の平均送金手数料 (USD)	手数料削減率 (%)	技術的要因
Base (Optimistic)	$0.150	$0.002	約 98.6% 削減	OP StackのBlob対応最適化により、データ可用性コストがほぼゼロに近接したため。
Optimism (OP Mainnet)	$0.120	$0.003	約 97.5% 削減	Baseと同様に、L1へのcalldata書き込みからBlob利用への移行が即座に完了した結果。
Arbitrum One (Optimistic)	$0.182	$0.005	約 97.2% 削減	独自のNitroアーキテクチャ内でのBlobデータのバッチ処理最適化による効果。
zkSync Era (ZK-Rollup)	$0.210	$0.011	約 94.7% 削減	ゼロ知識証明の検証コスト自体はL1で発生するものの、状態差異データの格納先をBlobに切り替えたことで大幅な削減を達成。

この実測データが示す通り、EIP-4844の導入はL2の経済性に構造的な変化をもたらしました。特にOptimistic Rollup系では、データ可用性コストの削減がダイレクトに反映され、1トランザクションあたり1セント未満（約0.1〜0.5円）という極限の低コスト環境が実現しています。

一方で、zkSync EraをはじめとするZK-Rollup系では、L1上でのゼロ知識証明の検証にかかる実行コストが一定割合で残るため、削減率は90%台前半に留まっています。しかし、これにより「セキュリティとファイナリティの速さを重視して数セントを払うZK-Rollup」か、「コストの安さを極限まで追求するOptimistic Rollup」かという、プロダクト要件に応じた明確な設計分岐点が生まれました。

自社プロジェクトへのロールアップ導入ロードマップ：開発実装における設計ステップ

イーサリアムのメインネットにおけるスケーラビリティ問題を解消し、実用的なトランザクションコストを実現するためには、レイヤー2へのデプロイが有力な選択肢となります。既存のプロダクトをL2に移行、あるいは新規にロールアップ環境を構築する具体的な手順を解説します。

L2へのデプロイ（スマートコントラクトの移行）手順と開発ツールの選定

L1からL2へのスマートコントラクトの移行は、EVM等価性の向上により、極めて容易になっています。しかし、EVM等価性の度合いに応じた仕様差異が存在するため、以下のステップに沿った検証が必要です。

• ステップ1：コンパイル互換性の検証とzkEVM対応の確認
  移行対象のSolidityコードが、ターゲットとするL2環境で完全に動作するかを検証します。ArbitrumやOptimismなどのOptimistic RollupはEVM等価性が高いため、既存のコードをほぼそのまま利用できます。一方で、zkSync EraやScrollなどのZK-Rollup環境では、ゼロ知識証明の生成を最適化するために一部のEVMオペコード（OPCODE）の挙動が異なります。例えば、zkSync EraではCREATE2の動作や、ガス代の算出方法（L1ガスのファクタリング）に独自の仕様があるため、専用コンパイラを用いた事前検証が必須です。
• ステップ2：開発環境（Hardhat/Foundry）のRPC設定
  既存の開発フレームワークに、対象とするL2のRPCエンドポイントを追加します。
  Foundryを使用する場合、foundry.tomlにL2のテストネットのRPC URLを設定します。

  [rpc_endpoints]
  arbitrum_sepolia = "https://sepolia-rollup.arbitrum.io/rpc"
  optimism_sepolia = "https://sepolia.optimism.io"

  デプロイ時には、L2独自のブロック時間（例：Arbitrumのミリ秒単位のソフトコンファメーション）や、L1ブロック番号とL2ブロック番号の差異を考慮したテストコードを記述する必要があります。

• ステップ3：ブリッジ設計とアセットミント権限の定義
  L1とL2の間でトークンやメッセージを安全に移動させるためのブリッジ設計を行います。ロールアップのセキュリティモデル（Optimistic Rollupの7日間のチャレンジ期間、またはZK-Rollupの妥当性証明による即時確定）に合わせ、メッセージリレーの遅延をフロントエンドに実装する必要があります。コントラクト側では、L1側のネイティブブリッジコントラクト（例：OptimismのL1StandardBridge）からの呼び出しのみを許可する修飾子（Modifier）を実装し、不正なミントを防止します。

セキュリティ監査とデータ可用性（DA）レイヤー（CelestiaやEigenDA等）の選定基準

L2のセキュリティにおいて最も重要な論点の一つがデータ可用性の確保です。ゲームやDeFiなどの大量のトランザクションを毎秒処理する必要があるプロジェクトでは、さらに低コストな外部DAレイヤー（オルトDA）の採用が有力な選択肢となります。以下の表は、各DAレイヤーの仕様とセキュリティ上のトレードオフをまとめたものです。

DAソリューション	セキュリティ担保モデル	コスト特性	トランザクション確定のボトルネック
イーサリアム L1 (EIP-4844 Blob)	イーサリアムの全バリデータ（フルセキュリティ）	中（ガス市場の混雑状況に依存）	イーサリアムのファイナリティ（約12分）
Celestia	独自のコンセンサス（DAS: データ可用性サンプリング）	極めて低	Celestiaブロック生成時間（約15秒）とL1へのステートコミット
EigenDA	イーサリアムのセキュリティを再利用（Restakingによる共有セキュリティ）	低（固定単価予約枠あり）	EigenDA演算器の署名集約とL1検証（約数分）

外部DAレイヤーを採用する場合、セキュリティの信頼前提が変わる点に注意が必要です。例えば、CelestiaをDAとして使用する「イーサリアム・L3」や「Validium」の構成では、L1のセキュリティに加えてCelestiaのバリデータセットの誠実性に依存することになります。バリデータが結託してデータを隠蔽した場合、L2の資産が凍結されるリスクが生じるため、プロジェクトが扱う経済的価値に応じた選定が求められます。

開発チームが検証すべき次の具体的なステップは以下の2点です。

• 予測トランザクション量の算出：1秒あたりの想定トランザクション数（TPS）を定義し、EIP-4844利用時のL1コストと、Celestia等のオルトDAを利用した場合のランニングコストのシミュレーションを行います。L2ビルダーキットであるOP StackやArbitrum Orbitを使用する場合、DAレイヤーの切り替えは設定ファイルの変更のみで実行可能です。
• テストネットでのテストデプロイ：まずはArbitrum OrbitやOP Stackのローカルデプロイ環境を用い、DAレイヤーにCelestiaのテストネット（Mocha）またはEigenDAのテストネットを指定してテストを行い、L1へのステート更新にかかる実際のレイテンシとガス代の挙動を確認してください。

よくある質問（FAQ）