レイヤー1並列実行を徹底解説：Aptos、Sui、Linera、Fuelはどのように実現しているのか？
TechFlow厳選深潮セレクト
レイヤー1並列実行を徹底解説：Aptos、Sui、Linera、Fuelはどのように実現しているのか？
ブロックチェーン技術の進化を改めて見直すとき、新しいL1が並列実行に注力しているという強力なトレンドが浮かび上がっている。
Web3業界の深掘り報道に専念し潮流を洞察
執筆：Mohamed Fouda
翻訳：TechFlow
ブロックチェーン技術の進化を振り返ると、新しいL1が並列実行に注力しているという強力なトレンドが見えてくる。
これはまったく新しい技術ではなく、現在ではSolanaもSealevel実行環境で採用している。
しかし、過去の好況期においてDeFiやNFTが示した印象的な成果により、技術の改善が急務であることが明らかになった。
次の市場サイクルでは、並列実行（PE）を採用する著名なプロジェクトが相次いで登場する。その代表例がAptos、Sui、Linera、Fuelである。
本稿ではこれらのプロジェクトの類似点と相違点、および直面する課題について考察する。
問題点
スマートコントラクトプラットフォームは多様な分散型アプリケーション（DApps）の構築を可能にする。こうしたアプリケーションを実行するには、共有された計算エンジンが必要となる。ネットワーク内の各ノードはこの計算エンジンを稼働させ、アプリケーションの実行およびユーザーとのインタラクションを処理する。ノードが実行結果に関して合意に達すると、コンセンサスが成立し、チェーンが前進する。
イーサリアム仮想マシン（EVM）は最も広く使われるスマートコントラクト（SC）実行エンジンであり、約20種類の異なる実装が存在する。
EVMが発明されて以来、開発者による採用は臨界点に達した。
イーサリアムおよびそのL2に加え、Polygon、BNBスマートチェーン、Avalanche Cチェーンなど多くのチェーンもEVMを実行エンジンとして採用しており、ネットワークのスループット向上のために主に合意形成メカニズムの変更に注力している。
EVMの主要な制限の一つはトランザクションの逐次的実行にある。EVMは基本的に一つのトランザクションを順番に実行し、他のすべてのトランザクションを保留にして、実行完了およびブロックチェーン状態の更新を待つ。たとえば、AliceからBobへの送金とCarolからDaveへの別の送金のように、互いに独立したトランザクションであっても、EVMでは並列実行できない。このような実行方式はフラッシュローンのようなユースケースを可能にする一方で、効率性・拡張性の観点からは劣る。
この逐次的実行はネットワークスループットの主要なボトルネックの一つである：
- まず、ブロック内のトランザクション実行時間が長くなり、ブロック生成時間に制限がかかる；
- さらに、ノードがトランザクションを実行してブロックを検証できるように、ブロックに含められるトランザクション数が制限される。
イーサリアムの平均スループットは約17 tx/秒である。この低いスループットのため、NFTミントなどの高負荷期間には、ネットワークのマイナー／バリデータがすべてのトランザクションを処理できず、優先実行を確保するために手数料の入札競争が発生し、ガス代が高騰する。イーサリアムの平均手数料は一時的に0.2 ETH（約800米ドル）を超えたこともあり、多くのユーザーが利用を避けている。
逐次実行の二つ目の問題はネットワークノードの低効率である。逐次命令実行では複数のプロセッサコアの恩恵を受けられず、ハードウェア利用率が低下し、非効率になる。これによりスケーラビリティが妨げられ、不要なエネルギー消費が生じる。
並列実行はこの問題を解決できるか？
EVMアーキテクチャの制約は、並列実行（PE）を実現する新たなL1の出現を促す土壌となった。並列処理により、複数のプロセッサコア間でトランザクション処理を分割でき、ハードウェア利用率が向上し、より良いスケーラビリティが実現される。高スループットチェーンでは、ハードウェアリソースの追加が処理可能なトランザクション数に直接関連する。
高頻度のアクティビティ期間中、バリデータノードは追加のトランザクション負荷を処理するためにより多くのコアを割り当てることができる。計算資源の動的拡張により、需要の高い時期にネットワークがより高いスループットを実現でき、ユーザーエクスペリエンスが大幅に改善される。
このアプローチのもう一つの利点は、トランザクション確認の遅延の改善である。ノードリソースの動的拡張により、あらゆるネットワークロードに対して低遅延での確認が可能になる。
トランザクションは数十または数百のブロックを待つ必要がなく、優先確認のために過剰な手数料を支払う必要もない。改善された確認時間はトランザクションのファイナリティを高め、低遅延ブロックチェーンの実現を可能にする。低遅延での実行保証は、これまで不可能だったさまざまなユースケースを可能にする。
PEを可能にするためにチェーンの実行モードを変更することは新しいアイデアではない。いくつかのプロジェクトがすでにこれを試みている。その一つのアプローチは、EVMが使用するアカウントモデルを、未使用トランザクション出力（UTXO）モデルに置き換えることである。UTXO実行モデルはビットコインで使用されており、トランザクションの並列処理を可能にするため、決済用途に最適である。
しかし、UXTOは機能に制限があるため、スマートコントラクトに必要な複雑な相互作用を実現するには拡張が必要となる。たとえば、Cardanoはこの目的のために拡張UTXOモデルを使用しており、Findoraは両方の会計モデルを実装するハイブリッドUTXOモデルを用いて、ユーザーが資産タイプをモデル間で切り替えられるようにしている。
PEの別のアプローチはアカウントモデルを変更せず、チェーンステートのアーキテクチャと変更方法に注力するものである。例えば、SolanaのSealevelフレームワークが該当する。
並列実行とはどのように機能するのか？
並列実行は、独立したトランザクションを特定し、同時に実行することで機能する。あるトランザクションの実行が別のトランザクションの実行に影響を与える場合、それらは関連していると見なされる。たとえば、同じプール内のAMMトランザクションは関連しており、逐次的に実行されなければならない。
並列処理の概念自体は単純に思えるが、困難は細部にある。最大の課題は「独立」トランザクションをいかに効率的に識別するかである。独立トランザクションの分類には、各トランザクションがブロックチェーンメモリ（チェーンステート）をどのように変更するかを理解する必要がある。同一のスマートコントラクト（例：AMMプール）と相互作用するトランザクションは、同時にコントラクトステートを変更できるため、並列実行できない。
現在のアプリケーション間の高い相互運用性を考えると、関連性の有無を判別するのは困難な作業である。UNIをUSDCに交換するAMM取引を例に考える。AMMが最適なルートとしてUNI → ETH → DAI → AAVE → USDCを発見した場合、この取引に関与するすべてのプールは、取引が完全に実行され、関連プールのステートが更新されるまで、他の取引を処理できない。
独立トランザクションの識別
本セクションでは、異なる並列実行エンジンが採用する手法を比較する。特に注目すべきは、ステート（メモリ）アクセスを制御する方法である。ブロックチェーンステートはRAMストレージと見なすことができ、チェーン上の各アカウントまたはスマートコントラクトは、変更可能な一連のメモリ位置を持つ。関連トランザクションとは、同じブロック内で同じメモリ位置を変更しようとするトランザクションを指す。異なるチェーンは異なるメモリアーキテクチャと識別メカニズムを用いている。
このカテゴリのいくつかのチェーンは、Facebookが中止したブロックチェーンプロジェクトDiemが開発した技術に基づいている。Diemチームはスマートコントラクト言語Moveを開発し、SCの実行を最適化した。Aptos、Sui、Lineraはこのグループに属する高注目プロジェクトである。このグループ以外では、Fuelが独自のSC言語を用いてPEに注力するもう一つの有名プロジェクトである。
Aptos
AptosはDiemのMove言語およびMoveVMを基盤として、並列実行を実現する高スループットチェーンを構築している。
Aptosのアプローチは、関連性の検出をユーザー／開発者に対して透過的に行うものであり、つまりトランザクションがどのステート部分（メモリ位置）を使用するかを明示的に宣言する必要がない。
AptosはSoftware Transactional Memory（STM）の改良版であるBlock-STMを採用している。
Block-STMでは、トランザクションはブロック内で事前に順序付けされ、プロセッサスレッド間で分割されて実行される。
このプロセスでは、すべてのトランザクションが互いに独立していると仮定して実行される。各トランザクションによって変更されたメモリ位置が記録され、実行後、すべてのトランザクション結果が検証される。検証中に、あるトランザクションが前のトランザクションによって変更されたメモリ位置にアクセスしていた場合、そのトランザクションは中止される。その結果は破棄され、再実行される。
このプロセスはブロック内のすべてのトランザクションが正常に実行されるまで繰り返される。
複数のプロセッサコアを使用することで、Block-STMは実行速度を加速する。その加速倍率はトランザクション間の関連度合いに依存する。
Aptosチームの実験結果によれば、32コア使用時、高関連性条件下で8倍、低関連性条件下で16倍の性能向上が達成された。もしブロック内のすべてのトランザクションが相互に依存している場合、Block-STMは逐次実行よりもわずかに劣る性能となる。Aptosはこの方式により、最大16万TPSのスループットを実現できると主張している。
Sui
別のPEアプローチは、トランザクションが変更するチェーンステートの部分を明示的に宣言することを求めるものであり、これは現在SolanaとSuiが採用している方法である。
Solanaではメモリユニットを「アカウント」と呼び、トランザクションはどのアカウントを変更するかを指定しなければならない。Suiも同様のアプローチを取っている。
Suiもまた、MoveVMを利用してDiemの技術をベースとしている。ただし、Suiは異なるバージョンのMove言語を使用している。
Sui Moveの実装は、Diemのコアストレージモデルと資産権限を変更しており、Aptosが採用する標準Diem Moveとの大きな違いとなっている。
Sui Moveは、独立トランザクションの識別が容易になるようなステートストレージモデルを定義している。
Suiでは、ステートストレージはObjectsとして定義される。Objectsは通常資産を表し、共有可能であり、複数のユーザーが同一オブジェクトを変更できる。各ObjectはSui実行環境内で一意のIDを持ち、所有者のアドレスを指す内部ポインタを持つ。これらの概念を利用することで、トランザクションが同じObjectsを使用しているかどうかをチェックすることで簡単に関連性を識別できる。
関連性の宣言を開発者に委ねることで、実行エンジンの実装が容易になり、理論的にはより高いパフォーマンスとスケーラビリティが期待できる。しかし、これは開発者体験の悪化という代償を伴う。
Suiはまだ本番ネットワークを開始しておらず、最近テストネットをリリースしたばかりである。
Suiの創業者は、並列実行の実装とNarwhalおよびTusk合意メカニズムの採用により、スループットが10万tx/秒を超えると主張している。これが真であれば、現在のSolanaの約2400 tx/秒を大きく上回り、VisaやMastercardのスループットをも超える可能性がある。
Linera
Lineraは並列処理分野の新参者であり、最近a16zを筆頭にした初の資金調達を発表した。プロジェクトの詳細な実装情報は少ない。しかし、資金調達のアナウンス記事から、Facebookで開発されたFastPayプロトコルを基盤としていることがわかっている。
FastPayはByzantine Consistent Broadcast（BCB）技術に基づいており、POSネットワークなどで発生する独立した支払いの高速化に焦点を当てている。この技術は、誠実なバリデータが3分の2以上いれば、支払いの整合性を保証できる。FastPayは銀行や金融機関間ネットワークで使われるリアルタイム総括決済（RTGS）システムの一種である。
FastPayを基盤として、Lineraは支払いトランザクションの並列実行により、迅速な決済と低遅延に特化したブロックチェーンの構築を目指している。注目に値するのは、Suiも単純な支払いに対してBCB方式を採用している点である。他のトランザクションについては、DeFi取引などのより複雑で関連性のある処理を効率的に扱うために、Sui独自の合意メカニズムNarwhalとTuskが使用される。
Fuel
Fuelはモジュラー型ブロックチェーンにおける実行層となることを目指しており、つまりFuel自身は合意形成を実装せず、ブロックチェーンデータもFuelチェーン上に保存しない。完全な機能を持つブロックチェーンとして、FuelはイーサリアムやCelestiaなどの他のチェーンと連携して合意形成とデータ可用性を実現する。
FuelはUTXOを用いて厳密なアクセスリストを作成し、同一ステートへのアクセスを制御する。このモデルは「正規トランザクション順序付け」の概念に基づいている。この方式では、ブロック内のトランザクション順序が固定されることで、トランザクション間の関連性検出が大幅に簡素化される。このアーキテクチャを実現するために、FuelはFuelVMという新しい仮想マシンとSwayという新しい言語を開発した。
FuelVMはEVMと互換性があり、簡素化された設計により開発者がFuelエコシステムに参加しやすくなっている。
さらに、Fuelがモジュラー型ブロックチェーンに注力しているため、FuelのSC実行はイーサリアムメインネット上で解決できる。このアプローチは、ロールアップ中心の決済・データ可用性レイヤーを目指すポストマージのイーサリアムビジョンと一致している。このアーキテクチャにより、Fuelはイーサリアム上で高スループットの実行を行い、バッチ処理と決済が可能になる。
コンセプトの検証として、FuelチームはUniswapに類似したAMMであるSwaySwapをテストネット上で動作させている。これはFuelVMがEVMよりも優れたパフォーマンスを発揮することを証明する目的がある。
並列実行アプローチの課題
並列実行のアプローチは論理的で直接的のように見えるが、現時点では依然としていくつかの課題が残っている。第一に、このような並列実行方式で実際に加速可能なトランザクションの割合を正確に見積もりにくいこと。第二に、ネットワークの非中央集権性の維持である。つまり、バリデータが計算能力を簡単に拡張してスループットを上げられる場合、フルノードはチェーンの正当性を検証するためにそれについていけるのか？
並列実行可能なトランザクションの割合
任意のチェーン上で並列実行可能なオンチェーントランザクションの割合を正確に推定することは困難である。さらに、ネットワーク活動の種類によって、この割合はブロックごとに大きく変動する。
たとえば、NFTミントでは関連性の高いトランザクションが集中する可能性がある。それでも、いくつかの仮定を用いることで、並列実行可能なトランザクションの平均割合を大まかに推定できる。
たとえば、ETHおよびERC20の大部分の送金は独立していると仮定できる。つまり、異なるアドレスから開始され、異なるアドレスに送信される。そのため、ETHおよびERC20送金の約25%が相互に関連している（つまり、SCへの預け入れや取引所ホットウォレットの資産をコールドウォレットに集約する場合）と仮定できる。
一方、同一プール内のすべてのAMMトランザクションは関連している。ほとんどのAMMは少数のプールに支配されており、AMMトランザクションは高度に組み合わせ可能で複数のプールと相互作用するため、少なくとも50%のAMMトランザクションが相互に関連していると安全に仮定できる。
イーサリアムのトランザクションカテゴリを分析すると、1日あたり約120万件のトランザクションの内訳は以下の通り：20-30%がETH送金、10-20%がステーブルコイン送金、10-15%がDEX取引、4-6%がNFT取引、8-10%がERC20承認、12-15%がその他のERC20送金。
これらの数字と仮定を用いると、PEによってSCプラットフォームの約70-80%のトランザクションが加速可能と推定できる。
つまり、関連トランザクションの逐次的実行は全トランザクションの20-30%を占める。言い換えれば、同じガス制限を用いた場合、PEによりスループットが3〜5倍の向上が可能である。
並列実行EVMの構築に関するいくつかの実験でも、同様の推定が示されており、継続的に3〜5倍のスループット向上が達成されている。
実際には、高スループットチェーンはより高いガス制限と短いブロック時間により、イーサリアムのスループットを100倍以上向上させている。この増加したスループットを処理するには強力なバリデータノードが必要となり、それが第二の課題――ネットワークの中央集権化――を引き起こす。
ネットワークの中央集権化
高スループットネットワークでは、ネットワークは1秒間に数万件のトランザクションを処理できる。
バリデータノードは手数料およびネットワーク報酬のインセンティブにより、これらのトランザクションを処理するために専用サーバーや拡張可能なクラウドアーキテクチャに投資する。しかし、チェーンを利用し、フルノードを実行してチェーンとインタラクトする企業や個人にとってはそうではない。これらは大規模なトランザクション負荷を処理できる高価なサーバーを負担できない。その結果、チェーン利用者はInfuraのような専門のRPCノードプロバイダーに依存せざるを得ず、中央集権化が進行する。
コンシューマーレベルのハードウェアでフルノードを運営する選択肢がない場合、高スループットチェーンは閉鎖的なシステムとなり、少数の実体がネットワークに絶対的な支配権を持つ可能性がある。このような状況下では、これらの実体がTornado Cashのようにトランザクション、アカウント、アプリケーションを協調して検閲し、Web2とほとんど変わらない許可型システムに転落するリスクがある。
現在、Suiテストネットのフルノード運営要件はAptosテストネットよりも低い。しかし、メインネットが立ち上がり、アプリケーションがチェーン上に登場するにつれて、これらの要件は大きく変化すると予想される。
非中央集権化の支持者たちは、こうした予想される問題を解決するためのソリューションを提案し続けている。その代表例は、ZK有効性証明や詐欺証明を用いて軽量ノードがブロックの正当性を検証する方法である。
Fuelチームはこの点で積極的であり、イーサリアムコミュニティが重視する非中央集権化の精神と一致している。AptosやSuiのチームがこうした方法や非中央集権化促進策を優先しているかどうかは不明である。Lineraチームは紹介記事でこうした問題に簡単に触れていながら、プロトコル実装ではこのコミットメントが確認されていない。
まとめ
並列実行エンジンは、スマートコントラクトプラットフォームのスループット向上に有望な解決策である。
合意形成メカニズムの革新と組み合わせることで、トランザクションの並列実行はチェーンのスループットを10万TPSに近づけ、あるいはそれを超えることが可能になる。このような性能はVisaやMastercardと同等であり、完全なオンチェーンゲームや分散型マイクロペイメントなど、現在最も困難なユースケースの実現を可能にする。
こうした印象的なスループット改善には課題が伴う。特に非中央集権性の確保に関する課題について、解決に取り組む創設者たちに期待したい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@MohamedFFouda
