Layer1の並行実行の詳細：Aptos、Sui、Linera、Fuelはどのように実現しているのか？

原文标题：《The Case for Parallel Processing Chains》

原文作者：Mohamed Fouda

原文编译：深潮 TechFlow

私たちがブロックチェーン技術の進化を再評価する際、新しいL1が並行実行に重点を置いているという強力なトレンドが現れていることがわかります。

これは新しい技術ではなく、現在SolanaはSealevelの実行環境でこれを使用しています。

しかし、過去のブルマーケットでは、DeFiやNFTの印象的なパフォーマンスが、技術の改善が急務であることを認識させました。

次の市場では、並行実行の理念を採用したいくつかの著名なプロジェクトが登場する予定で、そのリストにはAptos、Sui、Linera、Fuelが含まれています。

この記事では、これらのプロジェクトの違いと共通点、そして彼らが直面している課題について議論します。

問題

スマートコントラクトプラットフォームは広範な分散型アプリケーションを作成できます。これらのアプリケーションを実行するためには、共有の計算エンジンが必要です。ネットワーク内の各ノードはこの計算エンジンを実行し、アプリケーションを実行し、ユーザーとアプリケーションの相互作用を処理します。ノードが実行から同じ結果を得ると、彼らは合意に達し、チェーンの運営を推進します。

イーサリアム仮想マシンは最も主要なスマートコントラクト（SC）実行エンジンで、約20種類の異なる実装方法があります。

EVMが発明されて以来、開発者が採用するための臨界質量を確立しました。

イーサリアムとイーサリアムのL2を除いて、Polygon、BNBスマートチェーン、Avalanche Cチェーンなどの他のいくつかのチェーンもEVMを実行エンジンとして採用し、ネットワークのスループットを向上させるためにコンセンサスメカニズムを変更することに焦点を当てています。

EVMの主な制限的特徴は取引の順次実行です。EVMは基本的に1つの取引を1回実行し、他のすべての取引を保留にし、取引が完了し、ブロックチェーンの状態が更新されるまで待機します。たとえ2つの取引が独立していても、例えば、アリスからボブへの支払いとキャロルからデイブへの別の支払いであっても、EVMはこれらの取引を並行して実行することができません。この実行モードは、フラッシュローンのような興味深いユースケースを可能にしますが、効率もスケーラビリティもありません。

この順次実行取引はネットワークスループットの主要なボトルネックの1つです：

• まず、これによりブロック内の取引実行時間が長くなり、ブロック時間が制限されます。
• さらに、ノードが取引を実行し、ブロックを確認できるようにするために、ブロックに追加できる取引の数が制限されます。

イーサリアムの平均スループットは約17 tx/秒です。この低いスループットは、高い活動期間、例えばNFTミントの際に、ネットワークのマイナー/バリデーターがすべての取引を処理できないことを意味し、優先実行を確保するための手数料入札戦争が発生し、取引手数料が上昇します。イーサリアムの平均手数料は、ある時点で0.2 ETH（約800ドル）を超え、多くのユーザーがイーサリアムを使用することを躊躇しました。

順次実行の第二の問題はネットワークノードの非効率性です。順次命令実行は複数のプロセッサコアから利益を得ることができず、これによりハードウェアの利用率が低下し、効率が悪化します。これがスケーラビリティを妨げ、不要なエネルギー消費を引き起こします。

並行実行はこの問題を解決できるのか？

EVM構造の制限は並行実行（PE）のL1新領域を創出する条件を整えています。並行実行は、複数のプロセッサコア間で取引処理を分割し、ハードウェアの利用率を向上させ、より良いスケーラビリティを実現します。高スループットチェーンでは、ハードウェアリソースの増加は実行可能な取引の数に直接関連しています。

高頻度の活動期間中、バリデータノードは追加の取引負荷を処理するためにより多くのコアを委任できます。計算リソースの動的拡張により、ネットワークは高需要の時期により高いスループットを実現し、ユーザー体験を大幅に改善します。

このアプローチのもう1つの利点は、取引確認の遅延が改善されることです。ノードリソースの動的拡張により、すべての可能なネットワーク負荷に対する低遅延取引の確認が可能になります。

取引は数十または数百のブロックを待つ必要もなく、優先確認のために過剰な手数料を発生させる必要もありません。改善された確認時間は取引の確定性を高め、低遅延ブロックチェーンへの扉を開きます。取引を実行する低遅延を保証することで、いくつかの以前は実現不可能だったユースケースが可能になります。

チェーンの実行モデルを変更してPEを許可することは新しいアイデアではなく、いくつかのプロジェクトがこれを探求しています。1つのアプローチは、EVMが使用する会計モデルをアカウントモデルから未使用トランザクション出力（UTXO）モデルに置き換えることです。UTXO実行モデルはビットコインで使用されており、取引の並行処理を可能にするため、支払いの理想的な選択肢となります。

しかし、UXTOの機能は限られており、スマートコントラクトに必要な複雑な相互作用を実現するためには拡張が必要です。例えば、Cardanoはこの目的のために拡張されたUTXOモデルを使用し、FindoraはハイブリッドUTXOモデルを使用しており、これは2つの会計モデルを実現し、ユーザーが2つのモデル間で資産タイプを変更できるようにします。

PEの別のアプローチは、アカウントモデルを変更するのではなく、チェーン状態のアーキテクチャと修正を改善することに焦点を当てています。例えば、SolanaのSealevelフレームワークです。

並行実行はどのように機能するのか？

並行実行の方法は、独立した取引を特定し、それらを同時に実行することです。もしある取引の実行が別の取引の実行に影響を与える場合、2つの取引は関連しています。例えば、同じプール内のAMM取引は関連しており、順次実行する必要があります。

並行処理の概念は簡単に聞こえますが、困難は詳細にあります。主な課題は、どのように効果的に「独立」取引を特定するかです。独立取引の分類には、各取引がブロックチェーンのメモリやチェーン状態をどのように変更するかを理解する必要があります。同じスマートコントラクト（例えばAMMプール）と相互作用する取引は、同時に契約状態を変更することができないため、同時に実行することはできません。

現在のアプリケーション間のコンポーザビリティの程度を考えると、相互に関連しているかどうかを特定することは挑戦的なタスクです。例えば、UNIをUSDCに交換するAMM取引を想像してください。AMMはそれを実行する最も効率的なルートがUNI -> ETH -> DAI -> AAVE -> USDCであることを発見します。この取引に参加するすべてのプールは、この取引が完全に実行されるまで他の取引を処理できず、その後に初めてすべての参加プールの状態が更新されます。

独立取引の特定

このセクションでは、異なる並行実行エンジンが使用する方法を比較します。焦点は状態（メモリ）アクセスを制御する方法にあります。ブロックチェーンの状態はRAMストレージと見なすことができ、各チェーンのアカウントやスマートコントラクトは、変更可能なメモリ位置のセットを持っています。関連取引は、同じブロック内の同じメモリ位置を変更しようとする取引です。異なるチェーンは、これらの取引を特定するために異なるメモリアーキテクチャと異なるメカニズムを利用しています。

このカテゴリのいくつかのチェーンは、Facebookが開発したブロックチェーンプロジェクトDiemの技術の上に構築されています。Diemチームは、SCの実行を改善するために特別に設計されたスマートコントラクト言語Moveを作成しました。Aptos、Sui、Lineraは、このグループに属する3つの高名なプロジェクトです。このグループに加えて、FuelはPEに焦点を当てた別の著名なプロジェクトで、独自のSC言語を使用しています。

Aptos

AptosはDiemのMove言語とMoveVMに基づいて構築され、高スループットのチェーンを実現し、並行実行を実現しました。

Aptosのアプローチは、関連性を検出しながら、ユーザー/開発者に透明性を提供することです。つまり、取引はどの部分の状態（メモリ位置）を使用するかを明示的に宣言する必要はありません。

Aptosは、Software Transactional Memory（STM）の修正版であるBlock-STMを使用しています。

Block-STMでは、取引はブロック内で事前にソートされ、プロセッサスレッド間で分割されて実行されます。

その過程で、取引の実行は関連性がないと仮定されます。取引によって変更されたメモリ位置が記録され、実行後にすべての取引の結果が検証されます。検証プロセス中に、ある取引が前の取引によって変更されたメモリ位置にアクセスしていることが判明した場合、その取引は無効になります。その取引の結果はリフレッシュされ、再実行されます。

このプロセスは、ブロック内のすべての取引が実行されるまで繰り返されます。

複数のプロセッサコアを使用する場合、Block-STMは実行速度を加速し、加速の程度は取引の相互関連性の程度に依存します。

Aptosチームの結果は、32コアを使用することで高い相互関連性能を8倍、低い相互関連性能を16倍に向上させることができることを示しています。もしブロック内のすべての取引が相互依存している場合、順次実行と比較してBlock-STMはパフォーマンスのわずかな損失を引き起こします。Aptosは、このアプローチにより160,000 TPSのスループットを実現できると主張しています。

Sui

別のPEアプローチは、取引が変更するチェーン状態の部分を明示的に宣言することを要求するもので、現在SolanaとSuiがこの方法を使用しています。

Solanaはメモリユニットをアカウントと呼び、取引はどのアカウントを変更したかを明示する必要があります。Suiも同様のアプローチを使用しています。

SuiもDiemの技術の上にMoveVMを使用して構築されています。しかし、Suiは異なるバージョンのMove言語を使用しています。

Sui Moveの実装は、Diemのコアストレージモデルと資産権限を変更しており、これはコアDiem Moveを使用するAptosとの重大な違いを示しています。

Sui Moveは、独立取引をより容易に特定できる状態ストレージモデルを定義しています。

Suiでは、状態ストレージはオブジェクトとして定義されます。オブジェクトは通常資産を表し、共有可能であり、複数のユーザーがそのオブジェクトを変更できます。各オブジェクトはSui実行環境内で一意のIDを持ち、所有者アドレスへの内部ポインタを持っています。これらの概念を使用することで、取引が同じオブジェクトを使用しているかどうかを確認することで関連性を特定することが容易になります。

関連性を宣言する作業を開発者に移すことで、実行エンジンの実装が容易になり、理論的にはより良いパフォーマンスとスケーラビリティを実現できます。しかし、これはあまり理想的でない開発者体験の代償となります。

Suiはまだ開始されておらず、最近テストネットを立ち上げたばかりです。

Suiの創設者は、並行実行の実装とNarwhalおよびTuskコンセンサスメカニズムの使用により、スループットが100,000 tx/秒を超えると主張しています。このスループットが真実であれば、現在のSolanaの約2,400 tx/秒のスループットよりも大幅に向上し、VisaやMastercardのスループットを超える可能性があります。

Linera

Lineraは並行処理分野の最新メンバーで、最近a16zがリードした最初の資金調達を発表しました。プロジェクトの実施に関する詳細はあまりありません。しかし、彼らの資金調達発表の投稿によれば、これはFacebookで開発されたFastPayプロトコルに基づいています。

FastPayは、独立した支払いを加速することに焦点を当てた「Byzantine Consistent Broadcast」と呼ばれる技術に基づいています。これにより、検証者のグループは、3分の2以上の検証者が誠実である限り、支払いの完全性を確保できます。FastPayは、銀行や金融機関間のネットワーク用のリアルタイム毛額決済（RTGS）システムの一種です。

FastPayを基に、Lineraは並行実行による支払い取引を構築し、迅速な決済と低遅延に焦点を当てたブロックチェーンを構築する計画です。注目すべきは、Suiも簡単な支払いのためにByzantine Consistent Broadcastの方法を使用していることです。他の取引に関しては、Sui自身のコンセンサスメカニズムであるNarwhalとTuskが、DeFi取引などのより複雑で関連性のある取引を効率的に処理するために使用されます。

Fuel

Fuelはモジュラーなブロックチェーンの実行層になることに焦点を当てており、これはFuelがコンセンサスを実施せず、ブロックチェーンのデータをFuelチェーンに保存しないことを意味します。機能的なブロックチェーンに対して、FuelはEthereumやCelestiaなどの他のチェーンと相互作用してコンセンサスとデータの可用性を達成します。

FuelはUTXOを使用して厳格なアクセスリストを作成し、同じ状態へのアクセスを制御するためのリストを使用します。このモデルは、取引の順序を規定するという概念に基づいています。このスキームでは、ブロック内の取引の順序が取引間の関連性を検出することを大幅に簡素化します。このアーキテクチャを実現するために、Fuel社はFuelVMと呼ばれる新しい仮想マシンとSwayと呼ばれる新しい言語を構築しました。

FuelVMはEVMの互換性と簡略化された表現であり、開発者がFuelのエコシステムに参加しやすくなります。

さらに、Fuelはモジュラーなブロックチェーンに焦点を当てているため、Fuel SCの実行はEthereumメインネットで解決できます。このアプローチは、合併後のEthereumのビジョン、すなわちRollup中心の決済とデータ可用性層としての役割に一致します。このアーキテクチャでは、FuelはEthereum上でバッチ処理と決済の高スループット実行を実現できます。

この概念を検証するために、FuelチームはUniswapに似たAMMであるSwaySwapを作成し、テストネットで運用しています。目的は、FuelVMがEVMと比較してより高いパフォーマンスを持つことを証明することです。

並行実行方法の課題

並行実行の方法は論理的で直接的に見えますが、現在私たちはいくつかの課題に直面しています。まず、こうした並行実行方式で加速できる取引の実際の割合を推定することです。第二の課題は、ネットワークの分散化です。つまり、もしバリデーターがスループットを向上させるために計算能力を簡単に拡張できるなら、完全ノードはどのようにしてチェーンの正確性を確保するのでしょうか？

可並行取引の割合

任意のチェーン上で可並行実行の取引の割合を正確に推定することは挑戦的です。さらに、ネットワーク活動の種類に応じて、この割合はブロック間で大きく変動します。

例えば、NFTミントは高い割合の関連性のある取引の爆発を引き起こす可能性があります。つまり、可並行取引の平均割合の粗い推定を得るためにいくつかの仮定を使用できます。

例えば、ほとんどのETHとERC20の移転は独立していると仮定できます。つまり、異なるアドレスから発信され、異なるアドレスに受信されます。したがって、約25%のETHとERC20の送金は相互に関連していると仮定できます。これは、SCへの入金や取引所のホットウォレットの資産をコールドウォレットに集約する場合です。

一方、同じプール内のすべてのAMM取引は関連性があります。ほとんどのAMMが通常少数のプールによって主導され、AMM取引が高度なコンポーザビリティを持ち、複数のプールと相互作用することを考慮すると、少なくとも50%のAMM取引が相互に関連していると安全に仮定できます。

イーサリアムの取引カテゴリを分析すると、イーサリアムの毎日の約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倍のイーサリアムのスループット向上を実現します。増加したスループットは、これらのブロックを処理するために強力なバリデータノードを必要とし、この要求がネットワークの中央集権化という第二の課題を引き起こします。

ネットワークの中央集権化

高スループットのネットワークでは、ネットワークは毎秒数万の取引を処理できます。

バリデータノードは、これらの取引を処理するために手数料とネットワーク報酬によってインセンティブを受け、専用サーバーやスケーラブルなクラウドアーキテクチャに投資します。しかし、チェーンを使用し、完全ノードを実行してチェーンと相互作用する必要がある企業や個人にとっては、状況は異なります。これらの実体は、このような大規模な取引負荷を処理するための複雑なサーバーを負担できません。これにより、チェーン上のユーザーは、Infuraのような専門のRPCノードプロバイダーに依存することになり、より多くの中央集権化を引き起こします。

消費者向けハードウェアを使用して完全ノードを実行することを選択しない限り、高スループットのチェーンは閉じたシステムに変わる可能性があり、一部の実体がネットワークに対して絶対的な権力を持つことになります。この場合、これらの実体は取引、実体、さらにはアプリケーション（例えばTornado Cash）を検閲することを調整でき、これらのチェーンをWeb 2と何も変わらない許可システムに変えることができます。

現在、Suiテストネットで完全ノードを運営する要件はAptosテストネットノードの要件よりも低いです。しかし、メインネットが立ち上がり、アプリケーションがチェーン上に登場し始めると、これらの要件は大きく変わると予想されます。

分散化の提唱者たちは、これらの予想される問題を解決するためのソリューションを提案し続けています。これらのソリューションには、軽量ノードを使用し、ZK有効性証明や詐欺証明を使用してブロックの正確性を検証することが含まれます。

Fuelチームはこの点で非常に積極的で、Ethereumコミュニティの分散化の重要性に関する精神に一致しています。AptosとSuiのチームがこれらの方法や他の分散化を促進する方法を優先して実施しているかどうかは不明です。Lineraチームは彼らの紹介投稿でこれらの問題について簡単に議論しましたが、プロトコルの実施はこのコミットメントを確認していません。

まとめ

並行実行エンジンはスマートコントラクトプラットフォームのスループットを向上させる有望なソリューションです。

コンセンサスメカニズムの革新と組み合わせることで、取引の並行実行はチェーンのスループットを10万TPSに近づけるか、超えることができ、このようなパフォーマンスはVisaやMastercardに匹敵し、完全なオンチェーンゲームや分散型マイクロペイメントなど、今日の最も挑戦的なユースケースのいくつかを実現できます。

これらの印象的なスループットの改善は、分散化を確保する方法に関する課題を伴います。私たちは、これらの問題を解決することに取り組む創設者たちを期待しています。