高性能なブロックチェーンを構築する方法

上級4/27/2025, 6:08:07 AM
この記事はAptos Labsによって書かれ、高性能なブロックチェーンを構築する方法を体系的に説明しています。従来の直列処理からAptosの並列設計、そして最終的にザプトスの最適遅延モデルに進化するブロックチェーンシステムのパイプラインアーキテクチャの進化に焦点を当て、ブロックチェーンのパフォーマンス最適化のための主要な技術的経路とエンジニアリングプラクティスを紹介しています。


Source: Aptos Labs

コンピューティング技術の到来以来、エンジニアや研究者はコンピューティングリソースをパフォーマンスの限界まで引き出す方法を継続的に探求し、計算タスクの遅延を最小限に抑えながら効率を最大化しようとしてきました。高性能と低レイテンシーは常にコンピュータサイエンスの発展を形作る2つの要件であり、CPU、FPGA、データベースシステム、さらには人工知能インフラストラクチャやブロックチェーンシステムの最新技術の発展に影響を与えています。高性能を追求する中で、パイプライン技術は欠かせないツールとなっています。1964年のIBM System/360 [1]の導入以来、高性能システム設計の中心となり、この分野での重要な議論や革新を牽引しています。

パイプライン技術はハードウェアだけでなく、データベースでも広く使用されています。たとえば、Jim Grayは彼の著書『高性能データベースシステム[2]』でパイプライン並列法を導入しました。この方法は、複雑なデータベースクエリを複数の段階に分解して並行して実行し、効率とパフォーマンスを向上させています。パイプライン技術は人工知能においても重要であり、特に広く使用されているディープラーニングフレームワークTensorFlowでは、データパイプライン並列処理を利用してデータの前処理とロードを処理し、トレーニングと推論のためにスムーズなデータフローを確保し、AIワークフローをより迅速かつ効率的にします[3]。

ブロックチェーンも例外ではありません。その中核機能はデータベースと類似しており、取引の処理と状態の更新を行いますが、ビザンチン・フォールト・トレラント・コンセンサスの追加の課題があります。ブロックチェーンのスループット(秒間取引数)を向上させ、遅延(最終確認までの時間)を減らすには、異なる段階間の相互作用を最適化することが重要です。これには、高負荷下でのトランザクションの整理、実行、提出、および同期化が含まれます。この課題は特に高スループットのシナリオでは特に重要であり、従来の設計は低遅延を維持するのに苦労しています。

これらの考えを探求するために、なじみのあるアナロジーをもう一度考えてみましょう:自動車工場。組み立てラインが製造業を革命した方法を理解することで、ブロックチェーンパイプラインの進化を正しく評価し、Zaptos[8]のような次世代設計がブロックチェーンのパフォーマンスを新たな高みに押し上げている理由がわかります。

カーファクトリーからブロックチェーンへ

自分が自動車工場のオーナーであり、2つの主な目標を持っていると想像してみてください:

· スループットを最大化する:1日に可能な限り多くの車を組み立てる。

・レイテンシーを最小限に抑える:各車両の建設にかかる時間を短縮します。

今、3種類の工場を想像してください:

シンプル工場

単純な工場では、多才な労働者グループが段階的に車を組み立てます。1人の労働者がエンジンを組み立て、次の人がホイールを取り付け、その他も同様にして、1台の車を生産しています。

問題は何ですか?一部の労働者はよくアイドル状態になっており、全体的な生産効率が低下しています。なぜなら、同じ車の異なる部分に誰も同時に作業していないからです。

フォード工場

フォード組立ライン[4]に入力してください!ここでは、各労働者が1つのタスクに集中します。車はコンベアベルトに沿って移動し、通過するたびに専門の労働者がそれぞれの部品を追加します。

何が起こりますか?複数の車が同時に異なる段階で組み立てられており、すべての労働者が忙しいです。スループットが大幅に増加しますが、各車は依然として各労働者を1人ずつ通過しなければならず、つまり、車ごとの遅延時間は変わりません。

マジックファクトリー

今、同じ車に同時に作業できるすべての労働者がいる魔法の工場を想像してみてください!車を次の工程に動かす必要はありません。車のすべての部分が同時に建設されています。

結果は何ですか?車は記録的な速さで組み立てられ、すべての工程が同期して行われます。これは、スループットとレイテンシの両方の問題を解決するための理想的なシナリオです。

さて、車工場の議論は片付いたので、ブロックチェーンについてはどうですか?高性能なブロックチェーンを設計することは、組み立てラインを最適化することとそれほど違いがないことがわかりました。

ブロックチェーンは自動車工場のようなものです

ブロックチェーンでは、ブロックを処理することは、車を組み立てることに似ています。その類推は次のとおりです。

・Workers = バリデーターリソース

· Cars = ブロック

・アセンブリタスク = コンセンサス、実行、提出などの段階

単純な工場が1台の車を1台ずつ処理するように、ブロックチェーンが1つのブロックを1つずつ処理すると、リソースの過小利用につながります。それに対して、現代のブロックチェーン設計は、フォードの組み立てラインのように機能することを目指しており、複数のブロックの異なる段階を同時に処理することを目指しています。ここで、パイプライン技術が重要になります。

ブロックチェーンパイプラインの進化

伝統的なアーキテクチャ:シーケンシャルブロックチェーン

ブロックを順次処理するブロックチェーンを想像してください。検証者は次のものが必要です:

  1. ブロック提案を受け取ります。

  2. ブロックを実行して、ブロックチェーンの状態を更新します。

  3. その状態での合意を継続します。

  4. データベースに状態を永続化します。

  5. 次のブロックの合意を開始します。

何か問題でもありますか?

· 実行と提出は、コンセンサスプロセスの重要な部分です。

・各コンセンサスインスタンスは、前のインスタンスが終了するのを待たなければなりません。

このセットアップは、フォード時代前の工場のようです:労働者(リソース)は一度に1つのブロック(車)に集中するときにしばしばアイドル状態になります。残念ながら、多くの既存のブロックチェーンはまだこのカテゴリーに属しており、スループットが低く遅延が高い状態になっています。

Aptos: パラレル化されたパフォーマンス

Diemは、実行と提出をコンセンサスフェーズから切り離し、同時にコンセンサス自体のためにパイプライン設計を採用したパイプラインアーキテクチャを導入しました。

・非同期実行および提出[5]:検証者はまずブロックについて合意に達し、次に親ブロックの状態に基づいてブロックを実行します。必要な数の検証者によって署名された後、状態はストレージに永続化されます。

・パイプラインコンセンサス(Jolteon[6]):新しいコンセンサスインスタンスは、前のものが完了する前に開始することができ、まるで移動する組み立てラインのようです。

これにより、異なるブロックが同時に異なる段階にあることで、スループットが向上し、ブロック時間がわずか2つのメッセージ遅延に短縮されます。ただし、Jolteonのリーダーベースの設計は、トランザクションの配布中にリーダーが過負荷になる可能性があるため、ボトルネックを引き起こす可能性があります。

Aptosは、Quorum Store[7]を使用してパイプラインをさらに最適化しました。これはデータの配布とコンセンサスを切り離す仕組みです。Quorum Storeはもはや1つのリーダーに依存せず、コンセンサスプロトコルで大きなデータブロックをブロードキャストすることができ、データの配布をメタデータの順序付けから分離し、バリデーターが非同期かつ同時にデータを配布できるようにします。この設計は、すべてのバリデーターの合計帯域幅を利用し、コンセンサスにおけるリーダーのボトルネックを効果的に排除します。


イラスト: リーダーベースのコンセンサスプロトコルに基づいて、Quorum Storeがリソース利用のバランスを取る方法の説明。

これにより、Aptosブロックチェーンは、ブロックチェーンの「フォード工場」を作り出しました。フォードの組み立てラインが自動車生産を革命化したように、異なる車の異なる段階が同時に進行するように、Aptosは異なるブロックの異なる段階を同時に処理します。各検証者のリソースが十分に活用され、プロセスのどの部分も待機状態になりません。この巧妙な組み立てにより、高スループットシステムが実現し、Aptosは効率的かつスケーラブルにブロックチェーン取引を処理する強力なプラットフォームとなっています。


イラスト:Aptosブロックチェーン内の連続ブロックのパイプライン処理。 バリデータは、連続するブロックの異なる段階をパイプライン処理して、リソース利用を最大限に活用し、スループットを増加させることができます。

スループットは重要ですが、トランザクションの送信から最終確認までのエンドツーエンドのレイテンシー(遅延)も同様に重要です。支払い、分散型金融(DeFi)、ゲームなどのアプリケーションでは、ミリ秒単位での時間が重要です。多くのユーザーは、各トランザクションがクライアント - フルノード - バリデーター通信、合意、実行、状態の検証、提出、およびフルノードの同期の一連の段階を順次通過する必要があるため、高トラフィックイベント中の遅延を経験しています。高負荷時には、実行やフルノードの同期などの段階がさらに遅延を引き起こします。


イラスト:Aptosブロックチェーンのパイプラインアーキテクチャ。図にはクライアントCi、フルノードFi、およびバリデータViが表示されています。各ボックスは、ブロックチェーン内のトランザクションブロックが左から右に通過する段階を表しています。パイプラインは、合意(配布と順序付けを含む)、実行、検証、提出、フルノード同期の5つの段階で構成されています。

フォード工場のようなものです:組み立てラインは全体のスループットを最大限に活用していますが、各車両はまだ各労働者を順番に通過しなければならないため、完了時間が長くなります。ブロックチェーンのパフォーマンスを本当に限界まで引き出すためには、「マジック工場」を建設する必要があります――ここではこれらの段階が並行して実行されます。

ザプトス:最適なブロックチェーンレイテンシーに向けて移動

Zaptos[8]は、スループットを犠牲にすることなく、3つの主要な最適化を通じてレイテンシを低減します。

· 楽観的な実行:ブロック提案を受信した直後に実行を開始することで、パイプラインの待ち時間を短縮します。バリデータは、ブロックをパイプラインにすぐに追加し、親ブロックが完了した後に実行を予測します。フルノードも、バリデータから提案を受信すると、状態の証明を検証するために楽観的な実行を行います。

・楽観的な提出:ブロックの実行後すぐに状態をストレージに書き込みます。状態の検証前にも書き込みが行われます。検証者が最終的に状態を認定すると、提出を完了するために必要な更新は最小限です。ブロックが最終的に順序付けされない場合、楽観的に提出された状態は一貫性を維持するためにロールバックされます。

· 迅速な検証:バリデーターは、最終的な合意ラウンド中に実行されたブロックの状態検証を並列で開始し、合意が完了するのを待たずに行います。この最適化により、通常のシナリオではパイプラインの遅延が1ラウンド削減されます。


図: Zaptosの並列パイプラインアーキテクチャ。コンセンサス以外のすべての段階は、エンドツーエンドの遅延を削減するために実質的にコンセンサス段階内に隠されています。

これらの最適化により、Zaptosは実質的に他のパイプライン段階の遅延をコンセンサス段階内で隠します。その結果、ブロックチェーンが最適な遅延を持つコンセンサスプロトコルを採用すると、全体のブロックチェーンの遅延も最適に達することができます!

空談は無駄です。データが自己を証明します。

Zaptosのエンドツーエンドのパフォーマンスを、地理的に分散した実験を通じて評価しました。高性能のベースラインとしてAptosを使用しました。詳細については、[8]を参照してください。

Google Cloudでは、Aptosの展開で使用されている商用機に類似した商用機を使用して、100人の検証者と30台のフルノードから成るグローバルに分散したネットワークを10の地域に分散させ、シミュレートしました。

スループット-レイテンシー


イラスト:ZaptosとAptosブロックチェーンのパフォーマンス比較。

上のチャートは、両方のシステムのエンドツーエンドの遅延とスループットの関係を比較しています。両方とも、負荷が増加するにつれて遅延が徐々に増加し、最大容量で急激なスパイクがあります。しかし、ザプトスは、ピークスループットに達する前により安定した遅延を示し続け、低負荷時には遅延が160ミリ秒、高負荷時には500ミリ秒以上削減されています。

インプレッシブなことに、Zaptosは本番環境で20k TPSでサブセカンドのレイテンシーを達成しています。このブレークスルーにより、スピードとスケーラビリティを必要とする実世界のアプリケーションが実現可能になりました。

レイテンシーブレイクダウン


イラスト:Aptosブロックチェーンのレイテンシー分解。


イラスト:Zaptosの遅延分解。

レイテンシーブレイクダウン図は、バリデーターとフルノードの各パイプライン段階の期間の詳細なビューを提供します。主な洞察には、次のものが含まれます:

・最大10k TPS:Zaptosの全体的な遅延は、楽観的な実行、検証、および楽観的な提出段階が実質的にコンセンサス段階内で「隠されている」ため、そのコンセンサス遅延とほぼ同じです。

・10k TPS以上:楽観的な実行とフルノードの同期にかかる時間が増加するにつれて、非コンセンサス段階がより重要になります。それにもかかわらず、Zaptosはほとんどの段階を重複させることで全体の待ち時間を大幅に短縮します。例えば、20k TPSでは、基準の合計待ち時間は1.32秒(コンセンサス0.68秒、その他の段階0.64秒)ですが、Zaptosは0.78秒(コンセンサス0.67秒、その他の段階0.11秒)を達成します。

結論

ブロックチェーンアーキテクチャの進化は、単純な連続的なワークフローから高度に並列化された組み立てラインへの変革に似ています。Aptosのパイプラインアプローチはスループットを大幅に向上させ、Zaptosはレイテンシをサブセカンドレベルまで低減し、高いTPSを維持します。現代のコンピューティングアーキテクチャが効率を最大化するために並列処理を活用しているように、ブロックチェーンは不要なレイテンシを排除するために設計を継続的に最適化する必要があります。Zaptosは最低レイテンシのためにブロックチェーンパイプラインを完全に最適化することで、速度とスケーラビリティの両方を必要とする実世界のブロックチェーンアプリケーションへの道を開いています。

免責事項:

  1. この記事は[から転載されていますブロックビート], および著作権は原著作者に帰属します[Aptos Labs]. If you have any objections to the reprint, please contact the ゲートラーンチームは、関連手続きに従ってできるだけ早く対応します。

  2. 免責事項:この記事で表現されている見解および意見は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。

  3. 他の言語の記事バージョンは、Gate Learnチームによって翻訳されています。翻訳された記事は、引用を含めずにコピー、配布、または盗用されることはできません。Gate.io.

高性能なブロックチェーンを構築する方法

上級4/27/2025, 6:08:07 AM
この記事はAptos Labsによって書かれ、高性能なブロックチェーンを構築する方法を体系的に説明しています。従来の直列処理からAptosの並列設計、そして最終的にザプトスの最適遅延モデルに進化するブロックチェーンシステムのパイプラインアーキテクチャの進化に焦点を当て、ブロックチェーンのパフォーマンス最適化のための主要な技術的経路とエンジニアリングプラクティスを紹介しています。


Source: Aptos Labs

コンピューティング技術の到来以来、エンジニアや研究者はコンピューティングリソースをパフォーマンスの限界まで引き出す方法を継続的に探求し、計算タスクの遅延を最小限に抑えながら効率を最大化しようとしてきました。高性能と低レイテンシーは常にコンピュータサイエンスの発展を形作る2つの要件であり、CPU、FPGA、データベースシステム、さらには人工知能インフラストラクチャやブロックチェーンシステムの最新技術の発展に影響を与えています。高性能を追求する中で、パイプライン技術は欠かせないツールとなっています。1964年のIBM System/360 [1]の導入以来、高性能システム設計の中心となり、この分野での重要な議論や革新を牽引しています。

パイプライン技術はハードウェアだけでなく、データベースでも広く使用されています。たとえば、Jim Grayは彼の著書『高性能データベースシステム[2]』でパイプライン並列法を導入しました。この方法は、複雑なデータベースクエリを複数の段階に分解して並行して実行し、効率とパフォーマンスを向上させています。パイプライン技術は人工知能においても重要であり、特に広く使用されているディープラーニングフレームワークTensorFlowでは、データパイプライン並列処理を利用してデータの前処理とロードを処理し、トレーニングと推論のためにスムーズなデータフローを確保し、AIワークフローをより迅速かつ効率的にします[3]。

ブロックチェーンも例外ではありません。その中核機能はデータベースと類似しており、取引の処理と状態の更新を行いますが、ビザンチン・フォールト・トレラント・コンセンサスの追加の課題があります。ブロックチェーンのスループット(秒間取引数)を向上させ、遅延(最終確認までの時間)を減らすには、異なる段階間の相互作用を最適化することが重要です。これには、高負荷下でのトランザクションの整理、実行、提出、および同期化が含まれます。この課題は特に高スループットのシナリオでは特に重要であり、従来の設計は低遅延を維持するのに苦労しています。

これらの考えを探求するために、なじみのあるアナロジーをもう一度考えてみましょう:自動車工場。組み立てラインが製造業を革命した方法を理解することで、ブロックチェーンパイプラインの進化を正しく評価し、Zaptos[8]のような次世代設計がブロックチェーンのパフォーマンスを新たな高みに押し上げている理由がわかります。

カーファクトリーからブロックチェーンへ

自分が自動車工場のオーナーであり、2つの主な目標を持っていると想像してみてください:

· スループットを最大化する:1日に可能な限り多くの車を組み立てる。

・レイテンシーを最小限に抑える:各車両の建設にかかる時間を短縮します。

今、3種類の工場を想像してください:

シンプル工場

単純な工場では、多才な労働者グループが段階的に車を組み立てます。1人の労働者がエンジンを組み立て、次の人がホイールを取り付け、その他も同様にして、1台の車を生産しています。

問題は何ですか?一部の労働者はよくアイドル状態になっており、全体的な生産効率が低下しています。なぜなら、同じ車の異なる部分に誰も同時に作業していないからです。

フォード工場

フォード組立ライン[4]に入力してください!ここでは、各労働者が1つのタスクに集中します。車はコンベアベルトに沿って移動し、通過するたびに専門の労働者がそれぞれの部品を追加します。

何が起こりますか?複数の車が同時に異なる段階で組み立てられており、すべての労働者が忙しいです。スループットが大幅に増加しますが、各車は依然として各労働者を1人ずつ通過しなければならず、つまり、車ごとの遅延時間は変わりません。

マジックファクトリー

今、同じ車に同時に作業できるすべての労働者がいる魔法の工場を想像してみてください!車を次の工程に動かす必要はありません。車のすべての部分が同時に建設されています。

結果は何ですか?車は記録的な速さで組み立てられ、すべての工程が同期して行われます。これは、スループットとレイテンシの両方の問題を解決するための理想的なシナリオです。

さて、車工場の議論は片付いたので、ブロックチェーンについてはどうですか?高性能なブロックチェーンを設計することは、組み立てラインを最適化することとそれほど違いがないことがわかりました。

ブロックチェーンは自動車工場のようなものです

ブロックチェーンでは、ブロックを処理することは、車を組み立てることに似ています。その類推は次のとおりです。

・Workers = バリデーターリソース

· Cars = ブロック

・アセンブリタスク = コンセンサス、実行、提出などの段階

単純な工場が1台の車を1台ずつ処理するように、ブロックチェーンが1つのブロックを1つずつ処理すると、リソースの過小利用につながります。それに対して、現代のブロックチェーン設計は、フォードの組み立てラインのように機能することを目指しており、複数のブロックの異なる段階を同時に処理することを目指しています。ここで、パイプライン技術が重要になります。

ブロックチェーンパイプラインの進化

伝統的なアーキテクチャ:シーケンシャルブロックチェーン

ブロックを順次処理するブロックチェーンを想像してください。検証者は次のものが必要です:

  1. ブロック提案を受け取ります。

  2. ブロックを実行して、ブロックチェーンの状態を更新します。

  3. その状態での合意を継続します。

  4. データベースに状態を永続化します。

  5. 次のブロックの合意を開始します。

何か問題でもありますか?

· 実行と提出は、コンセンサスプロセスの重要な部分です。

・各コンセンサスインスタンスは、前のインスタンスが終了するのを待たなければなりません。

このセットアップは、フォード時代前の工場のようです:労働者(リソース)は一度に1つのブロック(車)に集中するときにしばしばアイドル状態になります。残念ながら、多くの既存のブロックチェーンはまだこのカテゴリーに属しており、スループットが低く遅延が高い状態になっています。

Aptos: パラレル化されたパフォーマンス

Diemは、実行と提出をコンセンサスフェーズから切り離し、同時にコンセンサス自体のためにパイプライン設計を採用したパイプラインアーキテクチャを導入しました。

・非同期実行および提出[5]:検証者はまずブロックについて合意に達し、次に親ブロックの状態に基づいてブロックを実行します。必要な数の検証者によって署名された後、状態はストレージに永続化されます。

・パイプラインコンセンサス(Jolteon[6]):新しいコンセンサスインスタンスは、前のものが完了する前に開始することができ、まるで移動する組み立てラインのようです。

これにより、異なるブロックが同時に異なる段階にあることで、スループットが向上し、ブロック時間がわずか2つのメッセージ遅延に短縮されます。ただし、Jolteonのリーダーベースの設計は、トランザクションの配布中にリーダーが過負荷になる可能性があるため、ボトルネックを引き起こす可能性があります。

Aptosは、Quorum Store[7]を使用してパイプラインをさらに最適化しました。これはデータの配布とコンセンサスを切り離す仕組みです。Quorum Storeはもはや1つのリーダーに依存せず、コンセンサスプロトコルで大きなデータブロックをブロードキャストすることができ、データの配布をメタデータの順序付けから分離し、バリデーターが非同期かつ同時にデータを配布できるようにします。この設計は、すべてのバリデーターの合計帯域幅を利用し、コンセンサスにおけるリーダーのボトルネックを効果的に排除します。


イラスト: リーダーベースのコンセンサスプロトコルに基づいて、Quorum Storeがリソース利用のバランスを取る方法の説明。

これにより、Aptosブロックチェーンは、ブロックチェーンの「フォード工場」を作り出しました。フォードの組み立てラインが自動車生産を革命化したように、異なる車の異なる段階が同時に進行するように、Aptosは異なるブロックの異なる段階を同時に処理します。各検証者のリソースが十分に活用され、プロセスのどの部分も待機状態になりません。この巧妙な組み立てにより、高スループットシステムが実現し、Aptosは効率的かつスケーラブルにブロックチェーン取引を処理する強力なプラットフォームとなっています。


イラスト:Aptosブロックチェーン内の連続ブロックのパイプライン処理。 バリデータは、連続するブロックの異なる段階をパイプライン処理して、リソース利用を最大限に活用し、スループットを増加させることができます。

スループットは重要ですが、トランザクションの送信から最終確認までのエンドツーエンドのレイテンシー(遅延)も同様に重要です。支払い、分散型金融(DeFi)、ゲームなどのアプリケーションでは、ミリ秒単位での時間が重要です。多くのユーザーは、各トランザクションがクライアント - フルノード - バリデーター通信、合意、実行、状態の検証、提出、およびフルノードの同期の一連の段階を順次通過する必要があるため、高トラフィックイベント中の遅延を経験しています。高負荷時には、実行やフルノードの同期などの段階がさらに遅延を引き起こします。


イラスト:Aptosブロックチェーンのパイプラインアーキテクチャ。図にはクライアントCi、フルノードFi、およびバリデータViが表示されています。各ボックスは、ブロックチェーン内のトランザクションブロックが左から右に通過する段階を表しています。パイプラインは、合意(配布と順序付けを含む)、実行、検証、提出、フルノード同期の5つの段階で構成されています。

フォード工場のようなものです:組み立てラインは全体のスループットを最大限に活用していますが、各車両はまだ各労働者を順番に通過しなければならないため、完了時間が長くなります。ブロックチェーンのパフォーマンスを本当に限界まで引き出すためには、「マジック工場」を建設する必要があります――ここではこれらの段階が並行して実行されます。

ザプトス:最適なブロックチェーンレイテンシーに向けて移動

Zaptos[8]は、スループットを犠牲にすることなく、3つの主要な最適化を通じてレイテンシを低減します。

· 楽観的な実行:ブロック提案を受信した直後に実行を開始することで、パイプラインの待ち時間を短縮します。バリデータは、ブロックをパイプラインにすぐに追加し、親ブロックが完了した後に実行を予測します。フルノードも、バリデータから提案を受信すると、状態の証明を検証するために楽観的な実行を行います。

・楽観的な提出:ブロックの実行後すぐに状態をストレージに書き込みます。状態の検証前にも書き込みが行われます。検証者が最終的に状態を認定すると、提出を完了するために必要な更新は最小限です。ブロックが最終的に順序付けされない場合、楽観的に提出された状態は一貫性を維持するためにロールバックされます。

· 迅速な検証:バリデーターは、最終的な合意ラウンド中に実行されたブロックの状態検証を並列で開始し、合意が完了するのを待たずに行います。この最適化により、通常のシナリオではパイプラインの遅延が1ラウンド削減されます。


図: Zaptosの並列パイプラインアーキテクチャ。コンセンサス以外のすべての段階は、エンドツーエンドの遅延を削減するために実質的にコンセンサス段階内に隠されています。

これらの最適化により、Zaptosは実質的に他のパイプライン段階の遅延をコンセンサス段階内で隠します。その結果、ブロックチェーンが最適な遅延を持つコンセンサスプロトコルを採用すると、全体のブロックチェーンの遅延も最適に達することができます!

空談は無駄です。データが自己を証明します。

Zaptosのエンドツーエンドのパフォーマンスを、地理的に分散した実験を通じて評価しました。高性能のベースラインとしてAptosを使用しました。詳細については、[8]を参照してください。

Google Cloudでは、Aptosの展開で使用されている商用機に類似した商用機を使用して、100人の検証者と30台のフルノードから成るグローバルに分散したネットワークを10の地域に分散させ、シミュレートしました。

スループット-レイテンシー


イラスト:ZaptosとAptosブロックチェーンのパフォーマンス比較。

上のチャートは、両方のシステムのエンドツーエンドの遅延とスループットの関係を比較しています。両方とも、負荷が増加するにつれて遅延が徐々に増加し、最大容量で急激なスパイクがあります。しかし、ザプトスは、ピークスループットに達する前により安定した遅延を示し続け、低負荷時には遅延が160ミリ秒、高負荷時には500ミリ秒以上削減されています。

インプレッシブなことに、Zaptosは本番環境で20k TPSでサブセカンドのレイテンシーを達成しています。このブレークスルーにより、スピードとスケーラビリティを必要とする実世界のアプリケーションが実現可能になりました。

レイテンシーブレイクダウン


イラスト:Aptosブロックチェーンのレイテンシー分解。


イラスト:Zaptosの遅延分解。

レイテンシーブレイクダウン図は、バリデーターとフルノードの各パイプライン段階の期間の詳細なビューを提供します。主な洞察には、次のものが含まれます:

・最大10k TPS:Zaptosの全体的な遅延は、楽観的な実行、検証、および楽観的な提出段階が実質的にコンセンサス段階内で「隠されている」ため、そのコンセンサス遅延とほぼ同じです。

・10k TPS以上:楽観的な実行とフルノードの同期にかかる時間が増加するにつれて、非コンセンサス段階がより重要になります。それにもかかわらず、Zaptosはほとんどの段階を重複させることで全体の待ち時間を大幅に短縮します。例えば、20k TPSでは、基準の合計待ち時間は1.32秒(コンセンサス0.68秒、その他の段階0.64秒)ですが、Zaptosは0.78秒(コンセンサス0.67秒、その他の段階0.11秒)を達成します。

結論

ブロックチェーンアーキテクチャの進化は、単純な連続的なワークフローから高度に並列化された組み立てラインへの変革に似ています。Aptosのパイプラインアプローチはスループットを大幅に向上させ、Zaptosはレイテンシをサブセカンドレベルまで低減し、高いTPSを維持します。現代のコンピューティングアーキテクチャが効率を最大化するために並列処理を活用しているように、ブロックチェーンは不要なレイテンシを排除するために設計を継続的に最適化する必要があります。Zaptosは最低レイテンシのためにブロックチェーンパイプラインを完全に最適化することで、速度とスケーラビリティの両方を必要とする実世界のブロックチェーンアプリケーションへの道を開いています。

免責事項:

  1. この記事は[から転載されていますブロックビート], および著作権は原著作者に帰属します[Aptos Labs]. If you have any objections to the reprint, please contact the ゲートラーンチームは、関連手続きに従ってできるだけ早く対応します。

  2. 免責事項:この記事で表現されている見解および意見は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。

  3. 他の言語の記事バージョンは、Gate Learnチームによって翻訳されています。翻訳された記事は、引用を含めずにコピー、配布、または盗用されることはできません。Gate.io.

今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.