2022年にRethの構築を開始し、Ethereum L1に弾力性を提供し、レイヤー2の実行レイヤースケーリングを解決することを目指しています。

今日は、2024年にL2で1ギガガスを達成するRethの道のりと、それを超える長期的なロードマップを共有できることをうれしく思います。

私たちは、暗号通貨のパフォーマンスと厳格なベンチマークの最前線を推進するにあたり、エコシステムとの協力を呼びかけます。

私たちはもうスケールされていますか？

仮想通貨がグローバルスケールに到達し、支配的なユースケースとしての投機から脱却するための非常にシンプルな道があります：取引が安くて速い必要があります。

パフォーマンスをどのように計測しますか？1秒あたりのガスとは何を意味しますか？

パフォーマンスは通常、「Transactions Per Second」（TPS）という指標によって測定されます。特にEthereumや他のEVMブロックチェーンにとって、より微妙で正確な指標は「1秒あたりのガス」です。この指標は、ネットワークが毎秒処理できる計算作業量を反映し、ここで「ガス」とは、トランザクションやスマートコントラクトのような操作を実行するために必要な計算作業量を測定する単位です。

パフォーマンスメトリックとしてのガス毎秒の標準化により、ブロックチェーンの容量と効率をより明確に理解することができます。また、システムへのコストの影響を評価するのにも役立ち、より微妙な測定を悪用する可能性があるサービス拒否（DOS）攻撃から保護します。このメトリックは、異なるEthereum Virtual Machine（EVM）互換チェーン間でのパフォーマンスの比較に役立ちます。

EVMコミュニティに、秒ごとのガスを標準メトリックとして採用することを提案し、ガス価格の他の側面包括的なパフォーマンス基準を作成する

今日はどこにいますか？

ガス毎秒は、ブロックあたりのターゲットガス使用量をブロック時間で割ることで決定されます。ここでは、さまざまなEVMチェーンL1およびL2（完全ではない）における現在のガス毎秒スループットとレイテンシを紹介します。

EVMネットワークのパフォーマンスを徹底的に評価するために、秒あたりのガスを重視しており、計算コストとストレージコストの両方を捉えています。Solana、Sui、Aptosなどのネットワークは、独自のコストモデルのため含まれていません。すべてのブロックチェーンネットワークでコストモデルを調和させ、包括的で公正な比較を可能にする取り組みを奨励します。

私たちは実際のワークロードを再現するRethの連続ベンチマークスイートに取り組んでいます。この件で協力したい場合は、ぜひご連絡ください。TPCベンチマークノード用。

Rethはどのようにして1ギガガス毎秒に達するのですか？それ以上は？

2022年にRethを構築する動機の一部は、Webスケールのロールアップ向けに目的に合ったクライアントを持つ必要性によるものでした。有望な道があると考えています。

Rethはすでにライブ同期中に100-200mgas/sを達成しています（送信者の回復、トランザクションの実行、およびすべてのブロックでトライの計算を含む）; ここから10倍にすると、私たちの短期目標である1ギガガス/sに到達します。

Rethの開発を進めるにつれて、スケーリング計画は拡張性と効率をバランスさせなければなりません。

• 縦方向のスケーリング：ここでの目標は、各「ボックス」を最大限活用することです。各個々のシステムが取引とデータをどのように処理するかを最適化することで、全体的なパフォーマンスを大幅に向上させると同時に、個々のノードオペレーターにとっても効率的にします。
• 水平スケーリング：最適化にもかかわらず、Webスケールの取引の数は、単一のサーバーが処理できる範囲を超えています。これを解決するために、私たちはブロックチェーンノードのためのKubernetesモデルに似た水平スケールアーキテクチャを実装したいと考えています。つまり、作業を複数のシステムに分散させて、単一のノードがボトルネックにならないようにすることを意味します。

ここで探っている最適化には解決が関係していません状態成長, which we are researching separately.

こちらが到達する方法の要約です:

全体のスタック全体で、アクターモデルを使用してIOとCPUの最適化も行っており、スタックの各部分をサービスとして展開し、その利用を細かく制御することができます。最後に、代替データベースを積極的に評価していますが、まだ候補を決定していません。

Rethの垂直スケーリングロードマップ

私たちの目標は、Rethを実行している単一のサーバーまたはノートパソコンのパフォーマンスと効率を最大限に高めることです。

Just-In-Time & Ahead-of-Time EVM

ブロックチェーン環境（EVM）のような環境では、バイトコードの実行は、逐次的に命令を処理するインタプリタを介して行われます。この方法では、ネイティブアセンブリ命令を直接実行せず、VMレイヤーを介して操作するため、オーバーヘッドが発生します。

Just-In-Time (JIT)コンパイルは、実行直前にバイトコードをネイティブ機械コードに変換することで、VMの解釈プロセスをバイパスしてパフォーマンスを向上させることでこれに対処します。このテクニックは、契約を最適化された機械コードに事前にコンパイルすることで、JavaやWebAssemblyなど他のVMでよく確立されています。

ただし、JITは、JITプロセスを悪用するように設計された悪意のあるコードに対して脆弱である可能性があり、実行中にライブで実行するには速すぎるかもしれません。Rethは、最も需要の高い契約をAhead-of-Time（AOT）でコンパイルし、それらをディスクに保存して、実行中に信頼されていないバイトコードがネイティブコードのコンパイルステップを悪用しようとするのを避けるようにします。

Revm用のJIT/AOTコンパイラをRethと統合中です。ベンチマークが完了次第、数週間以内にオープンソース化します。実行時間の約50%が平均でEVMインタプリタで費やされるため、これによりEVM実行が約2倍改善されるはずです。ただし、計算量の多いケースではさらに影響が大きいかもしれません。数週間以内に、Rethでの独自のJIT EVMのベンチマークと統合を共有します。

並列EVM

Parallel Ethereum Virtual Machine（Parallel EVM）のコンセプトは、EVMの従来の直列実行モデルから逸脱し、同時トランザクション処理を可能にします。ここでは、2つの進むべき道があります。

1. 履歴同期：履歴同期では、過去の取引を分析し、すべての履歴状態の競合を特定することで、最適な並列スケジュールを計算することができます。この取り組みの初期段階は、以前のブランチで見ることができます。ギットハブ.
2. ライブ同期：ライブ同期には、を使用できますブロックSTM-のような手法を用いて、アクセスリストなどの追加情報なしに仮実行するアルゴリズム。 このアルゴリズムは、状態の競合が激しい期間には性能が低いため、ワークロードの形状に応じて直列実行と並列実行を切り替えたり、静的にどのストレージスロットがアクセスされるかを予測して並列性の質を向上させたりすることを検討したいと考えています。 3rd party teamによる1つのPoCを参照してください。ここ.

私たちの歴史的な分析に基づくと、Ethereumのストレージスロットの約80%が独立してアクセスされており、並列処理によってEVMの実行が最大5倍向上する可能性があります。

国家コミットメントの向上

私たちは最近書かれたパフォーマンスにおけるステートルートの影響と、他のクライアントとのRethデータベースモデルの違い、およびその重要性について

Rethモデルでは、状態ルートの計算はトランザクションの実行とは別のプロセスです見る 私たちのコード）、標準のKVストアの使用を可能にし、トライについて何も知る必要がない。 これは現在、ブロックを封印するための終了時間の75%以上を占めており、最適化する非常に興味深い分野です。

私たちは、プロトコルの変更なしに、状態ルートのパフォーマンスを2〜3倍に向上させることができる次の2つの「簡単な勝利」を特定しています:

1. 完全に並列化されたステートルート：現在、変更されたアカウントのストレージTrieだけを並列に再計算していますが、さらに進んで、ストレージルートのジョブがバックグラウンドで完了する間にアカウントTrieも並列に計算することができます。
2. パイプライン化された状態ルート：実行中にディスクから中間トライノードを事前に取得し、ストレージスロットとアカウントの変更を状態ルートサービスに通知します。

それを超えると、Ethereum L1のステートルート動作から逸脱するいくつかの進むべき道が見えてきます。

1. State Rootの頻度を減らす：毎ブロックで状態ルートを計算する代わりに、Tブロックごとに計算します。これにより、システム全体で状態ルートに費やされる時間の割合が減少し、これが最も簡単で効果的な解決策となる可能性があります。
2. トレーリングステートルート：同じブロックで状態ルートを計算する必要がある代わりに、数ブロック遅れている状態ルートを計算します。これにより、状態ルートの計算でブロックされることなく、実行を進めることができます。
3. RLPエンコーダーとKeccak256を置換：RLPでエンコードする代わりに、バイトを単純に連結してBlake3のような高速ハッシュ関数を使用する方が安価かもしれません。
4. Wider Trie: 木のN-リティを増やして、トライのlogN深さによるIO増幅を減らす。

ここにはいくつかの質問があります:

1. 上記の変更が軽量クライアント、L2、ブリッジ、コプロセッサ、および頻繁なアカウント＆ストレージ証明を必要とする他のプロトコルに与える2次効果は何ですか？
2. SNARK証明とネイティブ実行速度の両方を最適化できますか？
3. 私たちが利用可能なツールで得られる最も広範な状態のコミットメントは何ですか？証人のサイズ周辺にはどんな2次効果がありますか？

Rethの水平スケーリングのロードマップ

2024年を通して、上記の複数のポイントを実行し、1ギガガス/秒の目標を達成します。

ただし、垂直スケーリングは最終的に物理的および実用的な限界に遭遇します。 1台のマシンでは世界のコンピューティングニーズを処理することはできません。 もっと多くのボックスを導入することで、より多くの負荷が到着するにつれてスケールアウトすることを許可する2つの方法があると考えています。

Multi-Rollup Reth

今日のL2スタックには、チェーンに従うために複数のサービスを実行する必要があります：L1 CL、L1 EL、L1 -> L2導出関数（L2 ELとまとめている場合があります）、およびL2 EL。モジュラリティには優れていますが、複数のノードスタックを実行する場合は複雑になります。100のロールアップを実行しなければならないと想像してください！

私たちは、Rethと同じプロセスでrollupsの起動を許可し、数千のrollupsをほぼゼロに近いランニングコストで実行することを目指しています。

私たちはすでにこれを進行中です実行エクステンションプロジェクト([1], [2])、今後数週間でさらに増える予定です。

クラウドネイティブReth

ハイパフォーマンスのシーケンサーは、単一のチェーンでの需要が大きいため、単一のマシンを超えてスケーリングする必要があります。これは、現在のモノリシックなノードの実装では不可能です。

Cloud-native Rethノードを実行し、コンピューティング需要に応じて自動スケーリングし、永遠のクラウドオブジェクトストレージを使用して永続化できるサービススタックとして展開することを許可したいと考えています。これはNeonDB、CockroachDB、またはAmazon Auroraなどのサーバーレスデータベースプロジェクトで一般的なアーキテクチャです。

見る初期の考え私たちのチームから、この問題に取り組むいくつかの方法についての提案

見通し

このロードマップを段階的にすべてのRethユーザーに展開する予定です。私たちの使命は、誰もが1ギガガス/s以上にアクセスできるようにすることです。Reth AlphaNetで最適化をテストし、RethをSDKとして使用して変更された高性能ノードを構築する人々を期待しています。

まだ答えが出ていない質問がいくつかあります。

• RethがL2エコシステム全体のパフォーマンス向上にどのように役立つのか？
• 私たちが最悪のケースを適切に測定する方法は何ですか？最適化の一部が平均ケース向けである可能性がある場合はどうすればよいですか？
• L1とL2の潜在的な発散の緊張をどのように管理すればよいですか？

これらの質問の多くには答えがありませんが、私たちにはしばらく忙しくするだけの初期の有望な手がかりがあり、これらの取り組みが今後の数ヶ月で実を結ぶことを願っています。

免責事項：

1. この記事は[から転載されましたパラダイム], すべての著作権は元の著者に帰属します[ゲオルギオス・コンスタントプロス]. If there are objections to this reprint, please contact the Gate Learnチームが promptly に対処します。
2. 責任の免責事項：この記事で表現されている意見や考えはすべて著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。