
出典: Aptos Labs
コンピューティング技術の誕生以来、エンジニアや研究者はコンピューティング リソースをパフォーマンスの限界まで押し上げる方法を常に模索し、コンピューティング タスクの待ち時間を最小限に抑えながら効率を最大化するよう努めてきました。高性能と低レイテンシという二つの柱は、CPU や FPGA からデータベース システム、さらに最近では AI インフラストラクチャやブロックチェーン システムまで、幅広い分野に影響を与えながら、コンピューター サイエンスの発展を形作り続けています。高性能を追求するには、パイプライン技術が欠かせない手段となります。パイプラインは、1964年にIBM System/360 [1]に導入されて以来、高性能システム設計の中心となり、この分野における重要な議論と革新を推進してきました。
パイプライン技術はハードウェアだけでなく、データベース分野でも広く利用されています。例えば、ジム・グレイは著書『ハイパフォーマンスデータベースシステム』[2]の中でパイプライン並列処理を紹介した。このアプローチでは、複雑なデータベース クエリを複数の段階に分割して同時に実行することで、効率とパフォーマンスが向上します。パイプラインは、人工知能の分野、特に広く使用されているディープラーニング フレームワーク TensorFlow においても重要です。データパイプラインを使用してデータの前処理と読み込みを並列化し、トレーニングと推論間のスムーズなデータフローを確保し、AIワークフローをより高速かつ効率的にします[3]。
ブロックチェーンも例外ではありません。そのコア機能はデータベースの機能に似ており、トランザクションの処理とステータスの更新を行いますが、ビザンチンフォールトトレラントコンセンサスという課題が加わります。ブロックチェーンのスループット(1 秒あたりのトランザクション数)を向上させ、レイテンシ(最終確認までの時間)を短縮するための鍵は、高負荷状態でのトランザクションの順序付け、実行、コミット、同期といったさまざまな段階の相互作用を最適化することにあります。従来の設計では低レイテンシを維持するのが難しいため、この課題は特に高スループットのシナリオで重大になります。
これらのアイデアを検討するには、よく知られた例えである自動車工場を思い出すと役立ちます。組立ラインが製造業にどのような革命をもたらしたかを理解することは、ブロックチェーン組立ラインの進化を理解するのに役立ちます。そしてなぜZaptos[8]のような次世代の設計がブロックチェーンの機能を新たな高みに押し上げているのかを理解するのに役立ちます。
次の 2 つの主な目標を持つ自動車工場のオーナーであると想像してください。
· スループットの最大化: 毎日できるだけ多くの自動車を組み立てます。
· 遅延を最小限に抑える: 各車両の製造時間を短縮します。
ここで、次の 3 種類のファクトリーを想像してください。
単純な工場で、多技能労働者のグループが段階的に自動車を組み立てています。 1 人の作業員がエンジンを組み立て、次の作業員が車輪を取り付け、これを 1 台ずつ行います。
何が問題なのですか?一部の作業員は待たされることが多く、同じ車両の異なる部品に同時に作業する人がいなかったため、全体的な生産性は低下していました。
フォード組立ライン [4] をご紹介します!ここでは、各作業者が 1 つのタスクに集中します。車はベルトコンベアに沿って移動し、各車が通過するたびに、専属の作業員が独自の部品を追加します。
結果はどうなりましたか?複数の自動車が同時にさまざまな組み立て段階にあり、作業員全員が忙しくしています。スループットは大幅に改善されましたが、各車両は依然として各作業員を順番に通過する必要があり、各車両の遅延は同じままです。
すべての作業員が同時に 1 台の車で作業できる魔法の工場を想像してみてください。車をあるワークステーションから次のワークステーションに移動させるのではなく、車のすべての部品が同時に製造されます。
結果はどうなりましたか?各ステップが同期して実行され、車は記録的な速さで組み立てられました。これは、スループットとレイテンシの問題を解決するための理想的なシナリオです。
さて、自動車工場については十分です。ブロックチェーンについてはどうでしょうか?高性能ブロックチェーンの設計は、組立ラインの最適化とそれほど変わらないことがわかりました。
ブロックチェーンでは、ブロックの処理は自動車の組み立てに似ています。以下に例えを示します。 · ワーカー = バリデーター リソース · 車 = ブロック · アセンブリ タスク = コンセンサス、実行、コミットの各段階 · 一度に 1 台の車だけを処理する単純な工場と同様に、一度に 1 つのブロックだけを処理するブロックチェーンでは、十分に活用されていないリソースが発生します。代わりに、現代のブロックチェーンの設計は、フォードの組立ラインのように、複数のブロックのさまざまな段階を同時に処理することを目指しています。ここで、組立ライン技術が登場します。
ブロックを順番に処理するブロックチェーンを想像してください。バリデーターは次のことを行う必要があります。
1.ブロック提案を受け取ります。
2.ブロックを実行してブロックチェーンのステータスを更新します。
3.状況について合意形成を継続します。
4.状態をデータベースに保存します。
5.次のブロックのコンセンサスを開始します。
何が問題なのですか?
· 実行と提出はコンセンサス プロセスのクリティカル パスにあります。
· 各コンセンサス インスタンスは、開始する前に前のインスタンスが完了するまで待機する必要があります。
この設定は、フォーディズム以前の工場のようなものです。労働者 (リソース) は、一度に 1 つのブロック (車) のみに集中しているため、アイドル状態になることがよくあります。残念ながら、既存のブロックチェーンの多くは依然としてこのカテゴリに分類され、スループットが低く、レイテンシが高くなります。
Diem は、実行と送信をコンセンサス ステージから分離するパイプライン アーキテクチャを導入し、コンセンサス ステージ自体もパイプライン設計を採用しています。
· 非同期実行と送信 [5]: バリデーターは最初にブロックについて合意に達し、次に親ブロックの状態に基づいてブロックを実行します。バリデーターの定足数によって署名および認証された後、状態はストレージに保存されます。
· 組立ラインコンセンサス(Jolteon[6]):移動中の組立ラインと同様に、前のコンセンサスインスタンスが完了する前に新しいコンセンサスインスタンスを開始できる。
これにより、異なるブロックが同時に異なるステージに存在できるようになるためスループットが向上し、ブロック時間がわずか 2 メッセージ遅延にまで大幅に短縮されます。ただし、Jolteon のリーダーベースの設計では、トランザクションの配布中にリーダーが過負荷になり、ボトルネックが発生する可能性があります。
Aptosは、データ配信とコンセンサスを切り離すメカニズムであるQuorum Store[7]を通じてパイプラインをさらに最適化します。コンセンサス プロトコルで大量のデータ ブロックをブロードキャストするために単一のリーダーに依存する代わりに、Quorum Store はデータ配布をメタデータの順序付けから切り離し、バリデーターがデータを非同期かつ並列に配布できるようにします。この設計では、すべてのバリデーターの合計帯域幅が活用され、コンセンサスにおけるリーダーのボトルネックが効果的に排除されます。

図: リーダーのコンセンサス プロトコルに基づいて、クォーラム ストアがリソース使用率を調整する方法。
これまでに、Aptos Blockchain はブロックチェーンの「フォード工場」を構築しました。フォードの組立ラインが自動車生産に革命をもたらしたように(異なる自動車の異なる段階が同時に実行される)、Aptos は異なるブロックの異なる段階を同時に処理します。各バリデーターのリソースが最大限に活用され、プロセスのどの部分も待機状態にならないようにします。この巧妙なオーケストレーションにより、高スループットのシステムが実現し、Aptos はブロックチェーン トランザクションを効率的かつスケーラブルに処理する強力なプラットフォームになります。

図: Aptos ブロックチェーンにおける連続ブロックのパイプライン処理。バリデーターは、連続するブロックのさまざまなステージをパイプライン化して、リソースの使用率を最大化し、スループットを向上させることができます。
スループットは重要ですが、エンドツーエンドのレイテンシ(トランザクションの送信から最終確認までの時間)も同様に重要です。支払い、分散型金融 (DeFi)、ゲームなどのアプリケーションでは、1 ミリ秒も無駄になりません。各トランザクションは、クライアント-フルノード-バリデータ通信、コンセンサス、実行、状態認証、コミット、フルノード同期という一連の段階を順番に通過する必要があるため、トラフィック量の多いイベント中に多くのユーザーが遅延を経験します。負荷が高い場合、実行や完全なノードの同期などのフェーズでレイテンシが増加します。

図: Aptos ブロックチェーンのパイプライン アーキテクチャ。この図は、クライアント Ci、フルノード Fi、バリデーター Vi を示しています。各ボックスは、トランザクション ブロックが左から右に通過する必要があるブロックチェーンのステージを表します。パイプラインは、コンセンサス(配布と順序付けを含む)、実行、認証、送信、およびフルノード同期の 5 つの段階で構成されます。
これはフォードの工場のようなものです。組み立てラインは全体のスループットを最大化しますが、各車両は各作業員を順番に通過する必要があるため、完成するまでに長い時間がかかります。ブロックチェーンのパフォーマンスを限界まで押し上げるには、これらの段階を並行して実行できる「魔法の工場」を構築する必要があります。
Zaptos[8]は、3つの主要な最適化により、スループットを犠牲にすることなくレイテンシをさらに削減します。
· 楽観的実行: ブロック提案を受け取った直後に実行を開始することで、パイプラインの待ち時間を短縮します。バリデータはブロックをすぐにパイプラインに追加し、親ブロックが完了した後に投機的に実行します。バリデーターからの提案を受け取った後、フルノードも楽観的実行を実行して状態証明を検証します。
· 楽観的コミット: ブロックが実行された直後、状態が認証される前であっても、状態をストレージに書き込みます。バリデーターが最終的にステータスを認証すると、コミットを完了するために必要なのは最小限の更新だけです。ブロックの順序が乱れた場合、一貫性を維持するために、楽観的にコミットされた状態がロールバックされます。
· 高速認証: バリデータは、コンセンサスが完了するのを待たずに、最終的なコンセンサス ラウンドで認証メッセージを並行して送信することにより、実行されたブロックのステータスの認証を事前に開始します。この最適化により、一般的なケースではパイプラインのレイテンシが 1 ラウンド短縮されます。

図: Zaptos の並列パイプライン アーキテクチャ。コンセンサス以外のステージは実際にはコンセンサス ステージ内に隠されているため、エンドツーエンドのレイテンシが削減されます。
これらの最適化により、Zaptos はコンセンサス ステージ内の他のパイプライン ステージのレイテンシを効果的に隠します。したがって、ブロックチェーンが最適なレイテンシを備えたコンセンサスプロトコルを採用すると、ブロックチェーン全体のレイテンシも最適化されます。
Aptos を高性能ベースラインとして使用し、地理的に分散した実験を通じて Zaptos のエンドツーエンドのパフォーマンスを評価しました。詳細は論文[8]を参照。
Google Cloud では、Aptos のデプロイメントに類似したコモディティ グレードのマシンを使用して、10 のリージョンに分散された 100 のバリデータと 30 のフルノードからなるグローバル分散ネットワークをシミュレートしました。

図: Zaptos ブロックチェーンと Aptos ブロックチェーンの共通パフォーマンス。
上の図は、2 つのシステムのエンドツーエンドのレイテンシとスループットの関係を比較しています。どちらも負荷が増加するとレイテンシが徐々に増加し、最大容量では急激に増加しますが、Zaptos はピークスループットまでより安定したレイテンシを示し、低負荷時にはレイテンシが 160 ミリ秒、高負荷時には 500 ミリ秒以上短縮されます。
驚くべきことに、Zaptos は実稼働レベルのメインネット環境で 20,000 TPS で 1 秒未満のレイテンシを実現しています。これは、スピードとスケーラビリティを必要とする実際のアプリケーションを可能にする画期的な技術です。

図: 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 を維持しながらレイテンシを 1 秒未満のレベルまで削減します。現代のコンピューティング アーキテクチャが並列処理を活用して効率を最大化するのと同様に、ブロックチェーンも不要な遅延を排除するために設計を継続的に最適化する必要があります。 Zaptos は、ブロックチェーン パイプラインを完全に最適化してレイテンシを最小限に抑えることで、スピードとスケールを必要とする実際のブロックチェーン アプリケーションへの道を開きます。
[1] Gene M. Amdahl、Gerrit A. Blaauw、および Frederick P. Brooks。 1964 年。「IBM System/360 のアーキテクチャ」 IBM Journal of Research and Development. https://doi.org/10.1147/rd.82.0087
[2] David DeWitt、Jim Gray。 1992 年。「並列データベース システム: 高性能データベース システムの将来」 ACM のコミュニケーション。 https://doi.org/10.1145/129888.129894
[3] Martín Abadi、Paul Barham、Jianmin Chen、Zhifeng Chen、アンディ・デイヴィス、ジェフリー・ディーン、マシュー・デヴィン 他2016 年。「TensorFlow: 大規模機械学習のためのシステム」第 12 回 USENIX オペレーティング システムの設計と実装に関するシンポジウム (OSDI)。 https://arxiv.org/abs/1605.08695
[4] 移動組立ラインと 5 ドル労働日。 https://corporate.ford.com/articles/history/moving-assembly-line.html
[5] Zekun Li、Yu Xia。 2021. DIP-213 - 分離実行。 https://github.com/diem/dip/blob/7dc44ee57bb7efe76559f05dcc6851d97e2d3149/dips/dip-213.md
[6] Rati Gelashvili、Lefteris Kokoris-Kogias、Alberto Sonnino、Alexanderシュピーゲルマンと項卓倫。 2022年。「JolteonとDitto:非同期フォールバックによるネットワーク適応型の効率的なコンセンサス」金融暗号とデータセキュリティに関する国際会議(FC)において。 https://arxiv.org/abs/2106.10362
[7] Quorum Store:Aptosブロックチェーン上でコンセンサスが水平にスケールする方法。 https://medium.com/aptoslabs/quorum-store-how-consensus-horizontally-scales-on-the-aptos-blockchain-988866f6d5b0
[8] Zhuolun Xiang、Zekun Li、Balaji Arun、Teng Zhang、Alexander Spiegelman。 202 2025.「Zaptos: ブロックチェーンのレイテンシの最適化に向けて」 arXiv プレプリント arXiv:2501.10612。 https://arxiv.org/abs/2501.10612 この記事は寄稿によるものであり、BlockBeats の見解を代表するものではありません。BlockBeats の公式コミュニティに参加しよう:
Telegram 公式チャンネル:https://t.me/theblockbeats
Telegram 交流グループ:https://t.me/BlockBeats_App
Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia