原題：「The Case for Parallel Processing Chains》
オリジナルの編集:
オリジナルの編集:ディープタイドTechFlow
ディープタイドTechFlow
ブロックチェーン テクノロジーの進化を再考すると、並列実行に重点を置いた新しい L1 という強力な傾向が現れていることがわかります。
これは新しいことではなく、Solana は現在 Sealevel の実行環境で使用されています。
しかし、過去の強気市場におけるDeFiとNFTの目覚ましいパフォーマンスは、このテクノロジーが緊急に改善する必要があるという事実にも認識をもたらしました。
この記事では、これらのプロジェクトの類似点と相違点、およびそれらが直面する課題について説明します。
質問
質問スマート コントラクト プラットフォームは、幅広い分散アプリケーションを作成できます。
これらのアプリケーションを実行するには、共有コンピューティング エンジンが必要です。ネットワーク内のすべてのノードは、このコンピューティング エンジンを実行するだけでなく、アプリケーションとアプリケーションとのユーザーの対話も実行します。ノードが実行されて同じ結果が得られると、ノードは合意に達し、チェーンを前進させます。
イーサリアム仮想マシンは主要なスマート コントラクト (SC) 実行エンジンであり、約 20 種類の異なる実装があります。
EVM が発明されて以来、開発者による採用のクリティカルマスを構築してきました。
イーサリアムとイーサリアムの L2 に加えて、Polygon、BNB スマート チェーン、Avalanche C チェーンを含む他のいくつかのチェーンはすべて、実行エンジンとして EVM を採用し、ネットワーク スループットを向上させるためにコンセンサス メカニズムの変更に重点を置いています。EVM の主な制限機能は、トランザクションの順次実行です。
EVM は基本的にトランザクションを一度に 1 つずつ実行し、トランザクションが実行されてブロックチェーンの状態が更新されるまで、他のすべてのトランザクションを保留します。 2 つのトランザクションが独立している場合でも (たとえば、アリスからボブへの支払いと、キャロルからデイブへのもう 1 つの支払い)、EVM はこれらのトランザクションを並行して実行することはできません。この実行モードではフラッシュ ローンなどの興味深い使用例が可能ですが、効率的でも拡張性でもありません。
このトランザクションの順次実行は、ネットワーク スループットの主なボトルネックの 1 つです。
まず、ブロック内のトランザクションの実行時間が長くなり、ブロック時間が制限されます。
さらに、ノードがトランザクションを実行してブロックを確認できるようにするために、ブロックに追加できるトランザクションの数が制限されます。
イーサリアムの平均スループットは約 17 tx/s です。このスループットの低さは、NFT Mintなどのアクティビティが活発な期間中、ネットワークマイナー/バリデーターがすべてのトランザクションを処理できず、優先実行を確保するために手数料入札合戦が発生し、トランザクション手数料が上昇することを意味します。イーサリアムの平均手数料はある時点で 0.2 ETH (約 800 ドル) を超え、多くのユーザーがイーサリアムの使用を思いとどまりました。順次実行に関する 2 番目の問題は、ネットワーク ノードの非効率性です。
順次命令の実行では複数のプロセッサ コアの恩恵を受けることができないため、ハードウェアの使用率が低くなり、非効率になります。これはスケーラビリティを妨げ、不必要なエネルギー消費につながります。
並列実行でこの問題は解決できるでしょうか?EVM アーキテクチャの制約により、並列実行 (PE) の新しい L1 レルムが可能になります。
並列処理により、トランザクション処理を複数のプロセッサ コア間で分割できるため、ハードウェアの使用率が向上し、スケーラビリティが向上します。高スループット チェーンでは、ハードウェア リソースの増加は、実行できるトランザクションの数に直接関係します。
アクティビティが活発な期間中、バリデーター ノードは追加のトランザクション負荷を処理するためにより多くのコアを委任できます。コンピューティング リソースの動的なスケーリングにより、需要が高い期間にネットワークがより高いスループットを達成できるようになり、ユーザー エクスペリエンスが大幅に向上します。
また、トランザクション確認のレイテンシが改善され、ノードリソースの動的な拡張により、考えられるすべてのネットワーク負荷を低レイテンシのトランザクションで確認できるという利点もあります。トランザクションは数十、数百のブロックを待つ必要もありませんし、優先順位の確認のために過剰な手数料を発生させる必要もありません。
確認時間の短縮によりトランザクションのファイナリティが向上し、低レイテンシーのブロックチェーンへの扉が開かれます。トランザクション実行時の低レイテンシが保証されているため、これまで不可能だったいくつかのユースケースが可能になります。
PE を許可するために連鎖実行モデルを変更することは新しいアイデアではなく、いくつかのプロジェクトがそれを検討しています。 1 つのアプローチは、EVM によって使用される会計モデルを、Accounts モデルから Unspent Transaction Output (UTXO) モデルに置き換えることです。ビットコインで使用されている UTXO 実行モデルでは、トランザクションを並行して処理できるため、支払いに最適です。ただし、UXTO の機能は限られているため、スマート コントラクトに必要な複雑なインタラクションを実現するには拡張する必要があります。
たとえば、Cardano はこの目的で拡張 UTXO モデルを使用しますが、Findora はハイブリッド UTXO モデルを使用します。これにより 2 つの会計モデルが実装され、ユーザーは 2 つのモデル間で資産タイプを変更できます。PE への別のアプローチでは、アカウント モデルは変更されませんが、代わりにアーキテクチャの改善とチェーン状態の変更に焦点が当てられます。
たとえば、Solana の Sealevel フレームワーク。
並列実行はどのように機能しますか?並列実行は、独立したトランザクションを識別し、それらを同時に実行することによって機能します。
1 つのトランザクションの実行が別のトランザクションの実行に影響を与える場合、2 つのトランザクションが関連付けられます。たとえば、同じプール内の AMM トランザクションはリンクされており、順番に実行する必要があります。"並列処理の概念は単純そうに見えますが、難しいのは細部にあります。"独立した
貿易。独立したトランザクションを分類するには、各トランザクションがブロックチェーン メモリやチェーンの状態をどのように変更するかを理解する必要があります。同じスマート コントラクト (AMM プールなど) と対話するトランザクションは、同時にコントラクトの状態を変更する可能性があるため、実行できません。同時に。
現在のアプリケーション間の構成可能性では、アプリケーションが相互に関連しているかどうかを識別するのは困難な作業です。 UNI を USDC に交換する AMM トランザクションを想像してください。AMM は、それを実行するための最も効率的なルートが UNI -> ETH -> DAI -> AAVE -> USDC であると判断します。トランザクションに参加しているすべてのプールは、トランザクションが完全に実行されるまで他のトランザクションを処理できません。完全に実行されると、参加しているすべてのプールの状態が更新されます。
独立したトランザクションを特定する
このカテゴリのいくつかのチェーンは、Facebook の廃止されたブロックチェーン プロジェクト Diem によって開発されたテクノロジーに基づいて構築されています。 Diem チームは、SC の実行を改善するために特別にスマート コントラクト言語 Move を作成しました。 Aptos、Sui、Linera は、このグループに分類される 3 つの注目度の高いプロジェクトです。このグループの他に、Fuel も独自の SC 言語を使用する PE に焦点を当てた有名なプロジェクトです。
Aptos
副題
Aptos は Diem の Move 言語と MoveVM に基づいて構築されており、並列実行を可能にする高スループット チェーンを作成します。Aptos のアプローチは、ユーザー/開発者に対して透過的に関連付けを検出することです。
つまり、トランザクションは状態のどの部分 (メモリの場所) を使用するかを明示的に示す必要はありません。
Aptos は、Block-STM と呼ばれるソフトウェア トランザクション メモリ (STM) の修正バージョンを使用します。
Block-STM では、トランザクションはブロック内で事前に順序付けされ、プロセッサ スレッド間で分割されて実行されます。
このプロセスでは、トランザクションの実行は無関係であると想定されます。トランザクションによって変更されたメモリ位置が記録され、実行後にすべてのトランザクションの結果が検証されます。検証中に、前のトランザクションによって変更されたメモリ位置にトランザクションがアクセスしていることが判明した場合、そのトランザクションは無効になります。トランザクションの結果はフラッシュされ、再実行されます。
このプロセスは、ブロック内のすべてのトランザクションが実行されるまで繰り返されます。
複数のプロセッサ コアが使用されている場合、Block-STM はトランザクションの相互接続の程度に応じて実行を高速化します。アプトスチームの結果は次のことを示しました。ブロック内のすべてのトランザクションが相互依存している場合、Block-STM は順次実行と比較してパフォーマンスにわずかなペナルティを引き起こす可能性があります。 Aptos は、このアプローチにより 160,000 TPS のスループットを達成できると主張しています。
Sui
副題
もう 1 つの PE アプローチは、トランザクションがチェーン状態のどの部分を変更するかを明示的に記述することを要求することであり、これは現在 Solana とSui によって使用されているアプローチです。
Solana ではメモリの単位をアカウントと呼び、トランザクションではどのアカウントを変更するかを指定する必要があります。スイも同様のアプローチをとりました。また、Sui は MoveVM を使用して Diem のテクノロジーを構築しています。
ただし、Sui は別のバージョンの Move 言語を使用します。
Sui Move の実装により、Diem のコア ストレージ モデルとアセットのアクセス許可が変更されます。これは、コア Diem Move を使用する Aptos との大きな違いを表します。
Sui Move は、独立したトランザクションを簡単に識別できるようにする状態ストレージ モデルを定義します。
Sui では、状態ストレージはオブジェクトとして定義されます。通常、オブジェクトはアセットを表し、共有できます。つまり、複数のユーザーがオブジェクトを変更できます。各オブジェクトは、Sui 実行環境内で一意の ID を持ち、所有者のアドレスを指す内部ポインターを持ちます。これらの概念を使用すると、トランザクションが同じオブジェクトを使用しているかどうかを確認することで、関連付けを簡単に識別できます。
関係を宣言する作業を開発者に移すことで、実行エンジンの実装が容易になり、理論的にはパフォーマンスとスケーラビリティが向上します。ただし、これには開発者エクスペリエンスが理想的とは言えないという代償が伴います。
Sui の創設者らは、並列実行の実装と Narwhal と Tusk のコンセンサス メカニズムの使用により、100,000 tx/秒を超えるスループットが得られたと主張しています。このスループットが本当であれば、Solanaの現在のスループット約2400tx/秒を大きく上回る可能性があり、VisaやMastercardのスループットを超えることになる。
Linera
副題Linera は並列処理分野への最も新しい参入者であり、最近、a16z が主導する最初の資金調達ラウンドを発表しました。
プロジェクトの実施に関する詳細はほとんどありません。ただし、資金調達に関する発表投稿によると、これも Facebook で開発された FastPay プロトコルに基づいていることがわかります。
Linera は、FastPay をベースに、決済トランザクションを並行して実行することにより、高速決済と低遅延に重点を置いたブロックチェーンを構築することを計画しています。注目に値するのは、Sui は簡単な支払いに Byzantine Consistent Broadcast 方式も使用していることです。他のトランザクションについては、Sui 独自のコンセンサス メカニズムである Narwhal と Tusk を使用して、DeFi トランザクションなどのより複雑でリレーショナルなトランザクションを効率的に処理します。
Fuel
副題Fuel は、モジュラー ブロックチェーンの実行層であることに重点を置いています。つまり、Fuel はコンセンサスを強制したり、ブロックチェーンのデータを Fuel チェーンに保存したりしません。
機能的なブロックチェーンの場合、Fuel はコンセンサスとデータの可用性を得るために、イーサリアムやセレスティアなどの他のチェーンと対話します。
Fuel は UTXO を使用して厳密なアクセス リスト、つまり同じ状態へのアクセスを制御するリストを作成します。このモデルは、正規のトランザクション順序付けの概念に基づいて構築されています。このスキームでは、ブロック内のトランザクションの順序付けにより、トランザクション間の関連性の検出が大幅に簡素化されます。このアーキテクチャを実装するために、Fuel は FuelVM と呼ばれる新しい仮想マシンと Sway と呼ばれる新しい言語を作成しました。
FuelVM は EVM と互換性があり簡略化された表現であり、開発者が Fuel エコシステムに効果的に参加できるようになります。
この概念を証明するために、Fuel チームは Uniswap に似た SwaySwap と呼ばれる AMM を作成し、テストネット上で実行しました。目的は、EVM と比較して FuelVM のパフォーマンスが高いことを実証することです。
最初のレベルのタイトル
並列実行のアプローチは論理的で簡単に思えますが、現時点ではまだいくつかの課題に直面しています。 1 つ目は、このタイプの並列実行を使用して高速化できるトランザクションの実際の割合を見積もることです。 2 番目の課題は、ネットワークの分散化です。つまり、バリデーターがコンピューティング能力を簡単に拡張してスループットを向上できる場合、フルノードはどのようにしてチェーンの正確性を確保できるでしょうか?
最初のレベルのタイトル
並列化できるトランザクションの割合どのチェーンでも並行して実行できるオンチェーン トランザクションの割合を正確に見積もることは困難です。
また、このパーセンテージは、ネットワーク アクティビティの種類に応じて、ブロックごとに大きく異なる可能性があります。
たとえば、NFT ミントは、関連トランザクションの割合が高く爆発を引き起こす可能性があります。とはいえ、いくつかの仮定を使用して、並列化できるトランザクションの平均割合を大まかに見積もることができます。
たとえば、ほとんどの ETH および ERC20 送金は独立している、つまり、異なるアドレスから発信され、異なるアドレスから受信されていると仮定できます。したがって、ETH と ERC20 の送金の約 25% は相互に関連している、つまり SC への入金と取引所のホット ウォレットからコールド ウォレットへの資産の集約であると推測できます。
一方、同じプール内のすべての AMM トランザクションは相関しています。ほとんどの AMM は通常、少数のプールによって支配されており、AMM トランザクションは高度に構成可能であり、複数のプールと対話することを考えると、AMM トランザクションの少なくとも 50% が相互接続されていると想定できます。
イーサリアムの取引カテゴリーを分析すると、イーサリアムでの 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 倍の増加を達成することが可能です。
実際には、高スループット チェーンは、より高いガス制限とより短いブロック時間を使用して、イーサリアムと比較して少なくとも 100 倍のスループット向上を達成します。スループットの向上には、これらのブロックを処理するための強力な検証ノードが必要ですが、この要件は 2 番目の課題であるネットワークの集中化につながります。
最初のレベルのタイトル
ネットワークの一元化
高スループットのネットワークでは、ネットワークは 1 秒あたり数万のトランザクションを処理できます。
バリデーターは、これらのトランザクションを処理するための手数料とネットワーク報酬によって動機づけられ、これらのトランザクションを処理するための専用サーバーまたはスケーラブルなクラウド アーキテクチャに投資します。これは、チェーンを使用し、チェーンと対話するためにフルノードを実行する必要がある企業や個人には当てはまりません。これらのエンティティには、このような大量のトランザクション負荷を処理するための複雑なサーバーを設置する余裕はありません。これにより、オンチェーン ユーザーは Infura などの特殊な RPC ノード プロバイダーに依存するようになり、集中化がさらに進みます。
フルノードを実行するために消費者グレードのハードウェアを使用するオプションがなければ、高スループットのチェーンは、ネットワーク上で絶対的な権限を持つ少数のエンティティのグループを持つ閉鎖システムになる可能性があります。この場合、これらのエンティティは、トランザクション、エンティティ、さらには Tornado Cash などのアプリケーションを精査して調整することができ、これらのチェーンを Web 2 と同様に許可されたシステムに変えることができます。現在、Sui テストネット上でフル ノードを動作させるための要件は、Aptos テストネット ノードの要件よりも低くなります。
ただし、メインネットが立ち上げられ、アプリケーションがオンチェーンに登場し始めると、これらのニーズが大きく変化すると予想されます。
要約する
要約する
並列実行エンジンは、スマート コントラクト プラットフォームのスループットを向上させる有望なソリューションです。
並列実行エンジンは、スマート コントラクト プラットフォームのスループットを向上させる有望なソリューションです。
元のリンク
