jakiro
著者：Georgios Konstantopoulos、Paradigm Research Partner＆AMP;
2022年にRethを構築し始め、L2での実行層の拡張を解決しながら、Ethereum L1に弾力性を提供しました。
今日、2024年のReth Planが1GBのガススループットを1秒間に達成する方法と、長期ロードマップでこの目標をどのように上回ることができるかをあなたと共有できることを嬉しく思います。
エコシステム全体を招待して、暗号化フィールドでパフォーマンスの最先端と厳格なベンチマークテストを共同で促進します。
1.スケール拡張を達成しましたか？
暗号通貨が世界規模に到達し、投機的行動を避けたい場合（主なケースとして）、非常に簡単な方法があります。トランザクションは低くて高速でなければなりません。
1.1パフォーマンスを測定する方法は？1秒あたりのガス量はいくらですか？
パフォーマンスは通常、「1秒あたりのトランザクション数」（TPS）で測定されます。特にイーサリアムやその他のEVMブロックチェーンの場合、より繊細でより正確な測定基準は「ガス量あたりの量」です。このインジケータは、1秒あたりの処理できるコンピューティングワークロードを反映しています。
ブロックチェーンの容量と効率をよりよく理解するためのパフォーマンスインジケーターとして標準化されています。また、システムのコスト効果を評価し、潜在的な拒絶サービス（DOS）攻撃を防ぐことができます。このインジケータは、Ethereum Virtual Machine（EVM）と有能なチェーンのパフォーマンスを比較するのに役立ちます。
EVMコミュニティは、標準インジケーターとして1秒あたりのガス量を採用し、同時に他のガス価格設定の寸法と組み合わせて包括的なパフォーマンス標準を作成することをお勧めします。
1.2今日の開発段階
1秒あたりのガスの量は、各ブロックのターゲットガスをブロック時間ごとに除去することにより決定されます。以下の表では、さまざまなEVMチェーンL1とL2の現在のガススループットと遅延を示しています（詳細ではありません）。
1秒あたりのガスの量は、EVMネットワークのパフォーマンスを包括的に評価するために使用され、同時に計算コストとストレージコストをキャプチャすることを強調します。Solana、SUI、Aptosなどのネットワークは、独自のコストモデルのために含まれていません。すべてのブロックチェーンネットワークのコストモデルを推奨して、包括的かつ公正な比較を実現します。
RETHが実際のワークロードをコピーするための途切れない基礎テストツールのセットを開発しています。ノードの要件は、TPCベンチマークに沿っています。
2。レスはどのようにして1 GBガスに到達しますか？さらに高い？
2022年にレスの作成の動機のいくつかは、Webロールアップのためにクライアントが緊急に必要なためです。私たちの前進は希望に満ちていると思います。
リアルタイムの同期中、レスは100〜200MBのガスに達しました（送信者の回復、各ブロックの計算を含む）。 10回拡張。
Rethの開発により、当社の拡張計画は、スケーラビリティと効率のバランスを見つける必要があります。
-
垂直拡張：私たちの目標は、各「ボックス」の使用を最大化して、その可能性に完全なプレーを与えることです。各単一システムのトランザクションとデータの処理方法を最適化することにより、全体的なパフォーマンスを大幅に改善し、同時に各ノードのオペレーターをより効率的にすることができます。
-
水平拡張：最適化されていますが、Webサイズの絶対トランザクションボリュームは、任意のサーバーの処理能力を超えています。この状況に対処するために、ブロックチェーンノードのKubernetesモデルに似た水平拡張アーキテクチャの展開を検討します。これは、ノードなしでボトルネックになる可能性のあるノードがないことを意味します。
ここで説明する最適化は、コンテンツのこの部分については、他の記事で個別に議論されています。以下は、この目標を達成するための計画の概要です。
テクノロジースタック全体では、スタックのすべての部分をサービスとして展開することができ、それらを細かく使用してIOとCPUを最適化しました。最後に、代替データベースを積極的に評価していますが、決定されていません。
2.1垂直拡張ロードマップ
私たちの垂直拡張目標は、Rethを実行するサーバーまたはラップトップのパフォーマンスと効率を最大化することです。
（1）偶数（Just-in-Time）EVMおよび昔のEVM
Ethereum Virtual Machine（EVM）のようなブロックチェーン環境では、Bytecodeの実行がインタープリターを介して実行され、インタープリターは命令を順番に処理します。この方法では、ネイティブアセンブリ命令が直接実行されるのではなく、VMレイヤーを介して実行される操作が行われるため、一定の費用が発生します。
インスタントコンピレーション（JIT）は、バイトコードをネイティブマシンコードに変換して実行する前に、VMの解釈プロセスをバイパスすることでパフォーマンスを向上させることにより、この問題を解決します。このテクノロジーは、契約を事前に最適化されたマシンコードにコンパイルできます。これは、JavaやWebAssemblyなどの他の仮想マシンで適切に使用されています。
ただし、JITは悪意のあるコードによって簡単に攻撃される可能性があります。Rethは、実際の実行中にネイティブコードの編集プロセスを乱用しようとしないプロセスを避けるために、ディスクにコンパイル（AOT）の最高の要件をコンパイルし、それらをディスクに保存します。
私たちはREVMのJIT/AOTコンパイラを開発しており、現在Rethと統合されています。今後数週間でベンチマークテストを完了した直後にオープンソースを開きます。平均して、実行時間の約50％がEVMインタープリターに費やされるため、EVM実行の改善の約2倍が必要ですが、一部の計算要件が大きい場合、影響は大きくなる可能性があります。今後数週間で、ベンチマークテストを共有し、独自のJIT EVMをRethに統合します。
（2）並列EVM
並列イーサリアム仮想マシン（Parallel EVM）の概念は、従来のEVMシリアル実行モデルとは異なる複数のトランザクションを同時にサポートしています。次の2つのパスがあります。
-
歴史的同期：履歴の同期は、過去のトランザクションを分析し、すべての歴史的な国家紛争を特定することにより、最適な並列曲を計算できます。
-
REAL -TIME同期：REAL -TIME同期のために、ブロックSTMと同様のテクノロジーを使用して、追加情報なしで実行を推測できます（アクセスリストなど）。このアルゴリズムは、厳しい州の競争中にパフォーマンスが低いため、ワークロードステータスに応じたシリアル実行と並列実行の切り替えと、並列品質を改善するためにどのストレージスロットにアクセスするかを検討したいと考えています。
私たちの歴史的分析によると、Ethereum Storage Slotの約80％は独立しています。つまり、並列はEVM実行効率を5倍増加させる可能性があります。
（3）最適化された州のコミットメント
RETHモデルでは、ステータスルートの計算はトランザクションに依存しないプロセスであり、Trie情報を取得する必要のない標準のKVストレージを使用できます。これには現在、ブロックを封印するための終了時間の75％が必要です。これは非常にエキサイティングな最適化分野です。
次の2つの「簡単な勝利」チャネルは、合意の変更なしにステータスルーツのパフォーマンスを2〜3回増やすことができると判断しました。
-
完全に平行な状態のルート：アカウントを変更したストレージツリーのみを再計算しますが、バックグラウンドでストレージのルーツが完了すると、アカウントツリーが並行して計算されます。
-
パイプラインステータスルート：実行プロセス中に、状態ルートサービスに関与するスロットとアカウントが保存され、中間トリエノードはディスクから事前に作成されます。
さらに、Ethereum L1ステータスルートアクティビティから逸脱して、いくつかの前方パスを探索することもできます。
-
低周波状態のルーツの計算：各ブロックのステータスルートを計算しませんが、各Tブロックごとに計算されます。これにより、システム全体の状態根の総時間割合が短縮されます。これは、最も単純で最も効果的なソリューションである可能性があります。
-
ステータスのルーツの追跡：同じブロックでステータスルートを計算するよりも、数ブロックの後ろに落ちる方が良いでしょう。このようにして、状態のルート計算をブロックすることなく、実行を進めることができます。
-
RLPエンコーダー＆amp; keccak256を交換します。RLPエンコーディングを使用して、バイトを直接組み合わせて、より速いハッシュ関数（Blake3など）を使用することができます。
-
より広いトリー：Trieのlognの深さのために拡大するIOを減らすために、ツリーN-rateサブノードを追加します。
ここにはいくつかの質問があります：
-
ライトクライアント、L2、ブリッジ、協力者、および頻繁なアカウントとストレージ証明書に依存するプロトコルのその他の二次的な影響に関する上記の変更は何ですか？
-
同時に、スナークの証明とネイティブの実行速度のステータスコミットメントを最適化できますか？
-
既存のツールで、私たちが得ることができる最も広い州の約束は何ですか？証人への二次的な影響は何ですか？
2.2レスの水平拡張ロードマップ
2024年を通じて上記の複数のアイテムを実行して、1秒あたり1GBガスの目標を達成します。
ただし、垂直拡張は最終的に物理的および実用的な制限に遭遇します。世界のコンピューティングニーズを処理できるマシンはありません。ここには、負荷が拡大した後により多くのボックスを導入することで拡張するための2つのパスがあると思います。
（1）マルチロールアップレス
今日のL2スタックは、チェーンを追跡するために複数のサービスを実行する必要があります。L1CL、L1 EL、L1-＆GT;これはモジュール化に非常に適していますが、複数のノードスタックを実行すると状況がより複雑になります。100個のロールアップを実行する必要がある場合は想像してみてください！
レスの開発中にロールアップを同時に許可し、数千のロールアップの運用コストをほぼゼロに削減したいと考えています。
実装拡張プロジェクトでこれを行いましたが、今後数週間でさらに進歩が遂げられます。
（2）Yunyuan Reth
高いパフォーマンスソーターは、単一のチェーンに対して多くの需要がある場合があり、拡張する必要があり、マシンはそのニーズを満たしていません。これは、今日のシングルノード展開を展開することは不可能です。
実行中のクラウドノードをサポートし、サービススタックとして展開し、計算要件に従って自動的に展開し、一見無限のクラウドオブジェクトストレージを使用して永続的なストレージを実現できることを願っています。これは、サーバーデータベースプロジェクト（NeondB、CockrochDB、Amazon Auroraなど）の一般的なアーキテクチャです。
3。将来の見通し
このルートマップをすべてのRethユーザーに徐々に起動したいと考えています。私たちの使命は、誰もが1秒あたり1GBガスの高速を得ることができることです。Reth Alphanetで最適化されたテストを実施します。人々がRethをSDKとして使用して、最適化された高性能ノードを構築することを願っています。
答えは見つかりませんでした。
-
レスは、L2エコロジー全体のパフォーマンスをどのように改善するのに役立ちますか？
-
一般的に発生する可能性のある最悪の状況のいくつかをどのように適切に測定できますか？
-
L1とL2の潜在的な違いにどのように対処しますか？
これらの質問の多くは答えを持っていませんが、明るい見通しを持つ多くの最初のアイデアがあります。
