過去世

**なぜカンクンのアップグレードが必要なのでしょうか? **

• イーサリアムのビジョンは、分散化を前提として、よりスケーラブルかつ安全になることです。イーサリアムの現在のアップグレードもこのトリレンマの解決に取り組んでいますが、大きな課題に直面しています。
• イーサリアムの問題: ※現状ではTPSやパフォーマンスが低く、ガス料金が高く混雑が深刻であると同時に、イーサリアムクライアントを動作させるために必要なディスク容量も急速に増大しています。イーサリアムのセキュリティと分散化 環境全体に対するボリュームコンセンサスアルゴリズムの影響もますます重要になってきています。 ※ したがって、分散化を前提に、より多くのデータを送信してガスを削減してスケーラビリティを高めるにはどうするか、コンセンサスアルゴリズムを最適化してセキュリティを確保するにはどうすればよいか、というのが現在イーサリアムが取り組んでいる取り組みです。
• セキュリティ、分散化、スケーラビリティのトリレンマを解決するために、イーサリアムは PoW-to-PoS メカニズムを使用してノードしきい値をさらに削減し、またビーコン チェーンを使用して検証者をランダムに割り当ててセキュリティを最適化することも計画しています。イーサリアムはスケーラビリティの観点から、ノードのワークロードを軽減するためにシャーディングの使用を検討しています。これにより、イーサリアムは同時に複数のブロックを作成し、スケーラビリティを向上させることもできます。 ※現在のイーサリアムの各ブロックのスペースは200～300程度です KB、各トランザクションの最小サイズは約 100 バイト、約 2000 トランザクション、ブロック時間 12 秒で割ると、イーサリアムの TPS の上限は約 100 に制限されます。このデータは明らかにイーサリアムのニーズを満たすことができません。 ※そのため、イーサリアムレイヤー2は大量のデータをいかにブロックに入れるかに重点を置いています。 宇宙では、不正証明と正当性証明によって安全性が保証されるため、DA層がセキュリティの上限を決定するのですが、これがカンクンアップグレードの中核的な内容でもあります。
• イーサリアムエコロジーの反復ルートでは、ベンチマークである Solana のパフォーマンス (遅延とスループットの点で) を構築することはできず、Near の断片化パフォーマンスや、Sui と Aptos の並列実行パフォーマンスは短期的には見られません。 短期的には、イーサリアムはロールアップをコアとした多層構造しか構築できないため、カンクンはTPS、ガスを解決するためにアップグレードします 料金と開発者の経験はイーサリアムのロードマップにとって重要です。

**イーサリアムのロードマップはどのように計画されていますか? **

最近のいくつかの重要なアップグレードとその目標

• 2020年12月1* ビーコン チェーンが正式にリリースされ、POS アップグレード*への道が開かれます
• 2021**8月5** ロンドンのアップグレード、EIP1559 はイーサリアムの経済モデルを変更します。
• 2022年9月15* パリのアップグレード (** マージ**)、POW 切り替え POS;* が完了しました。
• 2023年4月12* 上海でアップグレードされ、誓約撤回の問題が解決されました。*
• 経済モデルと POS 関連のアップグレードが完了し、次のいくつかのアップグレードでイーサリアムのパフォーマンス、TPS、開発者のエクスペリエンスの問題が解決されました。
• 次のステップは、イーサリアムのロードマップに焦点を当てることです * うねり* 。
• 目標： ロールアップで 100,000 以上の TPS を達成する。
• オンチェーンとオフチェーンの 2 スキームがあります:
• オフチェーン ソリューション: ロールアップなどを含む Layer2 を指します。
• オンチェーン スキーム: 一般的なシャーディング スキームである L1 で直接変更を行うことを指します。シャーディングを簡単に理解すると、すべてのノードを異なるエリアに分割し、各エリアのタスクを完了することで、効果的に速度が向上します。
• シャーディング スキームの分析:
• シャーディングスキームのジレンマ: シャーディングにはステートシャーディング、トランザクションシャーディングなどが含まれていましたが、異なるシャード間の同期が問題であり、現在、大規模なネットワークノードのデータ同期を完了することは困難です。 MEV の状況を解決することはできませんが、発生する可能性のあるさまざまな問題を補うために多数のパッチが必要になる可能性がありますが、これは短期的には実現できません。 ※ Danksharding はイーサリアム向けに提案された新しいシャーディング設計であり、 その中心的なアイデアは、集中型ブロック生成 + 分散型検証 + 検閲への耐性です。これは、以下で説明するサンプリング (DAS) のデータの可用性にも関連しています。生産者と梱包者の分離 (PBS) と検閲抵抗リスト (Crlist) をブロックします。 Danksharding の中核となるアイデアの最大の意義は、イーサリアム L1 を統一決済 (決済) とデータ可用性 (データ可用性) に変えることにあります。 可用性）層。

シャーディング スキームは 2 ステップに分割されており、現在は プロト- シャーディング とフルロールアップ******。 ***

• したがって- ダンクシャーディング**：**
• 導入： BLOB を導入することで L2 料金の削減とスループットの向上を支援します 、同時に完全なシャーディングへの道を開くプレシャーディング ソリューションとしても機能します。プロトダンクシャーディングの後、ダンクシャーリングの実装には 2 ～ 5 年かかると予想されます。
• 内容: プロトダンクシャーディングの主な特徴は、新しいタイプの BLOB トランザクションを導入することです. BLOB は大容量かつ低コストという特徴を持っています. このようなデータ パケットをイーサリアムに追加することで、すべてのロールアップ データを BLOB に保存することができます。メインチェーンへの負担を軽減し、保管のプレッシャーによりロールアップのコストも削減できます。
• フルロールアップ
• はじめに: ロールアップは、データの可用性の活用に焦点を当てて完全に拡張されました。
• コンテンツ：
• DAS の P2P 設計: データ シャーディング ネットワーク接続の問題に関する作業と研究。
• データ可用性サンプリング クライアント: 数キロバイトをランダムにサンプリングすることで、データが利用可能かどうかを迅速に判断できる軽量クライアントを開発します。
• 効率的な DA 自己修復: 最悪のネットワーク条件 (悪意のあるバリデータ攻撃や大規模ブロック ノードの長期ダウンタイムなど) の下でもすべてのデータを効率的に再構築できます。

イーサリアムコア開発者ミーティング

イーサリアムのすべてのアップグレードは、コア開発者の共同議論を通じたコア開発者会議に依存しており、開発者からの一連の提案に従って、将来の開発方向が決定されます

*定義: コア開発者会議は、イーサリアム開発コミュニティによって毎週開催される電話会議であり、さまざまな組織のコア貢献者が技術的な問題について話し合い、イーサリアムに関する今後の作業を調整します。彼らは、イーサリアムプロトコルの将来の技術的方向性を決定するとともに、イーサリアムのアップグレードについて実際に決定を下す権威者でもあり、アップグレードにEIPが含まれるかどうか、ロードマップを変更する必要があるかどうか、その他重要な事項を決定する責任を負っています。重要です。 ※コアプロセス：EIPを中心としたアップグレードプロセスは、大まかに以下のとおりです まず、コア開発者会議（略してACD）でEIPが承認され、その後、EIPがEIPに含まれるかどうかに関係なく、クライアントチームでテストされます。最終テスト後に再度検討し、議論を踏まえて実際のアップグレードに含めるかどうかを決定します。

• カンファレンスは2***カテゴリに分かれており、コンセンサス層ミーティングとエグゼクティブ層ミーティングが隔週で交互に開催されます。
• ** コンセンサスレイヤーミーティング (すべて コア開発者コンセンサス - ACDC)、イーサリアムコンセンサス層 (プルーフ オブ ステーク、ビーコン チェーンなど) に焦点を当てます。**
• 役員レベルの会議 ( 全員 コア開発者ソリューション - ACDE**)。イーサリアムの実行層 (EVM、**Gas スケジュールなど) に焦点を当てています。
• イーサリアム コア メンテナーには 3 つのタイプがあり、主に公式組織または提案について議論するボランティア フォーラムがあります。
• AllCoreDevs: コード管理者。ETH1 ネットワーク クライアントのアップグレード、イーサリアム コードとコア アーキテクチャの保守を担当します。
• 「プロジェクト管理」セクション: Ethereum 開発者をサポートし、ハード フォークを調整し、EIP を監視し、AllCoreDev の通信と運用を直接支援します。
• イーサリアム Magicians: EIP やその他の技術的なトピックに関する議論を求める「フォーラム」。

カンクンエスカレーション関連会議のタイムライン

協議の内容によれば、今回のカンクンアップグレードは大きく5******段階に分かれる。 ***

フェーズ 1 - アップグレード テーマの導入

新しいタスクの紹介proto-danksharding***、EOF、および「selfdestruct」 * オペコード、上海アップグレード内容の表面的な説明*

• 22年9月15日にイーサリアムの合併が完了した後、開発者会議は4週間中断され、開発者はその後のアップグレードで議論されたEIPを1か月間確認することができました。 ※22年10月28日の合併後初の開発者会議では、初めてプロトダンクシャーディング、EOF、「selfdestruct」オペコードの実装が提案されましたが、現時点ではプロトダンクシャーディングの具体的な範囲は決まっておりませんが、私の意見では、上海のアップグレードは、最初に約束されたETHの出金を可能にし、次にEIPをアップグレードするなど、いくつかの小さなアップグレードに分けることができます。 4844 ですが、別の開発者グループは、大規模なアップグレードを 1 ステップで実装する方が合理的であると考えています。

フェーズ 2 - 期間の決定と KZG 式典の準備

2022** 年末、イーサリアム カンファレンスは主に ***EOF と EIP を中心に展開します 4844 EIP の推進を継続しながらのディスカッション 4844 ***—KZG セレモニーに必要な事前信頼性設定セレモニー、開発者は ***23 に参加します 年 **** 1 **** 月、どのアップグレード **** 4844 **** が *** に登場するか正式に確認されました

• 11 月 22 日、イーサリアムのすべてのコア開発者によるカンファレンスコール #149 で、EOF またはプロトダンクシャーディングについて言及されましたが、現時点では、開発者はそれを上海アップグレードに含めることをまだ検討しています。 ※22年12月2日のコンセンサスレイヤー会議で、イーサリアムエコシステム責任者トレント氏 Van Epps が EIP を更新しました 4844 信頼できるセットアップセレモニーを生成するために必要な実装の進捗状況 4844で使用されるセキュリティコード。バン エップス氏は、この式典が暗号通貨業界史上最大規模の式典の一つとなり、8,000から10,000の寄付を集めることを期待しており、式典の一般寄付期間は約2か月続き、12月中に始まる予定である。 ※同日のコア開発者会議では、EOFと自己破壊オペコードの無効化について議論があり、イーサリアム財団の開発者は、コード変更が上海に含まれていない場合、カンクンでのEOF延期に反対した。カンクンに入る可能性は非常に低い、自爆コードに関しては、当時EIPの推進を主張する開発者がいる 4758 ですが、このオペコードを直接無効にすると一部のアプリケーションが機能しなくなるため、開発者は、このタイプのコントラクトを保護するためのエッジ ケースを作成する前に、この EIP をしばらくの間再度検討する必要があると考えています。 ※22年12月9日のコア開発者会議では、カンクンアップグレードと現行EIPに関してKZGセレモニーの実施を推進 4844 必要な信頼できるセットアップの準備ができています。 ※22年12月16日のコンセンサスレイヤーミーティングにてEIPについて 4844 では、開発者は 2 つの異なるプル リクエスト (PR) をプロト ダンクシャーディングの仕様にマージすることについて議論しました。1 つはデータ プルーニング後の特定の時点を超えたデータの可用性をノードが処理する方法に関連し、もう 1 つはブロックが警告するために新しいエラー コードが導入されるときです。 BLOB に関する情報が欠落しているノード
• 01/05/23 のコア開発会議中、開発者は上海アップグレードから EOF 実装に関連するコード変更を削除することで合意に達しました。この時、Beiko は EOF をカンクンに含めるべきかどうか 2 週間後に決定するよう提案しました。アップグレードされました。

フェーズ III - 提案の範囲に関する予備的な議論

231EOF の終わりに昇進のためカンクンに移動上海プロモーションから移転後、それ以来2月はEOFとEIPを除いて主に回っています。 4844以外の提案も議論され、同時にEOF**のカンクンからの移転も提案された。この期間は主に、カンクンのアップグレードに関する提案範囲の詳細を説明するために費やされました。 ***

• 1 月 20 日と 23 日のコア開発者会議で、EOF はアップグレードのためにカンクンに移動されました。
• 23 年 3 月 6 日のコア開発者会議では、カンクン アップグレードの暫定提案は次のとおりでした: EIP 4788 (パブリック ビーコン チェーン ステート ルート)、EIP 2537 (BLS 署名検証や SNARKs 検証などの操作を効率的に実行)、EIP-5920 (新しいオペコード PAY を導入)、および EIP 6189 (SELFDESTRUCT を Verkle ツリーと互換性を持たせるため) と EIP-6190 (限られた数の状態変更のみを引き起こすように SELFDESTRUCT 関数を変更する) を組み合わせた実装。 ※EOF、EIPを除く、23年3月16日のコア開発者ミーティングにて 4844 では、次の提案がカンクンに含められるか検討されました: SSZ 形式、SELFDESTRUCT の削除、EIP 2537、EVMMAX、EIP

1153. 無制限の SWAP および DUP 命令。EVM に PAY コードとビーコン状態ルートを導入します。 ※23年3月30日のコア開発者会議において、SELFDESTRCT無効化に関する提案EIP-6780が初めて提案され、カンクンが最終的に採用を決定したSELFDESTRUCT無効化提案でもある。ただし、EOF の実装に関しては、Erigon より (EL) クライアントチームの開発者は EOF と言いました 今後のカンクンアップグレードでイーサリアム改善提案EIPと競合するには「変更が多すぎる」 4844、カンクンのアップグレード直後にハードフォークで EOF を実装するという提案がありました。

第 4 段階 - プロポーザルのアップグレードの明確な方向性を決定し、無関係なプロポーザルを削除します

234月には、カンクンのアップグレードでカバーされるべき提案について明確な方向性があり、主要なノードは次のとおりです。 4 ******************************************** ************************************************* *********** EIP と tim も、代替案についてより詳細な議論を行いました。 4月27、EIP会議にて 6780、EIP 6475 およびEIP 1153 はカンクンに含まれることが決定され、同時に EOF および EVMMAX ( 付き) EOF 実装関連 EIP サブセット) がカンクンのアップグレードから削除されました。EOF アップグレードは主に役立ちますEVM** はバージョン管理を実行し、複数のコントラクト ルール セットを同時に実行できます。これはイーサリアムのその後の拡張に役立ちますが、アップグレード全体の実現可能性を考慮すると、** * EOFアップグレードは毎日のアップグレードで引き継がれる可能性があります*

• 23****4月12****、イーサリアム上海のアップグレードが完了しました;
• 13.04.23 のコア開発会議中、開発者は EIP について話し合いました。 4844 (EL 内の CL 状態ルートに関するデータを公開するため)、アップグレードの対象として検討されている他の EIP が少なくとも 9 つあります。つまり EIP 4844**、自己破壊 削除 (EIP-6780、EIP) 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP（EIP 6601 と EIP 6690)、SS 変更（EIP 6475、EIP 6493、EIP 6465、EIP 6404 および EIP 6466 ）、EIP 5656 および *EIP 6193；
• 23 年 4 月 27 日のコア開発者会議では、いくつかの進歩とトレードオフに焦点が当てられました。まず、EIP4844 は引き続きカンクンのアップグレードに含められるように識別されており、次の EIP が追加されています。 EIP 6780 (SELFDESTRUCT オペコードの機能変更)、EIP 6475 (オプションの値を表す新しいシンプル シリアル化 (SSZ) タイプ)、EIP 1153 (ステータスを操作するための新しいオペコードを追加); 次に、検討されているが正式にアップグレードに含まれていない EIP は EIP です。 6913 (SETCODE 命令の導入)、EIP 6493 (SSZ でエンコードされたトランザクションの署名スキームを定義)、EIP 4788 (EL ブロック ヘッダーのビーコン チェーン ブロック ルートを公開)、EIP 2537 (プリコンパイルとして BLS12-381 曲線を追加) および EIP 5656 (メモリ領域をコピーするための新しい EVM 命令を導入)、最後に EOF ** および ** EVMMAX** (** EOF ** 実装依存 ** * EIP* サブセット) はカンクンのアップグレードから削除されました。 **EOF このアップグレードは、20231**** 初めのイーサリアム開発者カンファレンスで上海から移動され、その後 * からアップグレードされました。 *** 23**** の 1 の終わりから 4 の始まりまで、デフォルトでカンクンのアップグレードに表示されますが、* 23** *EOF *は、29、4の開発者会議で再び削除されました。 **

第 5 段階 – 最終提案の決定と詳細の改善

235月は主に最終提案の詳細を合理化し改善します。SSZ-> RLP の変更は、カンクンの 2 つのSSZ が不要になることを意味します EIP**、つまりEIP 6475 と 6493 はアップグレードのためにカンクンから移動されます。同時に、26 日のコア会議で、ティム Beiko は、カンクンの範囲の拡大に関する将来の会話を次の 5 つのEIP:*EIP-5920 に限定することを推奨します。 * 、5656、7069、4788 および ****2530 * ****。開発者は現在、カンクンのアップグレードの全範囲を決定しています。 ***

*5/5/23 のイーサリアム コア コンセンサス ミーティングで、最後に言及された EIP について議論 4788、EIP の追加中 6987 と EIP 6475 での議論では、これら 2 つの提案はそれぞれ検証者と SSZ トランザクションに関するものです。

• 23 年 5 月 11 日の第 161 回イーサリアム エグゼクティブ レイヤー会議で、ティム ベイコ氏は、カンクンのアップグレードの範囲は今後数週間以内にまだ変更できるが、開発者からの明確なアドバイスがなければ、カンクンのアップグレードの範囲は「デフォルト」状態のままであり、EIP-4844に関する議論はそれを示していると述べた。開発者は、EIP-4844 の EL 実装から SSZ を削除することに同意しましたが、** 6475 ** の継続的な進捗にはまだ影響していません。 **これに加えて、開発者はカンクンで検討される 2 つの EIP、すなわち EIP についても簡単に議論しました。 6969（EIP）

1559. および EIP 5656 (メモリ領域をコピーするための効率的な EVM 命令);

• 4844 の開発は、EL 上のスマート コントラクト アプリケーションが CL 状態の証明を検証できるようにするなど、23 年 5 月 18 日の開発者コンセンサス会議で簡単に議論されました。
• SELFDESTRUCT の非アクティブ化、EIP-4844 仕様変更、オペコード管理、および最終的なカンクン追加の可能性については、2023 年 5 月 25 日の第 162 回イーサリアムコア会議で議論されました。ティム ベイコ氏は、カンクンの範囲拡大に関する今後の会話は次の 5 つの EIP に限定することを推奨しています: EIP-5920**、5656、7069、* ** 4788* ** と ** 2530**。開発者は今後数週間以内に確認する予定です ** Dencun** (****Deneb

• カンクンの全域****);** ※2023年6月1日に開催された第110回イーサリアムコンセンサスレイヤーミーティングにおいて、イーサリアム財団の研究者が、イーサリアムメインネットノードの大量データ配信能力に関するデータ実験の結果を紹介し、この結果から、研究者は、 EIP 4844 仕様では、ブロックあたり最大 4 つの BLOB から 6 つの BLOB に増加しました。同時に、開発者は EIP を検討しています。 4788 はカンクンのアップグレードに含まれています。

• 2023 年 6 月 13 日のコア開発者会議で、開発者は EIP を含むアップグレード範囲を正式に確認しました 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；
• 2023 年 6 月 15 日のコンセンサス ミーティングでは、どの CL 中心の EIP を Deneb に含めるかが議論され、その中で EIP-6988、EIP-7044、EIP-7045 が追加されることが提案され、CL クライアント チームはこれに同意しましたEIP-4844 テスト ネットワーク Devnet6 は、増加した BLOB をテストし、2 週間以内にこの問題について最終決定を下す予定ですが、イーサリアム財団の研究者 Michael 氏は、 Neuder は、アクティブなバリデータセットの増加を抑えるために 32 ETH ステーキングの上限を削除することを提案しました。
• 2023 年 6 月 22 日の会議で、tim は、プリコンパイルされたアドレス 4844 を 0xA に移動し、それらをパックして、BLS を別のアドレスに移動することを提案しました。ただし、BLS は EIP 経由でプリコンパイルされています。 2537 年ですが、カンクンでは考慮されません。
• 2023 年 6 月 29 日のコンセンサス ミーティングで、開発者は BLOB の数について議論を続け、対象の BLOB を制限しました 2 から 3 に増加し、最大 BLOB 制限が 4 から 6 に増加し、4844 テスト ネットワーク Devnet #7は近日公開予定です。

この人生

※コアコンテンツはEIPです 4844、すなわちプロトダンクシャーディング

• このカンクン アップグレードの最終的な EIP 範囲は次のとおりです: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788。一方、6月19日に開催された第111回イーサリアムACDC会議では、開発者らは**EIPについて議論を続けた。 6988**、** EIP 7044**、**EIP デネブに含めるための 7045。開発者らは、今後数週間以内に前述の 3 つの EIP を Deneb 仕様にマージする予定であると述べました。

キーEIPの分析

EIP 4844

• 導入：
• EIP4844 プロポーザルの名前は、シャーディング拡張 Danksharding のフルバージョンのプレプロトコルである Proto-Danksharding であり、シャーディング スキームのセット全体は、実際にはオンチェーン拡張のためのロールアップに基づいています。 プログラムの目的は、 2 レイヤー **ロールアップ——****L2 の料金削減とスループットの向上を支援することにより、拡張することです。 同時に、完全なシャーディング (シャーディング) への道を切り開きます。 **
• 2 月 23 日の電話会議で、イーサリアム開発者は EIP 4844 アップグレードの名前は Deneb です。これははくちょう座の一等星の名前であり、将来、関連する GitHub バージョンの EIP になります。 4844の名前はデネブに更新され、23年6月1日の会議ではイーサリアムの次期アップグレード仕様に若干の変更があり、CL側ではデネブ、EL側ではカンクンと呼ばれる。 ※23年6月23日の開発者会議では、開発者らはEIPアップデートの準備を行った 4844 のプリコンパイル済みアドレス。現在、コア開発者は EVM に 9 つのプリコンパイルを追加しており、次の方法で EIP をアクティブ化します。 4844 と 4788 は、それぞれ「0xA」アドレスと「0xB」アドレスの下に 2 つのプリコンパイルを作成します。 6 月 29 日のコンセンサス会議で、EIP の立ち上げ準備が完了 4844 の短期専用テスト ネットワーク Devnet ＃7。
• EIP-4844** は、まったく新しいトランザクション タイプ - Blob を導入します トランザクション。** *ブロブプロファイル:
• BLOB、プラグイン データ パケットに似ており、最初は 128 のみ KB のストレージ容量は、提案の議論の開始時点では Blob の目標と制限が 2/4 でしたが、23 年 6 月 9 日の開発者会議で 3/6 に調整されました。つまり、現在イーサリアムの各トランザクションは最大 3 つの Blob トランザクション、つまり 384 件を実行できます。 KB、各ブロックのターゲット BLOB の容量は 6、つまり 768 です KB。最大 16 個の BLOB (2MB) を保持できます。
• ネットワークの安定性に一定の影響を与える可能性がありますが、イーサリアム開発チームは、BLOB ブロックを拡張するための後続のハード フォークの必要性を避けるために、最初にテストすることにしました。
• ブロブ **in ** KZG commit Hash データ検証に使用される ** Hash として、この関数は ** Merkle ; に似ています。
• ノードはチェーン上の BLOB を同期します トランザクション後、BLOB パーツは有効期限が切れ、一定期間後に削除されます。保存期間は 3 週間です。
• BLOB 関数 - コストを削減しながら、イーサリアムの TPS を向上させます
• 現在、イーサリアム全体の総データ量はわずか約 1 TB ですが、Blob は毎年 2.5 ～ 5 TB の追加データ量をイーサリアムにもたらすことができ、これは台帳自体の数倍を直接的に超えます。
• ノードの場合、ブロックごとに 1 MB ～ 2 MB の BLOB データを追加でダウンロードしても帯域幅の負荷は発生せず、ストレージ容量は毎月約 200 ～ 400 GB の固定量の BLOB データが増加するだけであり、影響はありません。イーサリアムノード全体の分散化が図られていますが、ロールアップ周りの拡張が大幅に改善されています。
• 実際には、ノード自体はすべての BLOB データを保存する必要はありません。BLOB は実際には一時的なデータ パッケージであるため、実際には、ノードは 3 週間の固定量のデータをダウンロードするだけで済みます。
• EIP-4844の役割** - ダンクシャーディングの物語の最初の章を開く**
• **大容量拡張: **現時点では、EIP-4844 は最初に L2 容量を拡張できます。Danksharding のフルバージョンでは、EIP-4844 の BLOB データ ボリュームを 1MB から 2MB、16MB から 32MB まで拡張でき、分散化とセキュリティが確保されます。より高い拡大を達成する。
• **低料金: **バーンスタインのアナリストは、プロトダンクシャーディングによりレイヤー 2 ネットワークの料金を現在のレベルの 10 ～ 100 倍に削減できることを示しています。
• 実際のデータ:
• Opside テスト ネットワークは 4844 を導入しており、現在の観察によれば、ロールアップのコストを 50% 削減できます。
• AigenLayer の DA 技術ソリューションは、そのデータを評価できるほど多くの情報を開示していません。
• 厳密に言えば、Celestia はイーサリアムとはほとんど関係がなく、具体的な技術ソリューションに応じて、その DA コストを現時点で評価することはできません。
• Ethstorage の解決策は、レイヤー 2 ストレージ証明書をアップロードすることであり、DA コストは元の 5% に削減される可能性があります。 ※ダンクシャーディングの幹線ネットワークはセキュリティやレイヤー1 P2Pネットワークブロードキャストとの互換性も考慮する必要があるため、トピアでは100～1000分の1のコスト削減を見込んでいます。
• DA** 解決策: Danksharding (イーサリアム拡張用のシャーディング ソリューション) 現時点では、拡張が続くとノードの負荷が大きすぎる可能性があります (****16mb) **** 上記）、データの可用性が不十分（30 有効期限）。解決： **
• データ利用可能サンプリング (データ 可用性サンプリング) - ノードの負担を軽減します。
• Blob 内のデータをデータフラグメントに分割し、ノードが Blob データのダウンロードから Blob データフラグメントをランダムにチェックするように変更します。これにより、Blob データフラグメントはイーサリアムの各ノードに分散されますが、完全な Blob データはイーサリアム台帳では、ノードが十分で分散化されている必要があることが前提となります。
• DAS は 2 つのテクノロジーを使用します: Erasure Code (Erasure Code) コーディング) および KZG 多項式コミットメント (KZG) 献身）;
• Proposer-Packager Separation (PBS) —— ノードの分業の問題を解決し、エンコード配信用のすべてのデータのダウンロードを高パフォーマンス構成のノードが担当し、エンコード配信用のすべてのデータのダウンロードを低パフォーマンス構成のノードが担当します。スポットチェック検証。
• 高性能構成のノードはビルダーになることができます。ビルダーは、エンコード用の BLOB データをダウンロードしてブロック (Block) を作成し、それをスポット チェックのために他のノードにブロードキャストするだけです。ビルダーの場合、同期が行われるため、データ量と帯域幅の要件が高いため、比較的集中化されます。 ※性能の低い構成のノードでも提案者（Proposer）となることができ、提案者はデータの正当性を検証し、ブロックヘッダ（Block）を作成してブロードキャストするだけで済みます。 Header) ですが、提案者 (Proposer) にとっては、同期データ量と帯域幅の要件が低いため、分散化されます。
• 検閲防止リスト (crList) - 過剰なレビュー権限により、パッケージャが特定のトランザクションを意図的に無視し、MEV を取得したいトランザクションをランダムに並べ替えて挿入できるという問題を解決します。
• ビルダー (Builder) がブロック トランザクションをパックする前に、提案者 (Proposer) はまず、mempool 内のすべてのトランザクションを含むレビュー耐性のあるリスト (crList) を公開します。
• ビルダー (Builder) は crList 内のトランザクションをパッケージ化して並べ替えることのみを選択できます。つまり、ビルダーは MEV を取得するために独自のプライベート トランザクションを挿入したり、トランザクションを意図的に拒否したりすることはできません (Gas を除く) 制限がいっぱいです);
• パッキング後、Builder はトランザクション リスト ハッシュの最終バージョンを Proposer にブロードキャストし、Proposer はトランザクション リストの 1 つを選択してブロック ヘッダー (ブロック) を生成します。 ヘッダー）とブロードキャスト。
• ノードがデータを同期するとき、プロポーザー (Proposer) からブロック ヘッダーを取得し、次にパッケージャー (Builder) からブロック 本体を取得して、ブロック 本体が最終的に選択されたバージョンであることを確認します。
• デュアルスロット PBS - MEV を買収することで、集中型パッケージャーがますます集中化しているという問題を解決します
• 入札モードを使用してブロックを決定します。
• ビルダー (Builder) は crList を取得して入札した後、トランザクション リストのブロック ヘッダーを作成します。 ※提案者（Proposer）は最終的に落札したブロックヘッダーとビルダー（Builder）を選択し、提案者は（有効なブロックが生成されたか否かに関わらず）無条件で落札手数料を受け取ります。
• 検証委員会 (Committes) が勝者のブロックヘッダーを確認します。
• ビルダーは勝ったブロックの本体を公開します。 ※検証委員会（Committees）は、当選したブロックの本体を確認し、認証投票を行います（ブロックが通過した場合はブロックが生成され、パッカーが意図的にブロック本体を提供しなかった場合はブロックが作成されたものとみなされます）存在しない）。
• 意味：
• まず第一に、ビルダー (Builder) はトランザクションをパッケージ化するためのより多くの権限を持っていますが、上記の crList は、第一にトランザクションを一時的に挿入する可能性を制限し、第二に、ビルダー (Builder) がトランザクションの順序を変更することで利益を得たい場合、ブロック長の資格を確実に取得するには、最初に多額の入札コストを支払う必要があり、その後、MEVが得られる利益はさらに減少し、全体的な手段と実際の価値に影響を与えます。 MEV の取得。
• ただし、初期段階では、少数の人だけがパッカーになる可能性があり (ノードのパフォーマンスの問題を考慮して)、ほとんどの人は提案者になるだけであるため、さらなる集中化につながる可能性があります。の場合、MEV 機能を持つ一部の経験豊富なマイナーが入札に成功する可能性が高く、実際の MEV ソリューションの効果にさらに影響します。
• MEV オークションを使用する一部の MEV ソリューションに影響があります。
• 意味：
• EIP 4844 実際には超簡易バージョン Danksharding**: **Data と呼ばれる新しいオペコードを含む、Danksharding と同じアプリケーション インターフェイスを提供します。 ハッシュ、およびバイナリと呼ばれる新しいデータ オブジェクト ラージ オブジェクト、つまり Blob。
• proto-danksharding ** は、完全な ** Danksharding ** 仕様「ブラケット」** ** (**** はトランザクション形式と検証ルールです****) を実装するために使用されます。 * * 提案: ただし、シャーディングはまだ実装されておらず、すべての検証者とユーザーは依然として完全なデータの可用性を直接検証する必要があります。
• 長期的な視点でなぜ プロトダンクシャーディング ではない EIP 4488 ** は、* layer2 ** の料金を直接削減します。これは、将来完全なシャードにアップグレードするときに必要な調整はわずかだけであるためです**。
• EIP 4488 とプロトダンクシャーディングの主な実際的な違いは、EIP-4488 はイーサリアムが現在行う必要がある変更を最小限に抑えようとするのに対し、プロトダンクシャーディングは将来イーサリアムにアップグレードするために現在イーサリアムにさらに多くの変更を加えることです。フルバージョンのシャーディングに必要です。
• 完全なシャーディング (データ可用性のサンプリングなど) を達成するのは非常に複雑なタスクであり、プロトダンクシャーディングの実装後にやるべき作業はまだたくさんありますが、これらの複雑さはコンセンサス層で制御されます。プロトダンクシャーディングがデプロイされると、実行層クライアント チーム、ロールアップ開発者、およびユーザーは、完全なシャーディングに移行するために追加の作業を行う必要はありません。
• 完全なシャーディングを実現するには、 PBS*、委任証明、およびデータ可用性サンプリングの実際の実装を完了する必要がありますが、そのような変更は ** CL * に集中します。 * レイヤー、開発者が再調整する必要はありません **: 4844 は現在、完全なシャードに必要なトランザクション形式、コンセンサス相互検証ロジック、および実行レイヤー ロジックとまったく同じ新しいトランザクション タイプを実装しています。 BLOB 用に導出され、自動調整される独立したガス価格設定。将来的に完全なシャーディングを実現するには、PBS、委任証明、およびデータ可用性サンプリングの実際の実装を完了する必要がありますが、これらの変更は CL レイヤーでのみ行われます。 EL レイヤーまたはロールアップ開発者が変更する必要がないため、開発に便利です。

続いてSELFDESTRUCT 最終的には、、EIP-6780 の削除が最適なソリューションであると判断されましたが、開発者は 26 にtim*** 会議では、この提案に別のオペコードを追加することを提案SETCODE し、プログラマティック アカウントを引き続き更新できるようにしました***

自己破壊 削除 EIP-6780**：**X

• 背景：
• 3 月 21 日、Vitalik 氏は、SELFDESTRUCT はイーサリアムの生態系に利益よりも害を与えると提案しました。主な理由は、それが単一ブロック内の無限数の状態オブジェクトを変更できる唯一のものであり、その結果、契約コードが変更されることです。アカウントの同意なしに使用でき、アカウント残高の操作コードを変更できますが、これにはイーサリアムのセキュリティに大きな危険が潜んでいます。**
• オンチェーンでコントラクトを削除する唯一の方法は SELFDESTRUCT です。コントラクト内で selfdestruct 関数を呼び出すと、コントラクトを自己破棄できます。コントラクトに保存されたイーサリアムは、指定されたアドレスに送信されます。残りのコードとストレージ変数はステート マシンで削除されます。実際、契約破棄という行為は理論上は良さそうに聞こえますが、実際には非常に危険です。 selfdestruct** 機能は、開発者が緊急時にスマート コントラクトを削除し、コントラクトの残高を指定されたアドレスに転送するのに役立ちますが、この機能は犯罪者によっても使用され、攻撃手段となります。 **
• 4 月 13 日、23 日のコア開発者会議では、SELFDESTRUCT に関する 4 つの提案 (6780、4758、6046、6190) とそれに続く EIP が議論に参加するために紹介されました。 6780が最終案として決定された。
• はじめに: selfdestruct はスマート コントラクトの緊急ボタンで、コントラクトを破棄し、残りの ETH を指定されたアカウントに転送します。
• EIP 6780: コントラクト内の同じトランザクション内にない限り、SELFDESTRUCT を無効にします。
• 更新: 5 月 26 日、tim は SELFDESTRUCT の削除に加えて、別のオペコード SETCODE を追加して、プログラムによるアカウントを引き続き更新できるようにすることを提案しました。 (つまり、更新機能が追加され、更新/アップグレードによってスマート コントラクト内のプロパティが更新されます)、ここでは EIP の吸収が行われます 4758 の利点は、dapp にアップグレードの余地を与えることができます。

• 理由: SELFDESTRUCT コードを操作するには、当初、すべてのコードとストレージを削除するなど、アカウントの状態に対する広範な変更が必要でした。これは、将来 Verkle ツリーを使用する際に困難をもたらします。各アカウントは、ルート アカウントに明示的にリンクされない多くの異なるアカウント キーに保存されることになります。
• 変更済み: この EIP は、次の 2 つの場合を除き、SELFDESTRUCT を削除する変更を実装します。
• SELFDESTRUCT で資金を引き出すためだけに使用されるアプリは引き続き機能します。 ※コントラクト内の同一トランザクションで使用するSELFDESTRCTは変更する必要はありません。
• 重要性: セキュリティの向上
• 以前は、コントラクトを通じてトランザクションを開始できるユーザーを制限するために SELFDESTRUCT を使用するコントラクトがメインネット上にありました。
• SELFDESTRUCT 後にユーザーが引き続き資金を預け入れたり、保管庫で取引したりできないようにすると、この保管庫を繰り返し使用すると、誰かが保管庫内のトークンを盗む可能性があります。

以下の 3 つの提案は、23年****4 にその後削除された SELFDESTRUCT に関する提案です *** 6780 は ***28 のコア開発者会議で正式に選択され、他の 3 つの提案は放棄されました。イーサリアム開発チームは最終的に SELFDESTRUCT オペコードを完全に削除したいと考えており、次の 3 つの提案はほとんどが置き換えによって変更されます。 ***

• EIP-4758 (非推奨): SELFDESTRUCT を SENDALL に変更して SELFDESTRUCT を無効にします。これにより、すべての資金が呼び出し元に復元されます (アカウント内のすべてのイーサが呼び出し元に送信されます)。ただし、コードやストレージは削除されません。
• 理由: 上記と同様、以前は SELFDESTRUCT コードを操作するには、すべてのコードとストレージを削除するなど、アカウントの状態を大幅に変更する必要がありました。これは、将来 Verkle ツリーを使用する際に困難をもたらします。各アカウントは、ルート アカウントに明示的にリンクされない多くの異なるアカウント キーに保存されることになります。
• 変化：
• オペコード SELFDESTRUCT は SENDALL に名前変更され、アカウント内のすべての ETH を呼び出し元に移動するだけになりました。このスキームはコードとストレージを破壊したり、乱数を変更したりすることはなくなりました。 ※SELFDESTRUCT関連の返金は全て削除されました
• 意味：
• 一部のアプリケーションでは引き続き SELFDESTRUCT コードを使用する必要があるため、EIP-6780 と比較して元の機能が維持されます。
• EIP-6046 (非推奨): SELFDESTRUCT を DEACTIVATE に置き換えます。ストレージ キーを削除しないように SELFDESTRUCT を変更し、アカウント nonce で特別な値を使用して非アクティブ化を示します。
• 理由: 上記と同様、Verkle ツリーではアカウントの編成方法が異なります。アカウントのプロパティ (ストレージを含む) には個別のキーがありますが、使用されているすべてのキーを走査して見つけることは不可能です。以前は SELFDESTRUCT コードを操作するにはアカウントの状態を大幅に変更する必要があり、Verkle ツリーで SELFDESTRUCT を使用し続けることが非常に困難でした。
• 変化：
• 通常のノンスの増加が 2^64-1 ではなく 2^64-2 によって制限されるように、EIP-2681 によって導入されたルールを変更します。
• SELFDESTRUCT は次のように変更されます。
• ストレージ キーを削除せず、アカウントをそのまま残しておいてください。
• 口座残高をターゲット ** に転送し、**口座残高を 0 に設定します。
• アカウントの nonce を 2^64-1 に設定します。
• EIP-3529 以降、返金はありません。
• EIP-2929 の関連ルール SELFDESTRUCT は変更されません。
• 意味：
• この提案は、他の SELFDESTRUCT の直接削除よりも柔軟性があります。
• EIP-6190 (非推奨): Verkle と互換性のある SELFDESTRUCT が変更され、限られた数の状態変更のみが発生するようになりました。
• 理由: 上記と同様、Verkle ツリーではアカウントの編成方法が異なります。アカウントのプロパティ (ストレージを含む) には個別のキーがありますが、使用されているすべてのキーを走査して見つけることは不可能です。以前は SELFDESTRUCT コードを操作するにはアカウントの状態を大幅に変更する必要があり、Verkle ツリーで SELFDESTRUCT を使用し続けることが非常に困難でした。
• 変更: トランザクションの終了時にコントラクトを破棄する代わりに、それを呼び出したトランザクションの終了時に次の処理が行われます。 ※契約コードは0x1、乱数は2^64-1となります。
• コントラクトの 0 番目のストレージ スロットは、CREATE オペコード ( keccak256(contractAddress, nonce)) はアドレス指定時に発行されます。乱数は常に 2^64-1 です。
• コールが 1 つ以上のエイリアス コントラクトによって転送された後にコントラクトが自己消滅する場合は、エイリアス コントラクトの 0 番目のストレージ スロットをステップ 2 で計算したアドレスに設定します。
• 契約の残高はスタックの一番上のアドレスに全額転送されます。 ※スタック上部が飛び出ています。
• 意味：
• SELFDESTRUCT が最小限の変更で Verkle ツリーを形成できるように設計されています。 ※EIP-2929適用によりガス代が増加しました。

続いてEIP 1153***、ガス を節約しながら、将来のストレージ設計への道を切り開く***

EIP 1153X

• 概要: 一時ストア オペコード。ストアと同じように動作するが各トランザクション後に破棄される状態を操作するためのオペコードを追加します。
• 理由：
• Ethereum でトランザクションを実行すると、複数のネストされた実行フレームが生成され、各フレームは CALL (または同様の) 命令によって作成されます。コントラクトは同じトランザクションで再入力できます。その場合、複数のフレームが 1 つのコントラクトに属します。
• 現在、これらのフレームは 2 つの方法で通信できます。CALL 命令による入出力と、ストア更新による入出力です。別の信頼できないコントラクトに属する中間フレームワークがある場合、I/O 経由の通信は安全ではありません。
• 再入可能 たとえば、ロックでは、ロックの状態を通信するために中間フレームに依存することはできません。ストレージを介した SSTORE 通信 SLOAD は高価であり、一時ストレージはフレーム間通信の問題に対する専用のガス効率の高いソリューションです。
• 変更: 2 つの新しいオペコード、TLOAD ( 0xb3 ) と TSTORE ( 0xb4 ) が EVM に追加されました。
• 一時ストレージは、永続ストレージと同様に、それを所有するコントラクトにプライベートであり、所有するコントラクト フレームワークのみがその一時ストレージにアクセスできます。ストレージにアクセスするとき、すべてのフレームは永続ストレージと同じ方法で同じ一時ストレージにアクセスしますが、メモリとは異なります。
• 潜在的な使用例:
• 再入可能 ロック;
• オンチェーンで計算可能な CREATE2 アドレス: コンストラクター パラメーターは、初期化コード ハッシュの一部として渡されるのではなく、ファクトリ コントラクトから読み取られます。
• 単一トランザクション EIP-20 承認、例: #temporaryApprove(address 支出者、uint256 金額);
• 転送手数料契約: 取引中に転送のロックを解除するためにトークン契約に手数料を支払います。
• 「Till」モード: ユーザーがコールバックの一部としてすべてのアクションを実行できるようにし、最後に「Till」のバランスが取れているかどうかをチェックします。
• プロキシ呼び出しメタデータ: 不変のプロキシ コンストラクター パラメーターの値など、呼び出しデータを使用せずに追加のメタデータを実装コントラクトに渡します。
• 意味：
• 節約 ガス**、よりシンプルな** ガス 請求ルール;
• ** フレーム間通信の問題を解決します; **
• ** 既存の操作のセマンティクスを変更しないでください。 **
• 使用後に貯蔵タンクを空にする必要はありません;
• ** 将来のストレージ設計 (* Verkle ** ツリーなど) では、瞬間的なストレージに対する払い戻しを考慮する必要はありません。 **

4788 に続くと、質権プールに対する信頼の仮定を減らすことができます***

EIP 4788**：**X

• はじめに: EVM のビーコン ブロック ルート。 *更新: 23 年 6 月 15 日の開発者会議で、開発者はステーカー エクスペリエンスを向上させるためにコードを変更することを提案しました。この EIP は、DApp 開発用の EVM 内部チェーン状態情報を含むビーコン チェーン ブロックのルートを公開します。著者の信頼によりアクセスが最小限に抑えられます。
• 変更: 対応する実行ペイロード ヘッダー内の各ビーコン チェーン ブロックのハッシュ ルートをコミットし、それらのルートを実行状態のコントラクトに保存し、そのコントラクトを読み取るための新しいオペコードを追加します。
• 重要性: これは、コントラクト層 (CL) の状態を公開できるようにイーサリアム仮想マシン (EVM) を変更することを提案するコード変更提案です。実行層 (EL) のルート データにより、イーサリアム ネットワーク内のさまざまなプロトコルとアプリケーション間の通信がより効率的かつ安全になります**。 **ステーキングプール、ブリッジング、および再ステーキングプロトコルのためのよりトラストレスな設計を可能にします。

最後は5656*で、効率的な新しいメモリコピーオペコードを提供しますが、現在はテスト帯域幅のため一時的にアップグレードに含まれている状態です *

EIP 5656X

• 紹介：MCOPY

• メモリコピー命令。 更新: 09.06.23、開発チームは、MCOPY がセキュリティ問題を解決する一方で、アップグレードに必要な実装とテスト帯域幅に MCOPY を追加することに依然として懸念があるため、当初 MCOPY について意見が分かれていたと述べましたが、最終的には、 EIP ですが、開発者がテスト中またはクライアント側で容量の問題に遭遇した場合は削除が検討されます。そのため、MCOPY* は一時的にカンクンのアップグレードに含まれている状態です。 **

• 変更: メモリ領域をコピーするための効率的な EVM 命令が提供されました。
• 重要性: メモリのコピーは基本的な操作ですが、EVM での実装にはコストがかかります。
• MCOPY 命令の利用可能性により、コードワードとセンテンスをより正確にコピーできるようになり、メモリコピーのパフォーマンスが約 10.5% 向上します。これは、さまざまな計算集約型の操作に非常に役立ちます。
• コンパイラがより効率的で小さいバイトコードを生成するのにも役立ちます。
• アイデンティティのプリコンパイル済みガスコストをある程度節約できますが、実際にこの部分の実装を促進することはできません。

候補リスト****EIP

236月15** に開発者コンセンサス会議が *** で議論されました。 CL を中心とする EIP は Deneb** に含まれます。ここで、**** ** EIP 6988******、EIP 7044、******EIP 7045 *** *** が参加を提案されています。 ***

EIP 6988**：**X

• 概要: スラッシュされたバリデータがブロック提案者として選出されるのを防ぎます。
• 重要性: 違反ノードに対するペナルティの増加は DVT に利益をもたらします。

EIP 7044**：**X

• 概要: 署名されたバリデーター出口が永続的に有効であることを確認します。
• 意義: ステーカーのエクスペリエンスをある程度向上させることができます。

EIP 7045**：**X

• はじめに: 遺言書証明書 スロットの包含範囲は、1 エポックのローリング ウィンドウから 2 エポックまで拡張されます。
• 意義: ネットワークのセキュリティを強化します。

EIP* の分析を削除します

29日******************************** *********************************************** ** で160ACDE イーサリアム会議、EVMMAX および **** EOF **** はこのアップグレードから削除されることが確認されています。EOF に関連する変更は、その後の毎日のアップグレードで導入される可能性があります

EVMMAX EIP**：**

• 概要: EVMMAX は、イーサリアム上の算術演算と署名スキームに大きな柔軟性をもたらすことを目的としています。現在、EVMMAX 提案は 2 つあり、1 つは EOF あり、もう 1 つは EOF なしです。
• EIP 6601: EVM モジュラー算術拡張機能 (EVMMAX)
• 変更: EIP です 5843 回の反復、EIP あり 5843 の違いは次のとおりです。
• 6601 では、係数、事前計算されたモンゴメリ パラメータ、使用される値の数を格納する新しい EOF セクション タイプが導入されています (実行時に構成可能な係数は引き続きサポートされています)。
• 6601 は、EVM<->EVMMAX メモリ間で値を移動するための新しいロード/ストア オペコードを使用して、EVMMAX 値用に別のメモリ空間を使用します。
• 6601 は、最大 4096 ビット (EIP に記載されている暫定的な制限) のモジュライでの演算をサポートします。
• 重要性: EIP-5843 は、イーサリアム仮想マシンに効率的なモジュール式の加算、減算、乗算を導入します。EIP-6601 は、モジュール式算術演算用のセットアップ セクション、別個のメモリ空間、および新しいオペコードの導入により、これに基づいてさらにアップグレードされ、操作がより適切に構成されます。より大きな弾性率をサポートし、EVM パフォーマンスを向上させながら、柔軟性を高めます。
• EVM 契約として、さまざまな曲線 (BLS12-381 を含む) での楕円曲線算術演算が可能になります。
• MULMOD は、既存のオペコード ADDMOD と比較して、最大 256 ビットの値に対する演算のガス コストを 90 ～ 95% 削減します。
• modexp プリコンパイルを EVM コントラクトとして実装できるようにします。
• 代数ハッシュ関数 (MiMC/Poseidon など) および EVM における ZKP 検証のコストを大幅に削減します。 *EIP 6690：
• 変更: EIP-6990 は、EOF に依存せずに最適化されたモジュラー算術演算を EVM に導入するために EIP-6601 を改造した提案です。 EIP-6601 は依存関係として EIP-4750 と EIP-3670 を必要としますが、EIP-6990 はより独立したソリューションを提供します。 EOF への依存関係を削除することで、より単純化されたアプローチを提供します。
• 重要性: 最大 4096 ビットの奇数モジュラスで最適化されたモジュラー算術演算を実行できる EIP-6601 のコア機能を保持しています。この簡素化により、EIP-6601 の利点に関連する利点を提供しながら、より効率的な実装と導入が可能になります。

EOF 変更点**：**

• はじめに: EOF は EVM へのアップグレードであり、新しい契約標準といくつかの新しいオペコードが導入されています。従来の EVM バイトコード (バイトコード) は非構造化命令シーケンス (非構造化) 命令のシーケンス) バイトコード。 EOF では、構造化バイトコードを実装するコンテナの概念が導入されています。コンテナーは、ヘッダーと、バイトコードを構造化するためのいくつかのセクションで構成されます。アップグレード後、EVM はバージョン管理を実行し、複数のコントラクト ルール セットを同時に実行できるようになります。 *EIP 663：
• 概要: 無制限の SWAP および DUP 命令
• 重要性: SWAPN と DUPN という 2 つの新しい命令を導入することにより、スタックの深さが 16 要素から 256 要素に増加する点で SWAP と DUP とは異なります。
• EIP 3540：
• 導入：
• 以前は、チェーン上にデプロイされた EVM バイトコードには事前定義された構造がなく、コードはクライアントで実行される前にのみ検証されていました。これは間接的なコストであるだけでなく、開発者による新しいバイトコードの導入の妨げにもなっています。機能または廃止された古い機能。 ※このEIPはEVMの拡張・バージョン管理が可能なコンテナを導入し、EOFコントラクトの形式を宣言しており、これに基づいてEOFコントラクトのデプロイ時、つまり作成時にコードの検証が可能となります。 時間検証は、EOF フォーマットに準拠していないコントラクトのデプロイを防止できることを意味します。この変更により EOF バージョン管理が実装され、将来的に既存の EVM 命令を無効にしたり、大規模な機能 (アカウントの抽象化など) を導入したりするのに役立ちます。 。
• 意味：
• バージョン管理は、将来の新機能の導入または非推奨につながります (アカウント抽象化の導入など)。
• 契約コードとデータの分離は、L2 検証 (op) に有益であり、L2 バリデーターのガスコストを削減すると同時に、契約コードとデータの分離はオンチェーンデータ分析の作業にも便利ですツール。 *EIP 3670：
• はじめに: EIP-3540 に基づいて、EOF コントラクトのコードがフォーマットに準拠し有効であることを確認することを目的とし、レガシーに影響を与えることなくフォーマットに準拠しないコントラクトの展開を防止することを目的としています。 バイトコード。
• 重要性: 3540 によって導入されたコンテナに基づいて、EIP-3670 は EOF コントラクト内のコードが有効であることを確認するか、コードがデプロイされるのを防ぎます。これは、未定義のオペコードを EOF コントラクトにデプロイできないことを意味し、追加する必要がある EOF バージョンの数が減るという利点もあります。 *EIP 4200：
• 導入：
• 最初の EOF 固有のオペコードである RJUMP、RJUMPI、および RJUMPV を導入しました。 宛先は符号付き即値として指定されます。コンパイラは、これらの新しい JUMP オペコードを使用して、JUMP をデプロイおよび実行する際のガス コストを最適化できます。これは、既存の JUMP および JUMPI オペコードが Jumpdest を実行する必要がなくなるためです。 分析に必要な実行時間。この EIP は動的用です ジャンプの追加。
• 従来の JUMP 操作と比較すると、RJUMP などの操作は特定のオフセット位置を指定せず、(動的からの) 相対的なオフセット位置を指定する点が異なります。 ジャンプ -> 静的ジャンプ)、多くの場合静的であるため、 ジャンプだけで十分です。
• 意義: ネットワークを最適化し、コストを削減します。 *EIP 4750：
• 4200 の機能をさらに一歩進める: CALLF の導入 と RETF の 2 つの新しいオペコードは、RJUMP、RJUMPI、および RJUMPV で置き換えることができない状況に対する代替ソリューションを実装するため、EOF コントラクトでは JUMPDEST が不要になり、動的は禁止されます。 ジャンプ。
• 意義: コードをいくつかの部分に分割してコードを最適化します。
• EIP 5450：
• 背景: 背景としては、イーサリアムのコントラクトはデプロイ時にチェックされず、実行時にスタック オーバーフロー (上限は 1024) かどうか、ガスが十分かどうか、などの一連のチェックのみが実行されることです。等々。
• 内容: EOF コントラクトの有効性チェックを追加しました。今回はスタックです。この EIP は、EOF コントラクトのデプロイメントがスタックのアンダーフローまたはオーバーフローを引き起こす可能性がある状況を防ぎます (スタック アンダーフロー/オーバーフロー)。このようにして、クライアントは EOF 契約の実行中に行う有効性チェックの数を減らすことができます。
• 重要性: 大きな改善点は、実行中に発生するこれらのチェックをできるだけ少なくし、コントラクトのデプロイ時に発生するチェックを増やすことです。

5月26***************************** ************************************************* ************************************* 4844関連するトランザクション タイプがSSZ****** からRLP に変更カンクンの 2 つの a**** が不要になることを意味しますSSZ EIP****、つまりEIP 6475 と 6493** はアップグレードのためカンクンから移動***

EIP 6475X

• 概要: EIP 4844 へのコンパニオン提案。 Proto-danksharding では、他のトランザクション タイプで使用される RLP エンコードの代わりに SSZ エンコードを使用する新しいトランザクション タイプが導入されています。
• 更新: 第 161 回イーサリアム エグゼクティブ レイヤー コア開発者会議中に、EIP についての議論がありました。 4844 の SSZ シリアル化形式についての議論では、当初、開発者が BLOB トランザクションを介して EL に SSZ 形式の初期の反復を導入することを好み、最終的にはすべてのトランザクション タイプを RLP から SSZ にアップグレードすることを計画していましたが、その道筋が不明確で確実であることを考慮すると、開発者はカンクンのアップグレードには実装されていないため、開発者は EIP-4844 から SSZ を削除することを検討しています。多くの議論の結果、開発者は EIP-4844** の EL 実装から SSZ を削除することに同意しましたが、EIP6475**** は削除されません。 **SSZ-> RLP の変更は、カンクンの 2 つの SSZ が不要になることを意味します EIP: ** したがって EIP 6475 と 6493 はアップグレードのためにカンクンから移動されます。 **

EIP 6493X

• はじめに: SSZ トランザクション署名スキーム。この EIP は、シンプル シリアル化 (SSZ) でエンコードされたトランザクションの署名スキームを定義し、CL では SSZ 形式でフォーマットされているが、EL では別の方法でエンコードされている BLOB トランザクション タイプをノードが処理する方法に対処します。この EIP は、層間の一貫性を確保するための Ethereum シリアル化形式の更新の一部です。 ※背景：SSZ 変化
• はじめに: シンプル SerialiZe は、ビーコン チェーンで使用されるシリアル化メソッドです。 *SS この変更には、他の 3 つのサポート提案も含まれていますが、今回は 6465 のみが導入されました。 *EIP 6465: SSZ 撤回ルート、既存のマークル-パトリシアを定義 Trie (MPT) コミットメントの Simple Serialization (SSZ) 撤回への移行。 *EIP 6404 /EIP 6466：
• どちらも既存のマークル-パトリシアを定義します Trie (MPT) Promise は、Simple Serialization (SSZ) への移行の過程にあります。
• EIP-6404 — SSZ トランザクション ルート
• EIP-6466 — SSZ受入ベース

ティム Beiko** 氏は、5月26** のコア開発者会議で、カンクンの拡張に関する今後の展開を示唆しました。次の 5 つに制限されますEIP:EIP 5920、5656、7069、4788 および2537、この範囲内でフォローアップ提案が生成されます。フォローアップEIP 5656*** およびEIP 4788 は正式なアップグレード提案として確認されました、5920、7069、2537 どこから削除されましたEIP 5920 は、ETH*** の転送方法の潜在的な副作用、および未完成の推論、テスト、セキュリティ作業に対する開発者の懸念によるもので、アップグレードから取り除く。 ***

EIP 5920**：**X

• はじめに: 支払いオペコード。イーサリアム転送に新しいオペコード PAY を導入し、関数を呼び出すことなくイーサをアドレスに送信します。
• 理由: 現在、アドレスに ether を送信するには、ユーザーがそのアドレスで関数を呼び出す必要があり、これにはいくつかの問題があります。
• まず、受信者が送信者にコールバックできるため、再入攻撃のベクトルが開かれます。
• 2 番目に、DoS ベクトルを開くため、親関数は受信側のガスまたはコールバックが不足する可能性があることを認識する必要があります。
• 最後に、CALL オペコードは、メモリとスタックを拡張し、コードとメモリを含む受信側の全データをロードする必要があり、最後に呼び出しを実行する必要があるため、単純なイーサ転送には不必要にコストがかかります。これにより、意図しない操作が行われる可能性があります。
• 変化：
• 新しいオペコードが導入されました: ( PAY) PAY_OPCODE ここで:
• スタックから 2 つの値をポップします: addrthen val。 ※weiを実行アドレスvalからアドレスaddrへ転送します。 addr がゼロアドレスの場合、valwei は実行アドレスからプログラムされます。
• 潜在的な落とし穴: 既存のコントラクトは、呼び出しを行わずにアドレスにイーサを送信することがすでに可能であるため、ウォレットの実際の残高とは無関係に使用されます。
• 意味: **ガス****を節約します。 ** *更新: 09.06.23 PAY は、ETH の転送方法の潜在的な副作用と、提案を通過するために必要な推論、テスト、セキュリティ作業に関する懸念から、アップグレードから削除されました。

EIP 7069X

• はじめに: 修正された CALL 命令
• 変更: 3 つの新しい呼び出し命令、CALL2、DELEGATECALL2、STATICCALL2 が導入されました。これらはセマンティクスを簡素化する効果があります。新しい指令からガスのオブザーバビリティを削除し、再価格設定の影響を受けない新しいクラスの契約への扉を開くことを目指しています。
• 背景：
• 63/64 番目のルール: 呼び出しの深さを制限し、呼び出し先が戻った後に状態を変更するためのガスが呼び出し元に残っていることを確認します。
• ルール 63/64 が導入される前は、発信者の利用可能なガスをもう少し正確に計算する必要がありました。 Solidity には、適切なガス値を設定するために、呼び出し自体の実行にかかる呼び出し側のコストを推定しようとする複雑なルールがあります。
• 現在****63/64thを導入中 ルール:
• 呼び出し深度検査を削除。
• 呼び出された動作を実行する前に、必ず少なくとも 5000 ガスを予約してください。
• 呼び出された動作に利用可能なガスが少なくとも 2300 あることを確認してください。
• 補助金ルール: 有名な 2300 補助金など、契約が別の契約を呼び出すと、呼び出された契約には 2300 が付与されます。 ガスは非常に限定された操作を実行するために使用されます (ちょっとした計算を行ってログを生成するには十分ですが、ストレージ スロットを満たすには十分ではありません)。ガスの量は固定量に設定されているため、ユーザーがこれらを判断する方法はありません。ガス価格が調整できる限り、ガスはどのような種類の計算をサポートできますか?
• 意義: ** 将来の ** EOF ** の導入に道が開かれ、大規模な契約の運用がより便利になります。 **
• ガスのオプションを削除: 新しい指令ではガスを指定できません 制限はありますが、ガスを制限するには「63/64 ルール」 (主に EIP-150 の多数の IO 操作に対するガスの再価格設定を指し、特定の操作のガス消費量が増加します) に依存します。この重要な改善により、簡素化されます。 「Allowance」ルールに関するプロセスでは、値が送信されるかどうかに関係なく、呼び出し側はガスに関連する計算を実行する必要はありません。
• 新しい提案の導入後、ユーザーはトランザクションでより多くのガスを送信することでいつでもアウトを克服できます (もちろん、ブロック ガス制限の影響を受けます) ガスエラーです。
• 以前は、ストレージ コストを引き上げたとき (例: EIP-1884 で特定のオペコードのガスが増加)、呼び出しに限られた量のガスのみを送信する一部の契約は、新しいコスト計算メカニズムによって破られました。以前は、一部の契約には、使用できるガスの量を永続的に制限するガスの上限があり、サブコールにガスを送信したとしても、通話によって制限されるため、どれだけ追加のガスを送信しても、うまくいきませんでした。送金額。
• EOF 導入への道を開く: EVM オブジェクト フォーマット (EOF) が導入されると、古い呼び出し命令は EOF 契約で拒否され、ガス価格の変更の影響をほとんど受けなくなることが保証されます。これらの操作はガスの可観測性を除去するために必要であるため、EOF では既存の命令の代わりにこれらの操作が必要になります。
• より便利なステータス リターン コード: より詳細なステータス コード (成功 (0)、復元 (1)、失敗 (2)) を返す便利な関数が導入されており、将来的には拡張される可能性があります。

EIP 2537**：**X

• はじめに: BLS12-381 曲線操作のプリコンパイル。
• 変更: BLS 署名検証を効率的に実行し、SNARKs 検証などの操作を実行するために必要なセットにプリコンパイルされた BLS12-381 曲線の操作を追加しました。
• 重要性: イーサリアムは、より安全な暗号証明を作成でき、ビーコン チェーンとの相互運用性が向上します**。 **

PR 3175 *** 言及されているが最終候補には含まれていないため、これ以上の議論は不要 ***

PR 3175**：**X

• 概要: この提案により、ペナルティを受けたバリデーターがデキュー時にブロックを提案できなくなります。バリデーターの 50% 以上が悪意のある動作でペナルティを受けた場合でも、それらのバリデーターはネットワークから強制的に削除されている間もブロックを提案できます。このロジックの変更は、「高故障モード」に対する保護を提供する比較的小規模な CL 層の変更であると開発者らは述べています。 ※5月4日開催の第108回イーサリアムコア開発者コンセンサスミーティングによる PR 3175 は EIP としてフォーマットされる過程にあり、EIP-6987 に変更されます。これは、スラッシュ付きバリデーターがブロック プロポーザーとして選出されるのを防ぐセキュリティ上の理由からです。

未来

上記の情報に基づいて、次の結論に達しました。

**1.*カンクンのアップグレードの主な目標は、優先順位の順に、容量拡張、セキュリティ、ガスの節約、および相互運用性です。

• 拡張が最優先であることに疑いの余地はありません (4844)。
• 安全性とガスの節約は 2 番目に優先されます (6780、1153、5656、7045)。ただし、特定の開発者の経験を考慮しています。
• 3 番目は相互運用性です。dapp 間の接続、通信、相互運用性の最適化などです (4788、7044、6988)。
• 予想されるデータ: テストネット 4844 はオプサイドを削減できる ロールアップのコストの 50%、EigenLayer と Celestia の技術ソリューションはあまり公開されておらず、データを評価できない、Ethstorage は DA のコストが元の 5% に下がると見積もっている、Topia はコストの削減を期待している100〜1000倍。

2.** カンクンのアップグレード Danksharding** の今後 2~5 年は、DA* 層プロジェクト**** の黄金発展期です。

• レイヤー セキュリティの上限である 2 は、採用する DA 層によって異なります。プロトダンクシャーディングは、より安価な状態データ ストレージを通じて、ストレージ プロトコル、モジュラー プロトコル、L1 ストレージ拡張ネットワークに利益をもたらします。
• **最初に、*Danksharding ** イーサリアム ステート マシンの本質に戻ります。 V 神は、イーサリアムコンセンサスプロトコルの目的は、すべての履歴データの永久保存を保証することではない、と述べました。代わりに、安全性の高いリアルタイム掲示板を提供し、長期保存用に他の分散プロトコルの余地を残すことが目的です。 （ イーサリアムコンセンサスプロトコルの目的は保証することではありません すべての履歴データを永久に保存します。むしろ、目的は、 安全性の高いリアルタイム掲示板を提供し、 長期保存を行うための他の分散プロトコル。 ）；
• 第二に、ダンクシャーディング はDA **のコストを削減しますが、実際の着陸時間とデータの可用性の問題も解決する必要があります。 **
• DA** コスト削減: **この更新前は、ロールアップからイーサリアム メイン チェーンにデータを公開するには calldata を呼び出す必要があり、このコードを呼び出すためのガス料金が非常に高価でした。 2 つの中で最大の配当である EIP 4844 では、ロールアップ固有の追加データ スペースとしてデータ BLOB が導入されており、これによりストレージ コストが大幅に削減され、DA コストが削減されます。
• 実際の着陸時間は長く、 TPS ** の向上と ** ガス ** の削減にはまだ限界があるため、 DA * には適しています。 * その後の継続的な開発におけるレイヤー プロジェクト:**
• Polynya でのダンクシャーディングについては可能です セキュリティ データ シャーディングの記事では、実装には 2 ～ 5 年かかることが示されています。
• ** たとえ着陸したとしても、* TPS ** は増加し、* ガス ** は減少する可能性があります。** 規模は依然として制限されています:**
• EIP 4844 は現在 6 つのブロブをサポートしており、将来の拡張問題は Danksharding によってのみ解決できます。 ※現在のイーサリアムのブロック容量は約200 KB。 Danksharding 以降、仕様で計画されているサイズは 32 メガバイトで、これは約 100 倍になります。現在、イーサリアムのTPSは15程度ですが、理想的な状態では100倍にすると1500程度となり、大きな改善ではありません。
• したがって、着陸までに長い時間がかかります + 実際の変更は限られたものにのみ効果があります DA レイヤー プロジェクト (Celestia など) ** Aigenda** ** ** DA ** プロジェクトは、将来的に ** Danksharding ** と競合するために、より安価なコストとより高速な ** TPS ** を渡すことができます 、 ETHストレージ Topia* やその他の新しい DA プロジェクトも、上陸前に市場のギャップを埋めることができます。 **
• データ ストレージやデータの可用性の問題などの技術的な問題にも対処する必要があります。
• DAの主なコストは2つあり、1つはネットワーク帯域幅のコスト、もう1つはストレージのコストであり、4844自体はストレージ問題とブロックチェーンの帯域幅問題を解決するものではありません
• BLOB はイーサリアム コンセンサス レイヤーに約 3 週間保存され、その後削除されます完全な履歴記録を保存し、すべてのデータを利用できるようにしたい場合、現在のソリューションには次のものが含まれます: dapp 自体がそれ自体に関連するデータを保存する、イーサリアム ポータル ネットワーク(現在開発中) またはブロック エクスプローラー、BitTorrent の履歴データ、個々のユーザーによる自発的ストレージなどのサードパーティ プロトコル。
• したがって、Proto-Danksharding は、ストレージ プロトコル、モジュラー プロトコル、および L1 ストレージ拡張ネットワークに利益をもたらします。
• 履歴データの呼び出しに対する需要は、分散型ストレージ プロトコルまたはサードパーティのインデックス プロトコルの新しい開発チャネルにつながります。
• 後続のモジュラー契約は高速ロールアップを通じてトランザクションを実行でき、安全な決済レイヤーが決済を担当し、低コストおよび大容量のデータ可用性レイヤーが保証を担当します。
• Eth などの優れた L1 ストレージ拡張ネットワーク ストレージは、より低いストレージ コストでプログラマブル ストレージの第 2 層ソリューションを提供できます。

3.カンクンのアップグレードのメリットL2****ダイバーシティ、L3、RAASおよび データの可用性とその他の追跡

• L2 トラック分析:
• ヘッド Layer2 (Arbitrum など) オービット、OP スタック、ポリゴン2.0、フラクタル Scaling (StarkWare の下) および HyperChain (zkSync の下) を含む 5 つのプロジェクトが恩恵を受けます。 BLOB によるストレージ料金の削減により、以前の一連の制限付きレイヤーが作成されます。 2 開発コストとスケーラビリティの問題が大幅に改善され、データ スループットが大幅に向上しました。コストの問題を解決した後、ヘッド層は 2 特定の機能に対して、高度にカスタマイズされたマルチチェーン同時 L3 エコロジーを引き続き展開する機会が存在します。
• 第 2 層の Layer2 と主流の Layer2 の間の運用コストの差は縮まり、Aztec、Metis、Baba、ZKspace、layer2.finance などの一部の小規模プロジェクトに開発の機会が与えられます。
• モジュラーブロックチェーンプロジェクトの実際のニーズはまだ検証されていませんが、Starkware の Cario、Move シリーズ言語、Wasm でサポートされている C、C++、C#、Go シリーズ言語など、多様なプログラミング言語を使用することが可能です。さらに多くの Web2 開発者を紹介します。
• Raas トラック分析:
• Raas 自体の利点は、高度なカスタマイズ、カスタマイズされた要件 > 純粋なコストと効率にあり、コスト削減はカスタマイズされた Rollup の大きな利点です。
• しかし、RAAS トラックの問題は、それが OverHype である可能性があり、RAAS トラック自体についてさえ疑問があることです。 ** 5 ** ヘッド** layer2 ** の競争に直面し、さまざまな新しい ** DA ** の出現により、新しいプロジェクトは、トラック上の疑問符。 ** ※まずはヘッダー層 2 アプリケーション チェーンの展開の利点は、ネットワーク フレームワークの完全性とチェーン間のエコロジーのセキュリティにあり、RAAS の利点はそのカスタマイズと自由にあります。 ※ただし、OPシリーズやZKシリーズのRAASの技術的障壁は現時点では強くなく、まだ短期的なテストネットの段階にあり、実際の製品連携はありません。将来のレイヤー 3 の生態学的利点は、RAAS の実際の需要には疑問があります。 ※OP部：OPですが スタックの基盤アップグレード+ 4844 の発売により、コストと効率がわずかに向上しましたが、その増加はあまり魅力的ではありません。
• ZK シリーズ: 現在、多くの主要プロジェクトは ZKEVM ルートをたどり、イーサリアムとの互換性により注意を払っているため、回路設計は一定の効率を犠牲にしており、OP シリーズほどターゲットを絞っていません。しかし現在市販されているZKは ほとんどの RAAS は依然として主要なプロジェクト (ZkSync など) を使用してチェーンをフォークしており、その障壁はまだ強力ではありません。
• SO、短期 OP RAAS** *** layer3 ** が登場するまでにはまだ開発の余地があります。長期的には ** ZK RAAS ** と ** layer3 ** が将来のトレンドになる可能性があります。 ** *ZK RAAS は 4844 以降、コスト面でのデメリットが大きくなり、OP よりもはるかに多くの計算能力を消費します。L1 へのアップロードのコストは OP よりも低いですが、これは証明プロセスのコストと比較するとほんのわずかです。 while OP 利点は、短期間で迅速にエコロジーを構築できることであり、レイヤー 3 が登場するまでにはまだ開発の余地があることです。 ※従来のdefiアプリケーションやNFT市場においては、ロールアップの変革は厳格な要件ではなく、高い効率性を必要とする決済アプリケーションやゲームのみロールアップの需要が高くなります。将来的には、defi プロジェクトは l2 に、ソーシャル プロジェクトは l3 またはオフチェーンに配置される可能性があり、最終的にコア データと関係は l2 に配置される可能性があります。ゲーム プロジェクトは l3 またはロールアップに移動する必要がありますが、現在のほとんどのプロジェクトは l3 に移動する必要があります。チェーン ゲームは本質的にファンドであり、トークンが外部に流通できないことが開発のボトルネックとなっていますが、チェーン全体でのゲームの出現と相まって、l3 自体の生態学的魅力はロールアップのそれよりもはるかに大きいです。

**4.**カンクンのアップグレードにより、開発者とユーザーのエクスペリエンスが向上

• カンクン、2 番目の重要な提案 SELFDESTRUCT をアップグレード 削除によりイーサリアムのセキュリティがさらに向上すると同時に、削除後にプログラムによるアカウント更新の問題が発生する可能性があるため、この状況を改善するために新しいオペレーション コード SETCODE が用意されています。
• カンクンアップグレードのための第 3 提案 EIP 1153 は、一時的なストレージ操作コードを追加します。これにより、まずガスが節約され、次にフレーム間通信の問題が解決され、最後に、返金問題を考慮する必要のない Verkle ツリーなどの将来のストレージ設計への道が開かれます。一時的なストレージ。
• カンクンアップグレードのための第 4 提案 EIP 5656 では、コードワードとセンテンスをより正確にコピーできる MCOPY メモリ コピー命令が導入されており、メモリ コピーのパフォーマンスが約 10% 向上します。 ※カンクンアップグレードの5番目の提案はEIP 4788 は、イーサリアム ネットワーク内のさまざまなプロトコルとアプリケーション間の通信をより効率的かつ安全にすることができ、また、プレッジ プール、ブリッジング、および再ステーキング プロトコルのよりトラストレスな設計も可能にします。
• カンクンは、最新 (23 年 6 月 15 日) に提案された CL 中心の EIP アップグレードをアップグレードします: EIP 6988、EIP 7044、EIP 7045は、プレジャーのエクスペリエンスの向上やネットワークセキュリティの向上など、イーサリアムのセキュリティと使いやすさを詳細に向上させます。 ※削除された提案のうち、SSZ-> RLP の変換により 2 つの SSZ が作成されます。 EIP（EIP） 6475 と EIP

6493. はカンクン アップグレードから削除されました。EOF 関連のプロポーザルは上海アップグレードから削除された後、カンクン アップグレードから削除されました。現在、後のデイリー アップグレードで直接実装される可能性があると考えられています。EVMMAX は一部の EIP によるものです。 EOF 実装サブセットに関連しているため、ETH の転送方法に存在する可能性のある潜在的な副作用と、提案を通過させるために必要な推論、テスト、セキュリティ作業を考慮して、EOF とともにアップグレードするためにカンクンから移動されました。 、EIP 5920 がアップグレードから削除されました。

**5. *zkml とアカウントの抽象化との関係

zkml* にはほとんど影響なし

• ZKML はゼロ知識証明 (ゼロ知識証明) 知識）と機械学習（機械 学習); **ブロックチェーンと ML モデルの組み合わせにより、機械学習のプライバシー保護と検証可能性の問題が解決されます:
• プライバシー保護: 入力データの機密性 (トレーニング用のマシンに供給するデータとして大量の個人情報を使用する場合など)、個人情報の機密性が主要な要件である、またはモデル パラメーターがプロジェクトの中核的な競争力である、および暗号化は競争障壁を維持するためにも必要です。このような信頼性の問題が存在すると、ML モデルは大規模なデータやアプリケーションを取得できなくなります。 ※検証可能性：ゼロ知識証明技術は応用範囲が広く、ZKPを利用することで検証なしで情報の正しさを知ることができます。また、機械学習モデルは多くの計算を必要とするため、ML モデルは ZK-SNARK を通じて証明を生成し、証明サイズを削減し、ML の計算能力需要を軽減します。
• ZKML ** のストレージ要件は ** DA ** とはほとんど関係ありません: **Space のようなものが必要です この独立したストレージ構造の中核技術は、「SQL プルーフ」新しいセキュリティ プロトコルです。簡単に言うと、これはブロックチェーンに隣接するデータ ウェアハウスであり、開発者がシンプルな SQL 形式でオンチェーンとオフチェーンを接続できるようにします。結果をスマート コントラクトに直接ロードします。
• ZK-SNARKs ** は ** ZKML ** の ** ZK ** のメイン形式であり、** **ML のオンチェーン計算に適応できます。 ** ** 暗号の発展に伴い、特に再帰的な **SNARK 証明は有益です ZKML チェーン上の着陸: ※ZK-SNARKsはコンパクト性が高いのが特徴で、ZK-SNARKsを利用することで証明者は短い証明を生成することができ、検証者は対話する必要がなく、少量の計算を行うだけでその妥当性を検証できます。検証者と検証者間の対話の性質により、ZK-SNARK は実際のアプリケーションで効率的かつ実用的なものとなり、チェーン上の ML の計算能力要件により適しています。
• 現時点ではチェーン上でトレーニングすることは不可能であり、チェーン上に保存できるのはオフチェーン計算の結果のみです。
• 現在の ML の問題は、計算能力要件が満たされていないことと、アルゴリズムの制限 (並列計算できない) によって引き起こされるパフォーマンスの低下によるものです。大規模モデル ZK 証明にはより高い計算能力が必要ですが、チェーン上でサポートすることはできません。現在人気のあるモデルZK-SNARK は、小規模かつ少量の計算による ML ゼロ知識証明のみをサポートします。つまり、計算能力の制限は、ZKML ブロックチェーン アプリケーションの開発に影響を与える重要な要素であり、チェーンはオフの結果のみを保存できます。連鎖計算。

優れたアカウントの抽象化

• まず第一に、カンクンのアップグレードはある程度の削減が可能です ZK ロールアップ 料金証明:
• 現在の zkSync トランザクション手数料は 3 つの側面によって異なります。
• SNARK 証明を生成して検証するために検証者が消費する固定リソースのコストは比較的高くなります。
• 検証者がSNARK証明をイーサリアムメインネットに送信するときのガス料金。料金のこの部分は、メインネットの混雑によりそれに応じて増加します。
• 取引確認、メッセージブロードキャストなどを含む、ユーザーが検証者に支払うサービス料金。 ※そのため、4844を導入すれば、幹線ネットワークの混雑によるガス料金の増加の問題が緩和され、ZKP証明のコストもある程度削減でき、証明生成コストに比べれば大したことではありませんが、 ZK がまだ初期段階にあることを考慮すると、ZK シリーズの今後の開発動向を過小評価すべきではありません。
• 第 2 に、アカウントの抽象化により、従来の ** tx ** トランザクションが ** useroperation に変換され、その後 ** useroperations ** ECDSA * が使用されます。 * * ブロックにパックされると、チェーン上のストレージが以前より多く占有されるため、ストレージ要件が高くなります。
• **次に、アカウントの抽象化と ** ZK ロールアップ 相互に補完することができます:
• アカウント抽象化の現在の問題はGasです 手順が多すぎてスマートコントラクトが関与するため、料金が高く、データ量が多く、ガスが発生する 手数料が高くてZK ロールアップの利点は、データを削減できることです。 ※アカウントの抽象化によりセキュリティの確保が困難：AAには複数のコントラクトが含まれるためセキュリティが問題となるが、将来L2が段階的に形成された後もコンセンサス層は変更されず、スマートコントラクトの用途が広がり、セキュリティが確保されるZK の助けを借りて、アカウントの抽象化も保証できます ロールアップの信頼できる検証により、セキュリティがさらに向上します。
• 最後に、 AI ** テクノロジーの台頭を考慮すると、オンチェーン コントラクトのセキュリティを強化し、オンチェーン トランザクションやアクティビティ ステップを最適化するのに役立ちます。*
• AI とセキュリティ: AI テクノロジーを使用して、オンチェーン トランザクションのセキュリティとプライバシー保護を強化できます。たとえば、Web3 セキュリティ プラットフォーム SeQure は、AI を使用して悪意のある攻撃、詐欺、データ漏洩を検出および防止し、リアルタイムの監視および警報メカニズムを提供して、チェーン上のトランザクションのセキュリティと安定性を確保します。
• AI とチェーン上のアクティビティの最適化: ブロックチェーン上のアクティビティには、トランザクション、契約の実行、データの保存が含まれます。 AI のインテリジェントな分析および予測機能を通じて、オンチェーンのアクティビティをより適切に最適化し、全体的な効率とパフォーマンスを向上させることができます。 AI は、トランザクション パターンを特定し、異常なアクティビティを検出し、データ分析とモデル トレーニングを通じてブロックチェーン ネットワークのリソース割り当てを最適化するためのリアルタイムの推奨事項を提供します。
• *したがって、カンクンのアップグレードは、保管スペースの拡張から ZKとの統合までとなります。 ロールアップ ** の補完性と ** AI ** テクノロジーとの組み合わせは、アカウント抽象化の将来の開発に徐々に利益をもたらします。 **

**6.**イーサリアムのロードマップを振り返って、次は何になるか

• 現在、Layer2 ** には ** Solana ** のようなパフォーマンス (レイテンシとスループットの点で) がなく、 ** に近い* ** のようなパフォーマンスもありません。シャーディング パフォーマンス、* Sui ** や ** Aptos ** のような並列実行パフォーマンスはありませんが、カンクンのアップグレードにより、リーダーとしてのイーサリアムの主導的地位が向上しました。
• カンクンのアップグレード後、いくつかの主要な開発期間が見積もられています 完全ダンクシャルディング** (2~5 年)、MEV * および PBS** ランディング (1~3 年)、アカウント抽象化 (1~2 年)、***ZK * * *すべて (3~6 年)、EOF、開発者の経験 (拡張機能を何回見たことがありますか?)。 **

** スカージ**

• 目標: MEV の問題の解決に重点を置きます。
• 解決策: 「プロポーザーとビルダーの分離 (PBS)」を通じてアプリケーション層での MEV を最小化します。この時点で、BLOB が最適化され、事前確認サービスまたはプリエンプション保護が導入される可能性があります。 ※PBSとは、ブロックプロデューサーとソーターを分離したものです。ソーターはチェーンに関係なくソートのみを担当し、ブロック作成者はトランザクションを気にせず、ソーターが作成したパッケージを直接選択してチェーンに置きます。このプロセスにより、プロセス全体がより公平になり、MEV の問題が軽減されます。これが MEV 外部化のアイデアです。 ※PBSの完成度はまだまだ低く、より成熟したものほど 外部 MEV ソリューションとのコラボレーション - flashbot による mevboost。 ※『鎮座』の上級版 Proposer-Builder Separation（ePBS）」は完成度が低くサイクルが長く、短期的には実装されないと推定されている。また、PEPCやOptimisticには進歩版もある PBS フレームワークの柔軟性と適応性を強化する中継機能

** ヴァージ**

• 目標: Verkel ツリーを使用して Merkle を置き換え、信頼最小化ソリューションを導入し、ライト ノードがフル ノードと同じセキュリティを取得できるようにし、ブロック検証を可能な限りシンプルかつ軽量にします。
• 同時に、L1 の ZK 化が Verge のロードマップに明確に追加され、ZK は将来の拡張と高速化の一般的な傾向になります。
• 解決策: SNARK ベースのライト クライアントを含む古いプルーフ システムを置き換えるために zk-SNARK を導入します。コンセンサス状態変更のための SNARK。 ロールアップ。
• Verkle ツリーは、州固有の Merkle ツリーのより効率的な代替品であり、各姉妹ノード (同じ親を共有するノード) から選択したノードへのパスを提供する必要がなく、証明としてパス自体を提供するだけで済みます。 Verkle の一部証明はマークル証明よりも 3 倍効率的です。 ※祀られています ロールアップとは、L1 上で何らかのコンセンサス統合が行われたロールアップを指します。利点は、L1 のコンセンサスを継承し、ロールアップ アップグレードを実行するためにガバナンス トークンを必要としないことです。同時に、チェーンの外側で計算を実行し、公開のみを行うことによって、その結果をブロックチェーンに変換すると、トランザクション数を増やすことができますが、実装の技術的な難易度は比較的高くなります。将来的にこれらのロールアップを組み合わせることで、今後数十年間のブロックチェーン エコシステムのニーズのほとんどを満たすことができるようになります。

** パージ**

パージとは、ネットワークの検証に参加するためのストレージ要件を削減することでプロトコルを簡素化するという目標を指します。これは主に、冬眠と履歴と状態の管理によって実現されます。履歴データの休眠 (EIP-4444) により、クライアントは 1 年以上古い履歴データを削除し、P2P レベルでの提供を停止できます。 ※休眠状態です。状態の増大の処理に関しては、主に 2 つの目標があります: 弱いステートレス性 (状態を使用してブロックを構築するだけで検証はしないという目標を指します)、およびアクセスされる状態。状態の休止状態により、ノードが保存する必要がある状態が合計 20 ～ 50 減少します。 GB。 ※第5段階ではパージ、EIP 4444 はロードマップに明示的に書き込まれており、EIP-4444 ではクライアントに 1 年以上古いデータを消去するよう要求しています。この段階では、GAS や EVM のプリコンパイルのメカニズムの簡素化など、EVM の最適化作業がまだ残っています。

** 散財**

※最終第6ステージSplurge、EIPでは ウォレットエコロジーの長期的なレイアウト提案として、アカウントの抽象化により、ガソリンやソーシャルリカバリウォレットなどの支払いにステーブルコインを使用するなど、将来的にウォレットの使いやすさがさらに向上します。

参考資料：

• イーサリアムコア開発会議の最新情報:
• イーサリアム すべてのコア開発者は #148 に電話してください 書き上げる
• イーサリアム すべてのコア開発者が #149 の書き込みを呼び出す
• イーサリアム コンセンサス層コール #99 書き上げる
• イーサリアム すべてのコア開発者は#150に電話してください 書き上げる
• イーサリアム すべてのコア開発者は #151 に電話してください 書き上げる
• イーサリアム コンセンサス層コール #100 書き上げる
• イーサリアム すべてのコア開発者はコール #152 に連絡してください 書き上げる
• イーサリアム すべてのコア開発者はコール #153 に連絡してください 書き上げる
• イーサリアム オリジナルのマジシャンズフォーラムのディスカッション:
• イーサリアム すべてのコア開発者はコール #156 に連絡してください 書き上げる
• イーサリアム すべてのコア開発者はコール #157 に連絡してください 書き上げる
• イーサリアム すべてのコア開発者はコール #158 に問い合わせてください 書き上げる
• イーサリアム すべてのコア開発者はコール #159 に問い合わせてください 書き上げる
• イーサリアム すべてのコア開発者はコール #160 を使用してください 書き上げる
• イーサリアム 全コア開発者のコンセンサスコール #108 書き上げる
• イーサリアム すべてのコア開発者はコール #161 に連絡してください 書き上げる
• イーサリアム 全コア開発者のコンセンサスコール #109 書き上げる
• イーサリアム すべてのコア開発者はコール #162 に連絡してください 書き上げる
• イーサリアム すべてのコア開発者のコンセンサス コール #110 書き上げる *ティムは最新のイーサリアム カンクン アップグレード (09.06.23) についてツイートしました。
• イーサリアムの全コア開発者コンセンサス コール #111 書き上げる
• イーサリアム 全コア開発者のコンセンサスコール #112 書き上げる
• イーサリアムアップグレード関連コンテンツ:
• 自己破壊コードの紹介:
• EVMMAX 提案と BLS12-381 を調べる
• EIP-4844 以外に、カンクンのアップグレードには何が含まれますか?イーサリアムの最新コンセンサスコールを覗いてみる
• イーサリアム上海のアップグレードではどのような新しいコンテンツが追加されましたか? *ツイート:
• わかりました ベンチャーズ: イーサリアム上海のアップグレード後、カンクンは潜在的な投資機会をアップグレード - フォーサイトニュース
• 注目を集める EIP-4844 に加えて、カンクンのアップグレードにはどのような提案が含まれますか?
• V 神: 削除を検討する価値のある EVM 関数
• プロトダンクシャルディング よくある質問
• V 神推奨丨イーサリアムのシャーディング ロードマップを深く理解するには、このレポートを読むだけで十分です ※イーサリアムの新たなアップグレード計画「ダンクシャーディング」を理解するための記事
• イーサリアムの最新ロードマップにある興味深い事実と隠された秘密を解読する
• Vitalik: SELFDESTRUCT がイーサリアムの生態系に良い影響を与えるどころか害を及ぼす理由
• イーサリアムのビジョン:
• ブロックワークス 研究員Brrr: プロトダンクシャーディングがイーサリアムのL1をどのように加速するか ロールアップのスケーラビリティ
• 第 111 回イーサリアム ACDC 会議: Deneb アップグレードの最終範囲と EIP-7044 を含む 3 つの提案について議論 *コル Stacy Muur がイーサリアム スケーリング ソリューションの進化を覗く: OP スタック、任意 オービット、ポリゴン 2.0
• 3 種類のロールアップの水平比較: クラシック ロールアップ (Optimistic/ZK) ロールアップ）、鎮座 ロールアップ、ソブリン ロールアップ
• [AMA] 私たちは EF Research です (Pt. 8: 7 月 7 日) 2022年）：
• 2023 年に再考する価値のある 3 つの人気トラック
• モンテネグロ EDCON 2023 年末についての考え: インフラストラクチャとアプリケーションのトレンドの概観
• AIとWeb3の組み合わせの可能性への無限のファンタジー
• AI+Web3: 人工知能とブロックチェーンの統合を模索
• zk-rollup と op-rollup の比較: 検証方法から現在の zkSync である理由を分析 ガス代が高い
• 「ボリュームへのボリュームの追加」: ロールアップ時代のアカウント抽象化ソリューション
• ZKML の詳細な解釈: 技術原則、アプリケーション シナリオ、利点と課題 ※ZKML：AIとブロックチェーンを統合してプライバシー保護を実現するモデル展開技術 *可能 セキュリティデータ シャーディング
• EthStorage 創設者 Qi 氏との対談 Zhou | データの可用性と分散ストレージ
• イーサリアム開発ロードマップの最新バージョンを 1 つの記事で読む ※宇宙について そして 時間についての簡単な紹介 ※当初案： *EIP 4844： *EIP 6780： *EIP 1153：
• EIP 5920： *EIP 5656： *EIP 7069：
• EIP 4788： *EIP 2537： *EVMMAX EIP：
• EIP 6601：
• EIP 6990： *EOF 変更点：
• EIP 663：
• EIP 3540： *EIP 3670： *EIP 4200：
• EIP 4750： *EIP 5450： *EIP 6475：
• EIP 6493：
• PR 3175：