公共チェーンGravityがLitepaperを発表、高性能EVMに基づく新しいユーザーエクスペリエンスを提供

原文の出典：Gravity

はじめに

2024年8月にGravity Alphaメインネットが立ち上げられて以来、このネットワークは2.75億以上のトランザクションを処理し、日平均260万のトランザクションを達成し、3000万Gのトランザクション手数料を成功裏に実現しました。Litepaperの発表に伴い、この高性能EVMチェーンの未来のビジョンに期待が寄せられています。この記事では、Litepaperを詳しく分析し、Gravityがどのようにして現実世界のアプリケーションのために卓越した高性能Layer-1ブロックチェーンアーキテクチャを構築しているかを明らかにします。

GravityはGalxeが構築した高性能でEVM互換のレイヤー1ブロックチェーンです。Gravityの開発はGalxeの成長ニーズから生まれました。Galxeプラットフォームは、世界最大のオンチェーン配信プラットフォームとして、2500万人以上のユーザーを引き付ける巨大なマルチチェーンエコシステムを接続しています。その進化の過程で、GalxeはQuest、Passport、Score、Compass、Alvaなどの革新的なツールを統合した分散型スーパーアプリに成長しました。同時に、ロイヤリティポイント、イベントNFT、トークン報酬、zk-認証、クロスチェーンスマートセービングなどの豊富なサービスを提供しています。Galxeの高いトランザクションボリュームは、Gravityの構築を推進する重要な要因となりました。ロイヤリティポイントシステムは毎秒51.2トランザクションをサポートし、トークン報酬活動は平均毎秒32.1トランザクションをサポートします。このことが、分散型GalxeバックエンドにおいてEVMブロックチェーンに移行し、最適なユーザーエクスペリエンスを維持する必要性を促しました。

Galxeの全面的なオンチェーン化の進展に伴い、トランザクション量のさらなる増加が予想されます。スループットの需要は毎秒5000万ガスに達する見込みであり、より広範なエコシステムのニーズ（クロスチェーン決済、ロイヤリティポイント取引、NFT市場など）を満たすには毎秒5億ガスの処理能力が必要になる可能性があります。これを実現するために、Gravityの目標は毎秒1ギガガスのスループットをサポートし、リソース集約型アプリケーションの拡張ニーズを満たすことです。

既存のソリューションの中で、多くのプラットフォームはイーサリアムを通じてスケーラビリティを実現していますが、L2ロールアップのチャレンジ期間は避けられず、トランザクションの遅延を引き起こし、Galxeのように即時のトランザクション確認が必要なアプリケーションには優しくありません。いくつかのDAppは信頼モデルや外部監視を通じて遅延を補おうとしていますが、これらの方法は追加の複雑性とリスクを引き起こし、コアアプリケーションシナリオには明らかに理想的ではありません。

この背景のもと、Gravityが誕生しました。Gravityは並行EVMを中心に、現在最速のオープンソース並行EVM実行システムGrevmを開発し、L2とL1の性能差を縮めました。さらに、GravityはAptosのアーキテクチャをモジュール化し、Quorum StoreやAptosBFTコンセンサスエンジンなどの検証されたコンポーネントを統合しました。AptosBFTの成熟したアーキテクチャを利用することで、Gravityはゼロから開発する際の複雑さと潜在的リスクを回避しました。最終的に、Gravityは全チェーン体験を提供する高性能L1ブロックチェーンを構築するだけでなく、初のパイプラインブロックチェーンSDKを提供し、開発者とユーザーのインタラクションプロセスを大幅に簡素化しました。

Gravityは前例のないスケーラビリティ、分散化能力、ほぼ即時のトランザクション速度を提供します。その技術はL1とL2の利点を組み合わせ、毎秒10,000トランザクションとサブ秒レベルの最終性を実現します。同時に、EigenLayerやBabylonなどの再ステーキングプロトコルを統合することで、Gravityは立ち上げ段階で強力なセキュリティを確保し、単一資産に対する長期的な依存から生じるシステミックリスクを低減しました。

今後、Gravityは次のロードマップに従って進めていきます：

· Devnetフェーズ1をリリースし、リアルタイムのパフォーマンスをテストします。

· Longevity Testnetを開始し、ネットワークの長期的な安定性を検証します。

· Gravity Alphaメインネットから完全に運用されたGravityメインネットに移行し、分散型技術の大規模な応用の基盤を築きます。

以下はGravity Litepaperの全文の翻訳です。

要約

GravityはGalxeが構築した高性能でEVM互換のレイヤー1ブロックチェーンであり、大規模なアプリケーションとマルチチェーンエコシステムのために設計されています。特徴には、毎秒1ギガガスのスループット、サブ秒レベルのトランザクション最終確認、およびリステーキングプロトコルに基づくPoSコンセンサスメカニズムが含まれます。Gravityの設計は二つの主要なオープンソースコンポーネントに基づいています：(1) Gravity SDK、これはリステーキングに基づくパイプライン型AptosBFT PoSコンセンサスエンジンです；(2) Gravity reth、これは並行EVM Grevm (Gravity EVM) を駆動する実行層です。これらのツールは、Web3アプリケーションに代替のレイヤー1および効率的なレイヤー2を構築する能力を提供し、特にEVMチェーン上でのパフォーマンスが際立っています。この記事では、Gravityのエンジニアリングデザインと技術革新を深く探り、パイプラインアーキテクチャ、高度なコンセンサスアルゴリズム、並行実行技術、および最適化されたストレージメカニズム（rethの強化とAptosコンセンサスエンジンの改善を通じて）を通じて高性能の要求を満たす方法を示します。

はじめに

Gravityの開発は、Galxeが運営中に直面した課題から生まれました。Galxeは、ユーザーにロイヤリティポイント、イベントNFT、トークン報酬、ゼロ知識認証、クロスチェーンスマートセービングなどのサービスを提供する先進的なWeb3アプリケーションです。Galxeが急速に成長する中、ロイヤリティポイントシステムは平均毎秒51.2トランザクションを処理し、トークン報酬活動は平均毎秒32.1トランザクションを処理しています。Galxeを段階的に分散化する過程で、これらのユースケースをEVMブロックチェーンに移行し、スムーズなユーザーエクスペリエンスを維持することが課題となりました。したがって、高性能なEVMブロックチェーンを開発し、(1) 高トランザクションスループットと(2) ほぼ即時のトランザクション確認を満たすことが極めて重要です。

この背景において、既存のレイヤー2ソリューションを選択するか、新しいレイヤー1を開発するかは重要な意思決定ポイントです。レイヤー1はコンセンサスアルゴリズムを利用して最終性を実現し、レイヤー2はロールアッププロトコルを介してこの問題を解決します。両者にはトレードオフがあります：レイヤー1は通常、コンセンサスアルゴリズムの制約により一部のスループットを犠牲にしますが、より迅速なトランザクション最終確認を実現できます。例えば、AptosBFTに基づくコンセンサスアルゴリズムは、サブ秒レベルのトランザクション確認を実現できますが、オプティミスティックロールアップは最大7日間のチャレンジ期間を要する可能性があります。ゼロ知識証明がこのプロセスを加速する可能性がありますが、最終確認は依然として数時間かかります。Gravityがサブ秒レベルの最終確認を必要とすることを考慮すると（特にその全チェーン意図プロトコルのために）、私たちはレイヤー1を構築することを選択しました。

レイヤー2がイーサリアムとの通信においてネイティブな利点を持つ一方で、Gravityのようなレイヤー1は、Gravity意図プロトコルとクロスチェーンブリッジを通じてイーサリアムおよび他のブロックチェーンとの深い相互運用性を実現できます。この設計は、イーサリアムとシームレスに協力するだけでなく、全体のWeb3エコシステムの接続性を強化します。

さらに、リステーキングプロトコル（restaking）は、PoSレイヤー1ブロックチェーンの構築の難易度を大幅に低下させます。GravityはEigenLayerやBabylonなどのプロトコルを利用し、イーサリアムとビットコインのステーキング資産とその広範なバリデーターネットワークを統合しています。これにより、PoSコンセンサスに経済的保護を提供し、Gravityの分散化とセキュリティがイーサリアムと同等のレベルに達することを可能にします。

要約すると、Gravityは高性能でEVM互換のLayer-1ブロックチェーンとして構築されており、現代のWeb3アプリケーションのスケーラビリティと性能要求を満たします。もともとの開発目的はGalxeのサービスですが、Gravity SDKとGrevm (Gravity EVM) が提供する柔軟なフレームワークは、あらゆるLayer-1と効率的なLayer-2を構築するために適しています。これはTendermint/Cosmos SDKに類似しています。

我々は1ギガガス/sのスループットが必要です

ブロックチェーンにとって、スループットは最も重要な性能指標であり、通常は毎秒のトランザクション数 (TPS) または毎秒のガス使用量 (gas/s) で測定されます。Galxeのロイヤリティポイントシステムを例に取ると、安定して運用するためには少なくとも400万のgas/sを達成する必要があります。このデータは、各ロイヤリティポイントトランザクションが平均80,000のgasを消費し、同時に毎秒約51.2トランザクションを処理できることから算出されます。

この予測は、Gravity Alpha Mainnetの実践データによって支持されています。我々のテストにおけるレイヤー2ネットワークとして、Gravity Alpha Mainnetのロイヤリティポイントトランザクションは、そのスループットが安定して400万ガス/sに達することを示し、前述の推定の正確性を確認しました。

オンチェーン操作の高コストは需要を若干減少させる可能性がありますが、Galxeの拡大傾向は、高峰時に需要が現在の水準の2倍から3倍に達する可能性があることを示しています。さらに、NFT、トークン報酬、将来のゼロ知識証明に基づく完全なチェーンタスクなどの他のアプリケーションシナリオが追加されるにつれて、Galxeが完全にオンチェーン化されると、スループットの需要が5000万ガス/sに達することが予想されます。したがって、Gravityチェーン上のアプリケーションのガス使用がパレート分布に従うと仮定すると（Uniswapが常にイーサリアムの10%のガスを消費しているように）、クロスチェーン決済、ロイヤリティポイント取引、NFT市場などのより広範なエコシステムのニーズを満たすためには、理想的には5億ガス/sのスループットをサポートする必要があります。したがって、これらの潜在的ニーズを満たすためには、ブロックチェーンは毎秒1ギガガスの処理能力を持ち、リソース集約型アプリケーションの拡張に適応できることを保証する必要があります。

このような高いスループットを達成するためには、並行EVMを導入することが重要です。私たちはGrevmを開発しました。これは現在最速のオープンソース並行EVM実行システムであり、具体的な性能は後続の章を参照してください。

サブ秒レベルの確認時間

スループットに加えて、トランザクションの確認速度はユーザーエクスペリエンスにとっても非常に重要です。現代のユーザーは、Web2のようなほぼ即時の応答に慣れていますが、これはブロックチェーンにとって依然として課題です。Galxeを例にとると、それは完全にオンチェーンゲームに似ており、低遅延の要件があります。現在、大多数のEVMブロックチェーンのトランザクション確認時間は数秒から数日までさまざまであり、この要件を満たすにはほど遠いです。私たちは、サブ秒レベルの確認時間を実現するためにAptosBFTコンセンサスアルゴリズムを選択しました。

L2ロールアップは理論的にはスループットを向上させることができますが、そのチャレンジ期間はトランザクションの遅延を引き起こし、即時のトランザクション確認が必要なアプリケーション（Galxeなど）には非常に不利です。一部のDAppは信頼モデルや外部監視を通じてこれを最適化しようとしていますが、これは追加の複雑さとリスクを引き起こし、重要なアプリケーションには理想的ではありません。Gravity SDKは5段階のパイプラインを設計することによって、コンセンサスと実行プロセスを並行化し、L2とL1の性能差を縮小しました（具体的な設計については後述します）。

再ステーキングに基づくPoSセキュリティ

Gravity SDKは、L2ロールアップに限定されず、再ステーキングによる保護を通じてイーサリアムを安全に拡張する方法を提供します。これは、パフォーマンス、相互運用性、セキュリティのバランスを取るためのものです。コアモジュールは、EigenLayerやBabylonなどの再ステーキングプロトコルを統合し、経済的な信頼のサポートを提供し、堅牢なプルーフ・オブ・ステークコンセンサスの構築を保証します。

イーサリアムの450億ドルのステーキング資産と85万のバリデーター、さらにBabylonを通じてビットコインから6000億ドルの資産にアクセスすることで、Gravityは初めから堅固なセキュリティ基盤を構築し、新しいブロックチェーンが直面する一般的な立ち上げ問題やセキュリティリスクを回避し、単一資産に依存することで生じるシステミックリスクを長期的に低減します。

Gravity Chainアーキテクチャ

Gravity Chainは二つの主要なコンポーネントを含んでいます：Gravity SDKとGravity reth。Gravity SDKは、Aptosチェーンから改良されたブロックチェーンフレームワークであり、Aptosは現在最も進んだHotStuffコンセンサスアルゴリズムファミリーに基づくPoSブロックチェーンであり、そのパイプラインアーキテクチャはスループットとリソース効率を大幅に向上させます。Gravity rethは、rethに基づく実行層であり、ブロックストリームリアクター（BSR）の形で動作し、コンセンサス層からの提案されたブロックを受け取ります。rethを最適化することで、Gravity rethは並行実行、バッチ非同期状態提出計算、およびストレージ効率の向上を実現しました。これら二つのコンポーネントは、Gravityコンセンサスエンジンインターフェース（GCEI）とrethアダプターによって密接に結合されており、パイプラインコントローラーは各段階の進捗を動的に管理します。

この設計は、ブロックの実行をブロックのコンセンサスから分離し、実行層をブロック提案の消費者として機能させます。私たちのrethの最適化により、ブロックストリームリアクター（BSR）が管理するパイプラインブロック提案プロセスに完璧に適合します。

Gravity Chainのトランザクションフローは以下の通りです：

1. トランザクションはGravity reth JSON RPCインターフェースを介して提出され、このインターフェースはイーサリアムと完全に互換性があります。

2. 次に、トランザクションはGravity SDKのメモリプールに入り、ネットワーク内で伝播し、バリデーターはトランザクションをバッチ処理し、クォーラムストア（QS）証明を生成します。

3. 各ラウンドのリーダーが、ブロックメタデータとメモリプールおよびQSから選択されたオーダートランザクションを含むブロック提案を行います。

4. 提案が順序付けられた後、実行層に入ります。

5. 実行層のGrevmがトランザクションを並行処理し、実行結果を生成し、新しい状態を状態管理モジュールに渡します。

6. 状態モジュールは状態ルートを計算し、コンセンサスエンジンに渡して状態ルートのコンセンサスを達成します。

7. 状態のルートが最終的に確認された後、ストレージモジュールは状態のルートとブロックデータを永続化します。

次の章では、各コンポーネントを詳しく説明します。

Gravity SDK：オープンソースパイプラインブロックチェーンの革新実践

Gravity SDKは、モジュール化されたオープンソースブロックチェーンフレームワークであり、生産準備が整ったAptosブロックチェーンに基づいています。その目的は、Aptosのアーキテクチャをモジュール化し、Quorum StoreやAptosBFTコンセンサスエンジンのような検証済みコンポーネントを参考にして、初のパイプラインブロックチェーンSDKを構築することです。

Gravity SDKがAptosを基盤として選択した理由には、

· トップ技術アーキテクチャ：AptosはHotStuffファミリーコンセンサスに基づく先進的なPoSブロックチェーンです。

· 極致のパフォーマンス：Aptosは毎秒16万のトランザクションのスループットを提供し、最終確認時間は1秒未満です。

· 実戦的な信頼性：Aptosは生産環境での検証を経て、卓越した安定性と効率性を示しています。

· 再び車輪を再発明しない：Aptosの成熟したアーキテクチャを利用することで、ゼロから開発する際の複雑さと潜在的リスクを回避できますが、Aptosを超えようとする他の試みは多くが理論と実践が不足しています。

· 協同増益：Aptosの進展に伴い、Gravity SDKはその新機能（たとえば、ランダム数API）をシームレスに統合でき、モジュール化されたアーキテクチャと革新的なセキュリティメカニズムを通じてAptosに還元します。

Gravity SDKに基づくブロックチェーンは、Gravityコンセンサスエンジンインターフェース（GCEI）を介してパイプラインコンセンサスエンジンと接続されます。GCEIはさまざまな実行層と互換性がありますが、Gravity SDKは現在主にGravity rethをサポートしています。GCEIに関する詳細は後続の章で説明します。

Gravity Consensus Engine Interface (GCEI)

GCEI（Gravity Consensus Execution Interface）プロトコルは、コンセンサス層と実行層の間の通信ブリッジです。これは、二つの層間の相互作用を標準化し、パイプラインコントローラーを通じてコンセンサスと実行プロセスを同期させることを保証します。

従来のブロックチェーンSDKとGravity SDKの主な違いは、そのパイプライン化されたコンセンサスエンジンです。実行層はブロックストリームリアクター（Block Stream Reactor）として実装される必要があり、これは提案されたブロックストリームを継続的に消費できる必要があり、状態の約束はトランザクションの実行と非同期計算で行われなければなりません。また、実行層はコンセンサス層に対してバックプレッシャー信号を提供できる必要があり、ブロック提案のリズムを動的に調整します。

さらに、Gravity SDKのパイプライン特性により、実行層は提案されたブロック内の実行不可能なトランザクションを処理できる必要があります。これは、メモリプールが最新の世界状態にアクセスできないため、厳密にトランザクションの有効性を検証できないからです：実行がまだ完了していない可能性があります。同時に、実行結果は後続のブロック生成をブロックすべきではありません。Gravity SDKがブロックのコンセンサスと状態のコンセンサスを並行化した後、実行層は提案されたブロックストリームの反応器となり、後続の段階で実行結果を自由に返すことができます。

GCEIプロトコル仕様は二つのAPIグループを定義します：

· コンセンサス層 API：これらのAPIはGravity SDKによって実装され、実行層がコンセンサスエンジンが提案したブロックに対応し、状態の約束を提出するために使用されます。

· 実行層 API：これらの API は実行層によって実装されなければなりません。コンセンサスエンジンは、トランザクション提案をブロックに追加する前に、これらの API を使用して努力して検証し、提案されたブロックを流動化し、実行層に最終的な状態の約束を通知します。

トランザクションライフサイクルの観点から、GCEIプロトコルは以下の内容を定義します：

1. check_txn（実行層 API）

· 入力：トランザクション（GTxn）を入力として受け取ります。

· 出力：トランザクションの送信者アドレス、nonce、およびガス制限を返します。

用途：このメソッドは、コンセンサスエンジンがトランザクションをブロックに提案する前に尽力して検証を実行します。このメソッドは、同じトランザクションを複数回呼び出すことができます。たとえば、トランザクションがメモリプールに入ったとき、ブロックに提案される前、そして状態の約束が最終確定したときです。

2. submit_txn（コンセンサス層 API）

入力：実行層からトランザクション（GTxn）を受け取ります。

出力：Result<()を返し、トランザクションがメモリプールに正常に追加されたかどうかを示します。

用途：実行層はこの方法を使用してトランザクションをメモリプールに送信できます。コンセンサスエンジンはその後、ネットワークを介してトランザクションを広め、トランザクションのバッチを受け取った後にクォーラムストアを形成します。

3. recv_ordered_block（実行層 API）

入力：順序付けされたブロック（BlockBatch型）を受け取り、その中にソートされたトランザクションとブロックメタデータが含まれています。

出力：Result<()を返し、実行層がそのブロックを正常に受信し、受け入れたかどうかを示します。

用途：一度コンセンサスエンジンがブロックを提案すると、それは実行層に送信され、トランザクションが実行されます。このメソッドは実行層が提案されたブロックを受け取り、処理することを許可します。

4. update_state_commitment（コンセンサス層 API）

入力：特定のブロック番号の状態の約束（StateCommitment）を受け取ります。

出力：Result<() を返し、状態の約束がローカルコンセンサスエンジンによって成功裏に受け入れられたかどうかを示します。

用途：実行層が状態の約束を計算した後、それをコンセンサス層に送信して最終的な確定を行います。すなわち、他のバリデーターと2f + 1の軽量コンセンサスに達します。状態の約束に関するコンセンサスが提案されたブロックの進行状況との差が大きすぎる場合、パイプラインコントローラーはブロック提案のリズムを調整します。

5. commit_block_hash（実行層 API）

入力：提出するブロックを示す一連のblock_idsベクターを受け取ります。

出力：Result<()を返し、操作の成功を示します。

用途：状態の約束が最終的に確定したとき、コンセンサス層は実行層に状態のハッシュをブロックチェーンストレージに提出することを通知します。

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

Gravity SDK は、ハードウェアリソースの利用率を最大化するために5段階のパイプラインアーキテクチャを活用し、より高いスループットと低遅延を実現します。パイプラインは異なるブロック間でタスクを交互に実行し、パイプラインマネージャーはフィードバックメカニズムを使用してブロックチェーンの安定した進行を保証します。最初の3つの段階はコンセンサス層に属し、残りの2つの段階は実行層に属します。

各段階の説明は以下の通りです：

· フェーズ1：トランザクションの伝播：このフェーズでは、バリデーター間でのトランザクションの効率的な伝播を行い、ブロック構築中にトランザクションがタイムリーかつ信頼性の高い形で含まれることを確保します。設計では、トランザクションの伝播とコンセンサスメカニズムを切り離し、Narwhal & TuskおよびAptosの考え方に従い、バリデーターがトランザクションバッチを継続的に共有し、すべてのネットワークリソースを並行して活用します。一度に2f + 1の重み付き署名を獲得したバッチ（PoAvを形成する）は、少なくともf + 1の誠実なバリデーターによって保存され、すべての誠実なバリデーターがこれらのトランザクションを実行に使用できるようにします。

· フェーズ2：ブロックメタデータのソート：このフェーズでは、ネットワーク内で一貫性があり合意されたトランザクションとブロックメタデータの順序を確立します。コンセンサスメカニズム（AptosBFT）は、ビザンチン耐障害性のブロックを提供するために2チェーンルールに従います。ブロックはその後、実行段階に流れ、並行処理の準備をします。

· フェーズ3（BSR）：並行トランザクション実行：このフェーズは実行層の一部であり、この段階でトランザクションを並行して実行します。実行結果は状態の約束段階に渡されます。

· フェーズ4：状態の約束：このフェーズでは、トランザクション実行によって引き起こされた状態変化を完了し、ブロックの最終確定の準備をします。状態の約束はトランザクション実行と非同期計算で行われ、次のブロックの実行が現在のブロックの状態の約束によって妨げられないことを保証します。

· フェーズ5：状態の永続化：このフェーズでは、約束された状態変化をブロックチェーンストレージに永続化します。最終状態ルートと関連データはGravity Storeに保存され、高度に最適化されたストレージエンジンを使用して設計されており、迅速なアクセスと信頼性を保証します。同時に、メモリプールとクォーラムストアに通知して、将来的に含まれなくなるトランザクションをクリアします。

ステーキングとリステーキングモジュール

安全なプルーフ・オブ・ステーク (PoS) レイヤー1ブロックチェーンを構築することは複雑な作業であり、特定のトークンに依存してステーキングを行う場合、特に困難です。このアプローチは、トークンの価値の変動やバリデーターの参加度が限定されるなど、初期段階で経済的セキュリティの不足に直面する可能性があります。この問題を解決するために、Gravity SDK はネットワークのセキュリティを向上させるために、内部および外部のステーキングメカニズムを通じて柔軟なステーキングおよびリステーキングモジュールを提供します。

Gravity SDK の重要な戦略の1つは、EigenLayer や Babylon などのリステーキングプロトコルを導入することです。これらのプロトコルにより、バリデーターは、イーサリアムやビットコインなどの他の成熟したネットワークの資産を再ステーキングでき、既存のセキュリティを活用できます。バリデーターがこれらのチェーンの資産を担保にすることを許可することで、Gravity SDK はネットワークの経済的セキュリティを向上させ、完全にローカルトークンに依存することなく実現できます。このアプローチは、チェーンの堅牢性を強化するだけでなく、バリデーターエコシステムの多様性も促進します。ステーキングモジュールの設計はモジュール化を中心に構成されており、そのリステーキングコンポーネントは高度な柔軟性を持ち、ブロックチェーンエコシステムの進化に伴って新しいリステーキングプロトコルに容易に適応できます。

このモジュールは、再ステーキング資産をサポートするだけでなく、イーサリアム上のカスタムERC20トークン（たとえばGトークン）をステーキングすることもサポートします。バリデーターはこれらの許可されたトークンをステーキングすることでコンセンサスに参加し、ネットワークのセキュリティに貢献します。バリデーターの投票権は、カスタムトークンとリステーキングプロトコル内の資産を含む総ステーキング価値に基づいて計算されます。この計算はチェーンの具体的な構成に基づいて行われ、各チェーンが自身の要件に応じてステーキングと再ステーキングのルールを柔軟に設定できることを保証します。

コンセンサスエンジン内のエポックマネージャーは、ステーキングモジュールと直接協力して、次のラウンドのバリデーターセットの重みを計算します。これは、実行層からステーキング値を取得することによって、コンセンサスプロセスが最新のステーキングダイナミクスを正確に反映できるようにします。このアーキテクチャでは、クロスチェーン資産（イーサリアムからのステーキング資産など）は、最初に実行層にブリッジされ、その後バリデーターの総ステーキング値を計算するために使用される必要があります。ブリッジメカニズムの実装は実行層によって担当され、クロスチェーン通信の処理をより柔軟に行えるようにします。考えられる解決策には、PoSブリッジ、チェーン状態のゼロ知識証明、そして埋め込まれた自動的なクロスチェーンメッセージングが含まれます。

さらなる技術的詳細、API設計、およびステーキングとリステーキングメカニズムの完全な説明は、今後の文書で詳しく説明されます。

Gravity Reth：ブロックストリームリアクターEVM実行層

Gravity SDKアーキテクチャにEVM実行層を統合することは、特にそのパイプラインコンセンサスエンジンの能力を十分に活用する際にユニークな課題をもたらしました。シームレスな統合を実現し、このアーキテクチャの潜在能力を最大限に引き出すために、オープンソースのイーサリアムクライアントrethに対して多くの重要な最適化を行う必要があります。これらの最適化は、rethをGravity rethに根本的に変換し、パイプラインコンセンサスエンジンに特化したパイプライン最適化EVM実行層を形成します。

従来のブロックチェーンアーキテクチャはブロックを順次処理し、提案された次のブロックの前に各ブロックが完全に検証され、実行されることを保証します。しかし、Gravity SDKはパイプラインコンセンサスメカニズムを採用し、ブロック処理の各段階を分離して性能を向上させます。このパラダイムシフトは、複雑性をもたらします：

意外なトランザクション：パイプラインチェーンでは、先行するブロックの実行がまだ完了していないため、メモリプールは最新の世界状態にアクセスできません。したがって、提案されたブロックに含まれるトランザクションは、最新の状態がないため、提案時に実行できない可能性があります。

非ブロッキング実行結果：パイプラインの停滞を防ぐために、実行結果は後続のブロック生成を阻害するべきではありません。実行層は提案されたブロックを非同期に処理でき、後の段階で実行結果を返すことができる必要があります。このために、EVMにおいてはblockhashを再定義し、ブロックヘッダー内のstateRootフィールドへの依存を排除する必要があります。

これらの問題を解決するために、4つの重要な最適化を導入しました：

· ブロックストリームリアクター（Block Stream Reactor, BSR）：BSRはrethをGravity SDKのパイプラインブロック提案プロセスに調整することを目的としています。これにより、実行層は提案されたブロックストリームを継続的に消費でき、非同期処理を行うブロックのリアクターとして機能します。BSRはコンセンサスエンジンとの間に動的なフィードバックループを構築し、適切なバックプレッシャー信号と組み合わせます。これらの信号は、実行層のスループットと遅延に基づいて、ブロック提案と状態提出の速度をリアルタイムで調整します。複雑なトランザクションやリソース制限により実行層が遅延した場合、バックプレッシャーメカニズムはブロック提案速度を低下させ、システムの安定性を確保します。

· 状態提出とトランザクション実行の解耦：第2の最適化は、状態提出計算とトランザクション実行を分離することです。これらのプロセスを解耦することで、私たちは状態提出計算の非同期化を実現し、後続のブロックの実行が現在のブロックの状態提出の完了を待つ必要がなくなります。私たちはblockhashを再定義し、ブロックヘッダー内のstateRootフィールドへの依存を排除し、状態ルート計算が後続のブロック生成を妨げないことを保証します。

· ストレージ層の最適化：パイプラインアーキテクチャにおいて、高効率でマルチバージョン状態値と状態提出を持続することが不可欠です。第3の最適化は、これらのニーズを満たすためにストレージ層を強化することに焦点を当て、ボトルネックを導入しないようにします。ストレージメカニズムを最適化することで、状態データが迅速に書き込まれ、高い同時アクセスが可能になります。これにはマルチバージョンストレージエンジンの構築と、データベースからストレージAPIへの非同期I/Oのサポートが含まれます。

· 並行EVM：最後の最適化は、EVM内でのトランザクション実行の並行化に関するものです。私たちはGrevmを開発しました。これは、トランザクションの並行実行を実現し、トランザクション処理を大幅に加速します。Grevmは、トランザクションシミュレーションから得られたデータ依存性のヒントを利用して並行実行を最適化し、トランザクションの再実行を削減し、スループットを向上させます。

Grevm（Gravity EVM）- 並行EVM実行

Grevmはオープンソースプロジェクトであり、GitHubにホストされています（まだオープンソースではない場合、将来的にオープンソースになります）。詳細についてはREADMEを参照してください。

Grevm（Gravity EVM）は、revmを基にしたオープンソース並行EVM実行ランタイムです。GrevmのアルゴリズムはBlockSTMからインスパイアを受けており、シミュレーション結果から得られたトランザクションデータ依存グラフを取り入れることで強化されています。このメカニズムにより、並行実行スケジューリングがより効率的になり、トランザクション再実行を最小限に抑えることができます。

私たちのベンチマークテストにおいて、Grevmは現在最速のオープンソース並行EVM実装です。競合のないトランザクションに対して、Grevmは順次実行よりも4.13倍速く、26.50ギガガス/sの速度に達します。現実の100μsのI/O遅延をシミュレートすると、その速度は順次実行の50.84倍、スループットは6.80ギガガス/sです。この性能の飛躍は、並行実行と非同期I/O操作の統合によるものであり、並行化によりI/O操作が効率的に重なり、さらに加速されます。

Grevmの基本的な考え方は、トランザクション間のデータ依存性を利用し、推測されたトランザクションの読み取り/書き込みセットを通じて並行実行を最適化することです。すべてのヒントが完全に正確ではないものの、これらのシミュレーションに基づくヒントは実際には非常に実用的です。たとえば、イーサリアムメインネットでは、過去のガス使用状況に基づき、約30%のトランザクションが単純なイーサリアム転送であり、さらに25%-30%がERC20トークンの転送であり、これらのトランザクションは通常、限られた数のアカウントとストレージスロットの読み取りと書き込みに関与します。これらのトランザクションに対して、シミュレーション結果は一貫した正確性を持っています。

これらの洞察に基づいて、Grevmのために3段階の並行実行フレームワークを開発しました。これはBlock-STMモデルの後続作業であり、トランザクションシミュレーションから得られたデータ依存性のヒントを組み合わせています：

· フェーズ1：ヒント生成と状態の事前読み込み——シミュレーションしたトランザクションを使用して依存ヒントを収集し、メモリキャッシュを事前に温めます。このフェーズは、ブロックチェーンの設計によって異なるタイミングで実行できます。たとえば、新しいトランザクションがメモリプールに到着したときに、依存ヒントを事前に準備するためにシミュレーションをすぐに実行できます。

· フェーズ2：依存関係分析——シミュレーション段階で収集された依存関係のヒントをトランザクション間の依存関係を表す有向非循環グラフ（DAG）に変換します。このDAGは、次の並行実行におけるトランザクションスケジューリングを計画するために使用されます。

· フェーズ3：依存関係の解決に基づく並行実行——依存関係DAGに基づく修正版BlockSTMアルゴリズムを使用してトランザクションを並行して実行します。スケジューラーはもはや厳密にブロック内のトランザクションのシーケンス番号（1, 2, 3,..., n）に従ってトランザクションを選択するのではなく、DAGに基づいてトランザクションを優先的にスケジュールし、衝突を最小限に抑え、再実行の必要を減少させます。

非同期バッチ状態提出

状態提出の生成は、ブロックチェーンパイプラインにおける重要なボトルネックであり、メルケル化の本質的な順序性に起因します。各サブツリーの計算は、最終状態提出を生成する前に完了する必要があり、これが顕著な遅延を引き起こします。既存のソリューション（たとえば、rethのアカウントレベルの並行化）は一定の並行性を導入していますが、依然として大量の最適化空間があります。Gravity rethのブロックストリームリアクター（BSR）実行層の背景では、状態提出のコンセンサスとトランザクション実行を解耦し、実行をブロックすることなく、状態提出計算を非同期で遅延させ、バッチで処理することができます。

これらの問題を解決するために、提案されたフレームワークは以下の重要な革新を導入しました：

非同期バッチハッシュ計算：状態の提出コンセンサスとトランザクション実行の解耦を利用して、このフレームワークは状態の提出の非同期計算を実現しました。状態ルートの更新はバッチ処理（たとえば、10ブロックごとに計算）で行われ、状態ルート計算の頻度を減少させます。このバッチ処理方法は、共有された汚れたノードを集約し、効率的なハッシュ計算を実現することで、頻繁な更新のオーバーヘッドを最小限に抑え、全体的な計算コストを削減します。小さなブロックに対しては、バッチ処理が並行性を大幅に向上させます。大きなブロックに対しては、全体的な計算コストを削減できます。

完全並行化：このフレームワークは、単一のアカウントツリーだけでなく、全体の状態ツリーに並行化を拡張します。「汚れた」とマークされたノードについて、このフレームワークは並行状態計算アルゴリズムを採用し、木を独立したサブツリーに分割してそれらを並行して処理します。結果は、最終的なルートを効率的に計算するために上位で統合されます。この方法は、多くのトランザクションと状態変更を持つ大きなブロックが十分にマルチスレッドを活用できることを保証し、スループットを最大化します。

代替的な高速状態ルート：イーサリアムのブロックヘッダーおよびBLOCKHASHオペコード（最近の256ブロックの状態ルートへのアクセスが必要）の要件に適応するために、私たちは状態ルートを再定義しました。最終状態の提出（トランザクション実行中には利用できない）に依存するのではなく、状態ルートをブロック変更セットと以前の状態ルートのハッシュ値の組み合わせとして計算します。この方法により、状態ルートの計算がより迅速になり、完全な状態提出の完了を待つ必要がなくなります。

Gravity Store

高性能ブロックチェーンが大規模データ管理の要求を満たすために、Gravity Storeが最適化されたマルチバージョンストレージ層として登場しました。これはrethの設計に基づいており、rethは状態提出ストレージと状態データストレージを分離することで状態膨張の問題を減少させ、データの読み書きコストを低下させました。しかし、Gravity rethの実行層は、並行処理と非同期状態提出をさらにサポートする必要があり、さらなる技術的要求を提起しました。

これらの課題を解決するために、Gravity Storeは効率的なマルチバージョンツリー構造を提案し、私たちのBSR（Block Stream Reactor）アーキテクチャに特化しています。このツリー構造は、マルチバージョンの状態更新を管理することをサポートします。従来の方法では、変更後にすぐにハッシュ値を更新しますが、Gravity Storeでは変更されたノードを「汚れたノード」としてマークし、ハッシュ計算の遅延処理とバッチ実行を実現します。この設計により、新しいバージョンを迅速に作成し、特定のバージョンのデータを効率的にクエリし、指定された高さ未満の古いバージョンをクリーンアップすることができ、大幅にブロックチェーンの状態管理性能を向上させます。

さらに、Gravity DBという独立したストレージエンジンの開発を検討しており、その設計目標はブロックチェーンアプリケーションに最適化されたストレージ層を提供し、完全非同期I/O操作をサポートすることです。このエンジンの設計は、ブロックチェーン向けの高性能ログ構造化一般データベースエンジンLETUSにインスパイアされています。私たちの主任開発者RichardはLETUSの主要作成者の一人であり、その設計については近日中に公開されるブログ記事で詳しく説明します。

結論

Gravity Chainは、高性能なEVM互換の第一層ブロックチェーンであり、現代のWeb3アプリケーションのスケーラビリティと性能要求を満たすように設計されています。Gravity SDK、パイプライン型のAptosBFT PoSコンセンサスエンジン、およびGrevm駆動のBlock Stream Reactor実行層Gravity rethを組み合わせることで、Gravityは毎秒1ギガガスのトランザクションスループット、サブ秒レベルのトランザクション確認時間、およびリステーキングメカニズムに基づくPoSセキュリティを実現します。これらの技術コンポーネントの設計は、Web3アプリケーションにカスタムの代替L1ブロックチェーンまたはより効率的なL2ソリューションを作成するための堅実な基盤を提供し、特にEVMチェーンの使用シナリオを最適化するのに適しています。

この記事は投稿からのものであり、BlockBeatsの見解を代表するものではありません。