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つあります:
単純にプリコンパイルを削除する、例えば、EIP-7266はBLAKE2を削除します。7266はBLAKE2を削除します。簡単ですが、まだそれを使っているアプリケーションは壊れてしまいます。
たとえば、プリコンパイルを、(必然的に高いガスコストで) 同じ処理を実行するEVMコードのブロックに置き換えます。このEIP草案では、アイデンティティ・プリコンパイルがまさにそうなっている。これはより困難ですが、(新しいEVMコードのGasコストがある入力ブロックのGas制限を超えるようなまれなケースを除いて)それを使用するアプリケーションをほぼ確実に破壊することはありません
歴史 (EIP-4444)
今日、すべてのイーサ・ノードは、すべての履歴ブロックを永久に保存することが期待されています。これは長い間、非常に無駄の多いアプローチとして認識されており、高いストレージ要件のためにイーサ・ノードの運用を不必要に難しくしています。Dencunでは、約18日間のストレージしか必要としないブロブを導入しました。EIP-4444では、一定期間が経過すると、イーサ・ブロックもデフォルトのイーサ・ノードから削除されます。
対処すべき重要な疑問の1つは、古い履歴がすべてのノードによって保存されない場合、何を使用して保存するのかということです。実際には、ブロックブラウザのような大きなエンティティがこれを行います。しかし、p2pプロトコルがその情報を保存し、配信することも可能であり、難しくありません。
イーサリアムのブロックチェーンは永続的ですが、各ノードにすべてのデータを永久に保存することを要求するのは、その永続性を達成するための非常に「やりすぎ」な方法です。
1つのアプローチは、古い歴史のためのシンプルなピアツーピアの洪水ネットワークです。もうひとつは、ポータルネットワークのような、イーサネットの使用にもっと明確に最適化されたプロトコルのためのものです。
または、モーダル形式:
![7202722 kKp39xlQQkPePH7S8xt3RjVJWPVnhvHTMlI9KTMP.png](https://img.jinse.cn/7202722_watermarknone.png)
イーサネット・ノードを実行するために必要なストレージの量を削減することで、そうすることを望む人の数を大幅に増やすことができます。-4444はまた、ノードの同期時間を短縮し、多くのノードオペレータのワークフローを簡素化します。その結果、EIP-4444はイーサにおけるノードの分散化を大幅に促進することができます。潜在的には、各ノードがその履歴のごく一部をデフォルトで保存すれば、現在とほぼ同じ数の各特定の履歴のコピーをネットワーク上に保存することさえできます。
ログ改革
このEIP草案を直接引用します:
ログはもともと、分散型アプリケーション(dapps)がこの情報を簡単に照会できるように、アプリケーションがチェーン内のイベントに関する情報を記録できるようにするために導入されました。ブルームフィルターを使用することで、Dappsは履歴を素早くナビゲートし、自分のアプリケーションに関連するログを含むいくつかのブロックを特定し、必要なログを持つ個々のトランザクションを素早く特定することができるようになります。
現実には、この仕組みは遅すぎます。履歴にアクセスするほとんどすべてのDappsは、イーサネット・ノード(あるいはリモートでホストされたノード)へのRPC呼び出しではなく、集中化された特別なプロトコル・サービスを通じてそれを行っています。
私たちに何ができるでしょうか?私たちはブルーム フィルターを削除し、LOG
オペコードを単純化して、LOGが行うことは、状態にハッシュを置く値を作成することだけです。そして、ZK-SNARK とインクリメンタル検証可能計算 (IVC) を使用して、トピック
とログを必要とし、ログを必要とするアプリケーションを与えられたすべてのログの簡単に検索可能なテーブルを表す、証明可能な正しい「ログ ツリー」を生成する別々のプロトコルを構築することができます。Centralityは、これらの別々のプロトコルを使用することができます。
SSZへの再配置
今日でも、トランザクションやレシートを含むイーサのブロック構造のほとんどは、RLPとMerkleパトリシアツリーに基づいた時代遅れのフォーマットを使用して保存されています。そのため、このデータを使用するアプリケーションの開発が不必要に難しくなっています。
イーサネットのコンセンサスレイヤーは、よりクリーンで効率的なSimpleSerialize (SSZ)に移行しました。
![7202729 TZ215m0bMFNz67Nk7ftASzdtzKHBp4M6YAFIZF8w.png](https://img.jinse.cn/7202729_watermarknone.png)
InformationSource: https://eth2book.info/altair/part2/building_blocks/merkleization/
しかし、まだ変換を完了し、実行レイヤーを同じ構造に移動する必要があります。.
SSZの主な利点は以下の通りです: