Ethereum Dencunの内容の紹介

DencunはDenebとCancunの2つの名前で構成されており、Ethereum Consensus層と実行層の間のハードフォークを表しています。Dencun Hard ForkはGoerli、Sepolia、およびHoleskyテストネットワークで完成し、メインネットはEpoch 269568（2024年3月13日頃）で実施されます。

ヒントを読む

この記事を読む前に、あなたが知る必要がある最初の知識には次のものが含まれます。

ハードフォーク
イーサリアムは、コンセンサスレイヤーと実行レイヤーに分かれています。

Dencunのアップグレードには、9つのEIPが含まれています。

EIP-1153：一時的なストレージオペコード（実行レイヤーの変更）
EIP-4788：EVMのビーコンブロックルート（実行層とコンセンサスレイヤーの変更）
EIP-4844：Shard Blobトランザクション（実行レイヤーとコンセンサスレイヤーの変更）
EIP -5656：MCOPY-メモリコピー命令（実行レイヤーの変更）
EIP-6780：同じトランザクションでのみ自己破壊します
EIP-7044：永久に有効な署名された自発的出口
EIP-7045：Max Attestation Inclusion Slotを増やす（コンセンサスレイヤーの変更）
EIP-7514：最大エポックチャーン制限を追加します（コンセンサスレイヤーの変更）
EIP-7516：blobbasefee opcode（実行レイヤーの変更）

この記事では、これらのEIPの変更と影響を紹介します（EIP-4844を除く）。

Rollupの大きな追加：Proto-Danksharding（i）

https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6

Rollupの大きな追加：Proto-Danksharding（ii）

https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

次に、「実行レイヤーの変更に関連するEIP」、「コンセンサスレイヤーの変更に関連するEIP」、および「EIP-4844に関連するEIP」にほぼ分割された順序を導入します。

EIP-1153

実行レイヤーの変更
EIP-1153：一時的なストレージオペコード

https://eips.ethereum.org/eips/eip-1153

EIP-1153：ファンページ

https://www.eip1153.com/

EIP-1153：一時的なストレージオペコード

https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

EIP-1153には、「一時的な」ストレージデータの書き込みと読み取りに使用されるTSTOREとTLOADの2つの新しいオペコードが追加されています。彼らは多くの契約開発者にとって多くのガスコストを節約します。

背景

ストレージとは、SSTOREオペコードを介して契約のストレージスペースにデータを書き込むことを指します。「一時的な」特性は、「永続的な存在」と比較して、TSTOREによって記述されたデータは、トランザクションが実行されるまで有効であることです。

操作の詳細

TSTOREはSSTOREよりもはるかに安く、その有効期間は異なる契約間で呼び出します（トランザクションが終了するまで）。 B契約の記憶。これは多くの用途に非常に役立ちます：

再発ロック。現在、Re運転ロックはSSTOREでのみシミュレートできます。
ERC-20で使用されています。単一のトランザクション内で承認します。契約Aが契約Bと対話し、契約Aが契約BからERC-20を転送する必要がある場合、契約Bは最初にERC-20を承認して契約Aを呼び出す前にAを契約します。ERC-20の承認はすべてSSTOREを通じてあるため、コストは低くなく、TSTOREの使用に変更するとコストが大幅に削減されます。
deploymentパラメータcreate2を介して契約を展開するとき。コンストラクターパラメーターはCreate2展開の契約アドレスに影響を与えるため、コンストラクターパラメーターの影響を受けたくない場合、契約コンストラクターは、UNISWAP V3のプールなどの契約のストレージ読み取りパラメーターを展開するように設計されます。TSTOREを使用すると、このようなモデルは多くのコストを節約できます。

注意すべきこと

契約開発者は、TSTOREを使用して独自の再発ロックを書き直した場合、トランザクションが終わった後に自分自身をクリアするとは思わないため、ロックをクリアすることを忘れないでください。それ以外の場合は、トランザクションプロセス中に必要な場合、契約を締結した場合、ロックがロック解除されていない（クリアされていない）ため、入力できない場合があります。
EIP-1153はSolidityバージョン0.8.24で発売されており、開発者は事前に試してみることができます。開発者によって実装されたMutexの例は次のとおりです。TSTOREに依存しているUNISWAP V4も、DenCunのアップグレードが完了した後に起動されます。
このEIPには新しいオペコードがあるため、開発者が複数のチェーンに契約を展開したい場合、すべてのチェーンが最新のオペコードをサポートするかどうかに注意を払う必要があります。

EIP-4788

実行レイヤーの変更
EIP-4788：EVMのビーコンブロックルート

https://eips.ethereum.org/eips/eip-4788

EIP-4788：EVMのビーコンルート

https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

EIP-4788は、BEACON_ROOTS_ADDRESS契約を追加して、コンセンサスレイヤーブロックからデータを読み取ることができるようにします。つまり、実行レイヤーはコンセンサスレイヤーのデータを読み取ることができます。この契約を通じて、ステーキングと再定再数のプロトコルは、特定の検証者のステータスを読むなど、サードパーティを信頼することなく、コンセンサスレイヤーデータを読み取り、使用できます。

操作の詳細

ユーザーまたは契約は、契約を呼び出すことにより、特定の時点でビーコンブロックルートを照会できます。ブロックルートは、SSZエンコーディングを介したブロックコンテンツのマークルツリールートであるブロックコンテンツのハッシュ値（ビーコンブロックハッシュ）のようなものです。発信者は、タイムスタンプをUINT256の値にエンコードし、コールコンテンツを使用して対応するコンセンサスレイヤーブロックルートを検索し、渡します。

開発者がコンセンサスレイヤー情報を使用したい場合、彼の契約は、beacon_roots_address契約を読みたいコンセンサスレイヤーブロックのブロックルートを照会し、コンセンサスレイヤーブロックの情報を一致させます（たとえば、Verifierのバランス）そして、情報がブロックのルートに属しているかどうかを確認するためのマークル証明。（SSZコンテンツはMerkleツリーになっているため、コンテンツ内の情報は、コンテンツに情報が存在することを確認するために、対応するマークルプルーフを生成できます。）

userユーザーは、マークルプルーフおよびコンセンサスレイヤーブロックのタイムスタンプを提供します

merkleマークルプルーフは、特定の時点で検証剤のバランスを検証するために使用されます。

ただし、beacon_roots_address契約に保存されているコンセンサスレイヤーブロックルートは、実際には、実行レイヤーと同じブロックのブロックルートではなく、「メイン」ブロック（つまり、前のブロック）のブロックルートです。

blockブロック11001（1234567）のタイムスタンプは、ブロック11000のブロックルートに対応しています。同様に、ブロック11000（1234555）のタイムスタンプは、ブロック10999のブロックルートに対応しています。

注意すべきこと

beacon_roots_address契約は、最大8191コンセンサスレイヤーブロックルーツを保存し、8191以前のブロックルートが上書きされます。たとえば、現在ブロック18191である場合、アクセスできる現在のブロックルート範囲には、ブロック１００００のブロックルートがブロック18190になります。

EIP-5656

実行レイヤーの変更
EIP -5656：MCOPY-メモリコピー命令

https://eips.ethereum.org/eips/eip-5656

EIP-5656はMcOpy Opcodeを追加しました。これは、契約実行中にメモリに保存された値をコピーするために特に使用されています。契約は、このオペコードからのガスコスト削減の恩恵を受けます。

McOPY OpCodeを使用するには、契約開発者はコンパイラバージョンを0.8.24（または上）として指定し、EVMバージョンをCancunとして指定する必要があります。

mcopyを使用するには、コンパイラバージョンとEVMバージョンを設定する必要があります

注：バージョン0.8.24のコンパイラは、将来のバージョンでMcOpy（McOpy（）、Link）を使用することにしています。

注意すべきこと

このEIPには新しいオペコードがあるため、開発者が複数のチェーンに契約を展開したい場合、すべてのチェーンが最新のオペコードをサポートするかどうかに注意を払う必要があります。

EIP-6780

実行レイヤーの変更
EIP-6780：同じトランザクションでのみ自己破壊します

https://eips.ethereum.org/eips/eip-6780

EIP-6780：契約が作成されたのと同じトランザクションで発生する場合を除き、SelfDestructを非アクティブ化します

https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-exicte-where-it-occurs-in-the-same-in-the-same-a-contract-a-a contract-a-a contracted/13539

EIP-6780は、ヴェルクルツリーの準備と自己破壊オペコードの除去を準備するために、自己壊滅的なオペコードの動作を変更しました。SelfDestruct OpCodeを使用する開発者は特に注意が必要です。

背景

SelfDestruct OpCodeの現在の動作は次のとおりです。（1）契約のコードとストレージを削除し、（2）指定されたアドレスにそのすべてのETHを転送します。

当初、払い戻しメカニズムを備えたSelfDestruct Opcodeを設計して、開発者が未使用の契約とストレージスペースを削除して、イーサリアムの状態を適切なサイズに維持するのに役立ちました。しかし、実際にこれを行っている人は多くありませんが、自己破壊のために数十万人のETHが凍結する原因となったパリティマルチシグのような事故があるため、イーサリアムコミュニティは徐々に自己破壊的なオプコードを排除したいと考えています。過去にSelfDestruct Opcodeを変更または削除する多くの提案があり、EIP-6780はその1つであり、最終的にDencunハードフォークに含まれていました。

注：2023年初頭の上海ハードフォークでは、EIP-6049はSelf-Destructが排除されることを公式に発表しました。

Verkle Treeは、現在Ethereumコミュニティによって積極的に研究および開発されている状態貯蔵構造であり、現在のMerkle Patricia Treeを置き換えるために使用されます。Verkle Treeは、Ethereum Stateの証明サイズを小さくするため、Stateless Client Designの鍵でもあります。ステートレスクライアントを使用すると、ノードのハードウェアが削減され、より多くの人がより軽量で安価なハードウェアでノードを実行できるようになり、ネットワークの分散化が改善されます。

操作の詳細

EIP-6780の後、SelfDestruct OpCodeは（1）動作を削除し、（2）「指定されたアドレスに体のすべてのETHを転送」の機能を保持します。契約コードとストレージは、契約が同じトランザクションで作成され、その後セルフデストラクトが実行されない限り、変更されません。

したがって、SelfDestructがトリガーされたとき：

契約が同じトランザクションで作成されていない場合、契約コードとストレージは変更されていませんが、その上のETHは指定されたアドレスに転送されます。
契約が同じトランザクションで作成されている場合、動作は以前と同じです（EIP-6780以前）：契約のコードとストレージが削除され、ETHが指定されたアドレスに転送されます。

Verkle Treeの場合、（1）の動作を削除する必要があります

Verkle Treeのデザインでは、その保管ステータスはMerkle Patricia Treeのステータスとは異なります。マークルパトリシアツリーの貯蔵状態は、2つの層（木の木）の構造として想像できます。最初の層はすべてのアドレスで構成されるツリーで、2番目の層は各アドレスのすべてのストレージと合成で構成されるツリーです。そして、Verkleの木は、層状の完全に平らな構造として想像できます。したがって、マークルパトリシアツリーでは、アドレスのストレージを簡単に見つけて削除できますが、Verkleツリーでは、アドレスのストレージを見つけることはほとんど不可能です。同じツリーに均等に配布されると、どの値がどのアドレスストレージに属しているかを簡単に知ることができないため、Verkleツリーの契約コードとそのすべてのストレージを削除することはできません。

current現在の状態ツリーデザイン（Merkle Patricia Tree）は2層構造です。状態ルートは、すべてのアドレスセットで構成されるツリーに対応し、ストレージルートはアドレスの下のすべてのストレージおよび合成ツリーに対応します。

出典：https：//fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html

berkle verkleツリーステートツリーは完全に平らな木です。

図では、赤いノードがアドレスであり、緑色のノードはアドレスのストレージ値です。

出典：https：//youtu.be/s7fm6zz_g0i?t=572

redストレージ（緑色のノード）のみを削除する場合、契約が同じアドレスに再配置されている場合、潜在的に高い脆弱性になります。

出典：https：//youtu.be/s7fm6zz_g0i?t=572

したがって、Verkle Treeを歓迎するには、SelfDestruct OpCodeが契約コードとストレージの削除を禁止する必要があります。

注意すべきこと

開発者がCreate2 + SelfDestructを使用して同じアドレスに繰り返し展開する場合、これはDenCun後の同じトランザクション内でのみ同時に発生して完了します。
開発者がCreate2 + Self -destructを使用して契約のアップグレードの効果を実現した場合（Create2 + SelfDestructは同じトランザクションで完了しません）、Dencunの後も続くことはできません。

EIP-7044

コンセンサスレイヤーの変更
EIP-7044：永久に有効な署名された自発的出口

https://eips.ethereum.org/eips/eip-7044

EIP-7044：永久に有効な署名された自発的出口

https://ethereum-magicians.org/t/eip-7044-perpetially-valid-signed-voluntary-exits/14348

EIP-7044では、検証者が使用する署名がPOSを出ることを許可し、ネットワークハードフォークのために署名が無効であることを避けます。非管理されていない誓約サービス（LIDOなど）に委託された検証剤のユーザーエクスペリエンスと保護は改善されます。ハードフォークを必要とするたびに、第三者に再署名するように依頼する必要はありません。

背景

Ethereum POSの検証は、2つのプライベートキーを使用する必要があります。1つは検証（ブロックの生産や署名など）に使用されますアドレスのキーは、引き出しキーと呼ばれます。VALIDATORがPOSを終了しようとしているとき、彼はVALIDATORキーで署名し、署名されたコンテンツには現在のネットワーク（ハードフォーク）バージョンが含まれます。

現在の非ホストの誓約サービスでは、サービスプロバイダーはバリデーターキーを手に保持し、ユーザーは引き出しキーを保持します。非義務の目的を達成するために資産と取り扱い料金を誓約します。「POSを終了しない」ことでユーザーを強要すると脅しているサービスプロバイダーを避けるために、サービスプロバイダーは最初にExit POS証明書に署名し、ユーザーに証明をユーザーに引き渡すことができます。サービスプロバイダーの影響を受けます。

操作の詳細

ただし、POSを終了する署名コンテンツには、現在の上海や以前のバージョンのCapellaなどの現在のネットワーク（ハードフォーク）バージョンが含まれているためです。ネットワークは、「出口証明書のハードフォークバージョン」と「現在のバージョンのネットワーク」を比較します。バージョンの違いが2つ以上のバージョンである場合、言い換えれば、ネットワークが更新され続けているため、ハードフォークと新しいバージョンにアップグレードした後、古すぎる出口証明は無効になります。

たとえば、古いものから新しいものまでのコンセンサスレイヤーのハードフォークバージョンは、Altair、Bellatrix、および（現在の）Capellaです。Altairで署名された出口証明書は、Denebの次のバージョンに更新されると、AltairとBellatrixで署名された出口証明書が無効になります。この状況に対処するために、ユーザーがフォークを事前に獲得しない場合、ユーザーはサービスプロバイダーから別の出口証明書を要求する必要があります。 Exit POSは、ユーザーを脅迫することを脅かします。

注：ただし、「Exit POS」はCapellaの後にのみ開いているため、AltairまたはBellatrixのExit証明書に事前にサインアウトすることはできません。

したがって、EIP-7044は、出口証明書のハードフォークバージョンをCapellaに修正するため、現在のバージョンで署名されたすべての出口証明書が永続的に有効になります。将来何回更新されても、Capellaは出口証明書に署名され、ハードフォークバージョンの影響を受けなくなります。

注意すべきこと

出口証明書のハードフォークバージョンは既にCapellaで固定されているため、検証者またはサービスプロバイダーがDenebバージョンのExit証明書に事前に署名する場合、Denebの後に無効になります。

EIP-7045

コンセンサスレイヤーの変更
EIP-7045：Max Attestation Inclusion Slotを増やします

https://eips.ethereum.org/eips/eip-7045

EIP-7045：Max Attestation Inclusion Slotを増やします

https://ethereum-magicians.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342

EIP-7045は、バリデーターの投票の有効期間を延長し、より多くの時間を獲得し、ネットワークの安定性を高めます。一般ユーザーや検証剤には影響しません。

背景

もともと、検証者（証明）の投票には、たとえば獲得できるエポック（32スロット）時間があります。待ち時間の問題またはそれは、Slot 10020票の後にP2Pネットワークに成功裏に放送されましたが、彼女の投票はまだ獲得されます。しかし、彼女の投票が10033スロットまでしか表示されない場合、彼女の投票を含める方法はなく、投票がないとみなされます。

操作の詳細

EIP-7045は、最新の「投票の次のエポックが終了する前」まで、投票包含の有効期間を延長します。たとえば、Verifier AliceがEpoch 100のSlot 3205で投票するように割り当てられ、EIP-7045の前に、Slot 3237（3237 = 3205 + 32）まで有効であるとしますスロット3237（3237 = 3205 + 32）。

注：エポック0には、エポック100が含まれています。

EIP-7514

コンセンサスレイヤーの変更
EIP-7514：最大エポックチャーン制限を追加します

https://eips.ethereum.org/eips/eip-7514

EIP-7514：最大エポックチャーン制限を追加します

https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

背景

上海が2023年にPOSを退出するためにバリデーターをアップグレードして開設した後、より多くのユーザーを引き付けてバリデーターになり、バリーター待機シーケンス（エントリキュー）が常にいっぱいになり、バリデーターの総数も急速に増加しています。

open POSを終了した後、エントリキューが急増しました。出典：https：//www.validatorqueue.com/

バリエーターがシーケンスが完全にロードされたままになるのを待っている場合、2023年5月までに2023年9月（EIPが提案されたとき）から約8か月でETHがPOSを誓約します。 2019年。あまりにも多くのバリデーターなど、非常に多くのETHステーキングのいくつかの欠点があり、検証者の投票と集約署名が多すぎると、検証装置のP2Pネットワークの負担とコンセンサスチェーンの拡張が増加します。さらに、一部の人々は、イーサリアムに必要なセキュリティには、それほど多くのETHの株式が必要ではないと考えています。

そして、なぜそんなに多くのETHが注がれ続けるのですか？ETHが100％の株式に達したとしても、年間レートはまだ約1.6％であるため、液体ステーキングトークン（LST）の出現により、MEVのリターンと相まって資本利用効率がさらに向上しました。非常に魅力的なオプション。

幸いなことに、2023年後半に誓約が徐々に後退し、バリッターの数の成長が遅くなりました。

balidavertherivationの数の増加は2023年後半に減速し、2024年2月に約25％のETHが誓約しました。出典：https：//www.validatorqueue.com/

操作の詳細

エントリキューの元の数は、現在のバリデーターの数が増加または減少するごとに異なります。約950,000です）。

EIP-7514はエントリキューの制限を8に修正し、現在のバリッターの数とはもはや増加せず、それによりバリッターの成長を遅らせ、コミュニティに次のハードフォークなどの長期的なソリューションを考案する時間を与えますEIP-7251を獲得できます。

EIP-4844およびEIP-7516

EIP-4844：Shard Blobトランザクション

https://www.eip4844.com/

Rollupの大きな追加：Proto-Danksharding（i）

https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6

Rollupの大きな追加：Proto-Danksharding（ii）

https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844は、新しいタイプのトランザクションを追加しました。これは、BLOBデータを保存するために特別に使用されるトランザクションです。データをBLOBに配置することにより、ロールアップはさらに取引手数料を削減します。

EIP-4844は、容量を拡張してアップグレードするための変更ではありませんが、「ブロックガス制限をアップグレードする」や「コストを削減する」ようなものであり、ブロックがより多く（ロールアップ）トランザクションを入力できるようにします。しかし、EIP -4844はまた、実際の拡張計画であるDankshardingへの道を開いています。

さらに、Blob FairとGeneral Fairは、それぞれ独自の基本料金と優先料金を備えた独立した料金市場です。トランザクション）。

要約とフォーカス

Dencun Hard Forkは、コンセンサス層のDenebハードフォークと、実行層のCancunハードフォークで構成されています。
このアップグレードの主人公は、EIP-4844です。LollUpは、トランザクションコストをさらに削減し、Dankshardingの道を開くことができます。
コンセンサス層の変更には、EIP-7044、EIP-7045、およびEIP-7514が含まれます。
EIP-7044では、POSをオプトアウトする際に、未成年のハードフォークを避けるために、管理されていないステイクサービスを使用してバリデーターが許可されます。
EIP-7045およびEIP-7514は、POSネットワークの安定性を高める更新と見なすことができます。
実行層の変更には、EIP-1153、EIP-4788、EIP-5656、EIP-6780、EIP-7516が含まれます。
EIP-1153では、多くの契約設計モデルが多くのガスを節約できます。
EIP-4788を使用すると、実行レイヤーは、サードパーティを信頼する必要がない方法でコンセンサスレイヤー情報を読み取ることができ、関連するサービスをステーキングする可能性を増やすことができます。
EIP-6780はさらに、自己破壊を排除し、「契約コードとステータスを削除する」能力を削除します。
開発者は、EIP-1153を使用するときに「トランザクション後に一時的なストレージがクリアされる」という仮定に注意を払う必要があり、契約が影響を受ける場合に影響を受けるかどうかに注意してください。
一般的に、ユーザーは特に注意を払う必要がありません。

参照データと推奨される拡張読み取り

EIP-1153

https://eips.ethereum.org/eips/eip-1153
https://www.eip1153.com/
https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553
https://hackmd.io/@-_wyfkbvsmip5m7mnb4b8a/sjfh666eca

EIP-4788

https://eips.ethereum.org/eips/eip-4788
https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

EIP-5656

https://eips.ethereum.org/eips/eip-5656

EIP-6780

https://eips.ethereum.org/eips/eip-6780
https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-exicte-where-it-occurs-in-the-same-in-the-same-a-contract-a-a contract-a-a contracted/13539
https://www.youtube.com/watch?v=s7fm6zz_g0i

EIP-7044

https://eips.ethereum.org/eips/eip-7044
https://ethereum-magicians.org/t/eip-7044-perpetially-valid-signed-voluntary-exits/14348

EIP-7514

https://eips.ethereum.org/eips/eip-7514
https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

EIP-4844＆amp;

https://www.eip4844.com/
https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
https://eips.ethereum.org/eips/eip-7516
https://ethereum-magicians.org/t/eip-7516-blobbasefee-opcode/15761