イーサリアムパージフェーズ中に何をクリアする必要がありますか?

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

この EIP は、イーサリアム プロトコル開発の過小評価されがちな部分、つまり複雑さを取り除き、新しいセキュリティ保証を追加することでプロトコルを簡素化する取り組みの重要な例です。これは、私が「パージ」と呼んでいるもの、つまりイーサリアムを合理化し、技術的負債を解消するプロジェクトの重要な部分です。同様の精神を持った EIP はさらに増えるでしょう。そのため、EIP-6780 がその目標をどのように達成するのか、そして将来のパージで他のどの EIP がクリアされる可能性があるのか​​を理解することは価値があります。

EIP-6780 はイーサリアム プロトコルをどのように簡素化しますか?

EIP-6780 は SELFDESTRUCT の機能を微調整し、コントラクトを破棄するオペコードがトランザクション中にコントラクトが存在する場合にのみ実行されるように制限します。これにより、SELFDESTRUCT コントラクト破棄機能の悪用や、コードとストレージのクリアによって引き起こされる潜在的な問題が防止されます。これはより厳密な仕様を強制するものではありませんが、トランザクション中に存在するかどうかとコントラクトが呼び出されているかどうかという 2 つの新しい変数が導入されます。この変更により、信頼性が向上するため、同じ取引期間内でのみ契約を作成し、署名できるようになります。

1. EIP-6780 以降、1 つのブロックで編集できるストレージ スロットの最大数は制限されています (おおよそ: ガス制限 / 5000)。

2. コントラクトのトランザクションまたはブロックの先頭に空ではないコードがある場合、そのトランザクションまたはブロックの終わりにも同じコードが含まれます。

以前は、次の不変条件はいずれも True ではありませんでした:

1. SELFDESTRUCT多数のストレージ スロットを持つコントラクトは、単一ブロック内の無制限の数のストレージ スロットをクリアできます。 。これにより、この特殊なケースを効率的に処理するために追加のコードが必要になるため、Verkle ツリーの実装がより困難になり、イーサリアム クライアントの実装がより複雑になります。

コントラクトのコードは SELFDESTRUCT を介して非 null から空に変更でき、実際、直後にコントラクトを別のコードで再作成することもできます。これにより、トランザクション検証では DoS 攻撃に対して脆弱になることなくトランザクション内のコード ベースを使用する必要があるため、アカウント抽象化でのトランザクション検証がより困難になります。

現在、これらの不変条件は True であるため、イーサリアム クライアントやその他の種類のインフラストラクチャの構築が容易になります。数年以内に、将来の EIP がその仕事を完了し、SELFDESTRCT が完全に排除されることを願っています。

他にどのような「粛清」が行われているのでしょうか？

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

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

• Dencun の BLOB のストレージ ウィンドウは 18 日間です。これは、Ethereum ノードが BLOB データを保存するのに必要な容量は約 50 GB だけであり、この量は時間の経過とともに増加することはありません。

最初の 2 つと合わせて、クライアント開発者のエクスペリエンスが大幅に向上します。後者により、ノード オペレーターの寿命が大幅に延長されます。

他にパージする必要があるものは何ですか?

プリコンパイル

プリコンパイルは、EVM コードを持たない Ethereum コントラクトですが、クライアント自体によって直接実装する必要があるロジックを持っています。その考え方は、EVM では効率的に実装できない複雑な形式の暗号化をプリコンパイルを使用して実装できるということです。

現在、プリコンパイルの使用は、特に楕円曲線プリコンパイルを通じて ZK-SNARK ベースのアプリケーションを有効にするために非常に成功しています。ただし、めったに使用されないプリコンパイルは他にもあります:

• RIPEMD-160: ビットコインとの互換性を向上させるためにハッシュ関数が導入されました

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

• BLAKE2: 導入されたハッシュ関数は、との互換性の向上をサポートします。 Zcash

• MODEXPRSA ベースの暗号化をサポートするための非常に大規模な累乗剰余演算の導入

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

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

• プリコンパイルを削除するだけです。 EIP-7266 により BLAKE2 が削除されました。これは簡単ですが、それを使用しているアプリケーションは壊れてしまいます。

• プリコンパイルを、同じことを行う EVM コードのブロックに置き換えます (ただし、必然的にガスコストが高くなります)。このドラフト EIP は、アイデンティティのプリコンパイルのためにこれを行います。これはより困難ですが、これを使用するアプリケーションを壊すことはほぼ確実にありません (新しい EVM コードのガス コストが一部の入力のブロック ガス制限を超えるまれな場合を除く)

Historical Blocks (EIP-4444)

Today, every Ethereum node is expected to store all historical blocks permanently. This has long been considered a very wasteful approach and makes running an Ethereum node unnecessarily difficult due to high storage requirements. In Dencun, we introduced blobs, which only need to be stored for about 18 days. With EIP-4444, after a period of time, Ethereum blocks will also be removed from the default Ethereum node.

A key question that needs to be solved is: if the old history is not stored by each node, then what is used to store it? In fact, large entities such as block explorers will do this. However, it is also possible and not difficult to make a p2p protocol to store and transfer this information, which is more optimized for the task.

The Ethereum blockchain is permanent, but requiring each node to store all data forever is a very "overkill" way to achieve this permanence.

One approach is a simple peer-to-peer torrent network for old history. The other is a protocol more explicitly optimized for use with Ethereum, such as the Portal Network.

Or, in meme format:

Reducing the amount of storage required to run an Ethereum node can greatly increase the number of people willing to be nodes. EIP-4444 can also reduce node synchronization time, which also simplifies the workflow for many node operators. Therefore, EIP-4444 can greatly improve the decentralization of Ethereum nodes. Potentially, if each node stored a small portion of history by default, we could even store roughly the same number of copies of each specific history on the network as we do today.

Log Reform

Quote directly from this EIP draft:

The log was originally introduced to enable applications to record information about events on the chain in order to decentralize Applications (dapps) can easily query this information. Using bloom filters, a dapp will be able to quickly browse the history, identify several blocks that contain logs relevant to their application, and then quickly identify which individual transactions have the required logs.

Actually, this mechanism is too slow. Almost all dapps that access history end up not through RPC calls to Ethereum nodes (or even remotely hosted nodes), but through centralized additional protocol services.

what can we do? We can remove the bloom filter and simplify the LOG opcode so that all it does is create a value that puts the hash value into the state. We can then build a separate protocol that uses ZK-SNARKs and incremental verifiable computation (IVC) to generate a provably correct "log tree" that represents an easily searchable table of all logs given topic, and applications that require logging and want decentralization can use these separate protocols.

Moving to SSZ

Today, much of Ethereum’s block structure (including transactions and receipts) is still stored using an outdated format based on RLP and Merkle Patricia trees. This makes it unnecessarily difficult to develop applications that use this data.

The Ethereum consensus layer has moved to the cleaner and more efficient SimpleSerialize (SSZ):

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

However, we still need to complete the conversion and move the execution layer to the same structure.

The main advantages of SSZ include:

• The specification is simpler and clearer

• Comparison with the current six-branch Merkle Patricia tree Merkle proofs are 4x shorter in most cases than in most cases receipt output)

• No need to implement complex bit manipulation code (required for RLP)

• For ZK-SNARK use cases, it is usually possible to reuse the surrounding binary Existing implementations of Merkle tree construction

• Today, three types of cryptographic data structures exist in Ethereum: SHA256 binary trees, SHA3 RLP hash lists, and hexadecimal Patricia trees. Once we complete the transition to SSZ, we will be left with only two: SHA256 binary trees and Verkle trees. In the long term, once we get good enough at SNARKing hashes, we will likely replace SHA256 binary trees and Verkle with binary Merkle trees that use SNARK friendly hashes (a cryptographic data structure that works for all Ethereum) Tree.

以上がイーサリアムパージフェーズ中に何をクリアする必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。