今回は、Aptosブロックチェーンに関して更新された情報についてまとめました。
Aptosでは、1秒見なんのレイテンシーで1秒あたり10万以上のトランザクションを実現しています。
Aptosとは→仮想通貨【 Aptosとは 】必要知識まとめ
これまでに公開されている内容（詳細→【 Aptosのブロックチェーン 】詳細）から、更新されました。
Aptosブロックチェーンは、分散型ネットワークで高スループット・低レイテンシ・検証済みの状態同期を確保するために、幅広い新しい技術を活用しています。
現在、ピアは1秒あたり1万件をこえるトランザクション（TPS）を検証し、同期することができます。
そして1秒未満のレイテンシーを実現しています。
状態の同期は重要ですが、ブロックチェーン設計の見落とされな側面でもありあmす。
APtosでの状態同期の進化について説明します。
最新の状態同期プロトコルの設計の背後にあるいくつかの重要な洞察を提示します。
最近、ステート同期のスループットを10倍に向上させ、レイテンシを3分の1に短縮し、より高速で効率的なブロックチェーン動機への道を開き続けています。
Aptosの公式ホームページはこちらです。
状態同期とは
現在のほとんどのブロックチェーンは階層的に構造化されており、ネットワークの中心に一連のアクティブなバリデーターがあります。
バリデーターは、トランザクションを実行し、ブロックを生成し、コンセンサスを達成することにより、ブロックチェーンを成長させます。
バリデーター（ブロックやトランザクションなど）によって生成されたブロックチェーンデータを複製します。
状態同期は、バリデーター以外のピアがこのブロックチェーンデータを配布・検証・保持できるようにするプロトコルです。
エコシステム内の全てのピアが確実に同期されるようにします。
これがAptosでどのように見えるかについては下の図のとおりです。
状態同期が重要な理由
ブロックチェーンを評価する際に、状態同期について言及されることはあまりありません。
これは、より興味深いトピックに特化したホワイトペーパーの脚注であることがあります。
ただし、状態同期は、ブロックチェーンのパフォーマンス・セキュリティ・ユーザーエクスペリエンスに大きな影響を与えます。
①ファイナリティまでの時間とユーザーエクスペリエンス
新しいトランザクションがバリデーターによって実行されると、状態同期がピアとクライアントにデータを伝達する役割を果たします。
状態の同期が遅いか信頼性が低い場合、ピアはながいトランザクション処理の遅延を認識し、人為的にファイナリティまでの時間を膨らませます。
これはユーザーエクスペリエンスに大きな影響を与えます。
例えば、分散型アプリケーション（DApps）・分散型取引所（DEX）・支払い処理は全て非常に遅くなります。
②コンセンサスとの関係
バリデータセットの残りの部分よりもクラッシュしたり遅れたりしたバリデータは、状態の同期に依存して速度を戻します。
つまり、最新のブロックチェーンの状態を同期します。
状態同期がコンセンサスによって実行されるほど迅速にトランザクションを処理できない場合、クラッシュしたバリデーターは回復できなくなります。
更に、新しいバリデーターがコンセンサスに参加することは決してありません。
フルホードは最新の状態に同期することは決してできません。
③分散化への影響
迅速で効率的でスケーラブルな状態同期プロトコルを持つ頃で、次のことが可能になります。
・ネットワークで選択できる良いり多くの潜在的なバリデータ
・長時間待たずに、より多くのフルノードを迅速にオンラインにする
・リソース要件が低くなり、異質性が高まる
これらの要因は全て、ネットワークの分散化を促進し、ブロックチェーンのサイズと地理的規模を拡大するのに役立ちます。
④データの正確性
状態の同期は、同期中に全てのブロックチェーンデータの正確性を検証する責任があります。
これにより、ネットワーク内の悪意のあるぴあや敵対者がトランザクションデータを変更・検閲・作成し、それを有効なものとして提示することを防ぎます。
状態クライアントが騙されて無効なデータを受け入れる可能性があり、ネットワークに壊滅的な結果をもたらす可能性があります。
状態同期に関する論文
Aptosの目標
①高スループット
状態同期では、各ピアが1秒あたりに同期できるトランザクションの量を最大化する必要があります。
つまり、バリデーターによってコミットされた各Tに対して、SVからS（V＋1）※累乗根 への状態変異の速度化を最大化します。
スループットが低いと、同期時間が長くなり、ネットワークのボトルネックになります。
②低遅延
状態の同期は、最新のピアがバリデーターによってコミットされた新しいトランザクションを同期するのにかかる時間を最小限に抑える必要があります。
つまり、バリデーターによって新しくコミットされた各Tについて、SVのピアがS（V＋1） ※累乗根 と同期するのにかかる時間を最小限に抑えます。
これは、クライアントが認識するファイナリてぃまでの全体的な時間に影響します。
③高速なブートストラップ時間
状態同期は、新しいまたはクラッシュしたピアがブロックチェーンの最新の状態に同期するのにかかる時間を最小限に抑える必要があります。
つまり、ピアの現在のバージョンPと状態SP ※累乗根 に関係なく、SV ※累乗根（ Vはバリデーターによって合意された最高のデータベースバージョン）に同期するのにかかる時間を最小限に抑えます。
これにより、ピアは有用な作業をより迅速に実行できます。
具体的には、残高クエリの応答やトランザクションの検証などです。
④障害と悪意のあるアクターに対する耐性
状態同期は、障害（麻疹やネットワークの障害など）に対して耐性があり、他のピアを含むネットワーク内の悪意のあるアクターを許容する必要が愛rます。
これは、さあmざまな攻撃を克服することを意味します。
例えば、トランザクソンデータの偽造・ネットワークメッセージの改ざん・再生・エクリプス攻撃などです。
⑤リソースの制約と異質性
状態同期は、リソースの制約（CPU・メモリ・ストレージなど）を許容し、異質性を受け入れる必要があります。
分散型ネットワークの性質を考えると、ピアは様々な種類のハードウェアにアクセスし、様々な目標に合わせて最適化します。
必要な構成要素
状態同期プロトコルを構築するために必要な一連の基本的なビルディングブロックを紹介します。
簡潔にするために、以下に各ビルディングブロックの概要を示します。
技術的な詳細は今後の作業に委ねます。
①永続ストレージ
マシンのクラッシュや障害が発生してもデータを保持する（そして他のピアへのデータ配布を有効にする）には、各ピアが信頼できる永続ストレージにアクセスできる必要があります。
Aptosでは、現在Rocks DBを使用していますが、他のオプションを積極的に検討しています。
②検証可能なブロックチェーンデータ
悪意のあるアクターがブロックチェーンデータを変更するのを防ぐために、データが認証され、検証可能である可能性があります。
具体的には、次のことを証明できる必要があります。
・バリデータおによって実行およびコミットされた全てのトランzカウションT
・バリデータおによって実行およびコミットされた全てのトランザクションTの順序
・各トランザクションTをコミットした後の結果のブロックチェーン状態SV ※累乗根
Aptosでは、コミットされたトランザクションとその結果のブロックチェーン状態にマークルツリーを構築することでこれを実現します。
そしてバリデーターにこれらのツリーマークルルートに著名させ、それらを認証します。
③信頼の根幹
Aptosが動的なバリデータをセット（各エポックでのバリデータの変更）をサポートしていることを考えると、ピアはAptosブロックチェーンの検証済みの履歴から現在のバリデータセットを識別できる必要があります。
・最初のバリデータセットとブロックチェーンの初期状態S0 ※累乗根 を識別する、Aptosによって認証されたジェンシスブロブ
・最近の新r内で着るウェイポイント（例えば、現在のバリデータセットとブロックチェーン状態SV ※累乗根 のハッシュ）
ジェネシスブロブとウェイポイントが一緒になって信頼のルートを形成し、ピアが実際のAptosブロックチェーンを同期して攻撃を防止できるようにします。
このプロトコルをAptosで実装し、 devnetでベンチマークし、分析しました。
Aptosが行った観察項目は次のとおりです。
スループットはネットワークレイテンシーバウンド
このプロトコルは最大~1.2k TPSです。
ただし、スループットは、Aliceデータを順番に要求し、ピアが応答srううまで待機sルウ必要があるため、ネットワークの待機時間の影響を大きく受けます。
平均ネットワークラウンドトリップタイム（RTT）が150msdevnetであることを考えると、これは最適ではありません。
CPUは実行によって支配される
同期するトランザクションの新しいセットを受け取る55％と、CPU時間がトランザクションの実行に40％費やされ、データの検証。状態デルタのストレージへの適用および新しいトランザクションの永続化に費やされることが分かります。
5％は、メッセージ処理・シリアル化・その他のタスクに起因します。
待ち時間が長い
ネットワークを最大負荷で実行している場合、新しいトランザクションを受信する平均待ち時間は、トランザクションが〜900msコミットされた後です。
これは主に、Aliceデータをリクエストする際にピアをランダムに選択し、ネットワークトポロジを考慮していないためです。
バリデータに近いピアは、新しいトランザクションをより早く受け取ります。
ブートストラップが遅い
上記のプロトコルでは、ジェネシス以降の全てのトランザクションを再生して同期する必要があります。
最新の状態から大きく遅れている場合、有用な操作ができるようになるまで長い時間待たなければなりません。
これにあh数時間から数日かかることもあります。
パフォーマンスが簡単に操作される
このプロトコルのパフォーマンスは、悪意のあるピアノ影響を大きく受けます。
上記の1で特定されたように、意図的に遅いまたは反応しないピアは、長時間データを待機し、何もしないことを余儀されます。
したがって、同期時間が大幅に増加します。
リソース使用率が高い
このプロトコルはのパフォーマンスは、悪意のあるピアノ影響を大きく受けます。
上記の1で特定されたように、意図的に遅いまたは反応しないピアは、長時間データを待機し、何もしないことを余儀なくされます。
したがって、同期時間が大幅に増加します。
リソース使用率が高い
このプロトコルは、全てのリソースタイプでコストが高くなります。
・全てのトランザクションを再実行する必要があるため、CPU使用率が高くなる
・Aliceジェネシス以降の全てのトランザクションとブロックチェーンの状態を保存する必要があるため、ストレージが高くなる
・ネットワークAlice経由でジェネシス以降の全てのトランザクションを受信する必要があるため、ネットワークの使用率が高い（これは自動的に高いコストとリソース要件を課し、異質性を減らす）
リソースが消費されている
Aliceが新しいデータを同期している間、ネットワーク内のぴあも彼女から同期しています。
データを要求するピアノ数が増えると、これらの要求を処理するためにストレージとCPUに追加の読み取り負担がかかります。
ただし、Aliceピアが同じデータを要求することが多いため、これらの要求を処理するために実行される計算の多くは無駄です。
10k TPSの達成：最適されたアプローチ
上記の素朴なプロトコルを見ると、制限に対処するために多くの変更を加えることができます。
まず、プロトコルを拡張して、2つの追加の同期モードをサポートします。
状態デルタの同期
バリデーターが既にトランザクションを実行し、マークル証明を通じて結果のブロックチェーン状態を証明していることを考えると、ピアはバリデーターによって生成された状態デルタに依存して、トランザクションの実行をスキップできます。
これにより、次のことを回避できます。
・実行コストが高くなり、CPU時間がAptos VMの必要性により、差分の同期の実装が大幅に簡素化される
その結果、ピアは各トランザクションTと状態であるたDT ※累乗根 をダウンロードし、それらをストレージに適用して新しい状態S（V＋1） ※累乗根 を生成することで同期できるようになりました。
これには、ネットワーク使用量の増加（約2.5x）が伴います。
ブロックチェーンのスナップショット同期
バリデーターが各ブロックチェーンの状態SV ※累乗根 を証明することを考えると、ピアが最新のブロックチェーンの状態を直接ダウンロードできるようにすることで、ブートストラップ時間を更に短縮できます。
トランザクションまたは状態デルタを使用して生成する必要はありません。
これにより、ブートストラップ時間が大幅に短縮され、イーサリアムのスナップ同期と同様のアプローチになります。
トレードオフは、ピアがSV ※累乗根 より前のトランザクションまたはブロックチェーンの状態を保存しないことです。
最適化・追加機能
パフォーマンスとスケーラビリティを向上させるために、いくつかの一般的な最適化と追加機能を実装します。
データのプリフェッチ
ネットワークのレイテンシがスループットに影響を当てないようにsルウために、データのプリフェッチを実行できます。
ピアは、他のぴあからトランザクションデータ（トランザクションやステートデルタなど）を処理するためにプリフェッチして、ネットワークレイテンシを償却できます。
パイプライン化された実行とストレージ
同期のスループットをさらに向上させるために、トランザクションの実行をストレージの永続性から分離し、パイプライン化を使用できます。
パイプライン化は、プロセッサ設計で一般的に使用される最適化です。
これにより、トランザクションT1と状態デルタD T1 ※累乗根 を同時にストレージに永続化しながら、トランザクションT2 ※累乗根 を実行できます。
ピア監視・評判
可観測性を向上させ、悪意のあるピアをより許容するために、ピア監視サービスを実装して次のことを行うことができます。
・ピアが持つ全てのトランザクションデータの概要や、バリデータセットからの距離など、各ピアに関するメタデータを識別する
・各ぴあのローカルスコアを維持する
この情報は、新しいブロックチェーンデータを要求する時に、ぴあの選択を最適化するために使用できます。
データキャッシング
ストレージの読み取り負荷を軽減し、同期するピアが増えるにつれて状態同期が冗長な計算を実行するのを防ぐために、一般的に要求されるdー得た項目と応答をメモリに格納するデータキャッシュを実装できます。
ストレージプルーニング
ストレージが時間の経過とともに継続的に増加するのを防ぐために（例えば、より多くのトランザクションがコミットされるにつれて）、動的プルーなーを実装して、不要なトランザクションとブロックチェーンデータをストレージから削除することもできます。
これはピア構成によって異なります。
新しい状態同期プロトコル
上記の変更を実装し、新しい状態同期プロトコル（つまり、state syncv2）を作成しました。
devnetでベンチマークを行い、次のことを観察しました。
スループットが5倍から10倍に向上
トランザクションを実行する場合（並列実行なし）、主にパイプライン処理とデータのプリフェッチの結果として、プロトコルは最大値を達成します。
〜24.5k TPSです。
つまり、プロトコルはCPUを完全に緩和させることができるようになりました。
状態デルタを同期するとき、プロトコルをはるかに上回り（10k TPS）、トランザクションの実行を回避する更なる結果を達成します。
どちらの場合も、スループットはネットワーク遅延の影響を受けなくなりました。
待ち時間が3分の1に短縮
ネットワークを最大負荷で実行している場合、新しいトランザクションを受信するための平均待ち時間は、トランザクションが〜300msコミットされた後であることが分かります。
これは、データのプリフェッチとより効率的なピア選択によるものです。
より応答性が高く、バリデータに近いピアは、より頻繁に接続されます。
ブートストラップが大幅に高速化
ブロックチェーンスナップショット同期を使用するピアは、はるかに高速にブートストラップできます。
更に、ブートストラップ時間は、ブロックチェーンの長さ（つまりトランザクションの数）の影響を受けなくなりました。
しかし、同期するオンチェーンリソースの数によって影響を受けます。
現在devnetでは、ピアは数分以内にブートストラップできます。
リソース要件の削減
複数の同期モードとストレージのプルーニングにより、リソース要件が削減されました。
更に、ピアは同期戦略を柔軟に選択できるため、異質性がサポートされるようになりました。
例えば下記です。
・限られたCPUを持つピアは、トランザクションの実行をスキップできる
・ストレージが限られているピアは、プルーナーをアグレッシブに構成できる
・迅速に最新情報を取得したいピアは、ブロックチェーンスナップショットの同期を実行できる
リソースがより効率的に使用される
ピアからの同期要求を処理するとき、ストレージの読み取り負荷が大幅に削減され、無駄なCPUが少なくなります。
これは、頻繁に要求されるデータ項目と応答をメモリに格納する新しいデータキャッシュによるものです。
また、同期ピアノ数がdebnetで増加するにつれて、データキャッシュがより効率的になることが分かります。
例えば、同期ピア数が20の場合、1リクエストあたりのキャッシュヒット率は70〜80％です。
しかし、60ぴあの場合、キャッシュヒット率は93〜98％になります。
これは、キャッシュを維持するために約150MBのRAMが追加されるという代償を払っています。
10万TPS以上
既にスループットを10倍、レイテンシーを3倍に改善しました。
しかしまだやるべきことがあります。
特に、Block-STMに合わせて、Aptosを全ての人にとってのレイヤー1にしたいと考えています。
では、どうやって達成したら良いでしょうか？
次のステートシンクの目標である100k＋TPSは既に開始されています。
ただし、非常に熱心な読者にいくつかのヒントを提供したいと考えています。
トランザクションのバッチ処理
現在、Aptosは全てのトランザクションを検証可能なものとして扱います。
つまり、データの承認と検証に使用されるマークル証明は、トランザクションのコストが非常に高くなります。
これを回避する1つの方法は、トランザクションのバッチ処理、つまりトランザクションのバッチまたはブロックに対するプルーフを実行することです。
ネットワーク圧縮
ピアツーピア（詳細→【 ピアツーピア（P2P）とは 】分かりやすく解説）ネットワークではネットワーク帯域幅がボトルネックになることが多く、Aptosも例外ではありません。
現在、状態同期プリフェッチャーは、帯域幅を飽和させる前〜34k TPSにdevnetでフェッチできます。
スケーリングしたい場合、これは問題です。
ピアが効率的なシリアライゼーション形式を使用してデータを配布していることを既に認識しています。
市販の圧縮を使用することで、送信されるデータの量は10xです。
ストレージ書き込みの高速化
現在、状態同期のスループットは、ブロックチェーンデータをストレージに永続化するのにかかる時間がボトルネックになっています。
このボトルネックを取り除くためn、次のような様々な最適化と改善を積極的に検討しています。
・より効率的なデータ構造
・より最適なストレージ構成
・代替ストレージエンジン
並列データ処理
これまでは、状態同期プロセスデータを順次処理する必要がありました。
例えば、順次増加するバージョンでトランザクションを処理します。
ただし、この要件を回避し、並列データ処理を利用してスループットを大幅に向上させる既存のアプローチがいくつかあります。
まとめ
専門知識の羅列で、ブロックチェーンやプログラミングに関する知識がない場合は意味が不明だと思います。
知識があったとしても相当深い知識になります。
最近のコメント