実行環境の未来
暗号投資機関アーキタイプの研究者ベンジャミン・ファンクは、実行レイヤーのボトルネックを効率の悪い状態アクセスと計算に帰すると述べています。彼は、統合されたモジュラーエグゼキューション環境による設計選択肢を評価し、高いパフォーマンスを達成し、オンチェーンアプリケーションの範囲を拡大することを検討しています。転送されたオリジナルタイトル: デザイナーブロックスペース: 実行環境の未来
Ethereumが最初の分散型プログラマブルブロックチェーンを発表してから9年が経過し、仮想通貨は数十億人のユーザーにスケーリングするための障害に直面してきました。そして、この問題に対処するために、仮想通貨業界は継続的に新しいタイプのブロックチェーンを開発し、資金を提供してきました。
ただし、「パフォーマンス問題」という言葉は不適切に定義され、数量化されています。 例えば、「秒あたりの取引」などの合成メームは、本当は同等の計算作業を必要としない取引の間でリンゴとオレンジの比較をきれいにパッケージ化しています。 これらの指標の微妙な差異も、ブロックチェーンのコンポーネントがパフォーマンスに与える独立した影響を評価する能力を遮っており、高度に相互依存関係にある問題を解決するための最適化セットを特定するための原則に基づいたアプローチから私たちの注意を逸らしています。
この霧の中で、過去数年間にわたり、信頼性のある持続的なブロックチェーンのスケーラビリティの改善が実施されてきました。 Ethereum がロールアップ中心のロードマップを進める中、新しいロールアップの波、コプロセッサー、データの利用可能性（DA）レイヤー、および競合するL1が登場しており、それぞれがユニークなデザイン選択肢を持ち、開発者にスケーラブルでユーザーフレンドリーなdappsを構築するためのパフォーマンスの高い環境を提供しています。
今日、EIP4844の導入と代替DAレイヤーは重要なDAボトルネックを緩和しました。 この重要なマイルストーンにもかかわらず、証拠は他の重要なボトルネックを解決する必要があることを示しています。先月、ベース収集されました1日で157万ドルの取引手数料イーサリアムへのデータ可用性コストはわずか5,000ドルであり、これは状態更新の検証と処理に必要な計算作業が依然として重要なボトルネックであり、改善の機会であることを示しています。
この記事では、統合型およびモジュラー実行環境が採用した設計選択肢について評価し、高性能を実現し、オンチェーンで展開できるアプリケーションの範囲を拡大する過程を検討します。
今日の挑戦
実行レイヤーのパフォーマンスは、実行ノードがチェーンのブロック時間に対して達成する計算作業に基づいてベンチマークを取ることができます。または、「1秒あたりの計算ガス」
この点を考慮すると、実行レイヤーのボトルネックを効率の悪い状態アクセスと効率の悪い計算の2つの相互に関連する要因に絞ることができます。
効率の悪い状態アクセスとは、ブロックチェーンの状態を取得および更新する際に発生するオーバーヘッドのことであり、これによりトランザクション処理が遅くなる可能性があります。一方、効率の悪い計算は、操作や状態の遷移を実行するアルゴリズムによって発生するオーバーヘッドの関数であり、単純な送金から複雑なスマートコントラクトや署名検証まで、さまざまなものが含まれることがあります。
これらのボトルネックは相互に強化し合い、ステートのアクセスの遅延が計算時間を延ばす一方、効率の悪い計算プラクティスはステート管理を圧迫する可能性があります。さらに、これらの問題に対処するための提案された改善策は、しばしばシャーディングやステートレスアーキテクチャの採用などの体系的な改善を必要とし、ステートのアクセスと計算の効率を高め、実行パフォーマンスを向上させることができます。
ボトルネック＃1：非効率なステートアクセス
ブロックチェーンの状態にアクセスするために必要なコストと速度は、実行環境のパフォーマンスにとって重要なボトルネックであり、状態の膨張の問題に要約されることがあります。
ブロックチェーンでは、世界の状態は特定のデータ構造を介して管理および更新されます。木. ツリーはブロックチェーンにとって不可欠であり、実行ノード外の当事者にブロックチェーンの正しい状態に関する保証を提供する安全かつ効率的な方法を提供します。トライ内の各更新は新しいルートハッシュを生成し、軽量クライアントは全体のチェーンを維持せずに取引と口座残高を検証するために参照できます。
イーサリアムは、特にMerkle Patricia trie（MPT）として知られるデータ構造に依存しています。@chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.
Ethereumはスマートコントラクトとトークンを増やすにつれて、その状態のトライはより大きく複雑になります。状態が成長すると、より多くのストレージスペース、処理するためのより多くの計算リソース、および送信するためのより多くの帯域幅が必要になります。同時に、ノードのハードウェア制約はほぼ同じままです。
この状態の成長は、状態がディスクに保存され、ディスク操作には高いオーバーヘッドがかかるため、イーサリアムのパフォーマンスに直接影響します。 CPUレジスタからデータにアクセスするのに0.1ナノ秒かかる一方、10から100マイクロ秒かかることがあります。（100倍～1000倍遅い）ディスクからデータにアクセスすると、その時間に実行された可能性のある200,000 CPU命令に大まかに翻訳されます。それは保守的な見積もりで36 ERC-20の転送に相当します！
この問題を悪化させるのは、ブロックチェーンが状態への読み書きに対して多くの効率の悪いアクセスパターンを持っていることです。たとえば、Merkle Patricia trieの非連続構造は、ディスクへの入出力（I/O）操作がディスク上のさまざまな予測不可能な場所から読み書きを行うことにつながります。トランザクション入力のランダムな性質とそれに続く状態の変更は、散在したデータアクセスパターンにつながり、状態の検証と更新プロセスを著しく遅らせ、状態の検証と更新に関しては一部のみを利用します。ハードウェアデバイスの容量.
全般的に、ブロックチェーンのための状態管理プリミティブは、その絶対的な潜在能力を達成するには程遠いものであり、計算効率を向上させるためには多くの進歩がなされることができます。
ボトルネック＃2：非効率な計算
実行レイヤーも非効率な計算のボトルネックに直面しており、これはさまざまな形で表れています。
1つには、多くのプロセスが逐次処理を行い、複数の操作を同時に処理できる現代のマルチコアプロセッサを効果的に活用していません。この逐次実行は、トランザクション間に避けられないCPUアイドル時間を生み出し、貴重な計算リソースを無駄にしています。
さらに、仮想マシンを使用すると、高レベルのスマートコントラクト操作をバイトコードに変換する必要があります。これは、プラットフォームに依存しない低レベルのコードであり、その後、命令ごとに実行されます。この翻訳および実行プロセスによって、特に複雑で頻繁に繰り返される特定のアプリケーションタスクを持つアプリケーションには、かなりのオーバーヘッドが発生します。
これらの非効率性は、計算リソースの最適利用を妨げ、実行レイヤーのパフォーマンスを阻害します。
ソリューション：非効率な状態アクセス
チームが実行中のノードのハードウェアから状態を取得および更新するレートを向上させるいくつかの異なる方法があります。これには、複雑なデータ構造を単純化し、状態の膨張につながるコストの高いディスクI/O操作を削減する方法を見つけることが含まれます。
Statelessness & インメモリコンピューティング
一部の実行レイヤーは、単にそれを受け入れてしまうことでステートの膨張に対処しています。彼らは、より遅いディスクベースのシステムからより速いランダムアクセスメモリ（RAM）へのステートデータストレージをシフトします。RAMでのステート情報へのアクセスは、ディスク操作に伴うオーバーヘッドを大幅に削減し、それらはより遅く、リソースをより多く必要とします。
しかし、このアプローチは分散化の核心原則に挑戦しています。RAMに状態データをますます大量に格納することは、より高度で高価なハードウェアが必要とされるため、個人がノードオペレータとして参加する能力を制限する可能性があります。その結果、ハードウェア要件が高まるにつれて、より少ないエンティティがこれらのノードを運営する余裕があります。
コンピューティングの魅力と信頼の最小化のバランスを取るために、L1（Ethereumなど）とL2の両方が、バリデータの役割を分離された、中央集権的な実行ノードと多数の検証ノードに依存するスケーラビリティのロードマップを追求しています。このモデルでは、メモリ内でコンピューティングを行うためのハードウェア要件を持つ高性能なブロック生成者がブロックを生成する責任を持ち、検証ノードは暗号証明（詐欺と妥当性の証明）を活用してブロック生成者を責任を持たせます。
その結果、これらのシステムは、ブロック生産者が速度を最大限に活用できるようにするはずです。なぜなら、メモリ内で計算できるため、実行中に完全にディスクI/Oを排除できるからです。 RAMの遅延は通常100ナノ秒未満であるため、状態アクセスの遅延は、ディスクベースの実装に比べて最大1000倍短縮されます。
並行して、詐欺と有効性の証明が分散コンセンサスの代わりに使用されて、システムの信頼最小化特性とそのスループットを拡大します。その結果、強力な中央集権的なブロック生成ノードは、はるかに安価なハードウェアで実行できる検証ノードによって相殺されます。これらのノードは、状態遷移（または無効な状態遷移）の証明を独立して検証し、ブロックチェーン全体の状態を格納する負担なしに正確な状態を維持するための重要な機能を果たします。
このプロセスを最小信頼で実行するために、実行レイヤーは一定の程度を実装する必要があります。無国籍, 最も一般的なのは、「弱い状態のなさ」という概念です。弱い状態のなさは、ブロックプロデューサーが提供する暗号的な証明として知られているものを義務付けることによって実現されます。目撃者新しいブロックによる提案されたすべての状態変更をカプセル化することで、検証者がこれらの変更を追加の歴史データなしに検証できるようにする検証ノードに
この概念は、さまざまなツリー構造を使用して適用できますが、効率のためにMerkleツリーよりもVerkleツリーがよく選択されます。 Merkleツリーでは、データポイント（葉）からツリーのルートまでのパスに沿ってすべての兄弟ノードのハッシュを含める必要があり、データの整合性を証明するためにはこれが必要です。 この要件は、証拠のサイズ（整合性の証明）がツリーの高さとともに増加することを意味し、各レベルで追加のハッシュが必要となります。 結果として、Merkleツリーでのデータ整合性の検証は、特に大規模なデータセットの場合、計算量が増加し、コストがかかります。 対照的に、Verkleツリーはこのプロセスを効率化し、新しいブロックの生成と検証における計算とストレージに関連するオーバーヘッドを削減します。
イネヴィテーブル・イーサリアムの「Verkle Tree」からのVerkleツリースケーリング
Verkle treesは、従来のMerkle treesの構造を強化し、葉と根との間の接続を合理化し、検証プロセスで兄弟ノードを含める必要を排除することによって、その構造を向上させます。 Verkle treeでは、証明の検証には葉ノードの値、根ノードへのコミットメント、および多項式コミットメントに基づく単一のベクトルコミットメントのみが関与し、Merkle treeで見られる複数のハッシュベースのコミットメントを置き換えます。 この変化により、Verkle treesは固定サイズの証人を維持し、木の高さや検証される葉の数とともに増加しないため、データ検証中のストレージと計算の効率を大幅に向上させます。
今後数年間、L1およびL2レベルで状態のない実装が様々な構成で実施されることが予想されます。最新のEthereumのロードマップによると、検証者はブロックビルダーが特定のブロックの状態に関するVerkle証明を提供し、これらの軽量な証明を維持する代わりに検証することができます。
L2レベルでは、[Gate]のようなチームがいます MegaETHare actively applying the concept of statelessness to the design of optimistic rollups. In their design, the sequencer node generates a witness for each block containing the necessary state values and intermediate hashes while emitting a state delta representing the changes in the state. Verifier nodes can then re-execute any block by retrieving the witness from the DA layer or a peer-to-peer network without storing the entire state. In parallel, full nodes update their state by applying the state deltas disseminated through the network, allowing them to stay synchronized without re-executing transactions or storing the entire state history.
しかし、状態のないことやメモリ内での計算が可能であることの利点はあるものの、実行レイヤーのパフォーマンスに対する銀の弾丸とは言えません。
MegaETHの「Ethereum実行レイヤーパフォーマンスの理解」からのリアルタイムTPS
MegaETHの共同創設者であるYilong Liは、以下で識別します研究プレゼンテーションイーサリアムの実行時には、最適化されたままであるオンチェーン上のデータ構造とアクセスパターンには他の非効率があります。
データベースの改善
実行レイヤーで作業しているチームは、これらのデータベースの構造を改善し、イーサリアムや他のEVM互換ブロックチェーンが非効率な状態アクセスに対処する際に経験するいくつかのボトルネックを排除する方法を見つけようとしています。これにより、計算効率に影響を与える連鎖反応が生じます。
実際には、EVMで見つかった既存のデータベース設計の制限に影響を受けましたMonad’s*決定は、単に計算効率を最適化することを超えて、並列化を実現することを目指しています。Monadは、並列実行を実装した後も、データベースへのマルチスレッド読み取りと書き込みリクエストが互いにブロックし合うため、パフォーマンスのわずかなスピードアップしか見られなかったことが分かりました。その結果、Monadは非同期IO（AIO）または並列アクセスに対応したデータベースを実装することを解決策の重要な部分として採用しました。
非同期I/O
I/O操作（ストレージデバイスから読み取ったり書き込んだりするなど）は、特に機械式ハードディスクドライブ（HDD）では、しばしばボトルネックを作り出します。これらのドライブでは、データにアクセスするために読み書きヘッドを物理的に動かす必要があり、データ処理を著しく遅くする可能性があります。
AIOは、プログラムが他のプロセスと同時にI/O操作を実行できるようにすることで、この課題に対処しています。基本的に、プログラムはI/O操作を開始し、完了を待つことなく進むことができます。これは、I/O操作が完了すると、オペレーティングシステムやI/Oライブラリが満たすコールバック関数やプロミスを登録することで行われます。この非同期アプローチにより、メインプログラムは他のタスクを実行し続けることができ、I/Oタスクの完了を待つことなく全体的な効率が向上します。
非同期I/Oは、従来のHDDとソリッドステートドライブ（SSD）の両方で実装することができますが、SSDの方が効果がより顕著です。HDDはAIOを実行できますが、その機械的な性質から、データをフラッシュメモリに保存し動く部品がないSSDよりも遅くなる傾向があり、結果としてアクセス時間が速くなります。
例えば、MonadはSSDストレージ向けに最適化されたカスタムステートバックエンドを利用しており、高レベルな並列データ処理をサポートし、I/O待ち時間を削減しています。このセットアップは、従来のディスクベースのストレージだけに依存するシステムやインメモリデータベースを使用するシステムよりも効率的ですが、これらは依然として遅いストレージメディアへの頻繁なデータの書き込みや読み取りから遅延が発生する可能性があります。
同様に、Rethはデータベース操作をコアのEVM実行エンジンから分離する方法を採用しています。このセットアップにより、EVMバイトコードを単一スレッドで順次実行し、データベースI/Oタスクを並列プロセスにオフロードして一貫性を維持します。Rethはアクターモデルと呼ばれるソフトウェアアーキテクチャパターンを使用して、これらの並列プロセスを効果的に管理し、I/O操作がEVMインタプリタを中断しないようにします。
ステートメルカリゼーション周波数
最適化のための別のベクトルは、状態のマークライゼーション頻度です。イーサリアムの現行モデルでは、ブロックごとに状態をメルクライズするたびに、ディスクへの頻繁な書き込みや読み取り、連続したトライのトラバーサルが必要とされ、その結果、大幅なオーバーヘッドが発生します。メルクルツリーは通常、中間ハッシュを16個のセット（ノードと呼ばれる）にグループ化し、キーがノードのハッシュであり、値がノード自体であるキー値ストアデータベースに格納されます。
このツリーを横断してデータを検索および更新するには、横断するツリーの各層ごとに1回のランダムなディスクアクセスが必要であり、単純なMerkleツリーを横断するには、おおよそ1回のアクセスが必要となります。エントリーごとに8つの連続したデータベースクエリ.
Solanaの各エポックの終わりに状態のコミットメントを更新するアプローチは、その期間内の多くのトランザクションで書き込みコストを分割することを可能にします。同じエポック内で状態エントリが複数回修正される場合、各書き込みについてMerkleルートを即時更新する必要はありません。したがって、エポック中の状態更新に関連する全体的な計算オーバーヘッドが減少します。その結果、状態からの読み取りに関連するコストは一定のままであり、またはO(1)であり、状態は毎回Merkleパスをトラバースする必要がなく直接読み取ることができます。
Ethereumにおけるマークライゼーションの頻度を減らすことは、状態の読み取りと書き込みに伴うオーバーヘッドを減らし、パフォーマンスを向上させる可能性があります。しかし、軽量クライアントは、エポック間での状態の追跡のためにブロックの変更を再生する必要があり、そのような変更は現在のEthereumと互換性がないため、オンチェーン取引による状態の検証を行う必要があります。
効率的で専門化されたデータ構造
さらに、既存のEthereumクライアント内の階層ツリー構造は一般に効率の悪い状態アクセスパターンを引き起こし、状態の膨張にさらに寄与しています。 Ethereumの状態はMPTとして構造化されていますが、それはまたEthereumクライアントデータベースに格納されています。LevelDB,PebbleDB（go-ethereumで使用される）、またはErigonで採用されるMDBXのようなMerkleツリーにデータを格納するB-TreeまたはLSM-Tree.
このセットアップでは、別のタイプのデータ構造に根付いたデータ構造が、別のMerkleツリー型システムの下で操作されるクライアントの上に内部ツリー構造をナビゲートすることで、「読み取り増幅」が生じます。 読み取り増幅は、状態に含まれる情報にアクセスしたり更新するための複数のステップの結果として理解でき、必要な操作を実行する前にMPTへのエントリーポイントを見つけるために外部ツリーをナビゲートする必要があります。 その結果、ランダムリードのためのディスクアクセス数はlog(n)の要素で乗算されます。
この問題を解決するために、Monad はネイティブでディスクとメモリ上の Patricia トライデータ構造を利用しています。技術的な観点から見ると、Patricia トライは、空間効率、効率的な接頭辞一致、および最小限のノードトラバーサルの独自の組み合わせにより、他のMerkleツリー構造よりも優れていることがよくあります。このトライの設計は、単一の子を持つノードを統合し、ルックアップ、挿入、および削除を合理化することで、必要なディスクまたはネットワークI/O操作の数を削減します。さらに、Patricia トライは接頭辞一致を処理する適応能力に優れており、迅速な部分キー検索が必要なアプリケーションでのパフォーマンスを向上させます。
ツリー構造固有の別のボトルネックは、データにアクセスしたり更新するには複数の階層を横断する必要があり、多くの連続したディスクアクセスにつながります。Sovereign Labsこの効率の悪さに対処するために、バイナリMerkleツリー構成を提唱しています。このバイナリ構造への重要なシフトは、ツリーのトラバーサル中の潜在的なパスの数を劇的に減らし、更新、挿入、および暗号証明に必要なハッシュ計算を直接減らします。
Sovereign Labsの「Nearly Optimal State Merklization」からのバイナリMerkleツリー構成
このカテゴリにおける追加の例として、RethチームがRethを構成することがあります実行中にディスクから中間ツリーノードを事前に取得します状態ルートサービスにストレージスロットとアカウントの通知を行うことによって。
状態の有効期限
ステートの有効期限は、一定期間アクセスされていないデータを削除することで、ブロックチェーンの状態のサイズを管理および削減する仕組みです。 有効期限はしばしば「状態の無状態」というカテゴリーに分類されますが、実行の文脈においてこれらの概念を区別することが重要です。
ステートレス性は、実行ノードのメモリ内での計算能力を高めることによって実行を改善しますが、実行トランザクションを行うノードの数が少なくなるため、実行に対するハードウェア要件の向上が起因しています。一方、状態の有効期限は、実行ノードが少ない場合と多い場合の両方のブロックチェーンに適用することができます。
状態の有効期限を実装するために一般的に議論されている方法はいくつかあります。
- レンタルによる有効期限: この方法は、アカウントを状態データベース内でアクティブに保つためにメンテナンス料金または「家賃」を請求するものです。 家賃が支払われない場合、アカウントはアーカイブされ、復元するために料金が支払われるまで保管されます。
- 時間切れ：ここでは、アカウントが特定の期間アクセスされていない場合、つまり取引や相互作用がない場合、非アクティブと見なされます。
両方のメソッドは、より古い、あまりアクセスされないデータをメインシステムに負担をかけないアーカイブ状態に押しやる一方で、即座にアクセス可能なデータのみを維持することを目指しています。
状態の膨張を軽減することで、状態の有効期限が維持されることにより、ブロックチェーンのパフォーマンスに深刻な影響を与える可能性がある「状態の膨張」が軽減されます。状態のサイズが小さいと、ノードは状態を迅速に移動および更新できるため、ノードがスキャンする時間が少なく、処理する時間が多いことから、処理が速くなります。
実行シャーディング
シャーディングは、タスクとデータを限られた数の専門ノードに分散させることで、リソースの利用とパフォーマンスを最適化します（すべてのノードがグローバルな状態を実行するのではありません）。
シャーディングされたブロックチェーンアーキテクチャでは、グローバルステートはシャードと呼ばれる異なるパーティションに分割されます。各シャードは状態の一部を保持し、ネットワークのトランザクションのサブセットを処理する責任を持ちます。トランザクションは、送信者のアドレス、受信者のアドレス、およびトランザクションデータのハッシュなど、さまざまな要因を考慮した決定的なシャーディング関数に基づいて特定のシャードに割り当てられます。これにより、クロスシャード通信の必要性が最小限に抑えられ、より効率的なトランザクションの実行が可能となります。
Vitalik氏の「ブロックチェーンのスケーラビリティの限界」からのシャーディング図
これは、を探索すると明らかになりますNEARプロトコルのシャーディングデザイン、ナイトシェード, 信頼の最小化を損なうことなくスケーリング・シャーディングを実現する状態のない状態を達成します。
Nightshadeでは、ブロックチェーンは単一の論理チェーンとして構築され、各ブロックは複数の「チャンク」で構成され、1つのシャードごとに1つのチャンクが割り当てられます。これらのチャンクには、各シャード固有のトランザクションやステート遷移が含まれています。1つのブロック内にすべてのシャードのチャンクを含めることで、ブロックチェーン全体の状態を統一的に表示し、シャード間通信のプロセスを簡略化することが可能となります。
Ethereumのproper-builder分離（PBS）と同様に、Nightshadeは明示的に状態ノードと状態レスノードの役割を区別しています。NEARでは、状態ノードが特定のシャードに割り当てられ、トランザクションの収集、実行、およびシャード固有のチャンクの生成を担当します。彼らは割り当てられたシャードの完全な状態を維持し、状態証人を生成してバリデータがバリデーションプロセス中に使用できるようにします。
一方、状態を持たない検証者は、ブロックごとにランダムに特定のシャードを検証するように割り当てられます。彼らは完全なシャード状態を維持する必要はなく、他のシャードからブロックプロデューサーによって提供された状態の証人に依存して、チャンク内の状態遷移とトランザクションを検証します。検証者をシャードにランダムに割り当てることで、悪意のある行為者が共謀して特定のシャードを支配するのがより困難になり、ネットワークのセキュリティと整合性を確保するのに役立ちます。
ネットワーク内の各ノードは、全体のネットワークデータではなく、それぞれのシャードのデータのみを処理する必要があるため、個々のノードのストレージおよび計算負荷が軽減されます。
ソリューション：非効率な計算
並列実行
部屋の中の象に取り組む時間です:並列化。 トランザクションの実行を並列化することで、複数のコンピューティングリソースを同時に利用して複数のトランザクションを処理することが可能になります。 これにより、ハードウェアリソースが需要が高い時期にスケールアップされる際に、スループットが向上します。
ただし、複数の実行コンポーネントを並列化することができることを考慮することが重要です。その多くはコプロセッサによって実装されています。ラグランジュ*および[Gate]などの代替ブロックチェーンクライアントFiredancerブロックチェーンのパフォーマンスを大幅に向上させることができます。具体的には、並列化には次のようなものがあります：
- 状態アクセスの並列化
- 特定の操作の並列化
- コンセンサスと実行の並列化
状態アクセスの並列化
状態アクセスの並列化2つの重要な利点をもたらします:
- Parallel EVMsは、複数のCPUコアにトランザクション処理を分散させます。この設定により、複数のトランザクションを順番に待たせるのではなく、同時に処理することが可能となります。
- ストレージからデータを待つトランザクションがある場合（これにはかなりの遅延が発生する可能性があります）、システムはアイドル状態にはなりません。代わりに、実行の準備ができている別のトランザクションに切り替えることができます。これは、複数のコアが異なるタスクを独立して同時に処理できるためです。
トランザクション実行を並列化する上での主な課題は、共有されたグローバル状態への同時アクセスの管理による競合を回避することから生じています。ACID分散システムを更新するためのルール。ブロックチェーンに複数のトランザクションが並列で実行されている場合、そのうちいくつかは競合することになります。そのため、状態アクセスを並列化するための2つの主要な手法は、競合を解決するためにリソースを割り当てるタイミングが異なります: 悲観的実行（またはメモリロック）モデルと楽観的実行モデルです。
悲観的な実行
悲観的な実行モデルは、実行中にトランザクションがアクセスする状態変数（読み取りまたは書き込み）を宣言する必要があるトランザクション処理アプローチです。この情報はトランザクションのメタデータに含まれており、実行前にアクセスパターンを解析するランタイムが可能になります。
読み書きアクセスパターンを調査することで、ランタイムは重複しないアクセスセットを持つトランザクションを特定し、重複しないおよび読み取り専用トランザクションの並列実行を可能にし、スループットを向上させることができます。ランタイムは、バリデータノード上の各CPUスレッドに対して並列トランザクションキューを作成し、競合しないアクセスパターンを持つトランザクションが同時に処理されることを保証します。
この設計選択の結果、悲観的な実行モデルはリソース割り当てに対する細かい制御を得ることができ、ブロックチェーンの状態空間をセグメンテーションまたはパーティショニングすることが可能となります。
並列化は、統一されたセキュリティモデルに基づく、複数の同期的に合成可能な独立した実行シャードを効果的に作成します。これにより、ネットワークの混雑を解消し、正確なリソース管理と動的な手数料市場を通じてガスコストを最適化するのに役立ちます。状態アクセスの「ホットスポット」（高い取引需要のエリア）を特定することで、システムは異なる手数料設定、レート制限、または高競合状態への追加リソースの割り当てなど、ターゲットとなる最適化を実装できます。重要な点として、Solanaの現在の並列化の実装はしないことに注意する必要があります。ローカライズされた手数料マーケットの潜在能力を十分に実現する.
同時アクセスにおけるデータの整合性を確保するために、悲観的な実行モデルはロックメカニズムを利用しています。トランザクションが特定の状態変数にアクセスする前に、その変数に対してロックを取得する必要があります。ロックはトランザクションに変数への排他的アクセス権を提供し、他のトランザクションが同時に変更するのを防ぎます。トランザクションが実行されたら、ロックが解除され、他のトランザクションが変数にアクセスできるようになります。
Solanaの海抜ランタイムは、この悲観的実行モデルを実装し、トランザクションは実行中に読み取るか書き込むアカウントを指定します。Sealevelはアクセスパターンを分析し、各CPUスレッドに対して並列トランザクションキューを構築します。アカウントが複数回アクセスされる場合、競合を防ぐために1つのキューに順次リストされます。リーダーノードのブロック時間内に処理されないトランザクションは、次にスケジュールされたリーダーに転送されて処理されます。
未使用取引出力（UTXO）ベースのシステムは、計算効率を同様に向上させます。UTXOには、個々のウォレットに関連付けられた特定の通貨単位、つまりUTXOが含まれます。ウォレットの各取引ごとに、UTXOが消費され、新しいUTXOに置き換えられます。受信者のために1つ以上のUTXOが作成され、支払いを表し、通常、イニシエーターのためにもう1つ作成され、戻りの変更を表します。
どの契約に触れるかを定義することで、異なる契約の集合に触れる取引は、実行ノードによって並行して実行されることができます（これは厳密なアクセスリストを持つ「アカウント」データモデルで実現できます）。ただし、Ethereumスタイルのスマート契約との互換性を得るために、FuelなどのUTXOスキームは、ブロック生成ノードに重複するアクセスリストを持つ取引を順次実行するよう制約を課しています。
しかし、悲観的な実行モデルには制限があります。 トランザクションは、複雑または動的なトランザクションの場合、アクセスパターンが入力データや条件付きロジックに依存する可能性があるため、正確にアクセスパターンを事前に宣言する必要があり、これは困難を伴うことがあります。 不正確または不完全なアクセスパターンの宣言は、最適でないパフォーマンスや潜在的なランタイムエラーの原因となり得ます。 さらに、ロックメカニズムは、多くのトランザクションが同じ状態変数を競合する場合、遅延を導入し、並行性を低下させる可能性があります。 この競合は、パフォーマンスのボトルネックを形成する可能性があり、トランザクションは、高需要の状態変数のロックを獲得するために実行時間のかなりの部分を待機することがあります。
さらに重要なことに、このモデルは、契約のデータ依存関係を正確に事前に指定するために、開発者には深い理解が必要であり、これにより、特に分散型取引所や自動市場メーカーなどの動的かつ複雑な状態の相互作用を持つアプリケーションを設計する際に課題が生じる可能性があります。
楽観的な実行
一方、楽観的な実行モデルは、取引の実行に「仮定的」なアプローチを採用し、事前の状態アクセス宣言を必要とせずにトランザクションを並行して実行できるようにします。
紛争を事前に防ぐのではなく、トランザクションは独立していると仮定して楽観的に並行して実行されます。ランタイムはGateのようなテクニックを利用しています。マルチバージョン同時実行制御(MVCC) およびソフトウェアトランザクショナルメモリ（STM）は、実行中に読み取りセットと書き込みセットを追跡することで動作を追跡します。実行後、ランタイムは競合や依存関係を検出します。競合するトランザクションを中止して再実行するなどの対策を講じますが、競合するトランザクションを特定するためにディスクではなくメモリから読み取ることができます。
オプティミスティック実行モデルを使用すると、開発プロセスが簡素化され、プログラマは状態アクセス パターンの宣言を気にすることなく、コントラクト ロジックの記述に集中できます。トランザクションは状態の相互作用を事前に宣言する必要がないため、開発者はスマートコントラクトの設計の自由度が高くなり、ブロックチェーンの状態とのより複雑で動的な相互作用が可能になります。楽観的実行モデルは、悲観的モデルよりも高いスループットとスケーラビリティを提供できるため、大量のトランザクションと複雑なDAppsをサポートするプラットフォームに特に適しています。
このモデルの注目すべき実装の1つは、Gate.ioで見つけることができますAptosそして、MoveVMのMovement Labs*, which employs a technique known as ブロック-STM. ブロック-STMでは、トランザクションはまず並行して実行され、その後、競合するトランザクションが特定され、検出された依存関係に基づいて再実行のためにスケジュールされます。このアプローチにより、処理リソースが連続して利用され、スループットが向上し、トランザクションのワークフローの整合性が維持されます。
AptosのBlock-STMは、「注文の呪いをパフォーマンスの恩恵に変えてブロックチェーンの実行をスケーリングする」
その利点にもかかわらず、楽観的実行モデルには課題もあります。実行時の競合検出の必要性やトランザクションの中止とリトライの可能性により、計算オーバーヘッドと複雑さが発生します。さらに、状態の複数バージョンを維持し、競合解決に関連するオーバーヘッドを管理する必要があり、洗練されたシステム設計と堅牢な並行制御メカニズムが、ブロックチェーンの完全性とパフォーマンスを確保するために必要です。
Block-STMは、MVCCを活用して並行書き込みを効果的に管理し、データの複数バージョンを維持することで、同時書き込み操作間の競合を防ぎます。複数のスレッド間で実行と検証タスクを調整するための協調スケジューラを組み込んでおり、トランザクションが開始された順にコミットされるようにします。このセットアップにより、動的依存関係推定を使用してトランザクションの中止を最小限に抑え、依存関係を効率的に待機および解決してから処理を続行することができます。
さらに、MoveVMが使用するアカウントモデルは、EthereumのEVMとは異なり、衝突が少なくなります。 Ethereumでは、トークンは通常、1つのスマートコントラクトによって管理され、複数のトークントランザクションが同じコントラクトアドレスを介して相互作用する可能性があり、紛争の可能性が高まります。 対照的に、MoveVMはトークンを個々のユーザーアカウントに割り当て、各トランザクションが通常、異なるアカウントアドレスとやり取りするため、そのような紛争の可能性が低くなります。
Monadでは、並行して実行される最初の一連のトランザクションは、直ちにコミット可能な結果を生み出す可能性があるI/Oフェーズと、残りのトランザクションの競合を解消するために少量の作業が必要な「リトライ」フェーズとして構築できます。これらの競合するトランザクションはキャッシュに浮上し、実行オーバーヘッドを削減できるようにメモリ内に存在するため、実行時に迅速にアクセスされます。ほとんどの状態はディスク上に存在しますが、競合するトランザクションは実行時に迅速にアクセスされます。
悲観的および楽観的な実行モデルは、ブロックチェーンにおける取引の実行と状態管理を処理する独自のアプローチを提供します。これらのモデルの選択には、状態アクセスの明示的な複雑さと動的な衝突解決に伴う計算オーバーヘッドとの間のトレードオフが関与します。
データ＆タスク並列処理
データとタスクの並列処理は、計算負荷を複数のプロセッサに分散させることでパフォーマンスを最適化することに焦点を当てています。データ並列処理はデータセットを同時処理するためにセグメント化し、タスク並列処理はさまざまなタスクをさまざまなプロセッサに同時に操作させるために割り当てます。
これらの最適化は異なるが相互依存しており、状態アクセス並列性とは、複数のプロセスやスレッドが同時に操作する際に、メモリやデータベースなどの共有リソースへのアクセスを管理および同期し、競合を防ぎデータの整合性を確保するものです。
データ並列
Data parallelismでは、複数のデータ要素にわたって特定の操作を同時に並列化することが含まれます。このアプローチは、同じ操作を大規模なデータセットに適用する必要がある場合や、複数の入力値に対して計算集約的な操作を実行する場合に特に有益です。このポイントは、データを複数の処理ユニットに分散させ、異なるデータ要素に対して同時に同じ操作を実行することから生じます。
データ並列処理の一般的な手法の1つは、単一命令、複数データ（SIMD）は、単一の命令を複数のデータ要素に同時に実行することを可能にする。現代のCPUには、多くの場合、組み込みのSIMD機能が備わっており、複数のデータポイントに並列操作を行うことができる。SIMD命令を活用することで、開発者は数値計算、データ変換、信号処理など特定の操作に対して、著しい高速化を実現できる。
例えば、大量の数値配列に複雑な数学関数を適用する必要があるシナリオを考えてみましょう。各数値を順次処理する代わりに、SIMDは複数の数値を同時に処理できます。この同時処理は、CPUのSIMDレジスタに数値のサブセットを読み込み、並列にすべての読み込まれた数値に数学関数を実行し、その結果をメモリに格納することで実現されます。複数の数値を一度に処理することで、SIMDは全体の実行時間を大幅に短縮することができます。
FiredancerのED25519に対する作業シグネチャ検証は、複雑な計算を最適化するためのSIMDのパワーを示しています。シグネチャ検証プロセスには、ガロア体内での算術演算が含まれ、計算量が多くなります。SIMD命令を活用することで、Firedancerは複数のデータ要素でこれらの操作を同時に実行でき、大幅なパフォーマンスの向上が実現されます。これらの最適化は、既に状態アクセスの並列化を実装しているSolanaのパフォーマンス向上に重要となります。
タスク並列性
タスク並列処理は、プログラム内の異なるタスクや操作を複数の処理ユニットにわたって並列化することを指します。このアプローチは、プログラムが複数の独立したタスクで構成されており、それらを同時に実行できる場合に有用です。各タスクをCPUコアやGPUなどの別々の処理ユニットに割り当てることで、全体の実行時間を短縮することができます。
タスクの並列処理は、プログラムが複数の複雑な操作を同時に実行する必要があるシナリオでよく使用されます。たとえば、ビデオストリームにさまざまなフィルターやエフェクトをリアルタイムで適用する必要があるビデオ処理アプリケーションを考えてみましょう。タスクの並列処理では、すべてのコンピューティング ユニットを使用して各フィルターをまとめて順番に適用する代わりに、複数の処理ユニットにワークロードを分散できます。1 つの処理ユニットがぼかしフィルターを適用し、別のユニットが色補正フィルターを適用するなど、さまざまな処理ユニットが担当できます。これらのタスクを並行して実行することで、アプリケーションは処理を高速化し、スムーズなユーザーエクスペリエンスを維持できます。
Lagrange’s @lagrangelabsZK MapReduce（ZKMR）は、大規模なデータセット上の分散計算の証明を効率的に並列化および生成するためにデータおよびタスクの並列性を活用します。マップフェーズでは、入力データセットがより小さなチャンクに分割され、それぞれのチャンクが個別のマッパーワーカーまたはマシンで並列に独立して処理されます（タスクの並列性）。そして、「マップ」操作は、各マッパータスク内で複数のコアやプロセッサを跨いで並列化できます（データの並列性）。同様に、リデュースフェーズでは、各キーに関連付けられた値に対する「リデュース」操作を各リデューサータスク内で並列化できます（データの並列性）。対照的に、リデューサータスクは複数のワーカー間で並列に実行されます（タスクの並列性）。
データ並列処理とタスク並列処理を組み合わせることで、ZKMRは、巨大なデータセットに対する複雑な計算の効率的なスケーリングとパフォーマンスを実現し、再帰的な証明構成を通じてゼロ知識保証を維持します。
Lagrangeの「Introducing ZK MapReduce」から、ZKでの任意のMapReduce手順の検証
Lagrange’s ability to generate storage proofs for SQL computations over @lagrangelabs/ ユーリッド-イーサリアム初の検証可能なデータベースおよびZKコプロセッサ-cc4a5595365c">888,888のストレージスロットを1分20秒で示し、ZKMRのパワー、およびそれを支えるタスクとデータの並列処理を実証します。さらに、ラグランジュの最近の そばかすの木この論文は、バッチ証明がオンチェーンデータにも適用可能であり、バッチサイズに依存せず、𝑂(log𝑛)で計算可能であることを強調しています。
合意と実行の並列化
この記事ではコンセンサスについては触れていませんが、ブロックチェーンはコンセンサスと実行のプロセスを並列化することもできます。従来のブロックチェーンは、通常、トランザクションを順次処理し、トランザクション（ブロックN）のコンセンサスに達した後にそれらを実行します。コンセンサスと実行フェーズの並列処理は、実行効率を大幅に向上させるもので、Monadなどのシステムで見られる技術の一例です。ネットワークがブロックNのコンセンサスに達すると、それと同時に前のブロック（N-1）のトランザクションを実行します。
この戦略により、計算リソースの連続的かつ効率的な利用が確保され、アイドル時間が効果的に削減され、ネットワークのトランザクション処理能力が向上します。これらの改善により、システムのスループットが向上し、ネットワークへのスパム攻撃に必要な資本コストも増加します。
通訳者とオーバーヘッドの削減
Solidityなどの言語でスマートコントラクトが書かれると、まず低レベルのバイトコードにコンパイルされます。その後、EVMはインタプリタを使用してこのバイトコードを実行します。インタプリタは各命令を順次読み取り、実行し、まるでリアルタイムで外国語を通訳するかのように行います。パラダイムのRethの最新記事それにより、各命令を個別に処理し、実行時にバイトコードから機械命令に変換する必要があるため、オーバーヘッドが発生することが指摘されています。
Rethは、実行直前にネイティブマシンコードにバイトコードを変換するJIT（Just-In-Time）コンパイラを組み込むことで、EVMの非効率を解決しています。これにより、通常実行時に必要とされる資源集約型の解釈プロセスを回避します。
The Reth articleJITの実践では、インタープリターベースシステムの50%の実行時間がJITが理論上満月した過程を引き継いていることを示し、JIT実装により実行速度を倍にする可能性を持っている。しかし、Yilongは指すより、このプレゼンテーション, JITは特定のオペコードの処理に必要な時間を大幅に減らすことができますが、全体の実行には大きな影響を与えないかもしれません。これは、JITが占めるEVM実行時間の50%のかなりの部分が関わっているためです。"ホスト"と"システム"の操作(スライド13)、（算術）や（制御）のようなJIT最適化に適さない、非計算的な性質を持つものです。
インタープリターはパフォーマンスを制限する可能性がありますが、「翻訳」という機会を作り出し、新しい仮想マシンを活用できるコードの範囲を広げ、開発者がデザイナーブロックスペースを使用するオーバーヘッドを低減させることができます。例えば、Movement LabsはFractalを開発しており、開発者がSolidityベースの契約をMoveVM上に展開できるようにしています。Fractalは、SolidityをEVMオペコードで表現された命令を含む中間言語にコンパイルし、それらをMoveVMバイトコードにマッピングして、Solidity契約がMoveVM環境で実行されるようにします。
特殊化されたカスタマイズされたステートマシン
実行レイヤーのカスタマイズには、特定のアプリケーションに最適化された専用ステートマシンを設計することが含まれます。これは、実行環境が仮想マシンを完全に必要としなくなるだけでなく、アプリケーションが命令セットアーキテクチャ（ISA）、データ構造、および実行モデルを特定のニーズに合わせて調整します。 特定のアプリケーションにISAを調整する主なパフォーマンスの利点は、アプリケーションの計算パターンを従来のISAの汎用命令に変換するオーバーヘッドを削減することにあります。 汎用CPUは、基本的な命令セット（例：加算、ロード、分岐）を使用して、さまざまな種類のソフトウェアを実行サポートします。 ただし、アプリケーションが同じ多段階操作を頻繁に繰り返すと、これらのパターンを単純な命令のシーケンスで実装することが効率的ではありません。
たとえば、データベースアプリケーションでは、常にツリーデータ構造をトラバースしたり、エントリを検索したり、値を更新したり、ツリーをリバランスしたりする必要があるかもしれません。通常のCPUでは、これらの高レベルの操作をマッピングするには、それらをロード、ストア、ブランチ、算術などの低レベルのマイクロオプスの長いシーケンスに分割する必要があり、一般的なハードウェア上で個別に実行する必要があります。それに対して、データベース向けにカスタマイズされたISAは、これらの繰り返しパターンを最適化されたより広い命令に融合させることができ、専用のハードウェアを活用できます。例えば、「TraverseTree」命令では、メモリアドレスを計算し、関連するノードをロードし、その操作に設計された並列比較回路を使用してキーを比較できます。「UpdateEntry」では、最適化されたデータベースストレージレイアウトからエントリを直接取得し、変更し、新しい状態を1つの命令ですべて確定できます。
これにより、高レベルの操作を単純な命令にまで翻訳することから冗長なオーバーヘッドを取り除きます。また、ハードウェアが、そのニーズに合わせてより少なくても幅広く、明示的に並列な命令を使用してアプリケーションを最適に実行できるようにします。
LayerNのノルド特定の実行環境とデータ構造を専門とすることによるパフォーマンスの利点を、検証可能な注文簿の具体的な使用例を通じて示しています。LayerNのアプローチは、取引を注文簿データ構造に最適化することに焦点を当てており、そのパイプラインメカニズムは、新しい注文を注文簿データツリー内の適切な位置に効率的に挿入するよう設計されています。注文簿の特定の要件にデータ構造と挿入アルゴリズムを適合させることで、LayerNは低レイテンシの注文配置と高スループットを実現しています。
代わりに、アプリケーションがパフォーマンスを最適化するためにプラグインすることができる任意にプログラム可能なモジュールを可能にする汎用実行環境に注力することも可能です。このアプローチは、生のパフォーマンスよりも開発者体験を優先します。
流暢そしてCWD生の計算パフォーマンスを最適化するとともに、開発者の体験とエコシステムの互換性を向上させるためのトレードオフをバランスさせる戦略を利用します。このアプローチは、コードを実行するためのVMとしてWebAssembly（Wasm）を使用することに焦点を当てています。 Wasmは、幅広い言語サポートと広く採用されている度合いから、Web開発での選択肢となっています。
開発者がネイティブなクライアント実行ではなくWasmを使用する選択は、汎用的な実行環境の柔軟性と広範なアクセシビリティを好む戦略的な選択を反映しています。ハードウェア上でコードを直接実行するネイティブ実行は性能が向上するかもしれませんが、クロスプラットフォームの互換性が制限され、開発者にはアクセスしにくくなります。一方、Wasmはネイティブ実行と同じ生の速度を達成できないものの、異なるプラットフォーム間で均一で安全な実行環境を確保します。このトレードオフは、FluentとCWDの設計思想と一致し、最大の性能効率よりも開発者の生産性とより広範なエコシステムの統合を優先しています。
CosmWasmデプロイメント（CWD）, 特に、これを具体化するのは、スマートコントラクトの実行にWasmを採用するだけでなく、それをより包括的なフレームワークに組み込んで、ブロックチェーンの複雑さをサポートするように設計されています。 「周辺ロジック」で充実させたこのフレームワークは、高度なアカウント管理、カスタマイズ可能なガスメカニズム、最適化されたトランザクションの順序付けを提供しています。 これらの機能により、柔軟で効率的で安全な開発環境が実現され、開発者は比較的簡単にスケーラブルで複雑なdappsを構築することができます。
Stackr*は、カスタマイズされた実行環境の利点と伝統的なスマートコントラクトプラットフォームの柔軟性を組み合わせることで異なるアプローチを取ります。Stackrは、開発者がアプリケーションをロールアップとしてコーディングできるようにし、トランザクションの順序、実行、構成に関する独自のルールを定義できるようにします。Stackrモデルでは、開発者がそのアプリケーションの要件に最適なISA、データ構造、実行モデルを選択できます。
Stackrのマイクロロールアップデザインは、「Stackr SDKの紹介」からです
With Stackr, developers can apply state transition rules directly in the application’s runtime rather than being constrained by the rules of a general-purpose VM, giving them the ability to streamline their instruction set to be more efficient and redefine the set of things that can be done in a runtime environment.
これにより、ビジネスロジックがクライアントレベルで実装されるため、コストのかかるスマートコントラクトの呼び出しと検証の必要性がなくなり、より軽量で効率的な実行が実現されます。その結果、アプリケーションの構成方法に関する可能性が拡大し、パフォーマンスを犠牲にすることなく、開発者が単一のアプリケーションで使用できる異なる種類の言語、データ構造、署名が拡大します。
結論
最適な実行レイヤーパフォーマンスへの複数の経路があります。
独占的な技術的差別化ポイントとして、状態アクセスや並列化に対する単一の最適化は、DAppsを取り込む際に実行レイヤー間で際立っています。私たちが進める中で、Solanaのリソースベースの並列化の利点は、FuelのUTXOモデルにも同様に適用できます。だれでもAmazonのシャーディングを通じて水平スケーラビリティを向上させるための洞察に満ちたソリューションそして実行レイヤーのパフォーマンスを向上させます。
While execution layer performance is a critical vector for winning over builders of decentralized applications, new L1s and L2s centered around improving execution must compete on other variables, including security, interoperability, and compatibility with existing tooling. For this reason, the proliferation of new interoperability layers—from Nebra to Statenet to Polygon’s AggLayer—will be critical to developers buying designer blockspace, as they can build or buy specialized blockspace without sacrificing the synchronous composability and shared liquidity of traditional, general-purpose L1s.
状態管理の改善と計算効率の向上は相互に依存しています。
コミュニティ全体で新しい実行レイヤーを設計する中で、状態アクセスの並列化は、約束されたパフォーマンスの向上のための決定的なミームとなっています。これはその理由があるためですが、これにより、EVMの実行における5倍の改善, Monadの並列処理に関する初期実験からの証拠は、他の改善（例：非同期I/Oなど）が同時に開発されない限り、その役割が過大評価されていることを示しています。
これに基づいて、計算効率はしばしば、状態のアクセスと保存方法を改善することでのみ実現されることがわかります。効率的な状態管理は、データにアクセスして操作するために必要な時間とリソースを削減し、処理を高速化して計算負荷を軽減します。
これをさらに一歩進めると、ハードフォークに伴う惰性を考えると、既存の企業は、国家の管理と更新の方法を再設計する新しいブロックチェーン設計に対抗する能力を妨げるパス依存の選択をしている可能性があります。その結果、特殊なモジュール式実行レイヤーと代替の L1 により、より効率的な状態ストレージの設計上の選択と、それに対する読み取りと書き込みのプロトコルに関する防御性を作成できる可能性があります。これらの設計上の決定は、既存企業がハードフォークなしでデータベース構造を更新する際に惰性に直面する可能性があるため、競争上の優位性を提供します。
結局のところ、ブロックスペースの値は実行レイヤーの設計空間に影響を与えます。
実行レイヤーを改善する方法を理解する際に、最適化のクラスは、トランザクションを実行しているのは誰か、および関与するノードの数はいくつかに応じて異なることを区別できることがわかりました。これらの質問へのチームの最初の回答によって大きく異なる実行のボトルネックを解決するための開発者向けの技術は、大幅に異なります。
一方、SolanaやMonadのようなモノリシックなL1は、パフォーマンスを向上させるために強力で弱いノードにバリデータの役割を分けることを受け入れない。短期間のステートブロートを「受け入れる」ことは実用的な解決策ではないため、彼らはデータベースレイヤーや他のブロック生成エンジンのコンポーネント（コンセンサスなど）の改善に依存し、より多くの実行ノードを補うために、ネットワークの重要なコンポーネントおよびコアバリューと見なされるより広範な数のバリデータのコンセンサスに依存しています。これらのL1のセキュリティモデルは、ハードウェア要件の弱いより分散されたバリデータのコンセンサスに依存しているため、そのデータはディスク上に存在するデータベースに書き込まれる必要があり、許可された最大限に分散化されたブロックチェーンにとってコスト面で必然的に安価です。
一方、EthereumなどのプロジェクトとそのL2は、中央集権化に傾倒するロードマップを追求しており、中央集権化されたブロックビルダーを通じて実行ノードを持つうえで弱い検証提案者ノードに責任を負わせる詐欺や妥当性の証明を通じています。
中央集権的な取引および状態遷移の「実行者」が分散型の未来を追求する上で許容されると仮定する。その場合、物理法則は、1) 複数のアクターによる取引の再実行を必要とせずにチェーンにブロックを追加できるシステム、2) バリデータの要件を増やしてインメモリ計算を最大化し（状態の膨張問題を無視する）、および3) レイテンシとコンセンサスのボトルネックを減らすシステムは、広範な分散化とノード間の合意に依存するシステムと比較して明らかに優位に立つことを示している。
スケーラビリティと信頼の最小化のバランスを求める中で、実行レイヤーの目的は盲目的に分散化を最適化することではないこと、また実行が常に完全に許可されなければならないわけではないことが明らかになってきています。
私たちが有効性や詐欺証明などのさまざまな暗号ツールを開発および実装するにつれて、検閲に対抗し、安全性とライブネスを維持するために必要なノードの数を効果的に減らしています。 ただし、このアプローチにはトレードオフが伴い、実行者の可能な中央集権化により、検閲耐性、順序整合性、およびライブネス保証に潜在的な影響が及ぶ可能性があります。
Sreeramの指摘によると、「最小限の分散化」は「検証が許可されるべき」という意味ではなく、「適切にインセンティブが与えられるべき」という意味である。つまり、不正行為に対して検証者が重大な影響を受ける監視されたシステムは、過度な分散化なしでも安全性と活性を維持できることを意味する。h/t SreeramGate.
そのようなガバナンスモデルはすでに実践的なアプリケーションでテストされています。たとえば、Arbitrumのようなロールアップでは、取引の順序付けやリーダーの選択ルールを施行するためのガバナンスまたは委員会ベースのシステムを探求しており、シーケンサーがオンチェーンデータを使用して取引の順序付けポリシーを維持するメカニズムを検討しています。
これらの進歩にもかかわらず、分散とパフォーマンスのバランスを取るための明確な「パレート最適フロンティア」は存在しません。
イデオロギー的および技術的な考慮事項は、状態を検証するために分散型の実行ノードを支持し続けています。一方で、ノードを中央集権化することで合意のオーバーヘッドを減らし、ハードウェアのアップグレードによってパフォーマンスを大幅に向上させることができますが、これらの最適化が検閲に対抗するアプリケーションを作成に焦点を当てる開発者を惹きつけるかどうか、そして検閲に対する抵抗が業界の中核的な価値観としてどの程度残るかは、これからの課題です。
*アーキタイプ・ポートフォリオ・カンパニーを示す
免責事項：
この記事は[から転載されましたミラー )], 元のタイトル「デザイナーブロックスペース: 実行環境の未来」を転送します。すべての著作権は元の著者に帰属します[ベンジャミン・ファンク]. If there are objections to this reprint, please contact the Gate Learnチームは速やかに対応します。
責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
Artículos relacionados
ステーブルコインとは何ですか？
Cotiとは? COTIについて知っておくべきことすべて
実行環境の未来
転送されたオリジナルタイトル: デザイナーブロックスペース: 実行環境の未来
Ethereumが最初の分散型プログラマブルブロックチェーンを発表してから9年が経過し、仮想通貨は数十億人のユーザーにスケーリングするための障害に直面してきました。そして、この問題に対処するために、仮想通貨業界は継続的に新しいタイプのブロックチェーンを開発し、資金を提供してきました。
ただし、「パフォーマンス問題」という言葉は不適切に定義され、数量化されています。 例えば、「秒あたりの取引」などの合成メームは、本当は同等の計算作業を必要としない取引の間でリンゴとオレンジの比較をきれいにパッケージ化しています。 これらの指標の微妙な差異も、ブロックチェーンのコンポーネントがパフォーマンスに与える独立した影響を評価する能力を遮っており、高度に相互依存関係にある問題を解決するための最適化セットを特定するための原則に基づいたアプローチから私たちの注意を逸らしています。
この霧の中で、過去数年間にわたり、信頼性のある持続的なブロックチェーンのスケーラビリティの改善が実施されてきました。 Ethereum がロールアップ中心のロードマップを進める中、新しいロールアップの波、コプロセッサー、データの利用可能性（DA）レイヤー、および競合するL1が登場しており、それぞれがユニークなデザイン選択肢を持ち、開発者にスケーラブルでユーザーフレンドリーなdappsを構築するためのパフォーマンスの高い環境を提供しています。
今日、EIP4844の導入と代替DAレイヤーは重要なDAボトルネックを緩和しました。 この重要なマイルストーンにもかかわらず、証拠は他の重要なボトルネックを解決する必要があることを示しています。先月、ベース収集されました1日で157万ドルの取引手数料イーサリアムへのデータ可用性コストはわずか5,000ドルであり、これは状態更新の検証と処理に必要な計算作業が依然として重要なボトルネックであり、改善の機会であることを示しています。
この記事では、統合型およびモジュラー実行環境が採用した設計選択肢について評価し、高性能を実現し、オンチェーンで展開できるアプリケーションの範囲を拡大する過程を検討します。
今日の挑戦
実行レイヤーのパフォーマンスは、実行ノードがチェーンのブロック時間に対して達成する計算作業に基づいてベンチマークを取ることができます。または、「1秒あたりの計算ガス」
この点を考慮すると、実行レイヤーのボトルネックを効率の悪い状態アクセスと効率の悪い計算の2つの相互に関連する要因に絞ることができます。
効率の悪い状態アクセスとは、ブロックチェーンの状態を取得および更新する際に発生するオーバーヘッドのことであり、これによりトランザクション処理が遅くなる可能性があります。一方、効率の悪い計算は、操作や状態の遷移を実行するアルゴリズムによって発生するオーバーヘッドの関数であり、単純な送金から複雑なスマートコントラクトや署名検証まで、さまざまなものが含まれることがあります。
これらのボトルネックは相互に強化し合い、ステートのアクセスの遅延が計算時間を延ばす一方、効率の悪い計算プラクティスはステート管理を圧迫する可能性があります。さらに、これらの問題に対処するための提案された改善策は、しばしばシャーディングやステートレスアーキテクチャの採用などの体系的な改善を必要とし、ステートのアクセスと計算の効率を高め、実行パフォーマンスを向上させることができます。
ボトルネック＃1：非効率なステートアクセス
ブロックチェーンの状態にアクセスするために必要なコストと速度は、実行環境のパフォーマンスにとって重要なボトルネックであり、状態の膨張の問題に要約されることがあります。
ブロックチェーンでは、世界の状態は特定のデータ構造を介して管理および更新されます。木. ツリーはブロックチェーンにとって不可欠であり、実行ノード外の当事者にブロックチェーンの正しい状態に関する保証を提供する安全かつ効率的な方法を提供します。トライ内の各更新は新しいルートハッシュを生成し、軽量クライアントは全体のチェーンを維持せずに取引と口座残高を検証するために参照できます。
イーサリアムは、特にMerkle Patricia trie（MPT）として知られるデータ構造に依存しています。@chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">four sub-tries.
Ethereumはスマートコントラクトとトークンを増やすにつれて、その状態のトライはより大きく複雑になります。状態が成長すると、より多くのストレージスペース、処理するためのより多くの計算リソース、および送信するためのより多くの帯域幅が必要になります。同時に、ノードのハードウェア制約はほぼ同じままです。
この状態の成長は、状態がディスクに保存され、ディスク操作には高いオーバーヘッドがかかるため、イーサリアムのパフォーマンスに直接影響します。 CPUレジスタからデータにアクセスするのに0.1ナノ秒かかる一方、10から100マイクロ秒かかることがあります。（100倍～1000倍遅い）ディスクからデータにアクセスすると、その時間に実行された可能性のある200,000 CPU命令に大まかに翻訳されます。それは保守的な見積もりで36 ERC-20の転送に相当します！
この問題を悪化させるのは、ブロックチェーンが状態への読み書きに対して多くの効率の悪いアクセスパターンを持っていることです。たとえば、Merkle Patricia trieの非連続構造は、ディスクへの入出力（I/O）操作がディスク上のさまざまな予測不可能な場所から読み書きを行うことにつながります。トランザクション入力のランダムな性質とそれに続く状態の変更は、散在したデータアクセスパターンにつながり、状態の検証と更新プロセスを著しく遅らせ、状態の検証と更新に関しては一部のみを利用します。ハードウェアデバイスの容量.
全般的に、ブロックチェーンのための状態管理プリミティブは、その絶対的な潜在能力を達成するには程遠いものであり、計算効率を向上させるためには多くの進歩がなされることができます。
ボトルネック＃2：非効率な計算
実行レイヤーも非効率な計算のボトルネックに直面しており、これはさまざまな形で表れています。
1つには、多くのプロセスが逐次処理を行い、複数の操作を同時に処理できる現代のマルチコアプロセッサを効果的に活用していません。この逐次実行は、トランザクション間に避けられないCPUアイドル時間を生み出し、貴重な計算リソースを無駄にしています。
さらに、仮想マシンを使用すると、高レベルのスマートコントラクト操作をバイトコードに変換する必要があります。これは、プラットフォームに依存しない低レベルのコードであり、その後、命令ごとに実行されます。この翻訳および実行プロセスによって、特に複雑で頻繁に繰り返される特定のアプリケーションタスクを持つアプリケーションには、かなりのオーバーヘッドが発生します。
これらの非効率性は、計算リソースの最適利用を妨げ、実行レイヤーのパフォーマンスを阻害します。
ソリューション：非効率な状態アクセス
チームが実行中のノードのハードウェアから状態を取得および更新するレートを向上させるいくつかの異なる方法があります。これには、複雑なデータ構造を単純化し、状態の膨張につながるコストの高いディスクI/O操作を削減する方法を見つけることが含まれます。
Statelessness & インメモリコンピューティング
一部の実行レイヤーは、単にそれを受け入れてしまうことでステートの膨張に対処しています。彼らは、より遅いディスクベースのシステムからより速いランダムアクセスメモリ（RAM）へのステートデータストレージをシフトします。RAMでのステート情報へのアクセスは、ディスク操作に伴うオーバーヘッドを大幅に削減し、それらはより遅く、リソースをより多く必要とします。
しかし、このアプローチは分散化の核心原則に挑戦しています。RAMに状態データをますます大量に格納することは、より高度で高価なハードウェアが必要とされるため、個人がノードオペレータとして参加する能力を制限する可能性があります。その結果、ハードウェア要件が高まるにつれて、より少ないエンティティがこれらのノードを運営する余裕があります。
コンピューティングの魅力と信頼の最小化のバランスを取るために、L1（Ethereumなど）とL2の両方が、バリデータの役割を分離された、中央集権的な実行ノードと多数の検証ノードに依存するスケーラビリティのロードマップを追求しています。このモデルでは、メモリ内でコンピューティングを行うためのハードウェア要件を持つ高性能なブロック生成者がブロックを生成する責任を持ち、検証ノードは暗号証明（詐欺と妥当性の証明）を活用してブロック生成者を責任を持たせます。
その結果、これらのシステムは、ブロック生産者が速度を最大限に活用できるようにするはずです。なぜなら、メモリ内で計算できるため、実行中に完全にディスクI/Oを排除できるからです。 RAMの遅延は通常100ナノ秒未満であるため、状態アクセスの遅延は、ディスクベースの実装に比べて最大1000倍短縮されます。
並行して、詐欺と有効性の証明が分散コンセンサスの代わりに使用されて、システムの信頼最小化特性とそのスループットを拡大します。その結果、強力な中央集権的なブロック生成ノードは、はるかに安価なハードウェアで実行できる検証ノードによって相殺されます。これらのノードは、状態遷移（または無効な状態遷移）の証明を独立して検証し、ブロックチェーン全体の状態を格納する負担なしに正確な状態を維持するための重要な機能を果たします。
このプロセスを最小信頼で実行するために、実行レイヤーは一定の程度を実装する必要があります。無国籍, 最も一般的なのは、「弱い状態のなさ」という概念です。弱い状態のなさは、ブロックプロデューサーが提供する暗号的な証明として知られているものを義務付けることによって実現されます。目撃者新しいブロックによる提案されたすべての状態変更をカプセル化することで、検証者がこれらの変更を追加の歴史データなしに検証できるようにする検証ノードに
この概念は、さまざまなツリー構造を使用して適用できますが、効率のためにMerkleツリーよりもVerkleツリーがよく選択されます。 Merkleツリーでは、データポイント（葉）からツリーのルートまでのパスに沿ってすべての兄弟ノードのハッシュを含める必要があり、データの整合性を証明するためにはこれが必要です。 この要件は、証拠のサイズ（整合性の証明）がツリーの高さとともに増加することを意味し、各レベルで追加のハッシュが必要となります。 結果として、Merkleツリーでのデータ整合性の検証は、特に大規模なデータセットの場合、計算量が増加し、コストがかかります。 対照的に、Verkleツリーはこのプロセスを効率化し、新しいブロックの生成と検証における計算とストレージに関連するオーバーヘッドを削減します。
イネヴィテーブル・イーサリアムの「Verkle Tree」からのVerkleツリースケーリング
Verkle treesは、従来のMerkle treesの構造を強化し、葉と根との間の接続を合理化し、検証プロセスで兄弟ノードを含める必要を排除することによって、その構造を向上させます。 Verkle treeでは、証明の検証には葉ノードの値、根ノードへのコミットメント、および多項式コミットメントに基づく単一のベクトルコミットメントのみが関与し、Merkle treeで見られる複数のハッシュベースのコミットメントを置き換えます。 この変化により、Verkle treesは固定サイズの証人を維持し、木の高さや検証される葉の数とともに増加しないため、データ検証中のストレージと計算の効率を大幅に向上させます。
今後数年間、L1およびL2レベルで状態のない実装が様々な構成で実施されることが予想されます。最新のEthereumのロードマップによると、検証者はブロックビルダーが特定のブロックの状態に関するVerkle証明を提供し、これらの軽量な証明を維持する代わりに検証することができます。
L2レベルでは、[Gate]のようなチームがいます MegaETHare actively applying the concept of statelessness to the design of optimistic rollups. In their design, the sequencer node generates a witness for each block containing the necessary state values and intermediate hashes while emitting a state delta representing the changes in the state. Verifier nodes can then re-execute any block by retrieving the witness from the DA layer or a peer-to-peer network without storing the entire state. In parallel, full nodes update their state by applying the state deltas disseminated through the network, allowing them to stay synchronized without re-executing transactions or storing the entire state history.
しかし、状態のないことやメモリ内での計算が可能であることの利点はあるものの、実行レイヤーのパフォーマンスに対する銀の弾丸とは言えません。
MegaETHの「Ethereum実行レイヤーパフォーマンスの理解」からのリアルタイムTPS
MegaETHの共同創設者であるYilong Liは、以下で識別します研究プレゼンテーションイーサリアムの実行時には、最適化されたままであるオンチェーン上のデータ構造とアクセスパターンには他の非効率があります。
データベースの改善
実行レイヤーで作業しているチームは、これらのデータベースの構造を改善し、イーサリアムや他のEVM互換ブロックチェーンが非効率な状態アクセスに対処する際に経験するいくつかのボトルネックを排除する方法を見つけようとしています。これにより、計算効率に影響を与える連鎖反応が生じます。
実際には、EVMで見つかった既存のデータベース設計の制限に影響を受けましたMonad’s*決定は、単に計算効率を最適化することを超えて、並列化を実現することを目指しています。Monadは、並列実行を実装した後も、データベースへのマルチスレッド読み取りと書き込みリクエストが互いにブロックし合うため、パフォーマンスのわずかなスピードアップしか見られなかったことが分かりました。その結果、Monadは非同期IO（AIO）または並列アクセスに対応したデータベースを実装することを解決策の重要な部分として採用しました。
非同期I/O
I/O操作（ストレージデバイスから読み取ったり書き込んだりするなど）は、特に機械式ハードディスクドライブ（HDD）では、しばしばボトルネックを作り出します。これらのドライブでは、データにアクセスするために読み書きヘッドを物理的に動かす必要があり、データ処理を著しく遅くする可能性があります。
AIOは、プログラムが他のプロセスと同時にI/O操作を実行できるようにすることで、この課題に対処しています。基本的に、プログラムはI/O操作を開始し、完了を待つことなく進むことができます。これは、I/O操作が完了すると、オペレーティングシステムやI/Oライブラリが満たすコールバック関数やプロミスを登録することで行われます。この非同期アプローチにより、メインプログラムは他のタスクを実行し続けることができ、I/Oタスクの完了を待つことなく全体的な効率が向上します。
非同期I/Oは、従来のHDDとソリッドステートドライブ（SSD）の両方で実装することができますが、SSDの方が効果がより顕著です。HDDはAIOを実行できますが、その機械的な性質から、データをフラッシュメモリに保存し動く部品がないSSDよりも遅くなる傾向があり、結果としてアクセス時間が速くなります。
例えば、MonadはSSDストレージ向けに最適化されたカスタムステートバックエンドを利用しており、高レベルな並列データ処理をサポートし、I/O待ち時間を削減しています。このセットアップは、従来のディスクベースのストレージだけに依存するシステムやインメモリデータベースを使用するシステムよりも効率的ですが、これらは依然として遅いストレージメディアへの頻繁なデータの書き込みや読み取りから遅延が発生する可能性があります。
同様に、Rethはデータベース操作をコアのEVM実行エンジンから分離する方法を採用しています。このセットアップにより、EVMバイトコードを単一スレッドで順次実行し、データベースI/Oタスクを並列プロセスにオフロードして一貫性を維持します。Rethはアクターモデルと呼ばれるソフトウェアアーキテクチャパターンを使用して、これらの並列プロセスを効果的に管理し、I/O操作がEVMインタプリタを中断しないようにします。
ステートメルカリゼーション周波数
最適化のための別のベクトルは、状態のマークライゼーション頻度です。イーサリアムの現行モデルでは、ブロックごとに状態をメルクライズするたびに、ディスクへの頻繁な書き込みや読み取り、連続したトライのトラバーサルが必要とされ、その結果、大幅なオーバーヘッドが発生します。メルクルツリーは通常、中間ハッシュを16個のセット（ノードと呼ばれる）にグループ化し、キーがノードのハッシュであり、値がノード自体であるキー値ストアデータベースに格納されます。
このツリーを横断してデータを検索および更新するには、横断するツリーの各層ごとに1回のランダムなディスクアクセスが必要であり、単純なMerkleツリーを横断するには、おおよそ1回のアクセスが必要となります。エントリーごとに8つの連続したデータベースクエリ.
Solanaの各エポックの終わりに状態のコミットメントを更新するアプローチは、その期間内の多くのトランザクションで書き込みコストを分割することを可能にします。同じエポック内で状態エントリが複数回修正される場合、各書き込みについてMerkleルートを即時更新する必要はありません。したがって、エポック中の状態更新に関連する全体的な計算オーバーヘッドが減少します。その結果、状態からの読み取りに関連するコストは一定のままであり、またはO(1)であり、状態は毎回Merkleパスをトラバースする必要がなく直接読み取ることができます。
Ethereumにおけるマークライゼーションの頻度を減らすことは、状態の読み取りと書き込みに伴うオーバーヘッドを減らし、パフォーマンスを向上させる可能性があります。しかし、軽量クライアントは、エポック間での状態の追跡のためにブロックの変更を再生する必要があり、そのような変更は現在のEthereumと互換性がないため、オンチェーン取引による状態の検証を行う必要があります。
効率的で専門化されたデータ構造
さらに、既存のEthereumクライアント内の階層ツリー構造は一般に効率の悪い状態アクセスパターンを引き起こし、状態の膨張にさらに寄与しています。 Ethereumの状態はMPTとして構造化されていますが、それはまたEthereumクライアントデータベースに格納されています。LevelDB,PebbleDB（go-ethereumで使用される）、またはErigonで採用されるMDBXのようなMerkleツリーにデータを格納するB-TreeまたはLSM-Tree.
このセットアップでは、別のタイプのデータ構造に根付いたデータ構造が、別のMerkleツリー型システムの下で操作されるクライアントの上に内部ツリー構造をナビゲートすることで、「読み取り増幅」が生じます。 読み取り増幅は、状態に含まれる情報にアクセスしたり更新するための複数のステップの結果として理解でき、必要な操作を実行する前にMPTへのエントリーポイントを見つけるために外部ツリーをナビゲートする必要があります。 その結果、ランダムリードのためのディスクアクセス数はlog(n)の要素で乗算されます。
この問題を解決するために、Monad はネイティブでディスクとメモリ上の Patricia トライデータ構造を利用しています。技術的な観点から見ると、Patricia トライは、空間効率、効率的な接頭辞一致、および最小限のノードトラバーサルの独自の組み合わせにより、他のMerkleツリー構造よりも優れていることがよくあります。このトライの設計は、単一の子を持つノードを統合し、ルックアップ、挿入、および削除を合理化することで、必要なディスクまたはネットワークI/O操作の数を削減します。さらに、Patricia トライは接頭辞一致を処理する適応能力に優れており、迅速な部分キー検索が必要なアプリケーションでのパフォーマンスを向上させます。
ツリー構造固有の別のボトルネックは、データにアクセスしたり更新するには複数の階層を横断する必要があり、多くの連続したディスクアクセスにつながります。Sovereign Labsこの効率の悪さに対処するために、バイナリMerkleツリー構成を提唱しています。このバイナリ構造への重要なシフトは、ツリーのトラバーサル中の潜在的なパスの数を劇的に減らし、更新、挿入、および暗号証明に必要なハッシュ計算を直接減らします。
Sovereign Labsの「Nearly Optimal State Merklization」からのバイナリMerkleツリー構成
このカテゴリにおける追加の例として、RethチームがRethを構成することがあります実行中にディスクから中間ツリーノードを事前に取得します状態ルートサービスにストレージスロットとアカウントの通知を行うことによって。
状態の有効期限
ステートの有効期限は、一定期間アクセスされていないデータを削除することで、ブロックチェーンの状態のサイズを管理および削減する仕組みです。 有効期限はしばしば「状態の無状態」というカテゴリーに分類されますが、実行の文脈においてこれらの概念を区別することが重要です。
ステートレス性は、実行ノードのメモリ内での計算能力を高めることによって実行を改善しますが、実行トランザクションを行うノードの数が少なくなるため、実行に対するハードウェア要件の向上が起因しています。一方、状態の有効期限は、実行ノードが少ない場合と多い場合の両方のブロックチェーンに適用することができます。
状態の有効期限を実装するために一般的に議論されている方法はいくつかあります。
- レンタルによる有効期限: この方法は、アカウントを状態データベース内でアクティブに保つためにメンテナンス料金または「家賃」を請求するものです。 家賃が支払われない場合、アカウントはアーカイブされ、復元するために料金が支払われるまで保管されます。
- 時間切れ：ここでは、アカウントが特定の期間アクセスされていない場合、つまり取引や相互作用がない場合、非アクティブと見なされます。
両方のメソッドは、より古い、あまりアクセスされないデータをメインシステムに負担をかけないアーカイブ状態に押しやる一方で、即座にアクセス可能なデータのみを維持することを目指しています。
状態の膨張を軽減することで、状態の有効期限が維持されることにより、ブロックチェーンのパフォーマンスに深刻な影響を与える可能性がある「状態の膨張」が軽減されます。状態のサイズが小さいと、ノードは状態を迅速に移動および更新できるため、ノードがスキャンする時間が少なく、処理する時間が多いことから、処理が速くなります。
実行シャーディング
シャーディングは、タスクとデータを限られた数の専門ノードに分散させることで、リソースの利用とパフォーマンスを最適化します（すべてのノードがグローバルな状態を実行するのではありません）。
シャーディングされたブロックチェーンアーキテクチャでは、グローバルステートはシャードと呼ばれる異なるパーティションに分割されます。各シャードは状態の一部を保持し、ネットワークのトランザクションのサブセットを処理する責任を持ちます。トランザクションは、送信者のアドレス、受信者のアドレス、およびトランザクションデータのハッシュなど、さまざまな要因を考慮した決定的なシャーディング関数に基づいて特定のシャードに割り当てられます。これにより、クロスシャード通信の必要性が最小限に抑えられ、より効率的なトランザクションの実行が可能となります。
Vitalik氏の「ブロックチェーンのスケーラビリティの限界」からのシャーディング図
これは、を探索すると明らかになりますNEARプロトコルのシャーディングデザイン、ナイトシェード, 信頼の最小化を損なうことなくスケーリング・シャーディングを実現する状態のない状態を達成します。
Nightshadeでは、ブロックチェーンは単一の論理チェーンとして構築され、各ブロックは複数の「チャンク」で構成され、1つのシャードごとに1つのチャンクが割り当てられます。これらのチャンクには、各シャード固有のトランザクションやステート遷移が含まれています。1つのブロック内にすべてのシャードのチャンクを含めることで、ブロックチェーン全体の状態を統一的に表示し、シャード間通信のプロセスを簡略化することが可能となります。
Ethereumのproper-builder分離（PBS）と同様に、Nightshadeは明示的に状態ノードと状態レスノードの役割を区別しています。NEARでは、状態ノードが特定のシャードに割り当てられ、トランザクションの収集、実行、およびシャード固有のチャンクの生成を担当します。彼らは割り当てられたシャードの完全な状態を維持し、状態証人を生成してバリデータがバリデーションプロセス中に使用できるようにします。
一方、状態を持たない検証者は、ブロックごとにランダムに特定のシャードを検証するように割り当てられます。彼らは完全なシャード状態を維持する必要はなく、他のシャードからブロックプロデューサーによって提供された状態の証人に依存して、チャンク内の状態遷移とトランザクションを検証します。検証者をシャードにランダムに割り当てることで、悪意のある行為者が共謀して特定のシャードを支配するのがより困難になり、ネットワークのセキュリティと整合性を確保するのに役立ちます。
ネットワーク内の各ノードは、全体のネットワークデータではなく、それぞれのシャードのデータのみを処理する必要があるため、個々のノードのストレージおよび計算負荷が軽減されます。
ソリューション：非効率な計算
並列実行
部屋の中の象に取り組む時間です:並列化。 トランザクションの実行を並列化することで、複数のコンピューティングリソースを同時に利用して複数のトランザクションを処理することが可能になります。 これにより、ハードウェアリソースが需要が高い時期にスケールアップされる際に、スループットが向上します。
ただし、複数の実行コンポーネントを並列化することができることを考慮することが重要です。その多くはコプロセッサによって実装されています。ラグランジュ*および[Gate]などの代替ブロックチェーンクライアントFiredancerブロックチェーンのパフォーマンスを大幅に向上させることができます。具体的には、並列化には次のようなものがあります：
- 状態アクセスの並列化
- 特定の操作の並列化
- コンセンサスと実行の並列化
状態アクセスの並列化
状態アクセスの並列化2つの重要な利点をもたらします:
- Parallel EVMsは、複数のCPUコアにトランザクション処理を分散させます。この設定により、複数のトランザクションを順番に待たせるのではなく、同時に処理することが可能となります。
- ストレージからデータを待つトランザクションがある場合（これにはかなりの遅延が発生する可能性があります）、システムはアイドル状態にはなりません。代わりに、実行の準備ができている別のトランザクションに切り替えることができます。これは、複数のコアが異なるタスクを独立して同時に処理できるためです。
トランザクション実行を並列化する上での主な課題は、共有されたグローバル状態への同時アクセスの管理による競合を回避することから生じています。ACID分散システムを更新するためのルール。ブロックチェーンに複数のトランザクションが並列で実行されている場合、そのうちいくつかは競合することになります。そのため、状態アクセスを並列化するための2つの主要な手法は、競合を解決するためにリソースを割り当てるタイミングが異なります: 悲観的実行（またはメモリロック）モデルと楽観的実行モデルです。
悲観的な実行
悲観的な実行モデルは、実行中にトランザクションがアクセスする状態変数（読み取りまたは書き込み）を宣言する必要があるトランザクション処理アプローチです。この情報はトランザクションのメタデータに含まれており、実行前にアクセスパターンを解析するランタイムが可能になります。
読み書きアクセスパターンを調査することで、ランタイムは重複しないアクセスセットを持つトランザクションを特定し、重複しないおよび読み取り専用トランザクションの並列実行を可能にし、スループットを向上させることができます。ランタイムは、バリデータノード上の各CPUスレッドに対して並列トランザクションキューを作成し、競合しないアクセスパターンを持つトランザクションが同時に処理されることを保証します。
この設計選択の結果、悲観的な実行モデルはリソース割り当てに対する細かい制御を得ることができ、ブロックチェーンの状態空間をセグメンテーションまたはパーティショニングすることが可能となります。
並列化は、統一されたセキュリティモデルに基づく、複数の同期的に合成可能な独立した実行シャードを効果的に作成します。これにより、ネットワークの混雑を解消し、正確なリソース管理と動的な手数料市場を通じてガスコストを最適化するのに役立ちます。状態アクセスの「ホットスポット」（高い取引需要のエリア）を特定することで、システムは異なる手数料設定、レート制限、または高競合状態への追加リソースの割り当てなど、ターゲットとなる最適化を実装できます。重要な点として、Solanaの現在の並列化の実装はしないことに注意する必要があります。ローカライズされた手数料マーケットの潜在能力を十分に実現する.
同時アクセスにおけるデータの整合性を確保するために、悲観的な実行モデルはロックメカニズムを利用しています。トランザクションが特定の状態変数にアクセスする前に、その変数に対してロックを取得する必要があります。ロックはトランザクションに変数への排他的アクセス権を提供し、他のトランザクションが同時に変更するのを防ぎます。トランザクションが実行されたら、ロックが解除され、他のトランザクションが変数にアクセスできるようになります。
Solanaの海抜ランタイムは、この悲観的実行モデルを実装し、トランザクションは実行中に読み取るか書き込むアカウントを指定します。Sealevelはアクセスパターンを分析し、各CPUスレッドに対して並列トランザクションキューを構築します。アカウントが複数回アクセスされる場合、競合を防ぐために1つのキューに順次リストされます。リーダーノードのブロック時間内に処理されないトランザクションは、次にスケジュールされたリーダーに転送されて処理されます。
未使用取引出力（UTXO）ベースのシステムは、計算効率を同様に向上させます。UTXOには、個々のウォレットに関連付けられた特定の通貨単位、つまりUTXOが含まれます。ウォレットの各取引ごとに、UTXOが消費され、新しいUTXOに置き換えられます。受信者のために1つ以上のUTXOが作成され、支払いを表し、通常、イニシエーターのためにもう1つ作成され、戻りの変更を表します。
どの契約に触れるかを定義することで、異なる契約の集合に触れる取引は、実行ノードによって並行して実行されることができます（これは厳密なアクセスリストを持つ「アカウント」データモデルで実現できます）。ただし、Ethereumスタイルのスマート契約との互換性を得るために、FuelなどのUTXOスキームは、ブロック生成ノードに重複するアクセスリストを持つ取引を順次実行するよう制約を課しています。
しかし、悲観的な実行モデルには制限があります。 トランザクションは、複雑または動的なトランザクションの場合、アクセスパターンが入力データや条件付きロジックに依存する可能性があるため、正確にアクセスパターンを事前に宣言する必要があり、これは困難を伴うことがあります。 不正確または不完全なアクセスパターンの宣言は、最適でないパフォーマンスや潜在的なランタイムエラーの原因となり得ます。 さらに、ロックメカニズムは、多くのトランザクションが同じ状態変数を競合する場合、遅延を導入し、並行性を低下させる可能性があります。 この競合は、パフォーマンスのボトルネックを形成する可能性があり、トランザクションは、高需要の状態変数のロックを獲得するために実行時間のかなりの部分を待機することがあります。
さらに重要なことに、このモデルは、契約のデータ依存関係を正確に事前に指定するために、開発者には深い理解が必要であり、これにより、特に分散型取引所や自動市場メーカーなどの動的かつ複雑な状態の相互作用を持つアプリケーションを設計する際に課題が生じる可能性があります。
楽観的な実行
一方、楽観的な実行モデルは、取引の実行に「仮定的」なアプローチを採用し、事前の状態アクセス宣言を必要とせずにトランザクションを並行して実行できるようにします。
紛争を事前に防ぐのではなく、トランザクションは独立していると仮定して楽観的に並行して実行されます。ランタイムはGateのようなテクニックを利用しています。マルチバージョン同時実行制御(MVCC) およびソフトウェアトランザクショナルメモリ（STM）は、実行中に読み取りセットと書き込みセットを追跡することで動作を追跡します。実行後、ランタイムは競合や依存関係を検出します。競合するトランザクションを中止して再実行するなどの対策を講じますが、競合するトランザクションを特定するためにディスクではなくメモリから読み取ることができます。
オプティミスティック実行モデルを使用すると、開発プロセスが簡素化され、プログラマは状態アクセス パターンの宣言を気にすることなく、コントラクト ロジックの記述に集中できます。トランザクションは状態の相互作用を事前に宣言する必要がないため、開発者はスマートコントラクトの設計の自由度が高くなり、ブロックチェーンの状態とのより複雑で動的な相互作用が可能になります。楽観的実行モデルは、悲観的モデルよりも高いスループットとスケーラビリティを提供できるため、大量のトランザクションと複雑なDAppsをサポートするプラットフォームに特に適しています。
このモデルの注目すべき実装の1つは、Gate.ioで見つけることができますAptosそして、MoveVMのMovement Labs*, which employs a technique known as ブロック-STM. ブロック-STMでは、トランザクションはまず並行して実行され、その後、競合するトランザクションが特定され、検出された依存関係に基づいて再実行のためにスケジュールされます。このアプローチにより、処理リソースが連続して利用され、スループットが向上し、トランザクションのワークフローの整合性が維持されます。
AptosのBlock-STMは、「注文の呪いをパフォーマンスの恩恵に変えてブロックチェーンの実行をスケーリングする」
その利点にもかかわらず、楽観的実行モデルには課題もあります。実行時の競合検出の必要性やトランザクションの中止とリトライの可能性により、計算オーバーヘッドと複雑さが発生します。さらに、状態の複数バージョンを維持し、競合解決に関連するオーバーヘッドを管理する必要があり、洗練されたシステム設計と堅牢な並行制御メカニズムが、ブロックチェーンの完全性とパフォーマンスを確保するために必要です。
Block-STMは、MVCCを活用して並行書き込みを効果的に管理し、データの複数バージョンを維持することで、同時書き込み操作間の競合を防ぎます。複数のスレッド間で実行と検証タスクを調整するための協調スケジューラを組み込んでおり、トランザクションが開始された順にコミットされるようにします。このセットアップにより、動的依存関係推定を使用してトランザクションの中止を最小限に抑え、依存関係を効率的に待機および解決してから処理を続行することができます。
さらに、MoveVMが使用するアカウントモデルは、EthereumのEVMとは異なり、衝突が少なくなります。 Ethereumでは、トークンは通常、1つのスマートコントラクトによって管理され、複数のトークントランザクションが同じコントラクトアドレスを介して相互作用する可能性があり、紛争の可能性が高まります。 対照的に、MoveVMはトークンを個々のユーザーアカウントに割り当て、各トランザクションが通常、異なるアカウントアドレスとやり取りするため、そのような紛争の可能性が低くなります。
Monadでは、並行して実行される最初の一連のトランザクションは、直ちにコミット可能な結果を生み出す可能性があるI/Oフェーズと、残りのトランザクションの競合を解消するために少量の作業が必要な「リトライ」フェーズとして構築できます。これらの競合するトランザクションはキャッシュに浮上し、実行オーバーヘッドを削減できるようにメモリ内に存在するため、実行時に迅速にアクセスされます。ほとんどの状態はディスク上に存在しますが、競合するトランザクションは実行時に迅速にアクセスされます。
悲観的および楽観的な実行モデルは、ブロックチェーンにおける取引の実行と状態管理を処理する独自のアプローチを提供します。これらのモデルの選択には、状態アクセスの明示的な複雑さと動的な衝突解決に伴う計算オーバーヘッドとの間のトレードオフが関与します。
データ＆タスク並列処理
データとタスクの並列処理は、計算負荷を複数のプロセッサに分散させることでパフォーマンスを最適化することに焦点を当てています。データ並列処理はデータセットを同時処理するためにセグメント化し、タスク並列処理はさまざまなタスクをさまざまなプロセッサに同時に操作させるために割り当てます。
これらの最適化は異なるが相互依存しており、状態アクセス並列性とは、複数のプロセスやスレッドが同時に操作する際に、メモリやデータベースなどの共有リソースへのアクセスを管理および同期し、競合を防ぎデータの整合性を確保するものです。
データ並列
Data parallelismでは、複数のデータ要素にわたって特定の操作を同時に並列化することが含まれます。このアプローチは、同じ操作を大規模なデータセットに適用する必要がある場合や、複数の入力値に対して計算集約的な操作を実行する場合に特に有益です。このポイントは、データを複数の処理ユニットに分散させ、異なるデータ要素に対して同時に同じ操作を実行することから生じます。
データ並列処理の一般的な手法の1つは、単一命令、複数データ（SIMD）は、単一の命令を複数のデータ要素に同時に実行することを可能にする。現代のCPUには、多くの場合、組み込みのSIMD機能が備わっており、複数のデータポイントに並列操作を行うことができる。SIMD命令を活用することで、開発者は数値計算、データ変換、信号処理など特定の操作に対して、著しい高速化を実現できる。
例えば、大量の数値配列に複雑な数学関数を適用する必要があるシナリオを考えてみましょう。各数値を順次処理する代わりに、SIMDは複数の数値を同時に処理できます。この同時処理は、CPUのSIMDレジスタに数値のサブセットを読み込み、並列にすべての読み込まれた数値に数学関数を実行し、その結果をメモリに格納することで実現されます。複数の数値を一度に処理することで、SIMDは全体の実行時間を大幅に短縮することができます。
FiredancerのED25519に対する作業シグネチャ検証は、複雑な計算を最適化するためのSIMDのパワーを示しています。シグネチャ検証プロセスには、ガロア体内での算術演算が含まれ、計算量が多くなります。SIMD命令を活用することで、Firedancerは複数のデータ要素でこれらの操作を同時に実行でき、大幅なパフォーマンスの向上が実現されます。これらの最適化は、既に状態アクセスの並列化を実装しているSolanaのパフォーマンス向上に重要となります。
タスク並列性
タスク並列処理は、プログラム内の異なるタスクや操作を複数の処理ユニットにわたって並列化することを指します。このアプローチは、プログラムが複数の独立したタスクで構成されており、それらを同時に実行できる場合に有用です。各タスクをCPUコアやGPUなどの別々の処理ユニットに割り当てることで、全体の実行時間を短縮することができます。
タスクの並列処理は、プログラムが複数の複雑な操作を同時に実行する必要があるシナリオでよく使用されます。たとえば、ビデオストリームにさまざまなフィルターやエフェクトをリアルタイムで適用する必要があるビデオ処理アプリケーションを考えてみましょう。タスクの並列処理では、すべてのコンピューティング ユニットを使用して各フィルターをまとめて順番に適用する代わりに、複数の処理ユニットにワークロードを分散できます。1 つの処理ユニットがぼかしフィルターを適用し、別のユニットが色補正フィルターを適用するなど、さまざまな処理ユニットが担当できます。これらのタスクを並行して実行することで、アプリケーションは処理を高速化し、スムーズなユーザーエクスペリエンスを維持できます。
Lagrange’s @lagrangelabsZK MapReduce（ZKMR）は、大規模なデータセット上の分散計算の証明を効率的に並列化および生成するためにデータおよびタスクの並列性を活用します。マップフェーズでは、入力データセットがより小さなチャンクに分割され、それぞれのチャンクが個別のマッパーワーカーまたはマシンで並列に独立して処理されます（タスクの並列性）。そして、「マップ」操作は、各マッパータスク内で複数のコアやプロセッサを跨いで並列化できます（データの並列性）。同様に、リデュースフェーズでは、各キーに関連付けられた値に対する「リデュース」操作を各リデューサータスク内で並列化できます（データの並列性）。対照的に、リデューサータスクは複数のワーカー間で並列に実行されます（タスクの並列性）。
データ並列処理とタスク並列処理を組み合わせることで、ZKMRは、巨大なデータセットに対する複雑な計算の効率的なスケーリングとパフォーマンスを実現し、再帰的な証明構成を通じてゼロ知識保証を維持します。
Lagrangeの「Introducing ZK MapReduce」から、ZKでの任意のMapReduce手順の検証
Lagrange’s ability to generate storage proofs for SQL computations over @lagrangelabs/ ユーリッド-イーサリアム初の検証可能なデータベースおよびZKコプロセッサ-cc4a5595365c">888,888のストレージスロットを1分20秒で示し、ZKMRのパワー、およびそれを支えるタスクとデータの並列処理を実証します。さらに、ラグランジュの最近の そばかすの木この論文は、バッチ証明がオンチェーンデータにも適用可能であり、バッチサイズに依存せず、𝑂(log𝑛)で計算可能であることを強調しています。
合意と実行の並列化
この記事ではコンセンサスについては触れていませんが、ブロックチェーンはコンセンサスと実行のプロセスを並列化することもできます。従来のブロックチェーンは、通常、トランザクションを順次処理し、トランザクション（ブロックN）のコンセンサスに達した後にそれらを実行します。コンセンサスと実行フェーズの並列処理は、実行効率を大幅に向上させるもので、Monadなどのシステムで見られる技術の一例です。ネットワークがブロックNのコンセンサスに達すると、それと同時に前のブロック（N-1）のトランザクションを実行します。
この戦略により、計算リソースの連続的かつ効率的な利用が確保され、アイドル時間が効果的に削減され、ネットワークのトランザクション処理能力が向上します。これらの改善により、システムのスループットが向上し、ネットワークへのスパム攻撃に必要な資本コストも増加します。
通訳者とオーバーヘッドの削減
Solidityなどの言語でスマートコントラクトが書かれると、まず低レベルのバイトコードにコンパイルされます。その後、EVMはインタプリタを使用してこのバイトコードを実行します。インタプリタは各命令を順次読み取り、実行し、まるでリアルタイムで外国語を通訳するかのように行います。パラダイムのRethの最新記事それにより、各命令を個別に処理し、実行時にバイトコードから機械命令に変換する必要があるため、オーバーヘッドが発生することが指摘されています。
Rethは、実行直前にネイティブマシンコードにバイトコードを変換するJIT（Just-In-Time）コンパイラを組み込むことで、EVMの非効率を解決しています。これにより、通常実行時に必要とされる資源集約型の解釈プロセスを回避します。
The Reth articleJITの実践では、インタープリターベースシステムの50%の実行時間がJITが理論上満月した過程を引き継いていることを示し、JIT実装により実行速度を倍にする可能性を持っている。しかし、Yilongは指すより、このプレゼンテーション, JITは特定のオペコードの処理に必要な時間を大幅に減らすことができますが、全体の実行には大きな影響を与えないかもしれません。これは、JITが占めるEVM実行時間の50%のかなりの部分が関わっているためです。"ホスト"と"システム"の操作(スライド13)、（算術）や（制御）のようなJIT最適化に適さない、非計算的な性質を持つものです。
インタープリターはパフォーマンスを制限する可能性がありますが、「翻訳」という機会を作り出し、新しい仮想マシンを活用できるコードの範囲を広げ、開発者がデザイナーブロックスペースを使用するオーバーヘッドを低減させることができます。例えば、Movement LabsはFractalを開発しており、開発者がSolidityベースの契約をMoveVM上に展開できるようにしています。Fractalは、SolidityをEVMオペコードで表現された命令を含む中間言語にコンパイルし、それらをMoveVMバイトコードにマッピングして、Solidity契約がMoveVM環境で実行されるようにします。
特殊化されたカスタマイズされたステートマシン
実行レイヤーのカスタマイズには、特定のアプリケーションに最適化された専用ステートマシンを設計することが含まれます。これは、実行環境が仮想マシンを完全に必要としなくなるだけでなく、アプリケーションが命令セットアーキテクチャ（ISA）、データ構造、および実行モデルを特定のニーズに合わせて調整します。 特定のアプリケーションにISAを調整する主なパフォーマンスの利点は、アプリケーションの計算パターンを従来のISAの汎用命令に変換するオーバーヘッドを削減することにあります。 汎用CPUは、基本的な命令セット（例：加算、ロード、分岐）を使用して、さまざまな種類のソフトウェアを実行サポートします。 ただし、アプリケーションが同じ多段階操作を頻繁に繰り返すと、これらのパターンを単純な命令のシーケンスで実装することが効率的ではありません。
たとえば、データベースアプリケーションでは、常にツリーデータ構造をトラバースしたり、エントリを検索したり、値を更新したり、ツリーをリバランスしたりする必要があるかもしれません。通常のCPUでは、これらの高レベルの操作をマッピングするには、それらをロード、ストア、ブランチ、算術などの低レベルのマイクロオプスの長いシーケンスに分割する必要があり、一般的なハードウェア上で個別に実行する必要があります。それに対して、データベース向けにカスタマイズされたISAは、これらの繰り返しパターンを最適化されたより広い命令に融合させることができ、専用のハードウェアを活用できます。例えば、「TraverseTree」命令では、メモリアドレスを計算し、関連するノードをロードし、その操作に設計された並列比較回路を使用してキーを比較できます。「UpdateEntry」では、最適化されたデータベースストレージレイアウトからエントリを直接取得し、変更し、新しい状態を1つの命令ですべて確定できます。
これにより、高レベルの操作を単純な命令にまで翻訳することから冗長なオーバーヘッドを取り除きます。また、ハードウェアが、そのニーズに合わせてより少なくても幅広く、明示的に並列な命令を使用してアプリケーションを最適に実行できるようにします。
LayerNのノルド特定の実行環境とデータ構造を専門とすることによるパフォーマンスの利点を、検証可能な注文簿の具体的な使用例を通じて示しています。LayerNのアプローチは、取引を注文簿データ構造に最適化することに焦点を当てており、そのパイプラインメカニズムは、新しい注文を注文簿データツリー内の適切な位置に効率的に挿入するよう設計されています。注文簿の特定の要件にデータ構造と挿入アルゴリズムを適合させることで、LayerNは低レイテンシの注文配置と高スループットを実現しています。
代わりに、アプリケーションがパフォーマンスを最適化するためにプラグインすることができる任意にプログラム可能なモジュールを可能にする汎用実行環境に注力することも可能です。このアプローチは、生のパフォーマンスよりも開発者体験を優先します。
流暢そしてCWD生の計算パフォーマンスを最適化するとともに、開発者の体験とエコシステムの互換性を向上させるためのトレードオフをバランスさせる戦略を利用します。このアプローチは、コードを実行するためのVMとしてWebAssembly（Wasm）を使用することに焦点を当てています。 Wasmは、幅広い言語サポートと広く採用されている度合いから、Web開発での選択肢となっています。
開発者がネイティブなクライアント実行ではなくWasmを使用する選択は、汎用的な実行環境の柔軟性と広範なアクセシビリティを好む戦略的な選択を反映しています。ハードウェア上でコードを直接実行するネイティブ実行は性能が向上するかもしれませんが、クロスプラットフォームの互換性が制限され、開発者にはアクセスしにくくなります。一方、Wasmはネイティブ実行と同じ生の速度を達成できないものの、異なるプラットフォーム間で均一で安全な実行環境を確保します。このトレードオフは、FluentとCWDの設計思想と一致し、最大の性能効率よりも開発者の生産性とより広範なエコシステムの統合を優先しています。
CosmWasmデプロイメント（CWD）, 特に、これを具体化するのは、スマートコントラクトの実行にWasmを採用するだけでなく、それをより包括的なフレームワークに組み込んで、ブロックチェーンの複雑さをサポートするように設計されています。 「周辺ロジック」で充実させたこのフレームワークは、高度なアカウント管理、カスタマイズ可能なガスメカニズム、最適化されたトランザクションの順序付けを提供しています。 これらの機能により、柔軟で効率的で安全な開発環境が実現され、開発者は比較的簡単にスケーラブルで複雑なdappsを構築することができます。
Stackr*は、カスタマイズされた実行環境の利点と伝統的なスマートコントラクトプラットフォームの柔軟性を組み合わせることで異なるアプローチを取ります。Stackrは、開発者がアプリケーションをロールアップとしてコーディングできるようにし、トランザクションの順序、実行、構成に関する独自のルールを定義できるようにします。Stackrモデルでは、開発者がそのアプリケーションの要件に最適なISA、データ構造、実行モデルを選択できます。
Stackrのマイクロロールアップデザインは、「Stackr SDKの紹介」からです
With Stackr, developers can apply state transition rules directly in the application’s runtime rather than being constrained by the rules of a general-purpose VM, giving them the ability to streamline their instruction set to be more efficient and redefine the set of things that can be done in a runtime environment.
これにより、ビジネスロジックがクライアントレベルで実装されるため、コストのかかるスマートコントラクトの呼び出しと検証の必要性がなくなり、より軽量で効率的な実行が実現されます。その結果、アプリケーションの構成方法に関する可能性が拡大し、パフォーマンスを犠牲にすることなく、開発者が単一のアプリケーションで使用できる異なる種類の言語、データ構造、署名が拡大します。
結論
最適な実行レイヤーパフォーマンスへの複数の経路があります。
独占的な技術的差別化ポイントとして、状態アクセスや並列化に対する単一の最適化は、DAppsを取り込む際に実行レイヤー間で際立っています。私たちが進める中で、Solanaのリソースベースの並列化の利点は、FuelのUTXOモデルにも同様に適用できます。だれでもAmazonのシャーディングを通じて水平スケーラビリティを向上させるための洞察に満ちたソリューションそして実行レイヤーのパフォーマンスを向上させます。
While execution layer performance is a critical vector for winning over builders of decentralized applications, new L1s and L2s centered around improving execution must compete on other variables, including security, interoperability, and compatibility with existing tooling. For this reason, the proliferation of new interoperability layers—from Nebra to Statenet to Polygon’s AggLayer—will be critical to developers buying designer blockspace, as they can build or buy specialized blockspace without sacrificing the synchronous composability and shared liquidity of traditional, general-purpose L1s.
状態管理の改善と計算効率の向上は相互に依存しています。
コミュニティ全体で新しい実行レイヤーを設計する中で、状態アクセスの並列化は、約束されたパフォーマンスの向上のための決定的なミームとなっています。これはその理由があるためですが、これにより、EVMの実行における5倍の改善, Monadの並列処理に関する初期実験からの証拠は、他の改善（例：非同期I/Oなど）が同時に開発されない限り、その役割が過大評価されていることを示しています。
これに基づいて、計算効率はしばしば、状態のアクセスと保存方法を改善することでのみ実現されることがわかります。効率的な状態管理は、データにアクセスして操作するために必要な時間とリソースを削減し、処理を高速化して計算負荷を軽減します。
これをさらに一歩進めると、ハードフォークに伴う惰性を考えると、既存の企業は、国家の管理と更新の方法を再設計する新しいブロックチェーン設計に対抗する能力を妨げるパス依存の選択をしている可能性があります。その結果、特殊なモジュール式実行レイヤーと代替の L1 により、より効率的な状態ストレージの設計上の選択と、それに対する読み取りと書き込みのプロトコルに関する防御性を作成できる可能性があります。これらの設計上の決定は、既存企業がハードフォークなしでデータベース構造を更新する際に惰性に直面する可能性があるため、競争上の優位性を提供します。
結局のところ、ブロックスペースの値は実行レイヤーの設計空間に影響を与えます。
実行レイヤーを改善する方法を理解する際に、最適化のクラスは、トランザクションを実行しているのは誰か、および関与するノードの数はいくつかに応じて異なることを区別できることがわかりました。これらの質問へのチームの最初の回答によって大きく異なる実行のボトルネックを解決するための開発者向けの技術は、大幅に異なります。
一方、SolanaやMonadのようなモノリシックなL1は、パフォーマンスを向上させるために強力で弱いノードにバリデータの役割を分けることを受け入れない。短期間のステートブロートを「受け入れる」ことは実用的な解決策ではないため、彼らはデータベースレイヤーや他のブロック生成エンジンのコンポーネント（コンセンサスなど）の改善に依存し、より多くの実行ノードを補うために、ネットワークの重要なコンポーネントおよびコアバリューと見なされるより広範な数のバリデータのコンセンサスに依存しています。これらのL1のセキュリティモデルは、ハードウェア要件の弱いより分散されたバリデータのコンセンサスに依存しているため、そのデータはディスク上に存在するデータベースに書き込まれる必要があり、許可された最大限に分散化されたブロックチェーンにとってコスト面で必然的に安価です。
一方、EthereumなどのプロジェクトとそのL2は、中央集権化に傾倒するロードマップを追求しており、中央集権化されたブロックビルダーを通じて実行ノードを持つうえで弱い検証提案者ノードに責任を負わせる詐欺や妥当性の証明を通じています。
中央集権的な取引および状態遷移の「実行者」が分散型の未来を追求する上で許容されると仮定する。その場合、物理法則は、1) 複数のアクターによる取引の再実行を必要とせずにチェーンにブロックを追加できるシステム、2) バリデータの要件を増やしてインメモリ計算を最大化し（状態の膨張問題を無視する）、および3) レイテンシとコンセンサスのボトルネックを減らすシステムは、広範な分散化とノード間の合意に依存するシステムと比較して明らかに優位に立つことを示している。
スケーラビリティと信頼の最小化のバランスを求める中で、実行レイヤーの目的は盲目的に分散化を最適化することではないこと、また実行が常に完全に許可されなければならないわけではないことが明らかになってきています。
私たちが有効性や詐欺証明などのさまざまな暗号ツールを開発および実装するにつれて、検閲に対抗し、安全性とライブネスを維持するために必要なノードの数を効果的に減らしています。 ただし、このアプローチにはトレードオフが伴い、実行者の可能な中央集権化により、検閲耐性、順序整合性、およびライブネス保証に潜在的な影響が及ぶ可能性があります。
Sreeramの指摘によると、「最小限の分散化」は「検証が許可されるべき」という意味ではなく、「適切にインセンティブが与えられるべき」という意味である。つまり、不正行為に対して検証者が重大な影響を受ける監視されたシステムは、過度な分散化なしでも安全性と活性を維持できることを意味する。h/t SreeramGate.
そのようなガバナンスモデルはすでに実践的なアプリケーションでテストされています。たとえば、Arbitrumのようなロールアップでは、取引の順序付けやリーダーの選択ルールを施行するためのガバナンスまたは委員会ベースのシステムを探求しており、シーケンサーがオンチェーンデータを使用して取引の順序付けポリシーを維持するメカニズムを検討しています。
これらの進歩にもかかわらず、分散とパフォーマンスのバランスを取るための明確な「パレート最適フロンティア」は存在しません。
イデオロギー的および技術的な考慮事項は、状態を検証するために分散型の実行ノードを支持し続けています。一方で、ノードを中央集権化することで合意のオーバーヘッドを減らし、ハードウェアのアップグレードによってパフォーマンスを大幅に向上させることができますが、これらの最適化が検閲に対抗するアプリケーションを作成に焦点を当てる開発者を惹きつけるかどうか、そして検閲に対する抵抗が業界の中核的な価値観としてどの程度残るかは、これからの課題です。
*アーキタイプ・ポートフォリオ・カンパニーを示す
免責事項：
この記事は[から転載されましたミラー )], 元のタイトル「デザイナーブロックスペース: 実行環境の未来」を転送します。すべての著作権は元の著者に帰属します[ベンジャミン・ファンク]. If there are objections to this reprint, please contact the Gate Learnチームは速やかに対応します。
責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
Artículos relacionados
ステーブルコインとは何ですか？