イーサリアムを再起動することでノードの負担は軽減できるでしょうか？
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
、著者：Alexey Akhunov、翻訳および校正：Min Min & A Jian、Odailyの許可を得て転載。
Cosmos Hub の経験
Cosmos Hub がバージョン 1.0 からバージョン 2.0、バージョン 3.0 にどのようにアップグレードされたかを見たことがあれば、Cosmos Hub のアップグレードは基本的に、新しいジェネシス ブロックでブロックチェーンを再起動することによって達成されることがわかるでしょう。アップグレードする場合、ノード オペレーターはノードをシャットダウンし、Cosmos Hub 状態のスナップショットを生成し、このスナップショットを新しいジェネシス ブロックにパッケージ化して新しいブロックチェーンを作成する必要があります。
副題
ETH 1.0を「再起動」できますか?
同じ方法がイーサリアムに適用できるかどうかを想像してみましょう。 Ethereum ブロックチェーンは巨大 (150 ～ 160 Gb) であり、状態も巨大です (状態の保存方法に応じて 40 ～ 100 Gb)。イーサリアム ブロックチェーンを「再起動」することの明らかな利点は、新しく参加するノードが 150 GB のブロックチェーンではなく 40 GB の生成状態をダウンロードする必要があることです。ただし、40 Gb のジェネシス状態をダウンロードすることも素晴らしい経験ではありません。
イーサリアムの状態をオフチェーンに保存し、オンチェーンではマークル ルート ハッシュのみが表示されます
この 40 GB を「オフチェーン」に保存し、ルート ハッシュのみをジェネシス ブロックにパックできると仮定すると、空の状態から開始できます。しかし、トランザクションにこの暗黙的な状態へのアクセスを与えるにはどうすればよいでしょうか?
副題
これはステートレスイーサリアムではないでしょうか？
副題
ブロックでの証明とトランザクションでの証明
副題
取引証明のデメリット
トランザクションの送信者に、関連するすべての状態の証明をトランザクションに追加してもらいたいとします。これを行う利点は、証人に追加のガソリンを請求するために必要な作業が簡素化されることです。この主な欠点は、通常、これを静的状態アクセス (SSA) ではなく動的状態アクセス (DSA) で実現する必要があることです。トランザクションに特に複雑なスマート コントラクトが含まれる場合、たとえば、他のコントラクトへの多数のネストされた呼び出しが含まれる場合、トランザクションに関係する状態項目を事前計算することが難しい場合があります。攻撃者は DSA を使用してユーザーを「セットアップ」することもできます。つまり、ユーザーのトランザクションをプリエンプトする (同じ内容だがより高いガス料金のトランザクションを送信して、目の前でパッケージ化する) ことにより、ユーザーのトランザクションが不十分なために失敗するようにすることもできます。証拠。
ReGenesis によって提供される緩和策
DSA に潜む危険性を完全に解決することは困難ですが、ユーザーが不便を感じないように、また期待した状態遷移が永遠に実現できない状況に留まらないように、そのリスクを可能な限り軽減することは可能です。この軽減策には、トランザクションで提供される証明 (状態ルートに対して検証されていますが、トランザクションの成功を保証するには十分ではありません) が暗黙的な状態の一部になるという追加ルールの導入が必要です。したがって、ユーザーがトランザクションの実行を繰り返し試行すると、暗黙的な状態が増大し、最終的にはトランザクションが成功します。ユーザーを「ハッキング」しようとする攻撃者は、ユーザーの状態アクセスを既存の暗黙的な状態の外側にリダイレクトするためのより洗練された方法を見つける必要があり、最終的には失敗します。
暗黙的な状態が何もない (再起動されたばかりの) 状態から、より多くのアクティブにアクセスされた状態を含む状態に成長するにつれて、トランザクションが提供する必要のある証明は少なくなります。しばらくすると、大昔の州が関係する取引を除いて、ほとんどの取引は証拠を添付する必要さえなくなります。
ReGenesisを定期的に実行できます
私はこれを「再起動」reGenesis と呼んでいます。これは、マイニング以外のノードの負荷を軽減するために定期的に実行できます。 ReGenesis は、ステートレス イーサリアムのそれほど過激ではないバージョンでもあります。
ReGenesis を繰り返し実装すると、イーサリアム クライアント実装のアーキテクチャが簡素化され、より高レベルのスナップショット同期アルゴリズムの必要性がほぼなくなります。 ReGenesis を 100 万ブロック (約 6 か月) ごとに実行すると、状態のスナップショットとブロックチェーン ファイルを BitTorrent、Swarm、IPFS で公開できます。状態は 6 か月ではなく 15 秒ごとに遷移するため、現時点ではこれ (生成されたままのストレージ) を行うことはできません。クライアント実装が 6 か月分のブロックを再生できる場合、非常に複雑なスナップショット アルゴリズムは必要ありません。したがって、イーサリアムの実装の複雑さは軽減されます。
副題
リジェネシスのデメリット
これについては詳しく調査していませんが、私が感じた欠点は次の 3 つです。
