ETH 1.X：ステートレスイーサリアムの新発想「REGENESIS」
ソース |Ethereum Blog
著者 | グリフィン市場ホッチキス
最初のレベルのタイトル
Eth 1.x：ステートレスイーサリアムの新しいアイデア「reGenesis」今週は、技術ツリー
イーサリアム 1.x 開発にいくつかの新しい主要なマイルストーンを追加するためのアップデート。これらのマイルストーンはステートレス イーサリアムの完全な実装とはみなされませんが、中期的には合理的に達成できる目標です。
同時に、コード チャンキング (コード マークル化) や状態バイナリ ツリーなど、私たちに比較的近いいくつかの目標はすでに EIP の準備を進めています。この記事では、これまでの進捗状況を説明し、読者が興味のある分野を掘り下げることができるようにリンクを添付します。
最初のレベルのタイトル
二分木現在、イーサリアムは 16 個のフォークを使用していますパトリシア・メルケルの木
状態をエンコードしますが、バイナリに変換すると、特に監視サイズの点で効率が大幅に向上します。イーサリアムの状態を完全に再コーディングするには、明確な移行戦略だけでなく、新しいパラダイムの開発も必要です。最後に、スマート コントラクト コードをチャンク化して、このプロセスをバイナリ ツリー遷移に組み込むか、スタンドアロンの更新として組み込むかを決定する必要があります。
に記載されています）。ethresearch.
正式なバイナリ ツリー仕様とチャンキング ルールの説明は、次の場所にあります。
二分木への移行
バイナリ ツリー パラダイムの目的地だけが重要ではなく、その旅自体も重要です。理想的な移行では、ネットワークのトランザクション処理が中断されることはありません。つまり、クライアントは、15 秒ごとに出現する新しいブロックを処理しながら、新しいバイナリ ツリーを構築する必要があります。現在最も有望と思われる移行戦略は、「オーバーライド」メソッド
、これは部分的に geth の新しいスナップショット同期プロトコルに基づいています。一般に、バイナリ パラダイムでは、新しい状態の変更が既存の 16 進数に追加されます。これは、移行中に 2 進数と 16 進数が混在することを意味します。影響を受けない状態はバックグラウンド処理に移行します。変換後、2 つのレイヤーは 1 つのバイナリ ツリーにマージされます。
クライアントの多様性もバイナリ変換プロセスにおいて非常に重要な役割を果たすことに注意することが重要です。各クライアントは、独自のバージョンの移行を実装するか、他のクライアントに依存して移行を実行し、反対側で新しいツリーを待つ必要があります。
これには「よく考える」必要があり、すべてのクライアントが協力して移行のテストと調整を行う必要があります。セキュリティ上の理由から、移行中にネットワークを一時的に停止する必要がある可能性があります (例: いくつかの空のブロックをマイニングするため) が、具体的な計画について合意するには時期尚早です。
コードチャンク化
イーサリアムの状態ツリーの大部分はスマート コントラクト コードで構成されており、50 GB の状態のうち約 1 GB を占めます。スマート コントラクト インタラクションのすべての証人は、コード ハッシュを計算するためにインタラクションのコードを提供する必要があり、これにより大量の追加データが生成される可能性があります。
コードをチャンクに分割するにはさまざまな方法がありますが、複雑さに応じて、より単純な方法は一般的なチャンク化 (たとえば、各チャンク サイズが 64 バイト) であり、より複雑な方法は Solidity functionId または JUMPDEST 命令に基づく静的解析です。最適なコード チャンク化戦略は、最終的には、メイン ネットワークから収集された実際のデータに適用できるかどうかによって決まります。
reGenesis
文章@mandrigin による説明、同様に、同様に@realLedgerwatch によって提出された完全な提案
一言で言えば、reGenesis は基本的に「ブロックチェーンの大掃除」であると言えます。完全な状態は概念的に「アクティブ」状態と「非アクティブ」状態に分けられます。全体的な「アクティブ」状態は定期的に非アクティブ化され、その後、新しいトランザクションが作成されて、新しいアクティブ状態がほぼ最初から作成されます (そのため、「reGenesis」という名前が付けられています)。
トランザクションが以前の状態を必要とする場合、ステートレス イーサリアムで必要とされる証明と同様に、状態の変化が非アクティブな状態と一致することを証明するマークル証明が提供されます。トランザクションが状態の「非アクティブ」部分を必要とする場合、(トランザクションが成功したかどうかに関係なく) 自動的にそれを「アクティブ」状態に変更し、この部分は次の再生成が発生するまで残されます。
この利点の 1 つは、実際に状態を削除せずに、状態の使用に関して経済的な制約が生じることです。第 2 に、トランザクション送信者が盲目的に繰り返しトランザクションを試行している場合、証人を生成することはできません。
reGenesis の重要性に関しては、イーサリアムがステートレスの究極の目標に向けて大きな一歩を踏み出すとともに、ステートレスを達成するための最大の課題、つまり EVM 実行時のウィットネス ガスの計算方法を回避することができます。同時に、特定のバージョンのトランザクション監視をネットワーク内に伝播することも可能になり、より軽量なクライアントと Dapp 開発者がステートレス パラダイムと監視の生成に慣れる機会が増えるようになります。
再生成後の「真の」ステートレス性は程度の問題です。ステートレス イーサリアムは、実際には各ブロックの後の単なる再生成です。
州のネットワーク
当初から、ネットワーク プロトコルの最適化はテクノロジー ツリーの単なる「副次的なタスク」でしたが、reGenesis がステートレス イーサリアムの領域に入ると、イーサリアム チェーン データ (ステートを含む) を共有するための代替ネットワーク プリミティブを探索することが重要なタスクになりました。 ）のメインミッション。現在のイーサリアムのネットワーク プロトコルは全体ですが、実際には、異なる「サブネットワーク」を通じて共有できる複数の種類のデータがあり、これらの「サブネットワーク」はさまざまなニーズを満たすことができます。以前にステートレス セッションでこのトピックを議論したとき、私たちはそれを，「3つのネットワーク」DHTベース
ネットワークは、頻繁に変更されないデータ型をより効率的に処理できます。 reGenesis の導入により、この種の頻繁に変更されないデータに「非アクティブ」状態を含めることができ、理論的には、現在のフル ノードによる 1 つずつのブロードキャストの代わりに、ビットストリーム スウォーム ネットワークに適用できます。最後の reGenesis 以降、ネットワーク全体に不変状態を伝播するネットワークは静的状態ネットワークです。devp2p ライブラリの新しい Discovery v5.1 仕様に基づく (Ethereum ネットワーク プロトコル)
張る。Merry-go-Round sync以前と同様のSNAP protocolはアクティブ状態の同期に使用でき、完全に分散された動的状態ネットワークに向けた重要なステップであり、クライアントが完全な状態を迅速に同期できるようになります。
エピローグ
エピローグステートレス イーサリアム テクノロジー ツリーの各ブランチのより詳細な技術的説明については、読者は以下を参照してください。、これらのトピックはすべて、Eth1x/2 R&D Discord で議論することもできます。参加したい場合は、ethresear.ch で招待を求めることができます。フィードバックや提案については、Twitter の @gichiba または @JHancock までご連絡ください。
免責事項: ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に属します。転載する場合は、原文と ethereum.cn の出典を示す必要があります。再版の場合は、ethereumcn@gmail.com までご連絡ください。
