Vitalik: EIP-6780 イーサネット・プロトコルを簡素化する重要なステップ

著者：Vitalik 翻訳者：Good Oba、Golden Finance

最近のDencunハードフォークであまり知られていないEIPの一つがEIP-6780です。知られているEIPはEIP-6780で、オペコードSELFDESTRUCTの機能のほとんどを削除しています。

この EIP は、イーサ プロトコルの開発において過小評価されがちな重要な一例です。新しいセキュリティ保証を追加し、プロトコルの取り組みを単純化することによって開発されています。これは私が「クリーンアップ」と呼ぶものの重要な一部であり、Etherを合理化し、技術的負債を取り除くプロジェクトです。

EIP-6780はどのようにEtherプロトコルを単純化するのでしょうか？

EIP-6780は、オペコードSELFDESTRUCTの機能を削減します。これは、それを呼び出したコントラクトを破棄し、そのコードとストレージを空にします。これ自体は仕様の複雑さを軽減するものではありません。

1. EIP-6780 以降では、1 つのブロックで編集できるストレージ スロットの最大数があります (おおまかにはgas limit / 5000）。

2. トランザクションまたはブロックの開始時に空でないコードを持つコントラクトは、そのトランザクションまたはブロックの終了時にも同じコードを持ちます。

以前は、これらの不変条件はどれも真ではありませんでした:

1. SELFDESTRUCT 多くのストレージスロットを持つコントラクトは、1つのブロック内で無制限にスロットをクリアできます。これは、Verkleツリーの実装を難しくし、イーサネットクライアントの実装を複雑にするでしょう。

2. コントラクトのコードは、空でないSELFDESTRUCTから空のSELFDESTRUCTに変更できます。このため、DoS攻撃に脆弱でないコードベースを使用したアカウント抽象化ウォレットでは、トランザクションを検証することが難しくなります。

現在では、これらの不変条件が正しいため、イーサクライアントや他のタイプのインフラを構築するのがずっと簡単になりました。数年後には、将来のエコ工業団地がこの作業を完了し、SELFDESTRUCTを完全に排除できるようになることを願っています。

他にどのような「浄化」が行われているのだろうか？

• Gethは最近、何千行ものコードとプレマージ(PoW)ネットワークのサポートを削除しました。

• このEIPは、「空のアカウント」を心配するコードをもはや必要としないという事実を正式に示すものです (参照: 上海DoS攻撃の修正の一部としてこの概念を導入したEIP-161)

• Gethは最近、何千行ものコードを削除し、事前マージ (PoW) ネットワークのサポートを削除しました。

• Dencunのブロブのストレージウィンドウは18日で、これはイーサネットノードがブロブデータを保存するのに必要なのは約50GBだけで、この量は時間が経っても増えません。="text-align: left;">最初の2つは、クライアント開発者の生活を大幅に改善します。後者はノードオペレータの生活を大幅に改善します。

  他に削除する必要があるものは何でしょうか?

  プリコンパイル

  プリコンパイルとは、EVMコードを持たないEtherContractのことです。プリコンパイルは、EVMでは効率的に実装できない複雑な暗号を実装するために使用されます。

  今日、特に楕円曲線プリコンパイルによってZK-SNARKベースのアプリケーションを実現するために、プリコンパイルは大きな成功を収めて使用されています。

  • RIPEMD-160: ビットコインとのより良い互換性をサポートするためにハッシュ関数が導入されました

    。

  • Identity: 入力と同じ出力を返すプリコンパイル

  • BLAKE2

  • BLAKE2: ビットコインとの互換性を高めるために導入されたハッシュ関数。code>: Zcashとのより良い互換性をサポートするために導入されたハッシュ関数

  • MODEXP RSAベースの暗号化をサポートするために非常に大きなモジュロ乗を導入

  これらのプリコンパイルの必要性は、予想よりもはるかに少ないことが判明しました。Identityはデータをコピーする最も簡単な方法であったため広く使われていましたが、Dencun 以降、MCOPY コードを操作することがそれに取って代わりました。残念なことに、これらのプリコンパイルはすべてコンセンサスバグの巨大な原因であり、ZK-SNARK 回路、正式に検証されたフレンドリーな実装などを含む新しい EVM 実装にとって大きな苦痛の原因です。

  これらのプリコンパイルを削除する方法は2つあります:

  1. 単純にプリコンパイルを削除する、例えば、EIP-7266はBLAKE2を削除します。7266はBLAKE2を削除します。簡単ですが、まだそれを使っているアプリケーションは壊れてしまいます。

  2. たとえば、プリコンパイルを、(必然的に高いガスコストで) 同じ処理を実行するEVMコードのブロックに置き換えます。このEIP草案では、アイデンティティ・プリコンパイルがまさにそうなっている。これはより困難ですが、（新しいEVMコードのGasコストがある入力ブロックのGas制限を超えるようなまれなケースを除いて）それを使用するアプリケーションをほぼ確実に破壊することはありません

  歴史 (EIP-4444)

  今日、すべてのイーサ・ノードは、すべての履歴ブロックを永久に保存することが期待されています。これは長い間、非常に無駄の多いアプローチとして認識されており、高いストレージ要件のためにイーサ・ノードの運用を不必要に難しくしています。Dencunでは、約18日間のストレージしか必要としないブロブを導入しました。EIP-4444では、一定期間が経過すると、イーサ・ブロックもデフォルトのイーサ・ノードから削除されます。

  対処すべき重要な疑問の1つは、古い履歴がすべてのノードによって保存されない場合、何を使用して保存するのかということです。実際には、ブロックブラウザのような大きなエンティティがこれを行います。しかし、p2pプロトコルがその情報を保存し、配信することも可能であり、難しくありません。

  イーサリアムのブロックチェーンは永続的ですが、各ノードにすべてのデータを永久に保存することを要求するのは、その永続性を達成するための非常に「やりすぎ」な方法です。

  1つのアプローチは、古い歴史のためのシンプルなピアツーピアの洪水ネットワークです。もうひとつは、ポータルネットワークのような、イーサネットの使用にもっと明確に最適化されたプロトコルのためのものです。

  または、モーダル形式:

  

  イーサネット・ノードを実行するために必要なストレージの量を削減することで、そうすることを望む人の数を大幅に増やすことができます。-4444はまた、ノードの同期時間を短縮し、多くのノードオペレータのワークフローを簡素化します。その結果、EIP-4444はイーサにおけるノードの分散化を大幅に促進することができます。潜在的には、各ノードがその履歴のごく一部をデフォルトで保存すれば、現在とほぼ同じ数の各特定の履歴のコピーをネットワーク上に保存することさえできます。

  ログ改革

  このEIP草案を直接引用します:

  ログはもともと、分散型アプリケーション（dapps）がこの情報を簡単に照会できるように、アプリケーションがチェーン内のイベントに関する情報を記録できるようにするために導入されました。ブルームフィルターを使用することで、Dappsは履歴を素早くナビゲートし、自分のアプリケーションに関連するログを含むいくつかのブロックを特定し、必要なログを持つ個々のトランザクションを素早く特定することができるようになります。

  現実には、この仕組みは遅すぎます。履歴にアクセスするほとんどすべてのDappsは、イーサネット・ノード（あるいはリモートでホストされたノード）へのRPC呼び出しではなく、集中化された特別なプロトコル・サービスを通じてそれを行っています。

  私たちに何ができるでしょうか？私たちはブルーム フィルターを削除し、LOG オペコードを単純化して、LOGが行うことは、状態にハッシュを置く値を作成することだけです。そして、ZK-SNARK とインクリメンタル検証可能計算 (IVC) を使用して、トピックとログを必要とし、ログを必要とするアプリケーションを与えられたすべてのログの簡単に検索可能なテーブルを表す、証明可能な正しい「ログ ツリー」を生成する別々のプロトコルを構築することができます。Centralityは、これらの別々のプロトコルを使用することができます。

  SSZへの再配置

  今日でも、トランザクションやレシートを含むイーサのブロック構造のほとんどは、RLPとMerkleパトリシアツリーに基づいた時代遅れのフォーマットを使用して保存されています。そのため、このデータを使用するアプリケーションの開発が不必要に難しくなっています。

  イーサネットのコンセンサスレイヤーは、よりクリーンで効率的なSimpleSerialize (SSZ)に移行しました。

  

  InformationSource: https://eth2book.info/altair/part2/building_blocks/merkleization/

  しかし、まだ変換を完了し、実行レイヤーを同じ構造に移動する必要があります。.

  SSZの主な利点は以下の通りです:

  • 仕様がよりシンプルで明確

  • 現状の6つのフォークを持つMerkle Patriciaツリーと比較すると、ほとんどの場合、Merkle証明の長さは4分の1に短縮されます

  • 極端に長いMerkleの最悪のケースと比較すると、

  • Merkle証明の長さは4分の1に短縮されます。Merkle の証明は長さに制限がある（例えば、契約コードの証明や長いレシート出力）

  • 複雑なビット操作コードを実装する必要がない（RLPに必要）

  • ZK-SNARKのユースケースは、多くの場合、1.5倍である

  • 。SNARKのユースケースの場合、バイナリ・メルクル・ツリーを中心に構築された既存の実装を再利用できることがよくあります

  現在Etherに存在する暗号化されたデータ構造には、SHA256バイナリ・ツリー、SHA3 RLPハッシュ・リスト、16進パトリシア・ツリーの3種類があります。SSZへの移行が完了すれば、SHA256バイナリツリーとVerkleツリーの2つだけになります。長期的には、ハッシュのSNARKが十分にできるようになれば、SHA256バイナリツリーとVerkleツリーを、SNARKに適したハッシュを使用するバイナリMerkleツリーに置き換えることになるでしょう。