Vitalik Buterin、イーサリアム浄化計画を提示

イーサリアムの創設者であるVitalik Buterinは、ネットワークの次のステップとして、不要な重みを切り捨てることを発表しました。彼はこれを「ザ・パージ（浄化）」と呼んでいます。

シリーズの5番目のブログ記事で、Vitalikはブロックチェーンの肥大化を排除し、冗長な機能を撤廃してプロトコルを合理化するという過酷な計画を提示しました。イーサリアムのネットワークは、時代遅れのトランザクションや複雑なレガシー機能で混雑しています。

解決策は？ Vitalikは履歴と状態データの削減、プロトコル機能の簡素化、ノードの実行容易化を望んでいます。この積極的な決定は、イーサリアムの急速なデータ成長への対応です。

現在、完全なイーサリアムノードを実行するには、実行クライアントだけで1.1テラバイト以上のストレージが必要で、コンセンサスデータ用にはさらに多くの容量が必要です。

トランザクションとアカウントが積み重なるにつれてストレージ需要が増大し、ボトルネックが生じています。変更がない場合、イーサリアムは sluggish（遅延）化するリスクがあり、新しいクライアントがチェーンと同期するために painfully long（非常に長い）同期時間を要するようになります。

履歴の有効期限切れ：イーサリアムのメモリ負荷を縮小

すべてのノードが過去に記録されたすべてのトランザクションを保持するのではなく、Vitalikはノードが最近のデータのみを保持することを提案しています。過去のブロック、古いトランザクション、レシートは、ノード間で小分けにして配布されます。

Vitalikにとって、履歴データはtorrentネットワークのように機能すべきです。ノードがデータの断片を保持し、1つのノードがすべてを保持することなくデータの可用性を確保します。「毎年数百ギガバイトの古いブロックが積み上がっているのです」と彼は述べています。

すべてのデータをノードが保持する現在のモデルは、すでに調整されています。プルーフ・オブ・ステークに不可欠なコンセンサスブロックは6ヶ月間保存され、ブロブ（より大きなトランザクションデータブロック）は18日後に消去されます。

Vitalikの新しい提案、EIP-4444は、過去のブロックとレシートに対する1年間のストレージ上限を推進しています。彼の最終目標は、各ノードが履歴の断片のみを保持し、Merkle証明とエラスターコード（誤り訂正符号）を使用して正確性を保証する分散ネットワークです。

この分散された履歴ストレージは、イーサリアムのデータの信頼性を低下させません。Vitalikは、ノード数を増やすことでネットワーク全体にデータのコピーが分散され、履歴の各断片が十分にバックアップされると主張しています。 

エラスターコードは、ブロブのデータサンプリングを可能にする技術と同様に、回復力を追加します。Vitalikはまた、Portal Networkやピアツーピア（P2P）方式を、中央集権型ストレージに依存せずにイーサリアムがデータを分散管理するための可能な解決策として挙げています。

状態の有効期限切れ：データの永続性の制限

履歴に加え、Vitalikの浄化計画には、より複雑な「状態の有効期限切れ」も含まれます。履歴とは異なり、状態データ（アカウント残高、ノンス、スマートコントラクトのストレージなど）は有効期限切れにしにくいです。一度作成されると、状態オブジェクト（ETHを持つアカウントやコントラクトのストレージスロットなど）は、あらゆるトランザクションからアクセス可能になります。

そして、各オブジェクトごとにイーサリアムのデータは増大します。これを抑制するため、Vitalikは自動有効期限切れを提案し、最近触れられていないデータを切り捨てます。鍵は、状態の有効期限切れとイーサリアムの永続性のバランスを取ることです。 

彼は、ユーザーが「5年間姿を消し、戻ってきても資金にアクセスできる」べきだと考えています。このシステムには効率性が必要であり、開発者にとって追加の計算や複雑なモデルは不要です。

イーサリアムは「ブロックチェーン・レント（データ維持料）」のようにデータを存続させるためにユーザーに課金するアイデアや、「レジネシス（再創世）」のようにブロックチェーンをリセットしてデータを削減しようとするアイデアなど、さまざまな試みを行ってきました。しかし、どちらも定着しませんでした。

2つの新しい提案が状態の肥大化を対象としています。まず、「部分的な状態の有効期限切れ」があります。ネットワークはデータをチャンクに分割し、最近のチャンクのみを保存しつつ、存在を証明するための「スタブ（非アクティブなデータの小さな断片）」を保持します。 

チャンクが削除された場合、ユーザーは過去のデータの証明を使用してそれを復活させることができます。Vitalikの設計提案、EIP-7736は、Verkle木と「ステム・アンド・リーフ（茎と葉）」モデルを使用してデータをグループ化します。6ヶ月間触れられていないデータは削除され、必要に応じて復元できるスタブのみが残されます。

2つ目のアイデアは、アドレス期間ベースの有効期限切れです。これは、状態オブジェクトを時間で区分します。各アカウントには「アドレス期間」があり、最も最近の2つの期間からのデータのみが保存されます。

古いデータを取得したい場合、ユーザーはそれを再導入するためにMerkle証明を提出します。この期間ベースのセットアップでは、アドレス形式の変更が必要になり、現在の20バイト形式にバージョン番号と期間を含めるために拡張されます。

Vitalikはまた、互換性を維持するためのアドレス空間の収縮も提案しています。課題は、イーサリアムの可用性という中核的な約束を犠牲にすることなく、ユーザーがこの期間システムを理解し信頼できるようにすることです。

機能のクリーンアップ：イーサリアムのコード複雑さの削減

浄化の最終段階はプロトコルの複雑さに対処します。Vitalikは、「新しい機能ごとにイーサリアムは使いにくくなりますが、何かを削除するのは悪夢です」と述べています。最も有名な例はSELFDESTRUCTで、ユーザーがコントラクトストレージを削除できるopcodeです。 

元々、これは自発的な状態クリアを可能にするものでしたが、ほとんど使用されておらず、サービス拒否（DoS）攻撃のリスクがあります。イーサリアムのDencunハードフォークはこのopcodeを弱体化させ、Vitalikは間もなく完全に削除する計画です。

肥大化した他の機能には、古いトランザクションタイプ、冗長なデータ形式、および混合エンディアン（バイト順）のプロトコル設定が含まれます。これらの癖は開発を混乱させ、イーサリアムのアップグレードを困難にします。

Vitalikのクリーンアップリストには、データ形式をRLPからSSZへ移行し、ガスルールを簡素化してブロックリソースをよりよく管理し、RIPEMD160、MODEXP、BLAKEなどの未使用のプリコンパイルを削除することも含まれています。また、彼はイーサリアムをステートレスクライアントモデルに移行することを支持しており、これはほとんどのノードのストレージ負担をeliminate（排除）します。

これらの変更の一部には、アカウント抽象化が必要です。これにより、ユーザーは「デフォルトアカウントEVMコード」を通じてレガシートランザクションタイプを処理できるようになります。Vitalikは、これによりイーサリアム仮想マシン（EVM）が簡素化され、コードサイズが削減されると述べています。長期的には、EVM自体のアップグレードも可能です。

彼は、イーサリアムの開発者がRISC-VやCairoのような新しい実行モデルを検討しているか、またはコードルールを標準化するためにEVM Object Format（EOF）を使用する可能性があることを説明しています。 

EOFはガスルールを変更し、特定の命令を禁止してモジュラーアップグレードを可能にし、イーサリアムのスケーラビリティを向上させます。この形式は、開発者が増分的な改善を行い、最終的にイーサリアムを軽量に保つことを可能にすると報告されています。

しかし、Vitalikは別のオプションも提示しました。彼は 述べています。批評家は「要点を見落としている」と、同社は回避するのではなく、現在規制と必要な監督に従おうとしているからです。, 「より過激なイーサリアムの簡素化戦略は、プロトコルをそのまま維持しつつ、その大部分をプロトコル機能からコントラクトコードへ移行することです。」