パラダイムCTOが語る：レスはいかにして毎秒1GBのガスを実現したか

著者: Georgios Konstantopoulos, Research Partner & CTO, Paradigm; Translated by Golden Finance xiaozou

私たちは2022年にRethの構築を開始し、イーサネットL1に耐障害性を提供する一方で、L2上の実行レイヤーのスケーリングに取り組んでいます。

本日は、Rethが2024年にL2で毎秒1GBのスループットを達成する計画と、その目標を超えるための長期的なロードマップを共有できることを嬉しく思います。

私たちは、エコシステム全体が暗号におけるパフォーマンスのフロンティアと厳格なベンチマークを押し進めることに参加するよう呼びかけます。

1.スケールアウトは達成できましたか？

暗号通貨が世界的な規模に達し、投機（これが主なユースケースになる）を避けるには、非常にシンプルな方法があります。

1.1 パフォーマンスはどのように測定されますか？1秒あたりのガス量は何を指すのですか？

性能はしばしば「トランザクション/秒」（TPS）で測定されます。より微妙で、おそらくより正確な指標は、特にイーサや他のEVMブロックチェーンでは、「1秒あたりのガス量」です。この指標は、ネットワークが1秒間に処理できる計算量を反映したもので、「ガス」は取引やスマートコントラクトなどの処理を実行するのに必要な計算量の測定単位です。

パフォーマンス指標として1秒あたりのガスを正規化することで、ブロックチェーンの容量と効率をより明確に把握することができます。また、あまり粒度の細かくない測定値を利用できる潜在的なサービス拒否（DOS）攻撃に対するシステムのコストへの影響を評価するのにも役立ちます。この指標は、異なるイーサリアム仮想マシン（EVM）互換チェーンのパフォーマンスを比較するのに役立ちます。

私たちは、EVMコミュニティが1秒あたりのガス量を標準メトリックとして採用し、他のガス価格次元と組み合わせて包括的なパフォーマンス標準を作成することを推奨します。

1.2現在の状況

1秒あたりのガス量は、各ブロックの目標ガス使用量をブロック時間で割ることによって決定されます。以下の表では、異なるEVMチェーンL1とL2について、1秒あたりの現在のガススループットとレイテンシを示しています(網羅的ではありません):

1秒あたりのガス量を重視し、コンピュートとストレージのコストを把握しながら、EVMネットワークのパフォーマンスを完全に評価するために使用しています。Solana、Sui、Aptosなどのネットワークは、独自のコストモデルのため除外しています。私たちは、包括的で公平な比較のために、すべてのブロックチェーンネットワークのコストモデルを調和させる努力を奨励しています。

私たちは、実際のワークロードを複製するために、Reth用のノンストップベンチマークツールのセットを開発しています。ノードに対する私たちの要件は、TPCベンチマークに準拠することです。

2.どのようにしてRethは1秒あたり1GBのガスに達するのでしょうか?

2022年にRethを作成した動機の1つは、ウェブロールアップ用に構築されたクライアントがどうしても必要だったからです。私たちは、前途は有望であると見ています。

Rethは、リアルタイムの同期（送信者のリカバリ、トランザクションの実行、各ブロックのトライの計算を含む）において、すでに毎秒100～200MBのガスが発生しています。

したがって、毎秒1GBのガスという短期的な目標を達成するためには、さらに10倍スケールアップする必要があります。

Rethが成長するにつれて、私たちのスケーリング計画はスケーラビリティと効率のバランスを見つけなければなりません。

• Vertical scaling: 私たちの目標は、各「ボックス」を最大限に利用することです。それぞれの「箱」の可能性を最大限に引き出すことです。個々のシステムがトランザクションとデータを処理する方法を最適化することで、全体のパフォーマンスを劇的に向上させ、同時に各ノードのオペレーターをより効率的にすることができます。

• 水平スケーリング：最適化にもかかわらず、ウェブスケールのトランザクションの絶対量は、1つのサーバーの処理能力を超えます。これに対抗するため、ブロックチェーンノードのKubernetesモデルに似た水平スケーリングアーキテクチャの導入を検討します。これは、単一のノードがボトルネックにならないように、複数のシステムに作業負荷を分散することを意味します。

私たちがここで探求している最適化は、ステートフルな成長ソリューションには関与しません。

全体的な技術スタックでは、スタックの各部分をサービスとして展開し、その使用量をきめ細かく制御できるという考えをサポートするアクターモデルを使用して、IOとCPUも最適化しています。最後に、まだ特定されていない代替データベースを積極的に評価しています。

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

垂直スケーリングの目標は、Rethを実行しているサーバーやラップトップのパフォーマンスと効率を最大化することです。

(1)イーブン・イン・タイム(ジャスト・イン・タイム)EVMとアヘッド・オブ・タイム(時間先行)EVM

イーサ仮想マシン(EVM)のようなブロックチェーン環境では、バイトコードの実行はインタープリターを通じて行われ、インタープリターは命令を逐次処理します。命令を処理します。このアプローチでは、ネイティブのアセンブリ命令が直接実行されるのではなく、VMレイヤーを通して操作が実行されるため、若干のオーバーヘッドが発生します。

ジャスト・イン・タイム（JIT）コンパイルは、実行前にバイトコードをネイティブのマシンコードに変換することでこの問題を解決し、VMの解釈プロセスをバイパスしてパフォーマンスを向上させます。コントラクトを事前に最適化されたマシンコードにコンパイルするこの手法は、JavaやWebAssemblyなどの他のVMではすでに確立されています。

しかしながら、JITは、JITプロセスの脆弱性を悪用するように設計された悪意のあるコードや、実行中にリアルタイムで実行するには遅すぎるコードに対して脆弱である可能性があります。

Rethは、最も需要の高いコントラクトを前もってコンパイルし（AOT）、ディスクに保存することで、リアルタイム実行中に私たちのネイティブコードコンパイルプロセスを悪用する信頼されていないバイトコードの試みを回避します。

私たちはRevm用のJIT/AOTコンパイラを開発しており、現在それをRethに統合しています。ベンチマークが終わり次第、数週間以内にオープンソース化する予定です。平均して、実行時間の約50％がEVMインタープリタに費やされるため、約2倍のEVM実行改善が必要になるはずですが、計算ニーズがより大きいケースでは、影響はさらに大きくなる可能性があります。

(2) 並列EVM

並列イーサネット仮想マシン (並列EVM) の概念は、従来のEVMのシリアル実行モデルとは対照的に、複数のトランザクションの同時処理をサポートします。実行モデルとは対照的に、複数のトランザクションの同時処理をサポートします。

• History Sync: History Syncにより、履歴トランザクションを分析し、すべての履歴状態の競合を特定することで、最適な並列スケジューリングを計算できます。

• リアルタイム同期：リアルタイム同期では、Block STMのような技術を使用して、追加情報（アクセスリストなど）なしで実行を推測することができます。このアルゴリズムは、状態の競合が激しい間はパフォーマンスが低下するため、作業負荷の状況に基づいてシリアル実行と並列実行を切り替えることや、並列品質を向上させるためにどのストレージスロットにアクセスするかを静的に予測することを検討したいと考えています。

過去の分析によると、イーサネット ストレージ スロットの約 80% が独立してアクセスされています。

(3)ステートコミットの最適化

Rethモデルでは、ステートルートの計算はトランザクションの実行とは独立したプロセスであり、トライ情報を取得する必要のない標準的なKVストアを使用することができます。これは現在、ブロックを封印（SEAL）するエンドツーエンド時間の75％を要しており、最適化のための非常にエキサイティングな領域です。

私たちは、プロトコルを変更することなく、ステートルートのパフォーマンスを2～3倍向上させるための以下の2つの「簡単な勝利」の道を特定しました。type: disc;">

これに加えて、イーサネットL1のステートルート活動から逸脱して、いくつかのパスを探索することができます。

• Lower-frequency state root computation: 各ブロックでのステートルート計算はありません。ステートルートはTブロックごとに1回計算されます。これは、システム全体でステートルートに費やされる時間の合計割合を減らし、おそらく最もシンプルで効率的なソリューションです。

• 状態のルートを追跡する：同じブロック上で状態のルートを計算するのではなく、数ブロック後ろにある方がよい。これにより、状態のルート計算をブロックすることなく実行を進めることができます。

• RLPエンコーダーを置き換える & Keccak256:RLPエンコーディングを使用するよりも、単にバイトをマージし、より高速なハッシュ関数(Blake3など)を使用する方がコストがかからない場合があります。

• より広いトライ: ツリーのN-arityの子ノードを増やして、トライのlogN深さによるIOの増加を減らします。

ここでいくつか質問があります:

• 上記の変更は、ライトクライアント、L2、ブリッジ、コプロセッサ、および頻繁なアカウントとストレージ証明に依存する他のプロトコルに影響を与えます。

• 上記の変更は、ライトクライアント、L2、ブリッジ、コプロセッサ、および頻繁なアカウントとストレージ証明に依存する他のプロトコルにどのような副次的な影響がありますか?

• ネイティブの実行速度のために、SNARK証明とステートフルな約束の両方を最適化できますか?

• 今あるツールで得られる最も広範な状態約束とは何でしょうか?証人のサイズに対する副次的な効果は何でしょうか?

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

私たちは、1秒あたり1GBのガスという目標を達成するために、2024年を通して上記の多くを実行する予定です。

しかし、垂直スケーリングは、最終的には物理的な限界と実地的な限界にぶつかります。1台のマシンで世界のコンピューティングニーズを処理できるわけではありません。

(1) 複数のロールアップ

今日のL2スタックは、チェーンを追跡するために複数のサービスを実行する必要があります。これはモジュール性には優れているが、複数のノード・スタックを実行する場合、状況はより複雑になる。100のロールアップを実行しなければならないことを想像してみてください！

私たちは、Rethの進化に合わせてロールアップの同時リリースを可能にし、何千ものロールアップを実行する運用コストをほぼゼロにしたいと思います。

私たちはすでに実装拡張プロジェクトでこれに取り組んでいます。

(2)クラウドネイティブなReth

高性能なシーケンサーでは、1つのチェーンに多くの需要がある場合があり、スケールアウトする必要がありますが、1台のマシンでは追いつきません。これは今日のシングルノードの展開では不可能です。

私たちは、クラウドネイティブなRethノードの実行をサポートし、コンピュート需要に基づいて自動的にスケールできるサービススタックとしてデプロイし、永続的なストレージとして無限に見えるクラウドオブジェクトストレージを使用できるようにしたいと考えています。これは、NeonDB、CockroachDB、Amazon Auroraなどのサーバーレスデータベースプロジェクトで一般的なアーキテクチャです。

3.今後の展望

私たちは、このロードマップをすべてのRethユーザーに徐々に展開していきたいと考えています。私たちの使命は、毎秒1GB以上のガスをすべての人が利用できるようにすることです。私たちはReth AlphaNetで最適化をテストし、人々が最適化された高性能ノードを構築するSDKとしてRethを使用することを望んでいます。

まだ答えが見つかっていない質問もあります。

• RethはL2エコシステム全体のパフォーマンス向上にどのように貢献できるのでしょうか？

• 一般的に、いくつかの最適化で起こりうる最悪のシナリオを適切に測定するにはどうしたらよいでしょうか?

• L1とL2の間の潜在的な乖離をどう扱うか？

これらの質問の多くに対する答えはまだ持っていませんが、しばらくの間忙しくするのに十分な、有望な初期のアイデアがたくさんあります。