安全でスケーラブルでアップグレード可能な Web3 インフラストラクチャ

まとめ

新しいインターネット インフラストラクチャ ブロックチェーンの台頭により、開発者は数万の分散型アプリケーションを急速に展開しています。残念ながら、安定性の低さ、高コスト、低スループット、およびいくつかのセキュリティ上の問題により、ブロックチェーンはまだ広く採用されていません。 Web3 時代に広く使用されるためには、ブロックチェーン インフラストラクチャはクラウド インフラストラクチャの特性をエミュレートする必要があります。つまり、多くの分散型アプリケーションに対して、信頼性が高く、スケーラブルで、コスト効率が高く、継続的に最適化されたプラットフォームを提供する必要があります。

これらの課題に対処するために、私たちはスケーラビリティ、セキュリティ、信頼性、アップグレード可能性を中心的な設計原則として Aptos ブロックチェーンを立ち上げました。 Aptos ブロックチェーンは、過去 3 年間にわたって世界中の 350 人を超える開発者によって共同開発されました [1]。コンセンサス、スマートコントラクト設計、システムセキュリティ、パフォーマンス、分散化において新たなイノベーションを提供します。これらのテクノロジーを組み合わせることで、Web3 をより幅広いユーザーに提供するための強固な基盤が提供されます。

1. Aptos ブロックチェーンは、Move 言語をネイティブに統合して使用し、高速かつ安全なトランザクション実行を実現します [2]。 Move 言語で開発されたスマート コントラクトの正式な検証ツールである Move Prover は、コントラクトの定数と操作に対する追加の保証を提供します。このセキュリティを重視したアプローチにより、開発者は悪意のあるエンティティからソフトウェアをより適切に保護できます。

2. Aptos データ モデルにより、柔軟なキー管理とハイブリッド ホスティング オプションが可能になります。これは、署名前のトランザクションの透明性と実用的な軽量クライアント プロトコルと合わせて、より安全で信頼できるユーザー エクスペリエンスを提供します。

3. 高スループットと低レイテンシを実現するために、Aptos ブロックチェーンはトランザクション処理の主要な段階でパイプライン化されたモジュラー アプローチを使用します。具体的には、トランザクション分散、ブロックメタデータ順序付け、並列トランザクション実行、バッチストレージ、台帳検証などの操作が同時に実行されます。このアプローチでは、利用可能なすべてのハードウェア リソースが最大限に活用され、ハードウェア効率が向上し、高度な並列処理が実現されます。

4. 並列実行エンジンでは、読み書きする前に読み書きするデータを取得する必要があり、トランザクションのアトミック性が損なわれますが、Aptos ブロックチェーンは開発者にそのような制限を設けません。これにより、アプリケーションに高いスループットと低いレイテンシが提供され、複雑なトランザクションのアトミック性が保証されることで開発が簡素化されます。

5. Aptos モジュラー アーキテクチャはクライアントの柔軟性を保証し、頻繁なアップグレードに合わせて最適化されています。さらに、新しい技術革新を迅速に展開し、新しい Web3 ユースケースをサポートするために、Aptos ブロックチェーンは組み込みのオンチェーン変更管理プロトコルを提供します。

6. Aptos ブロックチェーンは、単一のバリデーターのパフォーマンスを超えた将来の取り組みを実験しています: そのモジュラー設計と並列実行エンジンはバリデーターの内部シャーディングをサポートし、同種の状態のシャーディング (同種の状態のシャーディング) は水平スループットを提供します。ノードオペレーターにさらなる複雑さをもたらします。

[1] 法的免責事項: このホワイト ペーパーとその内容は、トークンの販売を提案したり、トークンの購入を誘導したりするものではありません。このホワイトペーパーは、一般からのフィードバックやコメントを受け入れるためにのみ公開されています。この文書のいかなる内容も、Aptos ブロックチェーンまたはそのトークン (存在する場合) がどのように価値を開発、利用、または蓄積するかについて保証または約束として解釈されるべきではありません。アプトスは現在の計画の概要を示しているだけであり、計画は同社の裁量で変更される可能性があり、その成功は管理外の多くの要因に依存します。このような将来に関する記述には必然的に既知および未知のリスクが伴い、将来の期間における実際の業績および結果が、本ホワイトペーパーで記述または示唆されたものと大きく異なる可能性があります。アプトスは計画を更新する義務を負いません。実際の結果と将来の出来事は大きく異なる可能性があるため、ホワイトペーパーの記述が正確であるという保証はありません。今後の声明に過度に依存しないでください。

1. 前文

Web2 時代では、通信、ソーシャル メディア、金融、ゲーム、ショッピング、オーディオおよびビデオ ストリーミング メディアなどのサービスは、ユーザー データの権限を持つ集中企業 (Google、Amazon、Apple、Meta など) によって提供されます。これらの企業は、アプリケーション固有のソフトウェアを活用して、対象となるユースケースに合わせて開発インフラストラクチャを最適化し、クラウド インフラストラクチャを使用してそれらのアプリケーションをユーザーに展開します。クラウド インフラストラクチャは、仮想マシン (VM) のレンタルや、世界中のデータ センター (AWS、Azure、Google Cloud など) で実行されるベアメタル ハードウェアなどの仮想または物理インフラストラクチャ サービスへのアクセスを提供します。その結果、数十億のユーザーに拡張できる Web2 インターネット サービスの構築が、今日ほど簡単になったことはありません。ただし、Web2 では、ユーザーが集中管理されたエンティティを明示的に信頼する必要があり、この要件はますます社会的懸念を引き起こしています。

この懸念に対処するために、新しいインターネット時代、Web3 が始まりました。インターネットの Web 3 バージョンでは、ブロックチェーンが分散型の不変台帳を提供するために登場し、ユーザーが制御中間者や集中管理されたエンティティを信頼する必要なしに、安全かつ確実に相互に通信できるようになります。 Web2 インターネット サービスとアプリケーションがクラウド インフラストラクチャに依存するのと同様に、分散型アプリケーションはブロックチェーンを分散型インフラストラクチャ層として使用して、世界中の何十億人ものユーザーにアクセスできます。

しかし、多くのブロックチェーンが存在するにもかかわらず、Web3 はまだ広く採用されていません [3]。テクノロジーは業界を進歩させ続けていますが、既存のブロックチェーンは依然として信頼性が低いです。高額な取引手数料、低いスループット、セキュリティ問題による頻繁な資産損失、リアルタイム応答のサポートの欠如。クラウド インフラストラクチャが Web2 サービスを強化し、何十億人ものユーザーにアクセスできるようになったのと比較すると、ブロックチェーンはまだ Web3 アプリケーションを同じレベルまで引き上げていません。

2. アプトスビジョン

Aptos のビジョンは、Web3 に主流の採用をもたらし、分散型アプリケーションのエコシステムを強化して現実世界のユーザーの問題点を解決できるブロックチェーンを提供することです。私たちの使命は、柔軟なモジュール式ブロックチェーン アーキテクチャを提供することで、ブロックチェーンの信頼性、セキュリティ、パフォーマンスを新たな高みに引き上げることです。アーキテクチャは、頻繁なアップグレード、最新テクノロジーの迅速な導入、新たなユースケースに対するクラス最高のサポートをサポートする必要があります。

私たちは、コミュニティ ガバナンスによって運営される分散型で安全かつスケーラブルなネットワークを構築することを構想しています。世界中でインフラストラクチャの需要が高まるにつれ、ブロックチェーン コンピューティング リソースは、それらの需要を満たすために水平方向および垂直方向に拡張されています。新しい使用例や技術の進歩が現れると、ネットワークはユーザーを混乱させることなく頻繁かつシームレスにアップグレードする必要があります。ユーザーがインフラストラクチャ関連の問題に注意を払わないようにします。開発者とユーザーは、キーの回復、データ モデリング、スマート コントラクト標準、リソース使用量のトレードオフ、プライバシー、構成可能性に関するさまざまなオプションにアクセスできます。ユーザーは、自分の資産が安全で、利用可能であり、事実上無料でアクセスできると確信しています。誰でも、世界中の信頼できない当事者と不変のトランザクションを安全かつ簡単に実行できます。ブロックチェーンはクラウド インフラストラクチャと同じくらいユビキタスになるでしょう。

このビジョンを実現するには、テクノロジーを大幅に進歩させる必要があります。過去 3 年間にわたる Diem ブロックチェーン (Aptos ブロックチェーンの前身) の開発、アップグレード、展開の経験により、ネットワークがクライアントを中断することなく継続的にプロトコルをアップグレードできることが実証されました [4]。 2020 年初頭、Diem メインネットは複数のウォレット プロバイダーを備えた 12 ノードにデプロイされました。翌年、私たちのチームはコンセンサス プロトコルとコア フレームワークに対して 2 つの大きなアップグレードを実行しました。どちらのアップグレードも、ユーザーにダウンタイムを与えることなく完了しました。 Aptos ブロックチェーンでは、セキュリティ、透明性、頻繁なアップグレードを Diem ブロックチェーンからインスピレーションを得たコア機能として採用しながら、テクノロジー スタックに一連の根本的な改善を加えました。私たちは、トランザクション処理の新しい方法 (セクション 7 で説明) と、分散化およびネットワーク ガバナンスへの新しいアプローチに特に重点を置いています。

Aptos ブロックチェーンの継続的な改善と開発に伴い、プロトコルと設計の更新を継続し、その時点での最新バージョンのホワイト ペーパーをリリースします。以下では、Aptos ブロックチェーンの現状と将来の計画について説明します。

3. 概要

図 1 に示すように、Aptos ブロックチェーンは、ビザンチン フォールト トレランス (BFT) とプルーフ オブ ステーク (POS) コンセンサス メカニズムを使用してユーザー トランザクションを受信して処理するバリデーター (Validators) のグループで構成されています。トークン所有者は、選択したバリデーター (Validator) でトークンをロックまたはプレッジします。各バリデーターのコンセンサス投票重みは、ステークされたトークンの量に比例します。バリデーターはアクティブになって、コンセンサスの決定に参加できます。同様に、検証ノードに十分な誓約トークンがない場合、バリデータセットからローテーションされる場合、ブロックチェーン状態の同期時にオフラインになる場合、または履歴パフォーマンスが低いためにコンセンサスプロトコルがコンセンサスへの参加を拒否する場合、バリデータは非アクティブになることもあります。

クライアントは、トランザクションを送信したり、ブロックチェーンの状態と履歴をクエリしたりする必要があるシステムの一部です。クライアントは、バリデーターによって署名および検証されたデータをダウンロードして検証することを選択できます。 *フル ノード*は、ネットワーク内のバリデータ ノードまたは他のフル ノードからトランザクションとブロックチェーンの状態を複製するクライアントです。十分なストレージ容量を取り戻すために、必要に応じて一部のトランザクション履歴とブロックチェーン状態レコードを削除する場合があります。ライト クライアントは、現在の検証ノードのセットのみを維持し、完全なノードから部分的なブロックチェーンの状態を安全にクエリできます。ウォレットはライト クライアントの一般的な例です。

安全で高速、信頼性が高く、スケーラブルな Web3 インフラストラクチャを広く普及させるためのニーズを満たすために、Aptos ブロックチェーンは次の中心的な設計原則に基づいて構築されています。

• 新しいスマート コントラクト プログラミング言語 Move [5] により、オンチェーン ロジックの高速かつ安全な実行、およびシンプルな監査可能性と手順分析可能性が実現します。 Aptos ブロックチェーンは Diem ブロックチェーンを継承し、Move の開発を続けています。
• バッチ化、パイプライン化、並列化されたトランザクション処理方法により、非常に高いスループットと低い遅延が実現されます。
• 読み書きされるデータを事前に識別し、トランザクションの原子性を破壊する既存の並列実行エンジンとは異なり、Aptos ブロックチェーンは、並列実行エンジンとして Block-STM テクノロジーを革新的に使用し、任意の複雑なトランザクションの原子性を効果的にサポートします。
• 高速なステーキングバリデーターのローテーションとバリデーターの評判追跡を通じて、パフォーマンスと分散型ガバナンスを最適化します。
• アップグレード可能性と構成可能性は最も重要な設計原則であり、インフラストラクチャが新しいユースケースと最新のテクノロジーを受け入れることができます。
• 脅威モデリングやシームレスな導入のためのモジュール設計などの厳格なコンポーネントレベルのテストに合格し、高いセキュリティと運用の信頼性を保証します。
• 分散型の水平スループットのスケーラビリティを保証します。プログラムとデータ モデルから派生したシャーディングは、水平スケーリングにおける重要な概念です。

第 4 章では、開発者が Move 言語を通じて Aptos ブロックチェーンと対話する方法について説明します。第 5 章では論理モデルについて説明します。第 6 章では、Aptos ブロックチェーンが強力な検証方法を通じて安全なユーザー エクスペリエンスを実現する方法について詳しく説明します。第 7 章では、パイプライン化、バッチ処理、並列化に関する主要なパフォーマンスの革新について説明します。第 8 章では、さまざまなタイプのクライアントが他のノードと状態を同期するためのさまざまなオプションについて詳しく説明します。第 9 章では、コミュニティの所有権とガバナンスに関する計画について説明します。最後に、第 10 章では、分散化を維持しながらの将来のパフォーマンスの方向性について説明します。

4. プログラミング言語を移動する

Move は、セキュリティと柔軟性に重点を置いた新しいスマート コントラクト プログラミング言語です。 Aptos ブロックチェーンは、Move のオブジェクト モデルを使用して台帳状態を表し (セクション 5.5 を参照)、Move コード (モジュール) を使用して状態遷移のルールをエンコードします。ユーザーによって送信されるトランザクションには、新しいモジュールの公開、既存のモジュールのアップグレード、モジュールで定義されたインターフェイス関数の実行、およびモジュールのパブリック インターフェイスと直接対話できるスクリプトが含まれます。

Move エコシステムには、コンパイラー、仮想マシン、その他多くの開発ツールが含まれています。 Move は、線形型などの概念を通じてデータの所有権を明確にする Rust プログラミング言語からインスピレーションを得ており、リソースの希少性、保存、アクセス制御を重視しています。 Move モジュールは、各リソースのライフサイクル、ストレージ、およびアクセス モードを定義します。これにより、コインなどのリソースは適切な認証情報なしでは鋳造できず、二重に使用したり、消滅したりすることはありません。

信頼できないコードが存在する場合でも、Move はバイトコード検証ツールを利用して型とメモリの安全性を確保できます。より信頼性の高いコードの記述を支援するために、Move には、指定された仕様に従って Move プログラムの機能の正しさを検証できる型検証ツール Move Prover [6] が含まれており、この型検証機能は Move 言語に統合されています。

ユーザーアカウントと対応するアカウントの内容に加えて、分散台帳の状態には、Aptos ブロックチェーンのオンチェーン構成も含まれます。このネットワーク構成には、現在アクティブなバリデーターのセット、誓約の属性、Aptos ブロックチェーン内のさまざまなサービスの構成が含まれます。 Move のモジュールのアップグレード機能と完全なプログラマビリティのサポートにより、シームレスな構成変更が可能になるだけでなく、Aptos ブロックチェーン自体へのアップグレードのサポートも可能になります (これらのタイプのアップグレードはどちらもプライベート メインネットで複数回実行されており、ダウンタイムの記録はありません)。

Aptos チームは、Web3 の幅広いユースケースをサポートするために、Move 機能をさらに追加しました。以下のセクション 5.5 で説明するように、Aptos ブロックチェーンにより、きめ細かいリソース制御が可能になります。この機能は、並列実行を効果的にサポートするだけでなく、データへのアクセスと変更のコストをほぼ固定します。さらに、Aptos ブロックチェーンは、きめ細かいストレージ上に構築されたテーブル サポートを提供し、これにより大規模なデータ セット (たとえば、NFT の大規模なコレクション) を単一のアカウントに実装できます。同時に、Aptos は、完全にオンチェーンに組み込まれた共有アカウントまたは自動アカウントをサポートします。これにより、複雑な分散型自律組織 (DAO) がアカウントを共有し、それらのアカウントを異種リソースのコレクションのコンテナとして使用できるようになります。

5. 論理モデル

Aptos ブロックチェーンの台帳状態は、チェーン上のすべてのアカウントの状態を表します。台帳ステータスは、現在のシステムで実行されたトランザクションの数に対応するバージョン分割に符号なし 64 ビット整数を使用します。誰でもトランザクションを Aptos ブロックチェーンに送信して、台帳の状態を変更できます。トランザクションが実行されると、トランザクション出力が生成されます。トランザクションの出力は、台帳の状態 (書き込みセットと呼ばれる)、結果のイベントのセット (セクション 5.1.1 を参照)、消費されたガス、および実行されたトランザクションの状態を操作するための 0 個以上の操作で構成されます。

5.1 トランザクション

署名されたトランザクションには次の情報が含まれます。

• トランザクション認証子: 送信者は、1 つ以上のデジタル署名を含むトランザクション認証子を使用して、トランザクションが認証されたことを検証します。
• 送信者アドレス: 送信者のアカウント アドレス。
• ペイロード: ペイロードは、オンチェーン上の既存のインターフェイス関数を参照するか、インライン バイトコードとして実行される関数 (スクリプトと呼ばれる) を含みます。さらに、入力パラメータのセットはバイト配列にエンコードされます。ピアツーピアトランザクションの場合、入力パラメータには受信者の情報と送金金額が含まれます。
• ガス価格 (指定された通貨/ガス単位): これは、送信者がトランザクションを実行するために支払ってもよいガスの単位当たりの金額です。ガス料金とは、コンピューティング、ネットワーク、ストレージの料金の支払いを指します。気体は、固有の実際の値を持たない抽象的な計算単位です。
• 最大ガス量: 最大ガス量は、トランザクションが中止されるまでに消費できるガスユニットの最大数です。少なくとも、ガス単価にアカウント内の最大ガスユニット数を乗じた残高がなければなりません。そうでない場合、トランザクションは検証プロセス中に終了します。
• SequenceNumber: トランザクションのシーケンス番号。トランザクション内のシーケンス番号は、トランザクションの実行時に送信者のアカウントに保存されているシーケンス番号と一致する必要があります。トランザクションが正常に実行されると、リプレイ攻撃を防ぐためにアカウントのシーケンス番号が増分されます。
• 有効期限: トランザクションが無効になるまでのタイムスタンプ。
• ブロックチェーン ID: ブロックチェーン内のトランザクションの有効性を識別し、ユーザーに署名エラーに対するさらなる保護を提供します。

各バージョン i で、状態変化はタプル (Ti、Oi、Si) で表され、それぞれトランザクション、トランザクション出力、トランザクション後の台帳状態が含まれます。決定論的関数Applyを指定すると、トランザクションTi、台帳状態Si-1を実行し、トランザクション出力Oiと新しい台帳状態Siを生成します。つまり、Apply(Si-1*,Ti*) → 〈Oi,Si〉となります。

5.1.1 イベント

イベントはトランザクションの実行中に発行されます。各 Move モジュールは独自のイベントを定義し、実行時にイベントを発行するタイミングを選択できます。たとえば、送金中に、送信者のアカウントと受信者のアカウントはそれぞれ SentEvent と ReceivedEvent を発行します。データは台帳に保存され、Aptos ノードを通じてクエリできます。登録された各イベントには、イベントの詳細をクエリするために使用できる一意のインデックスがあります。

同じイベント インデックスに複数のイベントが発行されると、イベント ストリームが生成されます。イベント ストリームは、各エントリに 0 から増加する番号、タイプ、およびデータが含まれるイベントのリストです。すべてのイベントは何らかのタイプで定義する必要があります。特にジェネリックを使用する場合、同じまたは類似のタイプによって複数の異なるイベントが定義される可能性があります。イベントには関連データがあります。 Move モジュールの開発者にとっての一般原則は、データの変更やイベントの送信など、トランザクションの実行前後に発生する基礎となるリソースの変更を理解するために、必要なデータをすべて含めることです。

トランザクションはイベントを生成することのみができ、イベントを読み取ることはできません。この設計により、(以前に生成されたイベントなどの履歴情報ではなく) 現在のトランザクションの現在の状態と入力のみを使用してトランザクションを実行できます。

5.2 アカウント

各アカウントは、アカウント アドレスと呼ばれる一意の 256 ビット値によって識別されます。元帳状態で新しいアカウントを作成します (セクション 5.5 を参照)。これは、既存のアカウントがトランザクションを送信するときに create_account(addr) Move 関数を呼び出すことで作成できます。これは通常、トランザクションがまだ作成されていないアカウント アドレスに Aptos トークンを送信しようとしたときに発生します。便宜上、Aptos は転送 (from、to、amount) 関数もサポートしています。この関数は、転送前にアカウントが存在しない場合にデフォルトでアカウントを作成します。

新しいアカウントを作成するには、ユーザーはまず署名キーのペア (vk,sk) を生成します。次に、署名スキーム識別子 (ssid) が公開キー vk と結合され、暗号化されたハッシュ H: addr=H(vk, ssid) を通じて特定の署名スキームの新しいアカウント アドレスが取得されます。

アドレス addr で新しいアカウントを作成した後、ユーザーは、署名する秘密鍵 sk を使用して、addr のアカウントから送信されるトランザクションに署名できます。ユーザーは、sk をローテーションして、sk を積極的に変更したり、秘密鍵の漏洩の可能性に対応したりすることもできます。アカウント アドレスは公開キーからのみ作成されるため、秘密キーを変更する操作ではアカウント アドレスは変更されません。

Aptos ブロックチェーンは、アカウントを現実世界のアイデンティティにリンクしません。ユーザーは複数のキーペアを生成することで複数のアカウントを作成できます。同じユーザーによって管理されるアカウントは、本質的に相互にリンクされていません。

ただし、資産管理を容易にするため、1 人のユーザーが 1 つのウォレットで複数のアカウントを管理できます。この柔軟性により、ユーザーに匿名性が提供され、将来のバージョンでは、より多くのプライバシー保護プリミティブ (プライバシー保護プリミティブ) を使用するよう努めています。セクション 7.4 で説明したように、ユーザーまたはユーザーのグループが所有する複数のアカウントも、実行の同時実行性を高める手段を提供します。

5.3 モジュールの移動

Move モジュールには、データ型 (構造体) とプロシージャを宣言する Move バイトコードが含まれています。これは、モジュールを宣言するアカウントのアドレスとモジュール名によって識別されます。たとえば、図 2 の最初の通貨モジュールの識別子は 0x1::coin です。図 2 のウォレット モジュールに示すように、モジュールはチェーン上の他のモジュールに依存することができ、他のモジュールのコードは再利用できます。

モジュールはアカウント内で一意である必要があります。つまり、モジュール名は各アカウントで一意のままである必要があります。たとえば、図 2 のアドレス 0x1 のアカウントは、coin という名前の別のモジュールを要求できません。一方、アドレス 0x3 のアカウントは、coin という名前のモジュールを宣言でき、このモジュールの識別子は 0x3:coin になります。 0x1::coin::Coin と 0x3::coin::Coin は異なるタイプであり、互換的に使用することはできず、共通のモジュール コードを共有することもできないことに注意してください。対照的に、0x1::coin::Coin と 0x1::coin::Coin> は同じジェネリック型の異なるインスタンスであり、互換的に使用することはできませんが、共通のモジュール コードを共有できます。

同じアドレスにあるモジュールは同じ *パッケージ (パッケージ)* にマージされます。 このアドレスの所有者は、バイトコードとパッケージのメタデータを含むパッケージ全体をオンチェーンで公開します。パッケージのメタデータは、パッケージがアップグレード可能であるか不変であるかを決定します。アップグレード可能なソフトウェア パッケージの場合、アップグレードが許可される前に互換性チェックが実行されます。既存のインターフェイス機能は変更できず、リソースをメモリに保存することもできません。ただし、アップグレードにより新しい機能やリソースが追加される場合があります。

Aptos フレームワークは、定期的にアップグレード可能なモジュール パッケージとして定義される Aptos ブロックチェーンのコア ライブラリと構成で構成されます (セクション 9.2 を参照)。

図 3: オンチェーン データの例

5.4 リソース

モジュールと同様に、アカウント アドレスにもデータ値を関連付けることができます。各アカウント アドレスでは、データ値はそのタイプによって決定され、各アカウントでは、各タイプのデータ値が一意のままである必要があります。図 3 を例として使用すると、アドレス 0x50 は単一の値を保持します。0x3::coin::Coin は完全修飾型です。 0x3 は Coin モジュールのアドレス、Coin はモジュールの名前、Coin はデータ型の名前です。汎用データ値も使用でき、異なる汎用インスタンスは異なる型として扱われます。これはスケーラビリティにとって重要であり、異なるインスタンスが同じ関数コードを共有できるようになります。

値の変更、削除、公開のルールは、データ型を定義するモジュールにエンコードされます。 Move のセキュリティおよび検証ルールにより、他のコードまたはエンティティが他のモジュールで定義されたデータ型のインスタンスを直接作成、変更、または削除することが防止されます。

アドレスの下に各タイプのトップレベルの値を 1 つだけ含めるのは制限的であるように思えます。ただし、開発者はメンバー変数と同じ型のデータを持つ異なるラッパー型を定義することで制限を回避できるため、これは実際には問題になりません。 Wallet 構造 (図 3) は、ラッパー型の使用方法の例です。

すべてのデータ型をオンチェーンに保存できるわけではないことにも注意してください。データ インスタンスがトップレベルの値として認定されるためには、データ型に Key 機能が必要です。また、ネストされた値には Store 機能が必要です。 2 つの機能を持つデータ型はリソースとも呼ばれます。

5.5 台帳のステータス

移動仮想マシン (Move VM) の観点から見ると、各アカウントは一連の値とキーと値のデータ構造で構成されます。これらのデータ構造はエントリと呼ばれ、Binary Normalized Serialization format (BCS) で保存されます。このデータ構造設計により、開発者は、少量のデータが多数のアカウントにコピーされる場合に効率的に実行できるスマート コントラクトを作成できます。また、大量のデータが集中している場合に効率的に実行できるスマート コントラクトを作成することもできます。アカウントの数が少ない。移動モジュールはアカウント データと同様に保存されますが、別の名前空間に保存されます。 Genesis 台帳の状態は、ブロックチェーンが初期化されるときのアカウントの初期セットとそれらの関連状態を定義します。

起動時には、Aptos ブロックチェーンは単一の台帳状態で表されます。ただし、使用量が広がりテクノロジーが進化するにつれて、Aptos はスループットを向上させ (つまり、複数の台帳状態を有効にし)、シャード間で資産を移動またはアクセスするトランザクションをサポートするためにシャードの数を拡張します。各台帳状態は、特定のシャードのすべてのオンチェーン資産を維持し、同じアカウント モデルと、きめ細かいキーと値のデータ ストレージを提供して、ストレージ アクセスにほぼ固定のコストを提供します。

6. 安全なユーザーエクスペリエンス

何十億ものインターネット ユーザーにリーチするには、Web3 のユーザー エクスペリエンスが安全かつ便利でなければなりません。このセクションでは、この目標を達成するための Aptos ブロックチェーンのいくつかの革新について説明します。

6.1 取引実行可能性の保護

トランザクションに署名するということは、署名者がブロックチェーンにそのトランザクションを送信して実行することを許可することを意味します。場合によっては、ユーザーが注意せずに、または操作されていることに気づかずにトランザクションに署名することがあります。このリスクを軽減するために、Aptos ブロックチェーンはトランザクションの実行可能性に制限を設け、署名者が無限の確認操作に拘束されるのを防ぎます。現在、Aptos は、送信者のシリアル番号、トランザクションの有効期限、指定されたチェーン ID という 3 つの異なる保護手段を提供しています。

トランザクションのシーケンス番号は、送信者のアカウントごとに 1 回だけ送信できます。したがって、送信者が現在のアカウントのシーケンス番号 ≥ トランザクション t のシーケンス番号を検出した場合、t はすでにコミットされているか、t は決してコミットされません (t によって使用されるシーケンス番号はすでに別のトランザクションによって取得されているため)。

ブロックチェーン時間は、高精度かつ高頻度 (通常は 1 秒未満) で進められます。詳細については、セクション 7.3.1 を参照してください。ブロックチェーン時間がトランザクション t の有効期限を超える場合、やはり、t はコミットされたか、t は決してコミットされません。

各トランザクションには割り当てられたチェーン ID があり、異なるブロックチェーン環境間 (例: テストネットとメインネット間) の悪意のあるエンティティによるリプレイ攻撃を防ぎます。

6.2 移動ベースの鍵管理

セクション 5.2 で述べたように、Aptos アカウントはキー ローテーション (キー ローテーション) をサポートしています。これは、秘密キーの漏洩、リモート攻撃、および既存の暗号アルゴリズムの将来のクラッキングのリスクを軽減する重要な機能です。さらに、Aptos アカウントは新しいハイブリッド カストディ モデルをサポートするのに十分な柔軟性を備えており、ユーザーはアカウントの秘密キーをローテーションする機能を 1 人以上のカストディアンやその他の信頼できるエンティティに委任できます。次に、Move モジュールを通じてポリシーが定義され、これらの信頼されたエンティティが特定の状況下でキーをローテーションできるようになります。たとえば、エンティティは多くの信頼できる関係者が保持する kout-of-n マルチシグ キーである可能性があり、ユーザー キーが紛失した場合にキー回復サービスを提供します (たとえば、ビットコインの 20% が現在アカウントにロックされています [7])。 。

さらに、多くのウォレットは、クラウドを利用した秘密鍵、マルチパーティ計算、ソーシャルリカバリなどのさまざまな鍵回復スキームを提供していますが、これらのスキームはブロックチェーンの実装（つまり、オフチェーン）に基づいていません。したがって、各ウォレットは独自の鍵管理スキームを実装する必要があり、ユーザーにとって鍵管理はブラックボックスになります。それどころか、Aptos のキー管理機能は、完全かつ透過的なキー管理操作を提供すると同時に、ウォレット キー管理ソリューションの実装の難しさを大幅に軽減します。

6.3 事前署名されたトランザクションの透明性

現在、ウォレットは、署名されたトランザクションに対してほとんど不透明です。そのため、ユーザーは悪意のある取引に騙されることが多く、その結果、資金の損失や一連の深刻な結果が発生します。チェーン上の各トランザクションのデータをクエリできるブロックチェーンでも、この損失を避けることはできません。現在、ユーザーを保護する手段がほとんど導入されていないため、ユーザーはさまざまな攻撃にさらされています。

この問題を解決するために、Aptos エコシステムはトランザクション実行前サービスを提供します。つまり、トランザクションの結果 (人間が判読可能な形式) が、ユーザーが署名する前にユーザーに提供されます。 Aptos は、トランザクション事前実行サービスと既知の攻撃や悪意のあるスマート コントラクトを組み合わせることで、不正行為の削減に役立ちます。さらに、Aptos を使用すると、ウォレットが実行中にトランザクションに制限を課すことができます。これらの制限に違反すると、悪意のあるアプリケーションやソーシャル エンジニアリング攻撃からユーザーをさらに保護するためにトランザクションが中止されます。

6.4 実用的なライトクライアントプロトコル

API プロバイダーの TLS/SSL 証明書に依存してブロックチェーン クライアントとサーバー間の信頼を確立するだけでは、クライアントを適切に保護できません。有効な証明書が存在する場合でも、ウォレットとクライアントは、提供されたデータの信頼性と完全性を保証できません。したがって、API プロバイダーは虚偽または悪意のあるブロックチェーン データを返し、第三者を欺き、二重支払い攻撃を実行する可能性があります。

図 4: トランザクション処理ライフサイクルのすべてのフェーズは完全に独立しており、並列化可能

これを防ぐために、Aptos は、ウォレットとクライアントが信頼できないサードパーティサーバーから提供されたデータの有効性を検証するために使用できる、proof-of-state およびライトクライアント検証プロトコルを提供します。さらに、セクション 7.6.2 で説明されているように、ライト クライアントは、タイムスタンプ ベースの状態証明を使用して、ネットワーク構成の変更 (*エポック変更)* を追跡することも、現在信頼されているノード (*アンカー)* から同期することもできます。 state [8]、アカウントの状態をリアルタイム (例: 数秒以内) に維持します。 Aptos は、高頻度のタイムスタンプと低コストの状態証明により、安全なサービスをクライアントに提供します。

さらに、Aptos ノードは豊富な高性能ストレージ インターフェイスも提供しており、将来的にはこれらのインターフェイスをさらに微調整した後、サブスクリプション チェーン上の特定のデータとアカウントの証明をサポートする予定です。これにより、ライト クライアントは将来、完全なノードを実行したり、大量のトランザクションを処理したりすることなく、検証可能な最小限のデータのみを保持することができます。

7. 合理化されたバッチおよび並列トランザクション処理

スループットを最大化し、同時実行性を高め、エンジニアリングの複雑さを軽減するために、Aptos ブロックチェーンのトランザクション処理プロセスはさまざまな段階に分割されています。各ステージは完全に独立しており、最新のスーパースカラ プロセッサ アーキテクチャと同様に、独立して並列化できます。これにより、パフォーマンスに大きなメリットがもたらされるだけでなく、Aptos ブロックチェーンが新しいバリデータとクライアントの対話モデルを提供できるようになります。例えば：

• 特定のトランザクションが予約されたトランザクションのバッチに含まれる場合、クライアントに通知されます。保留中で有効なトランザクションは、通常、すぐにコミットされます。
• 予約されたトランザクションのバッチが注文されると、クライアントに通知されます。したがって、実行するトランザクションの結果を決定する際の遅延を減らすために、クライアントは、リモート検証ノードが実行を完了するのを待つ代わりに、ローカルでトランザクションを実行できます。
• クライアントは、検証者が認証されたトランザクションを実行するのを待ってから、完了したトランザクションのステータスを同期することを選択できます (セクション 8 を参照)。

Aptos モジュール設計は、開発速度の向上とリリース サイクルの短縮に役立ち、開発者はシステム全体ではなく個々のモジュールを最適化できます。同様に、モジュール設計により、バリデーターを拡張するための構造化されたパスが提供され、バリデーターが複数のマシンのコンピューティング、ネットワーク、およびストレージのリソースを利用できるようになります。図 4 は、トランザクション処理ライフサイクルのさまざまな処理フェーズを示しています。

7.1 バッチ処理

バッチ処理は、Aptos 処理のあらゆる段階で重要な効率の最適化です。トランザクションをブロードキャストするとき、バリデーターはトランザクションをバッチにグループ化し、コンセンサスフェーズ中にバッチはブロックにマージされます。実行、保管、台帳認証の各フェーズでもバッチ操作が行われ、並べ替え、操作 (二重計算や署名検証など) の削減、および並列実行の機会が提供されます。

トランザクションをバッチ処理すると、トランザクションを伝播する前にバッチがいっぱいになるまで 200 ミリ秒待機するなど、少量の遅延が発生する場合があります。ただし、バッチ処理の最大待機時間と最大バッチ サイズは構成可能であり、分散ネットワークで遅延と効率を自動的に最適化できます。バッチ処理により、悪意のあるクライアントによるサービス拒否 (DoS) 攻撃を回避しながら、トランザクションの手数料市場の効率的な優先順位付けが可能になります。

7.2 連続トランザクションブロードキャスト

Narwhal & Tusk [9] の主な観点によれば、Aptos におけるトランザクションの伝播とコンセンサスは切り離されています。バリデーターは、利用可能なすべてのネットワーク リソースを利用しながら、トランザクションのバッチを常に相互に転送します。検証者 v によって配布された各バッチは永続化され、署名されたバッチ ダイジェストが v に送り返されます。バッチダイジェスト上のすべての 2f + 1 ステーク重み付け署名は、セクション 7.3 で定義されたコンセンサス要件に従って、Proof of Availability (PoAv) を形成します。このような証明 (PoAv) は、少なくとも f+1 の重み付けされた正直なバリデーターがバッチを保存していることを保証するため、すべての正直なバリデーターが実行前にバッチを取得できるようになります。

保留中のトランザクションが無制限に存在すると、DoS 攻撃が発生し、バリデーター ノードがストレージ不足になってクラッシュする可能性があります。これを防ぐために、トランザクションの各バッチにはタイムスタンプが関連付けられています。バッチのタイムスタンプにより、バリデーターによる効率的なガベージ コレクションが可能になります。さらに、単一バリデータ ノードのクォータ メカニズムも、最も極端なケース (ビザンチン攻撃の可能性など) が発生した場合でも、スペースが枯渇しないように設計されています。同時に、バッチ内のデータ量には制限があり、Aptos は永続ストレージ内のデータ サイズを検証します。最後に、トランザクション キャッシュと冗長トランザクション データのクリーニングの最適化により、ストレージ コストが削減されるだけでなく、並列実行エンジンの高パフォーマンスの統合も保証されます。

7.3 ブロックメタデータの並べ替え

コンセンサス速度の遅さが、ブロックチェーンの高スループットと低レイテンシの主なボトルネックであるという誤解がよくあります。 Aptos ブロックチェーンの主要な革新の 1 つは、トランザクションの伝播、トランザクションの実行/保存、台帳の認証など、プロトコルに関連しないタスクをコンセンサス段階から切り離したことです。トランザクションの伝播をコンセンサスフェーズから切り離すことで、非常に低い帯域幅 (ブロックメタデータとプルーフのみ) で注文を実行できるため、トランザクションのスループットが高く、待ち時間が最小限に抑えられます。

現在、Aptos ブロックチェーンは、楽観的に応答する BFT コンセンサス プロトコルである DiemBFTv4 [10] の最新バージョンを使用しています。通常、コンセンサスには 2 回のネットワーク ラウンドトリップのみが必要であり (ネットワーク全体のラウンドトリップ時間は通常 300 ミリ秒未満です)、異常なバリデータはリーダー レピュテーション メカニズムを通じて動的に調整されます [11]。オンチェーン リーダーの評判メカニズムは、「ウィンドウ期間」中にブロックの送信に成功したバリデーターの評判を高め、参加しなかったバリデーターを降格します。この新しいメカニズムにより、分散システムのパフォーマンスが大幅に向上し、ノードに適切なインセンティブが提供され、非アクティブなバリデータがスループットとレイテンシに与える影響が最小限に抑えられます。

DiemBFTv4 は、部分同期下でのライブネスと非同期下でのセキュリティを保証します。合計バリデーター ステークが 3f + 1 以上の場合、ステーク重み付けされた間違ったバリデーターが最大で f 個存在する可能性があります。 2019年以来、DiemBFTv4は数十のノードオペレーターとマルチウォレットエコシステムによる広範なテストを複数回繰り返してきました。また、私たちは最近の研究 (例: Bullshark [12]) や、ブロック履歴と関連する通信に依存してブロック メタデータの順序とファイナリティを決定する他のプロトコルを実験しています。

図 5 に示すように、コンセンサス ブロックと提案タイムスタンプはリーダーによって提案され、他のバリデーターによって同意されます。各コンセンサス ブロックには、バッチのメタデータとプルーフのみが含まれることに注意することが重要です。 PoAV は、ブロックのメタデータの順序付け後の実行段階でトランザクションのバッチが利用可能であることを保証するため、コンセンサス ブロックでは実際のトランザクションは必要ありません (セクション 7.2 を参照)。検証者は、証明が検証され、ブロックのメタデータ基準が満たされた後、リーダーの提案に投票できます（たとえば、提案のタイムスタンプがブロックの有効期限を超えることはできません）。

7.3.1 ブロックチェーン時間

Aptos ブロックチェーンは、提案された各ブロックとそのブロック内のすべての対応するトランザクションに、合意されたおおよその物理タイムスタンプを割り当てます。このタイムスタンプは、多くの重要な使用例をサポートします。例えば：

• スマート コントラクトの時間関連ロジック。たとえば、開発者は、オークションのすべての入札を木曜日の正午までに受信する必要があるようにコード化したいと考えています。
• オラクルはオンチェーン データを公開するため、イベントを関連付けて実際のデータからのレイテンシを処理するには、正確で信頼できるオンチェーン タイムスタンプが必要です。
• クライアントは、ブロックチェーン上で自分がどの程度最新であるかを知ることができます。セキュリティ上の理由から、古いデータやリモート攻撃を避けるために、クライアントはアカウントの状態が更新されたときの高精度のタイムスタンプにアクセスできる必要があります。
• 信頼できるタイムスタンプを使用してブロックチェーンを監査すると、法的に強制された支出が予想どおりであることを確認するなど、オフチェーン イベントとの強い相関関係が得られます。
• トランザクションの有効期限は、最新のコミットのタイムスタンプに基づいています。クライアント側トランザクションの追加保護として、セクション 6.1 で説明されているように、クライアントはトランザクションの有効期限を選択できます。

Aptos ブロックチェーンは、ブロック内のすべてのトランザクションのタイムスタンプに対して次の保証を提供します。

• ブロックチェーンでは、タイムスタンプは単調増加します。ブロック B1 を仮定します。
• トランザクション ブロックのタイムスタンプ T が確認された場合、少なくとも f + 1 人の正直なバリデータは、時点 T が経過したと信じます。正直な検証者は、自分のクロックがブロックのタイムスタンプ T より大きい場合にのみ、ブロックに投票できます。セクション 7.2 を参照してください。
• トランザクション ブロックがタイムスタンプ T に特定の数のコンセンサス署名を持っている場合、正直な検証者は次のことを行います。

最新のタイムスタンプは、コミットされたブロックごとに更新され、そのブロック内のすべてのトランザクションのタイムスタンプとして使用されます。ネットワークが同期している場合、ネットワークのラウンドトリップごとにトランザクションのブロックがコミットされ、高速な更新と信頼性の高いタイミングが提供されます。必要に応じて、トランザクション ブロック内のより詳細な順序を決定できます。

7.4 トランザクションの並列実行

コンセンサスブロックのメタデータがソートされると、任意のバリデーターノード、フルノード、またはクライアントがトランザクションを実行できるようになります。少なくとも 2f+1 の重み付けされたバリデーターには、提案されたバッチ上で検証可能な進行中のトランザクションがあります。トランザクションの伝播は継続的であるため、他の誠実なバリデーターは時間の経過とともにトランザクションのバッチを受信します。正直なバリデーター・ノードが、実行フェーズに達するまでに順序付けられたトランザクションのバッチを受信していない場合、少なくとも f+1 のステーク重み付けバリデーター (少なくとも f+1 個のステーク重み付けバリデーターがあることが知られている) からそれらをダウンロードできます。ステーク重視の PoAV 署名者の半数以上）は正直です。

ブロックチェーンの重要な目標は、できるだけ多くの並列処理を実現することです。 Aptos ブロックチェーンは、データ モデルと実行エンジンの 2 つの側面から始まります。

7.4.1 並列データモデル

Move 言語のデータ モデルは、データとモジュールのグローバル アドレス指定をネイティブにサポートします。重複せず、競合するデータとアカウントを含むトランザクションは、並行して実行できます。 Aptos で使用されているパイプライン設計を考慮すると、トランザクションの順序を変更することで競合が軽減され、同時実行性が向上します。

トランザクションが同じオンチェーン値のセットを変更した場合でも、ほとんどのトランザクションは依然として並行して実行できます。 Aptos ブロックチェーンは、変更されたアカウントの状態ではなく、アカウントの状態への変更を記述する新しい概念であるデルタ書き込みを導入しています (たとえば、単に最終値を決定するのではなく整数を増加させる)。すべてのトランザクション処理は並行して実行でき、競合する値への差分書き込みは正しい順序で実行され、決定的な結果が保証されます。

Aptos ブロックチェーンは、時間の経過とともに同時実行性を高め（読み取り/書き込みヒントの利用など）、開発者のエクスペリエンスを向上させることでデータ モデルを強化し続け、開発者がオンチェーン値をより自然に作成、変更、結合できるようにします。 Move は、言語レベルおよびプラットフォーム固有の機能拡張に対する柔軟性を提供します。

7.4.2 並列実行エンジン

Block-STM 並列実行エンジンは、特定の順序で最大の並列処理を達成するためにオプティミスティック同時実行制御を実行しながら、順序付けされたトランザクションの競合を検出および管理します [13]。

バッチ トランザクションはオプティミスティック ロックを使用して並列化され、実行後に検証されます。検証が失敗すると、再実行が行われます。 Block-STM は、書き込みと書き込みの競合を避けるためにマルチバージョン データ構造を使用します。同じ場所へのすべての書き込みは、ID と楽観的に再試行された回数を含むバージョンとともに保存されます。トランザクション tx がメモリ データを読み取るとき、tx より前に現れるブロック高さが最も高いトランザクションをマルチバージョン データ構造からあらかじめ設定された順序で取得し、トランザクションの値とそれに関連するバージョンを書き込みます。

Block-STM は Aptos ブロックチェーンに統合されました Block-STM の潜在的なパフォーマンスを理解するために、意味のある (重要な) ポイントツーポイント移動トランザクション (例: 8 回の読み取りと 5 回の書き込み) を備えたインメモリ データベースを使用します。 ) スタンドアロンの実行専用 (エンドツーエンドではない) ベンチマークとして。図6にBlock-STMの実行結果を示します。各ブロックには 10,000 のトランザクションが含まれており、アカウントの数によって競合と紛争の程度が決まります。

低競合では、Block-STM の TPS は 32 スレッド線形実行の 16 倍であり、高競合では、Block-STM の TPS も 8 倍増加します。他のブロックチェーン並列実行エンジンとは異なり、Block-STM は、あらゆるワークロードの本質的な並列処理を動的かつ透過的に (ユーザー プロンプトなしで) キャプチャできます。 BlockSTM は、読み書きされるデータの場所についての事前の知識を必要とする並列実行環境よりも、より複雑なトランザクションを同時にサポートできます。この特性により、トランザクションの数は減りますが効率が向上し、コストが削減され、ユーザーの待ち時間が短縮されます。さらに重要なことは、物事を複数の小さなトランザクションに分割すると、トランザクションのアトミック性が損なわれることです (すべての操作は分割できず、すべての操作が成功するかすべて失敗するかのどちらかです)。 Block-STM での表現力豊かなトランザクション セマンティクスと並列実行を組み合わせることで、開発者は両方の長所を活用できるようになります。

ブロック メタデータの順序付けステップは、並列実行フェーズ中のトランザクションの並べ替えを妨げるものではないことに注意してください。並列実行の同時実行パフォーマンスを最適化するために、ブロック全体でトランザクションの順序を変更できます。唯一の要件は、すべての正直なバリデーターの並べ替えが不可逆的である必要があることです。並列実行を最適化し、並べ替えにランダム化を追加すると、パフォーマンスが向上し、悪意のあるバリデーター トランザクションによってマイナー抽出可能値 (MEV) テクノロジーが並べ替えられるのを潜在的に防ぐことができます。このパイプライン設計では、「Order-then-reveal」(Order-then-reveal) という MEV 対策戦略を追加することもできます。

ブロック STM とトランザクションの並べ替えは、実行の同時実行性を高めるための補完的な技術です。これらをトランザクションの読み取り/書き込みアクセス ヒントと組み合わせて、同時実行性を高めることができます。

7.5 バルクストレージ

並列実行フェーズの結果は、グループ内のすべてのトランザクションの書き込みセットです。これらの書き込みセットは、実行速度を最大にするためにメモリに保存し、次のブロックまたはブロックのセットを実行するためのキャッシュとして使用できます。重複する書き込みは、安定したストレージに 1 回書き込むだけで済みます。メモリ内書き込みセットを保存する前にバリデーターが失敗した場合、ブロック メタデータの順序付けフェーズから並列実行を再開するだけで済みます。書き込みセットの大容量ストレージを並列実行ステップから分離することで、並列実行を効率的に実行できるようになります。要約すると、書き込みセットをバッチ処理すると、ストレージ操作の数が減り、より効率的で大規模な I/O 操作が活用されます。

ライトセット キャッシュ用に予約されるメモリの量はマシンごとに手動で構成でき、自然なバック プレッシャー メカニズムを提供します。特定の I/O およびメモリ環境に合わせてチューニングが必要な場合、バッチ処理の粒度は並列実行ブロックの粒度とは異なる場合があります。

7.6 台帳認証

この時点 (バッチ ストレージ) で、パイプライン上の個々のバリデーターが、コミットされたトランザクション ブロックの新しい状態を計算しました。ただし、認証されたライトクライアントと状態の同期を効率的にサポートするために、Aptos ブロックチェーンは台帳履歴と台帳状態の台帳認証を実装しています。 Aptos ブロックチェーンとの主な違いは、台帳認証がトランザクション処理のクリティカル パス上になく、必要に応じて完全に無人で実行できることです。

7.6.1 アカウント履歴の確認

バリデーターは、トランザクションとその実行出力を、グローバルに認証された台帳データ構造に追加します。トランザクション出力の一部は、Move によってアクセス可能なグローバル状態に加えられた変更を含む、一連の状態書き込みです。このデータ構造の簡単なバリデータは、新しく実行されたトランザクションのバッチを含む、台帳履歴への拘束力のあるコミットメントです。トランザクションの実行と同様に、このデータ構造の生成は決定的です。

各検証者は、短い認証子に署名して、結果として得られる新しいバージョンのデータベースに組み込みます。バリデーターは、署名されたショート・バリデーターの最新のセットを相互に共有し、クォーラム署名されたショート認証者を集合的に集約し、最新のクォーラム署名されたショート・バリデーターも相互に共有します。

BFT プロトコルの特性に従って、この集合署名を使用すると、クライアントはデータベースのバージョンが完全で有効かつ不可逆的な台帳履歴を表すものであると信頼できます。クライアントは、任意のバリデーター (またはフルノードなどのデータベースのサードパーティのコピー) にクエリを実行してデータベース値を読み取り、バリデーターと必要なデータの証明を使用して結果を検証できます。

7.6.2 定期的なステータス認証

Move 言語でアクセスできるグローバル状態全体は、履歴の任意の時点で、台帳履歴の概要と同様の短いバリデータに集約できます。グローバル状態のランダムアクセスの性質により (付録のみの元帳履歴とは異なります)、この証明書の維持にはコストがかかります。ただし、大規模なバッチでデータ構造を更新する場合、更新を並行して計算し、個々の状態値が変化するときに更新する必要がある部分間の重複を利用することもできます。 Aptos ブロックチェーンは、意識的にグローバル状態の定期的な検証を使用して、重複した共有更新を削減します。

決定的で構成可能な期間中、ネットワークは状態照合ポイント トランザクションを公開します。その結果部分にはグローバル状態認証子が含まれます。このバージョンは状態チェックポイントと呼ばれます。 2 つの照合ポイント間のギャップが大きいほど、各トランザクションで状態認証データ構造を更新するための償却コストは低くなります。

状態照合ポイントを使用すると、すべてのグローバル状態を保存しなくても、トラストレスな方法で任意の状態値を読み取ることができます。この機能は、増分状態同期、バリデーター ノード間の共有ストレージ、ステートレス バリデーター ノード、ストレージに制約のあるライト クライアントなどのアプリケーションに適しています。

ただし、状態チェックポイントは定期的であるため、台帳状態の特定のバージョンの証明を取得するには、欠落している状態に対して追加のトランザクションを交互に実行するか、検証された台帳履歴からそれらを含む証明を取得する必要があります。

状態チェックポイントは台帳履歴内の特定のトランザクション バージョンに関連付けられているため、セクション 7 で説明したトランザクション バッチに関連付けられたタイムスタンプに関連付けられます。タイムスタンプを使用すると、ライト クライアントは証明された状態値の適時性を理解できます。タイムスタンプが存在しない場合、ライトクライアントの証明は、ずっと前の状態の有効性を保証することしかできず、結合性の保証はほとんどありません。さらに、履歴アクセスの追跡と監査 (例: トークン リザーブ内のトークンの時間ごとの平均残高の計算) には、状態証明のタイムスタンプが必要です。

状態チェックポイントは、以前の状態チェックポイントと、トランザクション結果におけるその後の状態変化に基づいて生成できます。したがって、安定したストレージへの状態チェックポイントの永続化は、トランザクション処理のクリティカル パス上にある必要はありません。さらに、状態検証ポイントの保持には、バッチ処理の有益な効果もあります。最新の状態チェックポイント (むしろそれらの間の差分) をメモリにキャッシュし、定期的な状態チェックポイントのみを安定したストレージにダンプすることで、ストレージ帯域幅の消費を大幅に削減できます。チェックポイントを保持する方法の選択は、検証されたデータ構造の計算には影響しません。したがって、これはノードごとに選択されます。ノード オペレーターは、メモリ容量とストレージ帯域幅の間で適切なトレードオフを行うことができます。

8. 状態の同期

Aptos ブロックチェーンは、エコシステムのすべての参加者に高スループット、低遅延のシステムを提供することを目的としています。したがって、ブロックチェーンは、ブロックチェーン データをライト クライアント、フル ノード、および検証ノードに伝播、検証、および永続化するための効率的な状態同期プロトコルを提供する必要があります [14]。さらに、ユーザーのさまざまなハードウェア リソースを考慮して、同期プロトコルは、ネットワーク内に存在するリソースの制限や差異とも互換性がある必要があります。たとえば、アーカイブフルノードがブロックチェーンの状態と履歴全体を検証して保存できるようにすると同時に、ライトクライアントがブロックチェーンの状態のごく一部のみに効率的にアクセスできるようにする必要があります。

この機能を実現するために、Aptos ブロックチェーンは、バリデーター、フルノード、その他のシンクロナイザー (セクション 7.6.1 を参照) によって提供される認定された台帳履歴と状態証明を利用して、柔軟で構成可能な同期プロトコルを実装します。具体的には、ネットワーク参加者はさまざまな同期戦略を選択して、自身のユースケースとニーズを最適化できます。

たとえば、Aptos は、完全な同期戦略や、履歴記録を無視してアンカーを使用して最新のブロックチェーン状態のみを同期する戦略など、完全なノードに対してさまざまな同期戦略を提供します。 Aptos は、特定のアカウントまたはデータを同期できる部分同期戦略や、検証済みのアカウント残高を取得できる検証済みデータの取得戦略など、ライト クライアント向けのさまざまな同期戦略を提供します。いずれの場合も、Aptos を使用すると、参加者は構成設定を通じて特定の量とバージョンのデータを取得、処理、保存できます。

この柔軟で構成可能な状態同期プロトコルを通じて、Aptos はさまざまな顧客のニーズを満たし、将来的にはより高度で効率的な同期戦略を提供できるようになります。

9. コミュニティガバナンス

Aptos ブロックチェーンは、広範で多様なコミュニティによって所有、運営、管理されます。ネイティブの Aptos トークンは、トランザクションおよびネットワーク料金、プロトコルのアップグレード、オンチェーン/オフチェーンプロセスのガバナンス投票に使用されるほか、プルーフオブステーク (PoS) モデルを通じてブロックチェーンを保護します。 Aptos トークンの具体的な経済モデルは後でリリースされる予定です。

9.1 取引手数料とネットワーク手数料

すべての Aptos トランザクションには手数料単価 (Aptos トークンで指定) があり、バリデーターはネットワーク内で最も価値の高いトランザクションを優先することができます。さらに、パイプライン モデルの各段階で、低価値のトランザクションを放棄する機会が複数あります (ブロックチェーンが最大のシステム容量で効率的に実行できることを可能な限り保証するため)。料金の導入により、時間の経過とともに、Aptos ブロックチェーンの使用コストがハードウェアの導入、メンテナンス、ノード運用の実際のコストに比例するようになります。さらに、開発者が設計したアプリケーションは、さまざまなコストに応じてコンピューティング、ストレージ、ネットワーキングの間でトレードオフを行うことができます。

9.2 ネットワークガバナンス

Aptos ブロックチェーン上のすべての主要な機能の最適化と反復は、提案、実装、テスト、展開などのいくつかの段階を経ます。この構造は、利害関係者や利害関係者がフィードバックを提供し、懸念を共有し、提案を行う機会を提供します。最終段階として、展開は通常 2 つのステップで行われます。まず、新しい機能を備えたソフトウェア バージョンが各ノードにデプロイされ、次に、機能フラグやオンチェーン構成変数などを介して機能がオンになります。

新しいソフトウェアがサポートされているバージョンと相互運用できることを保証するために、ノード オペレーターによるすべてのソフトウェア展開には下位互換性がなければなりません。新しいソフトウェア バージョンを展開するプロセスには、異なるタイム ゾーンのオペレーターや外部の問題を考慮するため、数日かかる場合があります。十分な数のノードがアップグレードされると、事前に合意されたブロック高さまたはエポック スイッチなどの同期ポイントによって新機能の有効化をトリガーできます。緊急事態（ダウンタイムが避けられない場合など）では、ノードオペレーターによる手動および強制的な変更によって再起動が可能になり、最悪の場合にはネットワークのハードフォークによって再起動が可能になります。

他のブロックチェーンとは対照的に、Aptos ブロックチェーンはその構成をオンチェーンでエンコードします。各バリデータは、ブロックチェーンの現在の状態と同期し、現在のオンチェーン値に基づいて正しい構成 (コンセンサス プロトコルや Aptos フレームワークのバージョンなど) を自動的に選択できます。この機能に基づいて、Aptos ブロックチェーンのアップグレードはシームレスかつ瞬時に行われます。

有効化プロセス中の柔軟性と構成可能性を可能にするために、Aptos ブロックチェーンは、トークン所有者がステーキングされたトークンの重みに基づいて投票できるオンチェーン ガバナンスをサポートします。オンチェーン投票プロトコルは公開されており、検証可能であり、即時に実行できます。オンチェーン ガバナンスにより、ソフトウェアを導入しなくてもノンバイナリの結果が得られます。たとえば、オンチェーンのリーダー選出プロトコルのパラメーターはオンチェーンのガバナンスを通じて変更できますが、すべての変更を事前に知る必要があるため、既知の同期ポイントでは動的変更を処理できません。

オンチェーン ガバナンスは、時間をかけてアップグレード管理プロセス全体にわたって展開できます。例えば：

1. トークン所有者は、新しい耐量子署名スキームへの移行をオンチェーンで投票します。

2. 開発者は、新しい署名計画を実装して検証し、新しいソフトウェア バージョンを作成します。

3. 検証者はソフトウェアを新しいバージョンにアップグレードします。

4. トークン所有者は、新しい署名スキームを有効にするためにオンチェーンで投票し、オンチェーン構成が更新され、変更が有効になります。

オープンソース プロジェクトである Aptos ブロックチェーンのガバナンスは、コミュニティからの強力なフィードバックとオンチェーン ガバナンスに大きく依存しています。場合によっては、オフチェーン アップグレードを有効にする必要がある場合もありますが、これは時間の経過とともに最小限に抑えられます。

9.3 ステーク誓約の合意の証明

Aptos ブロックチェーン上のトランザクション検証に参加するには、バリデーターは最小限の Aptos トークンのステークを持っている必要があります。トランザクション伝播、投票重み、およびブロックメタデータの順序付けにおけるリーダー選出プロセス中に、ステーク量は 2f + 1 ステーク重み PoAv に比例して影響します。バリデーターは、バリデーター自身とそれぞれのステーカーとの間の報酬の分配を決定します。ステーカーは、事前に合意された報酬の分配のためにトークンをステーキングするバリデーターを任意の数選択できます。各エポックの終了時に、バリデーターとそれぞれのステーカーは、関連するオンチェーン Move モジュールを介して報酬を受け取ります。

十分な担保を持つバリデーターは、自由に Aptos ブロックチェーンに参加できます。最小必要ステーク値を含むすべてのパラメーターは、セクション9.2で説明されているオンチェーンイネーブラーによって設定できます。

10. パフォーマンス

セクション 7 で説明したように、Aptos ブロックチェーンは、並列、バッチ最適化されたモジュール式トランザクション処理パイプラインを通じて、最適なスループットとハードウェア効率を達成できます。コンセンサス アップグレード、遅延書き込み、トランザクション ヒント、クリティカル パス キャッシュなどの追加のパフォーマンス イニシアチブにより、時間の経過とともにスループットが向上し、効率が向上します。

現在、ブロックチェーンのスループットは 1 秒あたりのトランザクション数で測定されることがよくあります。ただし、トランザクションとインフラストラクチャのコストと複雑さのレベルが異なることを考慮すると、これはシステムを比較する不正確な方法です。ファイナリティへのコミットの開始と終了が実験ごとに異なるため、トランザクションの遅延にも欠陥があります。

さらに、一部のシステムでは、トランザクションの入力と出力に関する事前の知識が必要であり、論理トランザクションをより小さく、それほど複雑でないトランザクションに分割する必要があります。トランザクションを分割すると、ユーザー エクスペリエンスが低下し、開発者が達成しようとしていることを無視して、レイテンシとスループットに人為的に影響を与えます。対照的に、Aptos のアプローチでは、開発者は合成トランザクションではなく現実世界のユースケースに対してスループットとレイテンシを無制限に構築および測定できます。

Aptos Blockchain は、個々のバリデーターのパフォーマンスの最適化を継続するとともに、ネットワークにさらに多くのバリデーターを追加するスケーリング技術の実験も行っていきます。どちらの方向にも明らかなトレードオフがあります。並列実行が可能なブロックチェーンは、より強力なハードウェアを必要としたり、各バリデーターをマシンの個別のクラスターとして構築したりすることで、より優れた同時実行性をサポートできます。ただし、グローバル バリデーターの数には実際的な制限があり、これはバリデーター オペレーターのコストと複雑さに対応します。クラウド サービスにおけるサーバーレス データベースの台頭と人気は、この種の複雑な分散システムを効果的に展開して維持できるエンティティがほとんどないことを示しています。

10.1 同種の状態のシャーディング

当初、Aptos ブロックチェーンは単一の台帳状態で起動されます。時間が経つにつれて、Aptos ネットワークは分散化されたままでありながら、水平方向のスケーラビリティに対して独自のアプローチを採用することになります。これは、複数のシャーディングされた台帳の状態を通じて実現されます。各台帳は均一な API を提供し、主な概念としてシャーディングを使用します。 Aptos トークンは、取引手数料、デポジット、およびすべてのシャードのガバナンスに使用されます。

データは同種のブリッジを介してシャード間で転送できます。ユーザーと開発者は、ニーズに応じて独自のシャーディング スキームを選択できます。たとえば、開発者は新しいシャードを提案したり、既存のシャード内でユーザーをグループ化したりして、シャード内で高い接続性を実現できます。さらに、シャードは異なるシステム特性を持つ場合があります。 1 つのシャードは SSD を使用したコンピューティング用に最適化でき、もう 1 つのシャードは低パフォーマンスの大規模ストレージ用に最適化できます。異なるシャード間でハードウェアの柔軟性を提供することで、開発者はアプリケーションのシステム リソースを最大限に活用できます。

要約すると、同種の状態のシャーディングは水平方向のスループット スケーリングの可能性を提供し、開発者がシャード間で単一の共通の状態を使用してプログラムできるようにし、ウォレットがユーザーのシャード データを簡単に組み込めるようにします。これにより、統合された Move スマート コントラクト プラットフォームのシンプルさと相まって、パフォーマンスに大きな利点がもたらされます。

参考文献

1. 「アプトスコア」、2022年。
   オンラインドキュメント。入手可能場所: https://github.com/aptos-labs/aptos-core
   
2. 「移動」、2022年。
   オンラインドキュメント。入手可能場所: https://github.com/move- language/move
   
3. 松岡、C. ディクソン、E. ラザリン、R. ハケット。 (2022) 「State of Encryption 2022」レポートのプレゼンテーション。オンラインドキュメント。入手可能場所: https://a16z.com/tag/state-crypto-2022/
4. アムスデン、R. アローラ、S. バノ、M. ボーデ、S. ブラックシア、A. ボスラ、G. カブレラ、C. カタリーニ、K. ハルキアス、チェン、A. チン、A. チャーシン、G. ダネジス、GD ジャコモ、DL ディル、H. ディン、N. ドゥドチェンコ、ガオ、Z. ガオ、F. ガリロット、M. ゴーベン、P. ヘイズ、JM ホウ、Y. フー、K. ハーリー、K. ルイス、C. リー、Z . リー、マルキ、S. マルグリス、B. マウラー、P. モハッセル、L. デ・ノーワ、V. ニコラエンコ、T. ノワツキ、O. オルロフ、ペレルマン、A. ポット、B. プロクター、S. カディール、レイン、 D. ルッシ、B. シュワブ、S. ゼザー、A. ソンニーノ、H. ヴェンター、L. ウェイ、N. ヴェルナーフェルト、B. ウィリアムズ、Q. ウー、X. ヤン、T. ザキアン、R. ジョウ、「天秤座」ブロックチェーン」、2019年。
   オンラインドキュメント。入手可能場所: https://developers.diem.com/papers/the-diem-blockchain/2020-05-26.pdf
   
5. Blackshear、E. Cheng、DL Dill、V. Gao、B. Maurer、T. Nowacki、A. Pott、S. Qadeer、DR Rain、S. Sezer、T. Zakian、R. Zhou、「Move: A The」 「プログラム可能なリソースの言語」、2019 年。
   [オンライン]。https://developers.diem.com/papers/diem-move-a- language-with-programmableresources/2019-06-18.pdf で入手可能です。
   
6. Dill、W. Grieskamp、J. Park、S. Qadeer、M. Xu、および E. Zhong、「Move Validator を使用したスマート コントラクトの高速かつ信頼性の高い正式検証」、Tools and Algorithms for the Construction and Analysis に掲載of Systems、D. Fisman および G. Rosu、Cham 編: Springer International Publishing、2022 年、183-200 ページ。
7. Popper. (2021) パスワードを紛失すると、億万長者のビットコインの財産がロックされてしまいます。
   オンラインドキュメント。入手可能場所: https://www.nytimes.com/2021/01/12/technology/bitcoin-passwords-wallets-fortunes.html
   
8. Diem Group、「再構成されたシステムにおけるコミットメント情報の状態の同期と検証」、2020 年。
   オンラインドキュメント。入手可能場所: https://github.com/aptos-labs/aptoscore/blob/main/documentation/tech-papers/lbft-verification/lbft-verification.pdf
   
9. Danezis、L. Kokoris-Kogias、A. Sonnino、および A. Spiegelman、「イッカクと牙: dag ベースのメモリプールと効率的な bft コンセンサス」、第 17 回欧州コンピュータ システム会議議事録、シリーズ EuroSys に掲載22. 米国ニューヨーク州ニューヨーク: コンピューティング機械協会、2022 年、34 ～ 50 ページ。
   オンラインドキュメント。入手可能場所: https://doi.org/10.1145/3492321.3519594
   
10. Diem Group、「Diembft v4: Diem ブロックチェーンにおけるステート マシン レプリケーション」、2021 年。
    オンラインドキュメント。入手可能場所: https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diemblockchain/2021-08-17.pdf
    
11. コーエン、R. ゲラシヴィリ、L. ココリス-コギアス、Z. リー、D. マルキ、A. ソンニーノ、および A. シュピーゲルマン、「リーダーについて知られるように」、CoR、vol. abs/2110.00960、2021 年。
    オンラインドキュメント。入手可能場所: https://arxiv.org/abs/2110.00960
    
12. Spiegelman、N. Giridharan、A. Sonnino、および L. Kokoris-Kogias、「ブルシャーク: Dag bft プロトコルの実践的実装」、第 20 回コンピュータおよび通信セキュリティ (CCS) 会議議事録、CCS 連載 [22] ]。米国カリフォルニア州ロサンゼルス: コンピューティング機械協会、2022 年。
13. Gelashvili、A. Spiegelman、Z. Xiang、G. Danezis、Z. Li、Y. Xia、R. Zhou、および D. Malkhi、「Block-stm: ソートの呪いをパフォーマンスの祝福に変えることによるブロックのスケーリング」処刑」、2022年。
    オンラインドキュメント。入手可能場所: https://arxiv.org/abs/2203.06871
    
14. Lind、「状態同期の進化: アプトスで 1 秒あたり 100,000 以上のトランザクション、1 秒未満のレイテンシーへの道」、2022 年。
    オンラインドキュメント。入手可能場所: https://medium.com/aptoslabs/52e25a2c6f10
    

記事のソース: Buidler DAO