ポピュラーサイエンス | ReGenesis: Ethereum を「再起動」できますか?

コスモスハブからの教訓

Cosmos Hub がバージョン 1.0 からバージョン 2.0、そしてバージョン 3.0 にアップグレードされた様子を観察したことがあるなら、Cosmos Hub のアップグレードは基本的に、新しいジェネシス ブロックでブロックチェーンを再起動することによって実現されることがわかるでしょう。アップグレードする場合、ノード オペレーターはノードをシャットダウンし、Cosmos Hub の状態のスナップショットを生成し、このスナップショットを新しいジェネシス ブロックにパッケージ化して新しいブロックチェーンを作成する必要があります。

現在、Cosmos Hub に参加したい人は、CosmosHub-3 のジェネシス ブロックを入手し、CosmosHub-3 のすべてのブロックをダウンロードして再生する必要があります (CosmosHub-1 または CosmosHub-2 のブロックをダウンロードする必要はなくなりました)。

ETH 1.0 を「再起動」できますか?

同じアプローチが Ethereum に適用できるかどうかを想像してみましょう。 Ethereum ブロックチェーンは巨大 (150～160 Gb) であり、状態も巨大です (状態の保存方法に応じて 40～100 Gb)。 Ethereum ブロックチェーンを「再起動」することの明らかな利点の 1 つは、新しく参加したノードが 150Gb のブロックチェーンではなく 40Gb のジェネシス状態をダウンロードする必要があることです。ただし、40 GB のジェネシス状態をダウンロードするのもあまり良い体験ではありません。

イーサリアムの状態をオフチェーンで保存し、オンチェーンではマークルルートハッシュのみを表示する

この 40 GB を「オフチェーン」で保存し、ルートハッシュのみをジェネシスブロックにパックして、空の状態から開始できると仮定します。しかし、トランザクションがこの暗黙の状態にアクセスできるようにするにはどうすればよいでしょうか?

ただし、この 40 Gb の状態は暗黙的であり、それを取得する方法は実装の詳細であることを覚えておいてください。1,000 万ブロックすべてを実行して計算するか、高速同期やワープ同期を介してスナップショットをダウンロードするか、他の人の外部ディスクからコピーして検証することができます。状態は暗黙的ですが、ブロック提案者 (通常はマイニング プール) がこの暗黙的なデータにアクセスし、すべてのトランザクションを処理できると想定しています。 1 つの仮定を放棄する必要があります。他のすべての検証ノードは暗黙の状態にアクセスして、ブロック内のトランザクションが有効であること、およびブロック ヘッダーの状態ルート ハッシュがブロックの実行結果と一致することを検証できます (翻訳者注: 現在の Ethereum プロトコルでは、すべての状態が明示的であるため、この仮定は妥当です)。

これはステートレスなイーサリアムではないでしょうか?

ステートレス イーサリアムについてご存知であれば、これがまさに私たちが目指していること、つまり「ブロック提案者は暗黙の状態にアクセスできる」という前提を維持し、「すべてのバリデータ ノードは暗黙の状態にアクセスできる」という前提を排除することだとお気づきかもしれません。私たちが提案する解決策は、ブロック提案者にブロックに追加の証明を追加させることです。この証明を「ブロック証人」と呼びます。

ブロック内の証明とトランザクション内の証明

このスキームについて初めて学ぶ人は、追加の証明は実際にはトランザクションの送信者によって提供され、トランザクションのペイロードの一部であると考えるでしょう。しかし、そうではなく、証明はブロック提案者によって提供されることを説明する必要がありました。しかし、後に、トランザクションには追加の証明も含める必要があることがわかりました。つまり、トランザクションの送信者は、送信者アドレスにガス料金を支払うのに十分な ETH があることを証明する必要があります。また、このアカウントによって開始された、より小さな nonce 値を持つ他のすべてのトランザクションにも証明する必要があります。さらに、トランザクションの送信者は、送信者のアカウントの nonce 値を証明する必要があります。これにより、ノードは nonce 値間にギャップがあるかどうかを判断でき、誰かが機会を利用して実行不可能なトランザクションのシリーズを送信し、DDOS 攻撃を実行するのを防ぐことができます。より厳格なチェックを実行することもできますが、ほとんどの DDoS 攻撃対策ソリューションでは、ETH 残高と送信者アカウントの nonce 値が必要な情報です (または、それだけでは不十分な場合があります)。

取引証明のデメリット

トランザクションの送信者に、トランザクション内の関連する各状態の証明を含めさせたいとします。これを行う利点は、証人に追加のガソリンを請求するために必要な作業が簡素化されることです。これを実行する主な欠点は、通常、静的状態アクセス (SSA) ではなく動的状態アクセス (DSA) を介して実行する必要があることです。トランザクションに関係するスマート コントラクトが特に複雑な場合 (たとえば、他のコントラクトへのネストされた呼び出しが多数ある場合)、トランザクションに関係する状態項目を事前に計算することが困難な場合があります。攻撃者は DSA を使用してユーザーに「罠を仕掛ける」ことさえできます。つまり、トランザクションをフロントラン (同じ内容だがガス料金が高いトランザクションを送信して最初にパッケージ化できるようにする) し、証明が不十分なためにユーザーのトランザクションを失敗させることもできます。

ReGenesisが提供する緩和策

DSA の隠れた危険性を完全に解決することは困難ですが、ユーザーが不便を感じたり、期待した状態遷移を実現できない状況に永久に制限されたりしないように、そのリスクを可能な限り最小限に抑えることはできます。この緩和策には、トランザクションで提供されるすべての証明 (状態ルートに対して検証されているが、トランザクションが成功したことを保証するには不十分) が暗黙の状態の一部になるという追加ルールの導入が必要です。したがって、ユーザーがトランザクションの実行を繰り返し試行すると、暗黙の状態が拡大し続け、最終的にトランザクションは成功します。ユーザーを「罠」にかけようとする攻撃者は、既存の暗黙的な状態の外にユーザー状態アクセスをリダイレクトするより複雑な方法を見つける必要があり、最終的には失敗します。

暗黙的な状態が、何もない状態（再起動時）から、アクティブにアクセスされる状態がどんどん含まれる状態へと拡大するにつれて、トランザクションが提供する必要のある証明は減少します。しばらくすると、はるか昔に存在した状態に関わるものを除いて、ほとんどの取引には証明を添付する必要さえなくなるでしょう。

定期的にReGenesisを実施できます

私はこれを「再起動」reGenesisと呼んでおり、非マイニングノードの負担を軽減するために定期的に実行することができます。 ReGenesis は、ステートレス Ethereum のより緩やかなバージョンでもあります。

ReGenesis を繰り返し実行することで、Ethereum クライアント実装のアーキテクチャが簡素化され、より高度なスナップショット同期アルゴリズムの必要性がほぼなくなります。 100 万ブロックごとに（約 6 か月ごとに）ReGenesis を実行すると、状態スナップショットとブロックチェーン ファイルを BitTorrent、Swarm、IPFS で公開できます。状態は 6 か月ごとではなく 15 秒ごとに変更されるため、現時点ではこれを行う (作成されたままの状態を維持する) ことはできません。クライアント実装が 6 か月分のブロックを再生できる場合、非常に複雑なスナップショット アルゴリズムは必要ありません。したがって、Ethereum 実装の複雑さが軽減されます。

ReGenesisの欠点

これについては詳しく調べていませんが、私が見つけた欠点は次の 3 つです。

1. ユーザーは、トランザクションを作成するために完全な暗黙の状態にアクセスする必要がある場合があります。実際のところ、それは妥当な妥協案だと思います。

2. (DSA のため) ユーザーは、目的の状態遷移が最終的に達成されるまで、トランザクションを繰り返し実行する必要がある場合があります。

3. 一部のロールアップ技術（ブロックチェーンデータを使用してデータの可用性を実現するもの）が影響を受ける可能性があります。

（以上）

オリジナルリンク: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582著者: Alexey Akhunov翻訳・校正: Min Min & A Jian