レイヤ 2 のセキュリティの上限は、採用する DA 層によって異なります。プロトダンクシャーディングは、より安価な状態データ ストレージを通じて、ストレージ プロトコル、モジュラー プロトコル、L1 ストレージ拡張ネットワークに利益をもたらします。
まず、ダンクシャーディングはイーサリアムのステートマシンの本質に立ち返ります。 V 神は、イーサリアムコンセンサスプロトコルの目的は、すべての履歴データの永久保存を保証することではない、と述べました。代わりに、高度に安全なリアルタイム掲示板を提供し、他の分散プロトコルが長期保存できる余地を残すことが目的です (イーサリアムコンセンサスプロトコルの目的は、すべての履歴データの永久保存を保証することではありません。むしろ、その目的は安全性の高いリアルタイム掲示板を提供し、他の分散プロトコルが長期保存できる余地を残すことです。);
第二に、ダンクシャーディングは DA のコストを削減しますが、実際の着陸時間とデータの可用性の問題も解決する必要があります。
ZKRAAS は 4844 以降、コスト面でのデメリットが大きくなり、OP よりもはるかに多くの計算能力を消費します。L1 へのアップロードのコストは OP よりも低いですが、これは証明プロセスのコストと比較するとバケツの一滴に過ぎません。 while OP 利点は、短期間で迅速にエコロジーを構築できることであり、レイヤー 3 が登場するまでにはまだ開発の余地があることです。
ZKML のストレージ要件は DA とはほとんど関係がありません。Space and Time のような別個のストレージ構造が必要であり、そのコア技術は新しいセキュリティ プロトコル「SQL Proof」です。または、オンチェーンとオフチェーンのデータをシンプルな方法で接続します。 SQL 形式で結果をスマート コントラクトに直接ロードします。
AI とセキュリティ: AI テクノロジーを使用すると、オンチェーン トランザクションのセキュリティとプライバシー保護を強化できます。たとえば、Web3 セキュリティ プラットフォーム SeQure は、AI を使用して悪意のある攻撃、詐欺、データ漏洩を検出および防止し、リアルタイムの監視および警報メカニズムを提供して、チェーン上のトランザクションのセキュリティと安定性を確保します。
AI とオンチェーン アクティビティの最適化: ブロックチェーン上のアクティビティには、トランザクション、契約の実行、データ ストレージが含まれます。 AI のインテリジェントな分析および予測機能を通じて、オンチェーンのアクティビティをより適切に最適化し、全体的な効率とパフォーマンスを向上させることができます。 AI は、トランザクション パターンを特定し、異常なアクティビティを検出し、データ分析とモデル トレーニングを通じてブロックチェーン ネットワークのリソース割り当てを最適化するためのリアルタイムの推奨事項を提供します。
したがって、カンクンのアップグレードは、ストレージ容量の拡大から ZKrollup との補完性、そして AI テクノロジーとの組み合わせに至るまで、アカウント抽象化の将来の開発に徐々に利益をもたらします。
イーサリアム カンクン アップグレードが近づいており、カンクン アップグレードの過去、現在、未来を振り返る
著者: ファットバードファイナンス
過去生
なぜカンクンのアップグレードが必要なのでしょうか?
イーサリアムのビジョンは、分散化を前提として、よりスケーラブルでより安全になることです。イーサリアムの現在のアップグレードもこのトリレンマの解決に取り組んでいますが、大きな課題に直面しています。
イーサリアムの問題:
現時点では、TPS とパフォーマンスが低く、ガス料金が高く、深刻な混雑が発生していると同時に、イーサリアム クライアントの実行に必要なディスク容量も急速に増加しており、根底にはイーサリアムのセキュリティ確保と分散化の作業負荷が影響しています。環境全体におけるコンセンサスアルゴリズムの重要性もますます高まっています。
したがって、分散化を前提に、より多くのデータを送信し、ガスを削減してスケーラビリティを高めるにはどうするか、コンセンサスアルゴリズムを最適化してセキュリティを確保するにはどうすればよいか、これらはすべてイーサリアムが現在取り組んでいる取り組みです。
セキュリティ、分散化、スケーラビリティのトリレンマを解決するために、イーサリアムは PoW-to-PoS メカニズムを使用してノードのしきい値をさらに下げ、またビーコン チェーンを使用して検証者をランダムに割り当ててセキュリティを最適化することも計画しています。スケーラビリティの観点から、イーサリアムはノードのワークロードを軽減するためにシャーディングの使用を検討しています。これにより、イーサリアムは複数のブロックを同時に作成してスケーラビリティを高めることもできます。
現在、イーサリアムの各ブロックの容量は約200~300KB、各トランザクションの最小サイズは約100バイト、ブロック時間12秒で割った約2000トランザクションとなり、イーサリアムのTPSの上限は制限されています約100まで。このデータは明らかにイーサリアムのニーズを満たすことができません。
そこで、イーサリアムレイヤー2では、ブロックスペースに大量のデータをいかに投入し、不正証明や正当性証明によってセキュリティを確保するかに重点を置き、セキュリティの上限を決めるのがDA層であり、これが核心的な内容でもあります。カンクンのアップグレード。
イーサリアムエコロジーの反復ルートでは、ベンチマークである Solana のパフォーマンス (遅延とスループットの点で) を構築することはできず、Near の断片化パフォーマンスは短期的には見られず、Sui と Aptos の並列実行パフォーマンスも見られません。短期的には、イーサリアムはロールアップをコアとして多層構造を構築することしかできないため、TPS、ガスフィー、開発者エクスペリエンスを解決するためのカンクンのアップグレードはイーサリアムのロードマップにとって重要です。
イーサリアムのロードマップはどのように計画されていますか?
最近の重要なアップグレードとその目標
2020 年 12 月 1 日、ビーコン チェーンが正式にリリースされ、POS アップグレードへの道が開かれました。
2021年8月5日のロンドンアップグレード、EIP1559はイーサリアムの経済モデルを変更しました。
2022 年 9 月 15 日、パリのアップグレード (TheMerge) により POW から POS への切り替えが完了しました。
2023 年 4 月 12 日、上海は誓約撤回の問題を解決するために格上げされました。
経済モデルと POS 関連のアップグレードは完了し、次のいくつかのアップグレードでイーサリアムのパフォーマンス、TPS、開発者のエクスペリエンスの問題が解決されました。
次のステップは、イーサリアムのロードマップの TheSurge に焦点を当てます。
目標: ロールアップで 100,000 以上の TPS を達成すること。
ソリューションには主にオンチェーンとオフチェーンの 2 つがあります。
オフチェーン ソリューション: ロールアップなどを含むレイヤー 2 を指します。
オンチェーン スキーム: L1 で直接変更を行うことを指します。これは一般的なシャーディング スキームです。シャーディングを簡単に理解すると、すべてのノードを異なるエリアに分割し、各エリアのタスクを完了することで、効果的に速度が向上します。
断片化スキームの分析:
シャーディングスキームのジレンマ: シャーディングにはステートシャーディング、トランザクションシャーディングなどが含まれていましたが、異なるシャード間の同期が問題であり、現在、大規模なネットワークノードのデータ同期を完了することは技術的に困難です。 MEV の状況を解決できないだけでなく、発生する可能性のあるさまざまな問題を補うために多数のパッチが必要になる可能性があり、それは短期的には実現できません。
Danksharding は、イーサリアム向けに提案された新しいシャーディング設計です。その中心的なアイデアは、集中ブロック生成 + 分散検証 + 検閲耐性です。これは、後述するデータ可用性サンプリング (DAS) およびブロックプロデューサーにも関連しています。 - パッケージャー分離 (PBS) と検閲耐性リスト (Crlist) 関連。 Danksharding の中核となるアイデアの最大の意義は、イーサリアム L1 を統合決済およびデータ可用性 (DataAvailability) レイヤーに変えることです。
シャーディングスキームは 2 段階に分かれており、現在は Proto-danksharding と Fully-Rollup に分かれています。
プロトダンクシャーディング：
はじめに: L2 が料金を削減し、スループットを向上させるために BLOB を導入することにより、ダンクシャーディングの事前スキームとしてフル シャーディングへの道も開かれます。プロトダンクシャーディングの後、ダンクシェアリングの実装には 2 ～ 5 年かかると予想されます。
内容: プロト ダンクシャーディングの主な特徴は、新しいタイプの BLOB トランザクションを導入することです。BLOB には大容量かつ低コストという特徴があります。このようなデータ パケットをイーサリアムに追加すると、すべてのロールアップ データを BLOB に保存できるようになり、トランザクションの大幅な削減が可能になります。メインチェーンの保管にかかる圧力だけでなく、ロールアップのコストも削減します。
フルロールアップ
概要: ロールアップは、データの可用性の利用に焦点を当てて、容量を完全に拡張します。
コンテンツ：
DAS の P2P 設計: データ シャーディング ネットワーク接続問題に関連するいくつかの研究と研究。
データ可用性サンプリング クライアント: 数キロバイトをランダムにサンプリングすることで、データが利用可能かどうかを迅速に判断できる軽量クライアントを開発します。
効率的な DA 自己修復: 最悪のネットワーク条件 (悪意のあるバリデータ攻撃や大規模なブロック ノードの長いダウンタイムなど) の下でもすべてのデータを効率的に再構築できます。
イーサリアムコア開発者ミーティング
イーサリアムのすべてのアップグレードは、コア開発者会議によるコア貢献者の共同議論を通じて行われ、開発者からの一連の提案に従って、将来の開発方向が決定されます。
定義: コア開発者会議は、イーサリアム開発コミュニティによって毎週開催される電話会議であり、さまざまな組織のコア貢献者が技術的な問題について話し合い、イーサリアムに関する今後の作業を調整します。彼らは、イーサリアムプロトコルの将来の技術的方向性を決定するとともに、イーサリアムのアップグレードについて実際に決定を下す権威者でもあり、アップグレードにEIPが含まれるかどうか、ロードマップを変更する必要があるかどうか、その他重要な事項を決定する責任を負っています。重要です。
コアプロセス：EIPを中心としたアップグレードプロセスは、大まかに以下のとおりです まず、コア開発者会議（略してACD）でEIPが事前承認され、その後、アップグレードにEIPが含まれるかどうかに関係なく、クライアントチームがテストを行います最終テスト後に再度検討し、議論を踏まえて実際のバージョンアップに含めるかどうかを決定します。
会議にはコンセンサス層会議とエグゼクティブ層会議の2種類があり、隔週で交互に開催されます。
コンセンサス層カンファレンス (AllCore Developers Consensus - ACDC)。イーサリアムのコンセンサス層 (プルーフ オブ ステーク、ビーコン チェーンなど) に焦点を当てます。
エグゼクティブ レイヤー カンファレンス (AllCore Developers ソリューション - ACDE)。イーサリアムの実行レイヤー (EVM、ガス スケジュールなど) に焦点を当てます。
イーサリアム コア メンテナーには 3 つのタイプがあり、主に公式組織または提案について議論するボランティア フォーラムがあります。
AllCoreDevs: コード メンテナ。ETH1 ネットワーク クライアント、アップグレード、イーサリアム コードとコア アーキテクチャを担当します。
「プロジェクト管理」セクション: Ethereum 開発者をサポートし、ハード フォークを調整し、EIP を監視し、AllCoreDev の通信と運用を直接支援します。
EthereumMagicians: EIP やその他の技術的なトピックに関するディスカッションを希望するための「フォーラム」。
カンクンエスカレーション関連会議のタイムライン
協議の内容によれば、今回のカンクンのアップグレードは大きく5段階に分けられる。
第 1 段階 - アップグレード テーマの導入
新しいタスクのプロト ダンクシャーディング、EOF、および「自己破壊」オペコードを紹介し、上海のアップグレード コンテンツについて簡単に説明します
イーサリアムの合併が22年9月15日に完了した後、開発者会議は4週間中断され、開発者はその後のアップグレードで議論されるEIPを1か月間確認することができた。
22年10月28日の合併後初の開発者会議では、初めてプロトダンクシャーディング、EOF、「selfdestruct」オペコードの実装が提案されたが、現時点ではプロトダンクシャーディングの具体的な範囲は決まっておらず、一部の開発者は当初、上海のアップグレードは、最初に約束されたETHの出金を可能にし、次にEIP4844をアップグレードするなど、いくつかの小さなアップグレードに分割できると考えていますが、一部の開発者は、大規模なアップグレードを1ステップで実装する方がより有意義であると考えています。
フェーズ 2 - KZG 式典の時間枠と準備の決定
2022年末のイーサリアムカンファレンスは主にEOFとEIP4844に焦点を当てますが、同時にEIP4844が要求する信頼性の高いセットアップセレモニー、つまりKZGセレモニーの促進も継続していきます。開発者は4844がどのアップグレードで実装されるかを正式に決定します。 1月23日に登場
11 月 22 日、イーサリアムのすべてのコア開発者によるカンファレンスコール #149 で、EOF またはプロトダンクシャーディングについて言及されましたが、現時点では、開発者は上海アップグレードにこれを含めることをまだ検討しています。
12/02/22 のコンセンサス層会議で、イーサリアム エコシステムの責任者であるトレント ヴァン エップスは、EIP4844 の実装に必要な信頼できるセットアップ セレモニーの進捗状況について最新情報を発表しました。これは、安全なコードを生成することを目的としています。 EIP4844で使用されます。ヴァンエップス氏は、この式典が仮想通貨業界史上最大規模の式典の一つとなり、8,000から10,000の寄付を集めることを期待している。
同日のコア開発者会議では、EOFと自己破壊オペコードの無効化について議論があり、イーサリアム財団の特定の開発者は、コード変更が上海に含まれていない場合、EOFをカンクンに延期することに反対した。カンクンの可能性は非常に低いです. 自己破壊コードに関しては、当時一部の開発者は EIP4758 の進化を主張していましたが、このオペコードを直接無効にすると一部のアプリケーションが破損する可能性があります. 開発者は、このタイプの契約を保護するためのエッジケースを作成する前に、この EIP は一定期間再度計量する必要があります。
22年12月9日に開催されたコア開発者会議では、カンクンアップグレードに関するKZGセレモニーの実施が推進され、現在、EIP4844が要求する信頼性の高い設定セレモニーが準備されている。
EIP4844 をテーマとした 2022 年 12 月 16 日のコンセンサス レイヤー ミーティングで、開発者は 2 つの異なるプル リクエスト (PR) をプロト ダンクシャーディングの仕様にマージすることについて議論しました。そのうちの 1 つは、One からプルーニングされたデータをノードが処理する方法に関連しています。特定のブロックで BLOB に関する情報が欠落している場合、新しいエラー コードがアラート ノードに導入されます。
23年1月5日のコア開発者会議では、開発者らは上海アップグレードからEOF実装に関連するコード変更を削除することで合意に達したが、この際、Beiko氏はEOFをハードルに含めるかどうかを2週間後に判断するよう提案した。 Kun はアップグレードされています。
フェーズ 3 - 提案の範囲に関する予備的な議論
1月末、EOFは上海から撤去され、アップグレードのためカンクンに移転したが、その後2ヶ月間で主にEOFとEIP4844を除く他の提案に焦点が当てられ、同時にEOFのカンクンからの移転も提案された。 。この期間は主に、カンクンのアップグレードに関する提案範囲の詳細を説明するために費やされました。
2013 年 1 月 20 日と 23 日に開催されたコア開発者会議で、EOF はアップグレードのためにカンクンに移動されました。
23 年 3 月 6 日のコア開発者会議では、カンクン アップグレードの暫定提案は次のとおりでした。EIP4788 (パブリック ビーコン チェーン ステート ルート)、EIP2537 (BLS 署名検証や SNARKs 検証などの操作を効率的に実行)、EIP-5920 (新しい導入) opcode PAY)、EIP6189 (SELFDESTRUCT を Verkle ツリーと互換性を持たせるため) と EIP-6190 (限られた数の状態変更のみを引き起こすように SELFDESTRUCT 関数を変更する) の組み合わせ実装。
23 年 3 月 16 日と 23 日のコア開発者会議では、EOF と EIP4844 に加えて、SSZ 形式、SELFDESTRUCT の削除、EIP2537、EVMMAX、EIP1153、無制限の SWAP および DUP 命令、PAY Beacon の導入などの提案がカンクンに含めることが検討されました。コードとEVMのルートをステートメントします。
23年3月30日のコア開発者会議では、SELFDESTRUCT無効化に関する提案EIP-6780が初めて提案され、これはカンクンが最終的に使用を決定したSELFDESTRUCT無効化提案でもある。しかし、EOF の実装に関して、Erigon(EL) クライアント チームの開発者は、EOF は「変更が多すぎる」ため、次のカンクンのアップグレードでイーサリアムの改善提案 EIP4844 と組み合わせることができないと述べました。この提案はカンクンの実装でアップグレードされることが提案されていました。その直後にハードフォークで EOF が発生します。
第 4 段階 - プロポーザルのアップグレードの明確な方向性を決定し、無関係なプロポーザルを削除します。
4 月 23 日、カンクン アップグレードの対象となる提案について明確な方向性が示され、その鍵となったのは 4 月 13 日の開発者会議でした。この会議では 9 つの EIP が提案され、ティム自身もより深い理解を得ました。 4 月 27 日の会議で、EIP6780、EIP6475、および EIP1153 がカンクンに含まれることが決定されましたが、EOF および EVMMAX (EOF 実装に関連する EIP サブセット) はカンクンのアップグレードから削除されました。EOF アップグレードは主に役立ちますEVM バージョン管理と複数セットのコントラクトルールを同時に実行できるため、その後のイーサリアム拡張に有利ですが、アップグレード全体の実現可能性を考慮すると、以下のような日次アップグレードで EOF アップグレードを推進する可能性があります。上
23年4月12日、イーサリアム上海のアップグレードが完了しました。
開発者が EIP4844 (EL の CL 状態ルートに関するデータを公開するため) について議論した 13.04.23 のコア開発会議に加えて、少なくとも 9 つの他の EIP がアップグレードの対象として検討されています。それらは EIP4844、SELFDESTRUCT の削除 ( EIP-6780、EIP4758、EIP6046、EIP6190）、EIP5920、EIP1153、EIP2537、EIP4788、EVMMAXEIP（EIP6601およびEIP6690）、SSZchange（EIP6475、EIP6493、EIP 6465、EIP6404およびEIP6466） 、EIP5656およびEIP6193。
23 年 4 月 27 日のコア開発者会議では、いくつかの進歩とトレードオフに焦点が当てられました。まず、EIP4844 は引き続きカンクンのアップグレードに含めるように識別されていますが、次の EIP が追加されました: EIP6780 (SELFDESTRUCT オペコードの機能を変更)、EIP6475 (オプションの値を表す新しいシンプル シリアル化 (SSZ) タイプ)、EIP1153 (次に、検討されているがアップグレードに正式には含まれていない EIP は、EIP6913 (SETCODE 命令の導入)、EIP6493 (SSZ でエンコードされたトランザクションの署名スキームの定義)、EIP4788 (EL ブロック内のビーコン チェーン ルートの開示) です。ヘッダー）、EIP2537（プリコンパイルとして BLS12-381 曲線を追加）、および EIP5656（メモリ領域をコピーするための新しい EVM 命令を導入）、最後に、EOF と EVMMAX（EOF 実装に関連する EIP のサブセット）がカンクンのアップグレードから削除されました。 EOF アップグレードは、2023 年 1 月初旬のイーサリアム開発者カンファレンスで上海アップグレードから削除され、2023 年 1 月末から 2023 年 4 月初めまでカンクン アップグレードにデフォルトで表示されましたが、23 年 4 月 29 日の開発ではEOF は著者会議中に再び削除されます。
第 5 段階 - 最終提案の決定と細部の改善
5 月 23 日、最終提案の詳細は主に合理化および改善されました。SSZ->RLP の変更は、カンクンにある 2 つの SSZEIP が不要になることを意味するため、EIP6475 と 6493 はアップグレードのためにカンクンから移動されます。また、26日の党員集会で、ティム・ベイコ氏は、カンクンの範囲拡大に関する今後の協議は、EIP-5920、5656、7069、4788、2530の5つのEIPに限定することを示唆した。開発者は現在、カンクンのアップグレードの全範囲を決定しています。
23年5月5日のイーサリアムコアコンセンサスミーティングでは、前回言及したEIP4788について議論が行われ、それぞれバリデーターとSSZトランザクションに関するEIP6987とEIP6475についての議論が追加されました。
23年5月11日の第161回イーサリアムエグゼクティブレイヤー会議で、ティムベイコ氏は、カンクンのアップグレードの範囲は今後数週間以内にまだ変更できるが、開発者からの明確な提案がない場合、カンクンのアップグレードの範囲は変更されると述べた。 「デフォルト」ステータスを維持し、EIP-4844 に関する議論では、開発者が EIP-4844 の EL 実装から SSZ を削除することに同意していることが示されていますが、6475 の継続的な進歩には影響していません。これに加えて、開発者らはカンクンで検討する 2 つの EIP、すなわち EIP6969 (EIP1559 の修正バージョン) と EIP5656 (メモリ領域をコピーするための効率的な EVM 命令) についても簡単に議論しました。
4844 の開発は、EL 上のスマート コントラクト アプリケーションが CL 状態の証明を検証できるようにするなど、18.05.23 の開発者コンセンサス ミーティングで簡単に議論されました。
SELFDESTRUCT の非アクティブ化、EIP-4844 仕様の変更、オペコード管理、および最終的にカンクンに追加される可能性については、2023 年 5 月 25 日の第 162 回イーサリアムコア会議で議論されました。 Tim Beiko 氏は、カンクンの範囲拡大に関する今後の協議は、EIP-5920、5656、7069、4788、2530 の 5 つの EIP に限定することを提案しました。開発者は今後数週間以内にデンクン (デネブ+カンクン) の全範囲を決定する予定です。
2023 年 6 月 1 日に開催された第 110 回イーサリアム コンセンサス レイヤー ミーティングで、イーサリアム財団の研究者は、イーサリアム メインネット ノードが大量のデータを配布する能力に関するデータ実験の結果を紹介し、この結果から、研究者は EIP4844 が仕様はブロックあたり最大 4 つの BLOB から 6 つに増加しました。同時に、開発者はカンクンのアップグレードに EIP4788 を組み込むことを検討しています。
2023 年 6 月 13 日のコア開発者会議で、開発者は EIP4844、EIP1153、EIP5656、EIP6780、および EIP4788 を含むアップグレードの範囲を正式に確認しました。
2023 年 6 月 15 日のコンセンサス ミーティングでは、どの CL 中心の EIP を Deneb に含めるかが議論され、その中で EIP-6988、EIP-7044、EIP-7045 が追加されることが提案され、CL クライアント チームは次の点で合意しました。次のEIP-4844テストネットワークDevnet6でブロブ数の増加をテストし、2週間以内にこの件について最終決定を下す 同時に、イーサリアム財団の研究者マイケル・ノイダー氏は、32ETHのキャンセルを提案したアクティブなバリデータセットの増大を抑えるための誓約制限。
2023 年 6 月 22 日の会議で、ティムは、4844 のプリコンパイル済みアドレスを 0xA に移動し、それらをパックして、BLS を別のアドレスに移動することを提案しました。このプリコンパイル済みアドレスは EIP2537 を通じて導入されましたが、カンクンの計画では考慮されません。
2023 年 6 月 29 日のコンセンサス ミーティングで、開発者は BLOB の数について議論を続け、ターゲット BLOB 制限を 2 から 3 に引き上げ、最大 BLOB 制限を 4 から 6 に引き上げました。同時に、4844 テストネット Devnet #7も近日発売予定です。
この人生
コアコンテンツはEIP4844、Proto-Dankshardingです
カンクン アップグレードの最終的な EIP 範囲は、EIP4844、EIP1153、EIP5656、EIP6780、および EIP4788 です。同時に、6月19日の第111回イーサリアムACDC会議では、開発者らはEIP6988、EIP7044、およびEIP7045をDenebに含めるために議論を続けた。開発者らは、今後数週間以内に前述の 3 つの EIP を Deneb 仕様にマージする予定であると述べました。
主要な EIP の分析
EIP4844
導入：
EIP4844 プロポーザルの名前は Proto-Danksharding で、これは Danksharding のフルバージョンのプレシャーディング ソリューションです。シャーディング ソリューションのセット全体は、実際にはオンチェーン拡張のためのロールアップに基づいています。このソリューションの目的は、完全なシャーディングへの道を切り開きながら、L2 の料金削減とスループットの向上を支援することで、レイヤー 2 ロールアップを拡張することです。
2 月 23 日の電話会議で、イーサリアム開発者は EIP4844 をアップグレードし、はくちょう座の一等星の名前であるデネブと名付けました。つまり、関連する GitHub バージョン上の EIP4844 の名前は、今後; 3月1日の会議では、CL側ではデネブ、EL側ではカンクンと呼ばれるイーサリアムの次期アップグレード仕様に若干の変更があった。
23年6月23日の開発者会議で、開発者はEIP4844のプリコンパイル済みアドレスを更新する予定だった。現在、コア開発者は EVM に 9 つのプリコンパイルを追加しており、それぞれ EIP4844 と 4788 をアクティブにすることにより、「0xA」と「0xB」アドレスの下に 2 つのプリコンパイルを作成します。 6月29日のコンセンサス会議では、EIP4844専用の短期テストネットワークであるDevnet#7が準備された。
EIP-4844 では、まったく新しいトランザクション タイプである BlobTranscation が導入されています。
BLOB の概要:
BLOB はプラグイン データ パッケージと同様、当初は 128KB の保存容量しかありませんが、提案の議論の開始時点では、Blob のターゲットと制限は 2/4 でした。6 月 9 日の開発者会議では, 23、3/6に調整されました。つまり、現時点では、イーサリアムの各トランザクションは最大 3 つの Blob トランザクション (384 KB) を保持でき、各ブロックの targetBlob 容量は 6 (768 KB) で、最大 16 の Blob トランザクション (2MB) を保持できます。
ネットワークの安定性に一定の影響を与える可能性がありますが、イーサリアム開発チームは、BLOB ブロックを拡張するための後続のハードフォークの必要性を避けるために、最初にテストすることにしました。
BLOB は、Merkle と同様に、データ検証用のハッシュとして KZGcommit ハッシュを使用します。
ノードがチェーン上の BlobTransaction を同期した後、BLOB 部分は期限切れとなり、一定期間後に削除されます。保存期間は 3 週間です。
Blob の役割 - コストを削減しながらイーサリアムの TPS を向上させる
現在、イーサリアム全体の総データ量はわずか約 1 TB ですが、Blob は毎年 2.5 ～ 5 TB の追加データ量をイーサリアムにもたらすことができ、これは台帳自体の数倍を直接上回ります。
ノードの場合、ブロックごとに 1MB ～ 2MB の BLOB データをダウンロードしても帯域幅の負担は発生せず、ストレージ容量も毎月約 200 ～ 400GB の固定量の BLOB データが増加するだけであり、ノード全体の分散化には影響しません。 Ethereum ノードですが、Rollup 周りの拡張が大幅に改善されました。
また、ノード自体はすべての BLOB データを保存する必要はありません。BLOB は実際には一時的なデータ パッケージであるため、実際には、ノードは 3 週間に固定量のデータをダウンロードするだけで済みます。
EIP-4844 の役割 - ダンクシャーディングの物語の最初の章を開く
高拡張性: 現在、EIP-4844 は最初に L2 容量を拡張できますが、Danksharding のフルバージョンでは、EIP-4844 の BLOB データ ボリュームを 1MB から 2MB、16MB、32MB まで拡張できます。
低料金: バーンスタインのアナリストによると、プロトダンクシャーディングによりレイヤー 2 ネットワークの料金を現在のレベルの 10 ～ 100 倍に下げることができます。
実際のデータ:
Opside テスト ネットワークは 4844 を導入しており、現在の観察ではロールアップのコストを 50% 削減できます。
EigenLayer の DA 技術ソリューションは、そのデータを評価できるほど多くの情報を開示していません。
厳密に言えば、Celestia はイーサリアムとはほとんど関係がなく、具体的な技術ソリューションに応じて、その DA コストを現時点で評価することはできません。
Ethstorage の解決策は、レイヤー 2 ストレージ証明書をアップロードすることです。これにより、DA コストが元の 5% に削減される可能性があります。
トピアでは、メインネットワークのダンクシャーディングではセキュリティやレイヤー1 P2Pネットワークブロードキャストとの互換性も考慮する必要があるため、コストを100～1000分の1に削減できると見込んでいる。
DA ソリューション: Danksharding (イーサリアム拡張用のシャーディング ソリューション) は現在、過度のノード負荷 (16 MB 以上) や不十分なデータ可用性 (有効期間 30 日) などの問題を引き起こす可能性があります。解決：
DataAvailability Sampling - ノードの負担を軽減します
Blob 内のデータをデータ フラグメントに分割し、ノードが Blob データのダウンロードから Blob データ フラグメントをランダムにチェックするように変更します。これにより、Blob データ フラグメントはイーサリアムの各ノードに分散されますが、完全な Blob データは保存されますイーサリアム全体では、Fang 台帳では、ノードが十分で分散化されている必要があることが前提となります。
DAS は、消去コーディング (ErasureCoding) と KZG 多項式コミットメント (KZGCommitment) という 2 つのテクノロジーを使用します。
プロポーザーとパッケージャーの分離 (PBS) - ノード間の分業の問題を解決し、高パフォーマンス構成のノードがエンコードと配布のためのすべてのデータのダウンロードを担当し、低パフォーマンス構成のノードがスポット チェックを担当できるようにします。そして検証。
高性能構成のノードはビルダーになることができます。ビルダーはエンコード用の BLOB データをダウンロードしてブロックを作成するだけで済み、スポット チェックのために他のノードにブロードキャストするだけです。ビルダーの場合、同期データ量と帯域幅の要件が高いため、比較的集中化。
性能の低い構成のノードでも提案者 (Proposer) になることができます。提案者は、データの正当性を検証し、ブロック ヘッダー (BlockHeader) を作成してブロードキャストするだけで済みます。ただし、提案者 (Proposer) にとって、同期データの量は重要です。帯域幅要件は比較的高く、低いため、分散化されます。
検閲防止リスト (crList) - 過剰なレビュー権限により、パッケージャが特定のトランザクションを意図的に無視し、MEV を取得したいトランザクションを挿入できるという問題を解決します。
ビルダー (Builder) がブロック トランザクションをパックする前に、提案者 (Proposer) はまず、mempool 内のすべてのトランザクションを含むレビュー耐性のあるリスト (crList) を公開します。
ビルダー (Builder) は、crList 内のトランザクションをパッケージ化して並べ替えることのみを選択できます。つまり、ビルダーは、MEV を取得するために独自のプライベート トランザクションを挿入したり、(Gaslimit がいっぱいでない限り) トランザクションを意図的に拒否したりすることはできません。
パッキング後、Builder はトランザクション リスト ハッシュの最終バージョンを Proposer にブロードキャストし、Proposer はトランザクション リストの 1 つを選択してブロック ヘッダー (BlockHeader) を生成してブロードキャストします。
ノードがデータを同期するとき、プロポーザー (Proposer) からブロック ヘッダーを取得し、次にパッケージャー (Builder) からブロック本体を取得して、ブロック本体が最終的に選択されたバージョンであることを確認します。
デュアルスロット PBS - MEV を買収することで、集中型パッケージャーがますます集中化しているという問題を解決します
入札モードを使用してブロックを決定します。
ビルダー (Builder) は、crList と入札を取得した後、トランザクション リストのブロック ヘッダーを作成します。
提案者（Proposer）は、最終的に入札に成功したブロックヘッダーとビルダー（Builder）を選択し、提案者は（有効なブロックが生成されたかどうかに関わらず）無条件で落札手数料を受け取ります。
検証委員会（Committee）は、勝ったブロックヘッダーを確認します。
ビルダーは、勝ったブロックの本体を公開します。
検証委員会（Committees）は、勝ったブロックのボディを確認し、検証投票を行います（ブロックが合格した場合はブロックが生成され、パッケージャが意図的にブロックボディを与えなかった場合は、ブロックは生成されなかったものとみなされます）存在する）。
意義：
まず第一に、ビルダー (Builder) はトランザクションをパッケージ化するためのより多くの権限を持っていますが、上記の crList は、第一にトランザクションを一時的に挿入する可能性を制限し、第二に、ビルダー (Builder) がトランザクションの順序を変更することで利益を得たい場合、そのブロックヘッドの資格を確実に取得するには、最初に多額の入札費用を支払う必要があり、その後、取得するMEVの利益はさらに減少し、全体として取得の手段と実際の価値に影響を与えますMEV;
ただし、初期段階では (ノードのパフォーマンスの問題を考慮して) 少数の人だけがパッカーになる可能性があり、ほとんどの人は提案者になるだけであるため、さらなる集中化につながる可能性があります。小規模 特定の状況下では、MEV 機能を持つ一部の経験豊富なマイナーが入札に成功する可能性が高く、実際の MEV ソリューションの効果にさらに影響を与えます。
これは、MEV オークションを使用する一部の MEV ソリューションに影響を与えます。
意義：
EIP4844 は、実際には Danksharding の超簡易バージョンであり、DataHash と呼ばれる新しいオペコードや BinaryLarge Objects と呼ばれる新しいデータ オブジェクト (Blob) を含む、Danksharding と同じアプリケーション インターフェイスを提供します。
proto-danksharding は、完全な Danksharding 仕様を実装するための「ブラケット」 (つまり、トランザクション形式と検証ルール) 提案です。ただし、シャーディングはまだ実装されておらず、すべての検証者とユーザーは依然として完全なデータの可用性を直接検証する必要があります。 ;
長期的にレイヤー 2 料金を直接下げるために、EIP4488 ではなくプロトダンクシャーディングを選択する理由は、将来完全なシャードにアップグレードするときにわずかな調整だけが必要なためです。
EIP4488 とプロトダンクシャーディングの主な実際的な違いは、EIP-4488 はイーサリアムが現在行う必要がある変更を最小限に抑えようとするのに対し、プロトダンクシャーディングは将来イーサリアムにアップグレードするために現在イーサリアムにさらに多くの変更を加えることです。フルバージョンのシャーディングに必要です。
フル シャーディング (データ可用性サンプリングなど) の実装は複雑な作業であり、プロトダンクシャーディングの実装後にも複雑な作業が必要ですが、これらの複雑さはコンセンサス層で制御されます。プロトダンクシャーディングがデプロイされると、エグゼクティブ層のクライアントチーム、ロールアップ開発者、およびユーザーは、フルシャーディングに移行する際に追加の作業を行う必要がありません。
完全なシャーディングを実現するには、PBS、委任されたプルーフ、およびデータ可用性サンプリングの実際の実装を完了する必要がありますが、そのような変更は CL 層に集中するため、開発者は再調整する必要はありません。現在、4844 は新しいトランザクション タイプを実装しています。完全なシャーディングに必要なトランザクション形式、コンセンサス相互検証ロジック、および実行層ロジックはまったく同じであり、BLOB の自己調整型の独立したガス価格設定も導出されます。将来的には、PBS と委任証明書を完成させ、データ可用性サンプリングを実際に実装する必要がありますが、これらの変更は CL 層でのみ行われ、EL 層やロールアップ開発者による変更を必要としないため、開発者にとっては便利です。
SELFDESTRUCTremoval に続き、EIP-6780 が最終的に最適なソリューションであると判断されましたが、26 日の開発者会議で、Tim は、この提案に別のオペコード SETCODE を追加して、プログラマティック アカウントを引き続き更新できるようにすることを提案しました。
SELFDESTRUCT除去 EIP-6780：X
背景：
3 月 21 日、Vitalik 氏は、SELFDESTRUCT はイーサリアムのエコロジーに利益よりも悪影響を与えると提案しました。主な理由は、単一ブロック内の無限数の状態オブジェクトを変更できる唯一のものであるため、コントラクト コードの変更が発生し、アカウント残高の操作コードには、イーサリアムのセキュリティに対する大きな危険が潜んでいます。
オンチェーンでコントラクトを削除する唯一の方法は SELFDESTRUCT です。コントラクト内で selfdestruct 関数を呼び出すと、コントラクトを自己破棄できます。コントラクトに保存されたイーサリアムは、指定されたアドレスに送信されます。残りのコードとストレージ変数はステート マシンで削除されます。実際、契約破棄という行為は理論上は良さそうに聞こえますが、実際には非常に危険です。自己破壊機能は、開発者が緊急時にスマート コントラクトを削除し、コントラクトの残高を指定されたアドレスに転送するのに役立ちますが、この機能は犯罪者によっても使用され、攻撃手段となります。
4月13日、23日のコア開発者会議では、SELFDESTRUCTに関する4つの提案、すなわち6780、4758、6046、6190が議論に参加するために紹介され、それに続くEIP6780が最終提案として決定されました。
はじめに: selfdestruct はスマート コントラクトの緊急ボタンで、コントラクトを破棄し、残りの ETH を指定されたアカウントに転送します。
EIP6780: コントラクト内の同じトランザクション内にない限り、SELFDESTRUCT を無効にします。
更新: 5 月 26 日、tim は SELFDESTRUCT を削除することに加えて、別のオペコード SETCODE を追加して、プログラムによるアカウントを引き続き更新できるようにすることを提案しました。 (つまり、アップデート機能が追加され、アップデート/アップグレードによりスマートコントラクト内のプロパティが更新されます。) ここではEIP4758の利点が吸収され、dappにアップグレードの余地が生まれます。
理由: SELFDESTRUCT コードを操作するには、当初、すべてのコードとストレージを削除するなど、アカウントの状態に対する広範な変更が必要でした。これにより、将来 Verkle ツリーを使用する際に困難が生じます。各アカウントは、ルート アカウントに明示的に関連付けられない多くの異なるアカウント キーに保存されることになります。
変更済み: この EIP は SELFDESTRUCT を削除する変更を実装していますが、次の 2 つの例外があります。
SELFDESTRUCT から資金を引き出すためだけに使用されるアプリは引き続き動作します。
コントラクト内の同じトランザクションで使用される SELFDESTRUCT も変更する必要はありません。
意義：安全性の向上
以前は、コントラクトを通じてトランザクションを開始できるユーザーを制限するために SELFDESTRUCT を使用するコントラクトがメインネット上にありました。
SELFDESTRUCT 後にユーザーが引き続き資金を預け入れたり、保管庫で取引したりできないようにするには、この保管庫を繰り返し使用すると、保管庫内のトークンが盗まれる可能性があります。
以下の 3 つの提案は、その後削除された SELFDESTRUCT に関連する提案です。6780 は 23 年 4 月 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 を使用し続けることが非常に困難でした。
変化：
EIP-2681 によって導入されたルールを変更して、通常の nonce 増分が 2^64-1 ではなく 2^64-2 で制限されるようにします。
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適用によりガスコストが増加しました。
次に、ガスを節約し、将来のストレージ設計への道を開く EIP1153 です。
EIP1153X
概要: 一時ストア オペコード。ストアと同じように動作するが、各トランザクション後に破棄される状態を操作するためのオペコードを追加します。
理由：
Ethereum でトランザクションを実行すると、複数のネストされた実行フレームが生成され、各フレームは CALL (または同様の) 命令によって作成されます。コントラクトは同じトランザクションで再入力できます。その場合、複数のフレームが 1 つのコントラクトに属します。
現在、これらのフレームワークは、CALL 命令による入出力とストア更新による入出力の 2 つの方法で通信できます。別の信頼できないコントラクトに属する中間フレームワークがある場合、I/O 経由の通信は安全ではありません。
リエントランシーロックを例にとると、ロックの状態を送信するために中間フレームに依存することはできません。ストレージを介した SSTORE 通信 SLOAD は高価であり、一時ストレージはフレーム間通信の問題に対する専用のガス効率の高いソリューションです。
変更: 2 つの新しいオペコード、TLOAD (0xb3) および TSTORE (0xb4) が EVM に追加されました。
一時ストレージは、それを所有するコントラクトにとってプライベートであり、永続ストレージと同様に、所有するコントラクト フレームワークのみがその一時ストレージにアクセスできます。ストレージにアクセスするとき、すべてのフレームは永続ストレージと同じ方法で同じ一時ストレージにアクセスしますが、メモリとは異なります。
潜在的な使用例:
再入ロック；
チェーン上の計算可能な CREATE2 アドレス: コンストラクターのパラメーターは、初期化コード ハッシュの一部として渡されるのではなく、ファクトリ コントラクトから読み取られます。
単一トランザクション EIP-20 承認、例: #temporaryApprove(addressspender, uint256 amount);
転送手数料契約: トランザクション中に転送のロックを解除するためにトークン契約に料金を支払います。
「Till」モード: ユーザーがコールバックの一部としてすべての操作を実行できるようにし、最後に「Till」のバランスが取れているかどうかを確認します。
プロキシ呼び出しメタデータ: 不変のプロキシ コンストラクター パラメーターの値など、呼び出しデータを使用せずに追加のメタデータを実装コントラクトに渡します。
意義：
ガスを節約し、ガス請求ルールを簡素化します。
フレーム間通信の問題を解決します。
既存の操作のセマンティクスは変更されません。
使用後にストレージスロットを空にする必要はありません。
将来のストレージ設計 (Verkle ツリーなど) では、瞬間的なストレージのチャージバックの問題を考慮する必要はありません。
次に 4788 ですが、これは質権プールの信頼想定を減らすことができます。
EIP4788：X
概要: ビーコン ブロックのルートは EVM にあります。
更新: 15.06.23 の開発者会議で、開発者はステーカー エクスペリエンスを向上させるためにコードを変更することを提案しました。この EIP は、DApp 開発者の信頼のために、EVM の内部チェーン状態情報を含むビーコン チェーン ブロックのルートを公開します。最小限のアクセス。
変更: 対応する実行ペイロード ヘッダーで各ビーコン チェーン ブロックのハッシュ ルートを送信し、これらのルートを実行状態のコントラクトに保存し、そのコントラクトを読み取るための新しいオペコードを追加します。
重要性: これはコード変更提案であり、イーサリアム仮想マシン (EVM) を変更して、実行層 (EL) のコントラクト層 (CL) 状態ルートのデータを開示できるようにすることを提案しています。これにより、異なるプロトコルとEthereum ネットワーク内のアプリケーション プログラム間の通信がより効率的かつ安全になります。ステーキング プール、ブリッジング、およびプロトコルの再ステーキングに対して、よりトラストレスな設計が可能になります。
最後に、5656 があります。これは、効率的な新しいメモリ コピー オペコードを提供しますが、現在はテスト帯域幅のため、アップグレードに一時的に含まれている状態です。
EIP5656X
はじめに: MCOPY - メモリコピー命令。
更新: 09.06.23 に、開発チームは、セキュリティ問題は解決されるものの、アップグレードに追加するために必要な実装とテストの帯域幅に懸念があるため、MCOPY について当初意見が分かれていたが、最終的には EIP を含めることで合意したと述べました。 , ただし、開発者がテスト中またはクライアント側で容量の問題に遭遇した場合は、削除が検討されます。そのため、MCOPYはカンクンのアップグレードに一時的に含まれる状態となっている。
変更: メモリ領域をコピーするための効率的な EVM 命令が提供されました。
重要性: メモリのコピーは基本的な操作ですが、EVM での実装にはコストがかかります。
MCOPY 命令を利用できるようになると、コードワードとセンテンスをより正確にコピーできるようになり、メモリコピーのパフォーマンスが約 10.5% 向上します。これは、さまざまな計算集約型の操作に非常に役立ちます。
また、コンパイラーがより効率的で小さいバイトコードを生成するのにも役立ちます。
ID のプリコンパイルにかかるガスコストをある程度節約できますが、実際にこの部分の実現を促進することはできません。
候補者リスト EIP
23 年 6 月 15 日の開発者コンセンサス会議では、どの CL 中心の EIP を Deneb に含めるかについて議論され、その中には EIP6988、EIP7044、および EIP7045 が追加されることが提案されました。
EIP6988：X
概要: スラッシュされたバリデーターがブロック提案者として選出されるのを防ぎます。
重要性: 違反したノードに対するペナルティの増加は、DVT に利益をもたらします。
EIP7044：X
概要: 署名されたバリデーター出口が永続的に有効であることを確認します。
重要性: ステーカーのエクスペリエンスをある程度向上させることができます。
EIP7045：X
概要: 認証スロットの包含範囲を 1 エポックのローリング ウィンドウから 2 エポックに拡張します。
重要性: ネットワークのセキュリティを強化します。
EIPの分析を削除します
23年4月29日の第160回イーサリアムACDE会議では、EVMMAXとEOFがこのアップグレードから削除されることが確認され、EOFに関連する変更はその後の毎日のアップグレードで導入される可能性があります
EVMMAXEIP:
概要: EVMMAX は、イーサリアム上の算術演算と署名スキームに大きな柔軟性をもたらすことを目的としています。現在、EVMMAX 提案は 2 つあり、1 つは EOF あり、もう 1 つは EOF なしです。
EIP6601: EVM モジュラー算術拡張機能 (EVMMAX)
変更: これは EIP5843 の反復であり、EIP5843 との違いは次のとおりです。
6601 では、係数、事前計算されたモンゴメリ パラメータ、使用される値の数を格納する新しい EOF セクション タイプが導入されています (実行時に構成可能な係数は引き続きサポートされています)。
6601 は、EVMMAX 値用に別のメモリ空間を使用し、EVM<->EVMMAX メモリ間で値を移動するための新しいロード/ストア オペコードを使用します。
6601 は、最大 4096 ビット (EIP に記載されている暫定的な制限) のモジュライでの演算をサポートします。
重要性: EIP-5843 は、イーサリアム仮想マシンに効率的なモジュール式の加算、減算、乗算を導入し、EIP-6601 は、セットアップ セクション、別個のメモリ空間、およびモジュール式算術演算用の新しいオペコードを導入することでこれを構築します。より優れた構成と柔軟性を提供します。さらに大規模なモジュールをサポートし、EVM パフォーマンスを向上させます。
EVM コントラクトとして、BLS12-381 を含むさまざまな曲線での楕円曲線算術演算を可能にします。
MULMOD は、既存のオペコード ADDMOD と比較して、最大 256 ビットの値を操作する際のガス コストを 90 ～ 95% 削減します。
modexp プリコンパイルを EVM コントラクトとして実装できるようにします。
代数ハッシュ関数 (MiMC/Poseidon など) および EVM における ZKP 検証のコストを大幅に削減します。
EIP6690：
変更: 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 はバージョン管理を実行し、複数のコントラクト ルール セットを同時に実行できるようになります。
EIP663：
概要: 無制限の SWAP および DUP 命令
重要性: SWAPN と DUPN という 2 つの新しい命令を導入することにより、スタックの深さが 16 要素から 256 要素に増加する点で SWAP と DUP とは異なります。
EIP3540：
導入：
以前は、チェーン上にデプロイされた EVM バイトコードには事前に定義された構造がなく、コードはクライアントで実行される前にのみ検証されていましたが、これは間接的なコストとなるだけでなく、開発者が新しい機能を導入する際の妨げにもなります。または、古い機能を廃止します。
この EIP は、EVM 用に拡張およびバージョン管理できるコンテナを導入し、EOF コントラクトの形式を宣言します。これに基づいて、EOF コントラクトのデプロイ時にコードを検証できます (作成時検証)。この変更により EOF バージョン管理が実装され、既存の EVM 命令を無効にしたり、将来的に大規模な機能 (アカウントの抽象化など) を導入したりするのに役立ちます。
意義：
バージョン管理は、将来の新機能 (アカウント抽象化の導入など) の導入または廃止に役立ちます。
コントラクト コードとデータの分離は、L2 検証 (op) にとって有益であり、L2 バリデーターのガスコストを削減すると同時に、チェーン上のデータ分析ツールにとっても便利です。
EIP3670：
はじめに: EIP-3540 に基づいて、EOF コントラクトのコードがフォーマットに準拠し、有効であることを確認することを目的としています。フォーマットに準拠していないコントラクトについては、その展開が阻止され、Legacybytecode は影響を受けません。
重要性: 3540 によって導入されたコンテナに基づいて、EIP-3670 は EOF コントラクト内のコードが有効であることを確認するか、コードがデプロイされないようにします。これは、未定義のオペコードを EOF コントラクトにデプロイできないことを意味し、追加する必要がある EOF バージョンの数が減るという利点もあります。
EIP4200：
導入：
最初の EOF 固有のオペコードである RJUMP、RJUMPI、および RJUMPV が導入されました。これらは、宛先を符号付き即値としてエンコードします。コンパイラは、これらの新しい JUMP オペコードを使用して、既存の JUMP および JUMPI オペコードのジャンプデスタ分析を行うために必要なランタイムを排除するため、JUMP のデプロイと実行のガス コストを最適化できます。この EIP はダイナミックジャンプを補完するものです。
従来の JUMP 操作と比較した場合の違いは、RJUMP などの操作では特定のオフセット位置を指定せず、静的ジャンプで十分な場合が多いため、相対オフセット位置 (動的ジャンプ -> 静的ジャンプ) を指定することです。
意義: ネットワークを最適化し、コストを削減します。
EIP4750：
4200 の機能をさらに一歩進めます。CALLF と RETF の 2 つの新しいオペコードを導入することにより、RJUMP、RJUMPI、および RJUMPV で置き換えることができない状況に対する代替ソリューションが実現され、EOF コントラクトで JUMPDEST が不要になります。つまり、ダイナミックジャンプは無効になります。
重要性: コードをいくつかの部分に分割してコードを最適化します。
EIP5450：
背景: 背景としては、イーサリアム コントラクトはデプロイ時にチェックされず、実行時にスタック オーバーフロー (上限は 1024) かどうか、ガスが十分かどうか、などの一連のチェックのみが実行されるという点です。すぐ。
内容: EOF コントラクトの有効性チェックを追加しました。今回はスタックに関してです。この EIP は、EOF コントラクトの展開によってスタックのアンダーフロー/オーバーフローが発生する可能性がある状況を防ぎます。このようにして、クライアントは EOF 契約の実行中に行う有効性チェックの数を減らすことができます。
重要性: 大きな改善点は、実行中に発生するこれらのチェックをできる限り少なくし、コントラクトのデプロイ時に発生するチェックを増やすことです。
5 月 26 日の開発者会議の更新後、EIP4844 に関連するトランザクション タイプが SSZ から RLP に変更されたため、カンクンの 2 つの SSZEIP が不要になったため、EIP6475 と 6493 はアップグレードのためにカンクンから移動されました。
EIP6475X
はじめに: EIP4844 への関連提案。 Proto-danksharding では、他のトランザクション タイプで使用される RLP エンコードの代わりに SSZ エンコードを使用する新しいトランザクション タイプが導入されています。
更新: 第 161 回イーサリアム実行層コア開発者会議で、EIP4844 の SSZ シリアル化形式に関する議論で、当初開発者は BLOB トランザクションを介して SSZ 形式の初期の反復を EL に導入する傾向があり、最終的にはすべてのトランザクション タイプを導入することを計画していることが明らかになりました。は RLP から SSZ にアップグレードされましたが、開発者は、SSZ の経路が不明確であり、カンクンのアップグレードでは確実に実装されていないことを考慮して、EIP-4844 から SSZ を削除することを検討しています。多くの議論の後、開発者は EIP-4844 の EL 実装から SSZ を削除することに同意しましたが、まだ EIP6475 は削除されていません。 5 月 26 日の更新後、SSZ->RLP の変更により、カンクンの 2 つの SSZEIP が不要になるため、EIP 6475 と 6493 はアップグレードのためにカンクンの外に移動されます。
EIP6493X
はじめに: SSZ トランザクション署名スキーム。この EIP は、シンプル シリアル化 (SSZ) でエンコードされたトランザクションの署名スキームを定義し、CL では SSZ 形式でフォーマットされているが、EL では別の方法でエンコードされている BLOB トランザクション タイプをノードが処理する方法に対処します。この EIP は、層間の一貫性を確保するための Ethereum シリアル化形式の更新の一部です。
背景: SSZchanges
はじめに: SimpleSerialIZe は、ビーコン チェーンで使用されるシリアル化メソッドです。
SSZchanges には他にも 3 つのサポート提案が含まれていますが、今回は 6465 のみが導入されました。
EIP6465: SSZ 引き出しルート。既存の Merkle-PatriciaTrie (MPT) コミットメントの Simple Serialization (SSZ) 引き出しへの移行プロセスを定義します。
EIP6404/EIP6466：
どちらも、既存の Merkle-PatriciaTrie (MPT) コミットメントを Simple Serialization (SSZ) に移行するプロセスを定義します。
EIP-6404 - SSZ トランザクション ルート
EIP-6466— SSZ レシートベース
Tim Beiko 氏は、5 月 26 日のコア開発者会議で、カンクンの範囲の拡大に関する今後の話し合いは、EIP5920、5656、7069、4788、2537 の 5 つの EIP に限定され、その後の提案はこの範囲内で生成されるだろうと提案しました。その後の EIP5656 と EIP4788 は正式なアップグレード提案として確認され、5920、7069、2537 は削除されましたが、このうち EIP5920 は、ETH の転送方法の潜在的な副作用に対する開発者の懸念、および未完成の推論、テスト、およびセキュリティ作業。アップグレードから削除されました。
EIP5920：X
はじめに: 支払いオペコード。イーサリアム転送に新しいオペコード PAY を導入し、関数を呼び出すことなくイーサをアドレスに送信します。
理由: 現在、アドレスに ether を送信するには、ユーザーがそのアドレスで関数を呼び出す必要があり、これにはいくつかの問題があります。
まず、受信者が送信者にコールバックできるため、再入攻撃の経路が開かれます。
2 番目に、DoS ベクトルを開くため、親関数は受信側のガスまたはコールバックが不足する可能性があることを認識する必要があります。
最後に、CALL オペコードは、メモリとスタックを拡張し、コードとメモリを含む受信側の全データをロードする必要があり、最後に呼び出しを実行する必要があり、おそらく他の意図しない操作を行う必要があるため、単純なイーサ転送には不必要にコストがかかります。
変化：
新しいオペコードが導入されました: (PAY)PAY_OPCODE、ここで:
スタックから 2 つの値をポップします: addrthenval。
wei を実行アドレス val からアドレス addr に転送します。 addr がゼロアドレスの場合、valwei は実行アドレスからプログラムされます。
潜在的な落とし穴: 既存のコントラクトは、電話をかけずにアドレスにイーサを送信することがすでに可能であるため、ウォレットの実際の残高とは無関係に使用されます。
意義: ガスを節約します。
更新: 09.06.23 に、ETH の転送方法に存在する可能性のある潜在的な副作用と、提案を通過させるために必要な推論、テスト、セキュリティ作業に関する懸念から、PAY はアップグレードから削除されました。
EIP7069X
はじめに: 変更された CALL 命令
変更: 3 つの新しい呼び出し命令、CALL2、DELEGATECALL2、STATICCALL2 が導入されました。これらはセマンティクスを簡素化する効果があります。新しい指令からガスのオブザーバビリティを削除し、再価格設定の影響を受けない新しいクラスの契約への扉を開くことを目指しています。
背景：
63/64 番目のルール: 呼び出しの深さを制限し、呼び出し先が戻った後に状態を変更するためのガスが呼び出し元に残っていることを確認します。
ルール 63/64 が導入される前は、呼び出し元が利用できるガスをある程度正確に計算する必要がありました。 Solidity には、適切なガス値を設定するために、呼び出し自体の実行にかかる呼び出し側のコストを推定しようとする複雑なルールがあります。
現在、63/64 番目のルールが導入されています。
呼び出しの深さの検査を削除しました。
呼び出された動作を実行する前に、必ず少なくとも 5000 ガスを予約してください。
呼び出された動作に少なくとも 2300 ガスが利用可能であることを確認してください。
補助金ルール: 有名な 2300 補助金など、コントラクトが別のコントラクトを呼び出すと、呼び出されたコントラクトは非常に限定された操作を実行するために 2300gas を取得します (ちょっとした計算を行ってログを生成するには十分ですが、ストレージ スロットを満たすには十分ではありません) ）、ガスの量が固定されているため、ガス価格が調整できる限り、これらのガスがどのような種類の計算をサポートできるかを判断する方法はありません。
意義: 将来の EOF 導入への道を切り開き、大規模な契約の実行を容易にします。
ガスのオプションを削除: 新しいコマンドではガス制限を指定できませんが、「63/64 番目のルール」に依存しています (主に、EIP-150 の多数の IO 操作に使用されるガスの再価格設定を指します。これにより、特定の操作のガス消費量) からガスの制限まで、この重要な改善は、「補助金」に関するルールを簡素化することです。値が送信されるかどうかに関係なく、呼び出し元はガスに関する計算を実行する必要がありません。
新しい提案の導入により、ユーザーはトランザクションでより多くのガスを送信することで、いつでもガス不足エラーを克服できます (もちろん、ブロック ガス制限の影響を受けます)。
限られた量のガスのみを呼び出しに送信する一部の契約は、以前にストレージ コストを引き上げたときに新しいコスト計算メカニズムによって破られました (たとえば、EIP-1884 では特定のオペコードのガスが増加しました)。以前は、一部の契約には、使用できるガスの量を永続的に制限するガスの上限があり、サブコールにガスを送信したとしても、通話によって制限されるため、どれだけ追加のガスを送信しても、うまくいきませんでした。送金額。
EOF 導入への道を開く: EVM オブジェクト フォーマット (EOF) が導入されると、古い呼び出し命令は EOF 契約で拒否され、ガス価格の変更の影響をほとんど受けなくなります。これらの操作はガスの可観測性を除去するために必要であるため、EOF では既存の命令の代わりにこれらの操作が必要になります。
より便利なステータス戻りコード: より詳細なステータス コード (成功 (0)、復帰 (1)、失敗 (2)) を返す便利な関数が導入されており、将来拡張可能です。
EIP2537：X
概要: BLS12-381 曲線操作のプリコンパイル。
変更: BLS 署名検証や SNARK 検証などの操作を効率的に実行するために必要なセットにプリコンパイルとして BLS12-381 曲線の操作を追加しました。
重要性: イーサリアムは、より安全な暗号証明を作成し、ビーコン チェーンとの相互運用性を向上させることができます。
PR3175 について言及されましたが、最終候補には挙げられず、それ以上の議論は行われませんでした
PR3175：X
概要: この提案により、ペナルティを受けたバリデーターがデキュー時にブロックを提案できなくなります。バリデーターの 50% 以上が悪意のある動作でペナルティを受けた場合でも、それらのバリデーターはネットワークから強制的に削除されている間もブロックを提案できます。このロジックの変更は、「高故障モード」に対する保護を提供する比較的小規模な CL 層の変更であると開発者らは述べています。
5月4日に開催された第108回イーサリアムコア開発者コンセンサス会議によると、PR3175はEIPとしてフォーマットされている段階であり、セキュリティ上の理由から、スラッシュ検証ノードが選択されないようにするため、EIP-6987に変更される予定です。ブロック提案者。
＃＃＃ 未来
上記の情報に基づいて、次の結論に達しました。
1. カンクンのアップグレードの主な目標は、優先順位の順に、拡張、セキュリティ、ガスの節約、相互運用性です。
拡張が最優先事項であることに疑いの余地はありません (4844)。
安全性とガスの節約は 2 番目に優先されます (6780、1153、5656、7045)。ただし、特定の開発者の経験が考慮されています。
3 つ目は相互運用性です。dapp 間の接続、通信、相互運用性の最適化などです (4788、7044、6988)。
予想されるデータ: Testnet 4844 は opsiderollup のコストを 50% 削減できる、EigenLayer と Celestia の技術ソリューションはあまり開示されていないため、データを評価できない、Ethstorage は DA のコストが元のコストの 5% に下がると見積もっている; トピアでは100～1000分の1のコスト削減が見込まれます。
2. カンクンがダンクシャルディングに格上げされる今後 2 ～ 5 年は、DA 層プロジェクトの黄金の開発期間です
レイヤ 2 のセキュリティの上限は、採用する DA 層によって異なります。プロトダンクシャーディングは、より安価な状態データ ストレージを通じて、ストレージ プロトコル、モジュラー プロトコル、L1 ストレージ拡張ネットワークに利益をもたらします。
まず、ダンクシャーディングはイーサリアムのステートマシンの本質に立ち返ります。 V 神は、イーサリアムコンセンサスプロトコルの目的は、すべての履歴データの永久保存を保証することではない、と述べました。代わりに、高度に安全なリアルタイム掲示板を提供し、他の分散プロトコルが長期保存できる余地を残すことが目的です (イーサリアムコンセンサスプロトコルの目的は、すべての履歴データの永久保存を保証することではありません。むしろ、その目的は安全性の高いリアルタイム掲示板を提供し、他の分散プロトコルが長期保存できる余地を残すことです。);
第二に、ダンクシャーディングは DA のコストを削減しますが、実際の着陸時間とデータの可用性の問題も解決する必要があります。
DA コストの削減: この更新前は、ロールアップからイーサリアム メイン チェーンにデータを解放するために calldata を呼び出す必要があり、このコードを呼び出すためのガス料金が非常に高価であり、これがレイヤー 2 での最大の支出でした。ロールアップ 独自の追加データ スペースによりストレージ コストが大幅に削減され、DA コストが削減されます。
実際の着陸時間は長く、改善できる TPS と削減できるガスはまだ限られているため、今後の DA レイヤー プロジェクトの継続的な開発に適しています。
Polynya の iablesecurity データ シャーディングに関する danksharding に関する記事では、実装には 2 ～ 5 年かかることが示されています。
たとえ着陸したとしても、増加できる TPS と減少できるガスレベルは依然として制限されています。
EIP4844 は現在 6 つの BLOB をサポートしており、将来の拡張問題は Danksharding によってのみ解決できます。
現在のイーサリアムのブロックスペースは約200KBです。 Danksharding 以降、仕様で計画されているサイズは 32 メガバイトで、これは約 100 倍の向上です。現在、イーサリアムのTPSは15程度ですが、理想的な状態では100倍にすると1500程度となり、大きな改善ではありません。
したがって、長い実装時間 + 限られた実際の変更は、DA レイヤー プロジェクトに利益をもたらします。Celestia や Eigenda などの一部の DA プロジェクトは、より安価なコストとより高速な TPS により、依然として Danksharding と競合することができます。ETHstoragetopia などの新しい DA プロジェクトは、以前の市場ギャップを埋めることもできます。
データ ストレージやデータの可用性の問題などの技術的な問題にも対処する必要があります。
DA には主に 2 つのコストがあり、1 つはネットワーク帯域幅のコスト、もう 1 つはストレージのコストであり、4844 自体はストレージの問題とブロック チェーンの帯域幅の問題を解決しません。
BLOB はイーサリアム コンセンサス レイヤーに約 3 週間保存され、その後削除されます。完全な履歴記録を保存してすべてのデータを利用できるようにしたい場合、現在のソリューションには次のものが含まれます: dapp 自体がそれ自体に関連するデータを保存し、イーサリアム ポータル ネットワーク(現在開発中) 開発中)、またはブロック エクスプローラー、BitTorrent の履歴データ、個々のユーザーによる自発的ストレージなどのサードパーティ プロトコル。
したがって、プロト ダンクシャーディングは、ストレージ プロトコル、モジュラー プロトコル、および L1 ストレージ拡張ネットワークに利益をもたらします。
履歴データを呼び出す需要は、分散ストレージ プロトコルやサードパーティのインデックス プロトコルの新しい開発チャネルにつながります。
後続のモジュラー契約は高速ロールアップを通じてトランザクションを実行でき、安全な決済層が決済を担当し、低コストで大容量のデータ可用性層が保証を担当します。
これは、より低いストレージ コストでプログラマブル ストレージの第 2 層ソリューションを提供できる Ethstorage などの L1 ストレージ拡張ネットワークに適しています。
3. カンクンのアップグレードは、L2 ダイバーシティ、L3、RAAS、データ可用性、その他のトラックに適しています
L2 トラック分析:
最上位のレイヤー 2、ArbitrumOrbit、OPStack、Polygon2.0、FractalScaling (StarkWare の下)、HyperChain (zkSync の下) などの 5 つのプロジェクトが恩恵を受けます。 BLOB によってもたらされるストレージ料金の削減により、レイヤー 2 の開発を制限していたこれまでの一連のコストとスケーラビリティの問題が大幅に改善され、データ スループットが大幅に向上します。コストの問題を解決した後、ヘッド レイヤー 2 は特定のデータをデプロイし続ける機会が得られます。機能、高レベルのカスタマイズされたマルチチェーン同時 L3 エコロジー。
第 2 層のレイヤー 2 と主流のレイヤー 2 との間の運用コストの差は縮まり、Aztec、Metis、Baba、ZKspace、layer2.finance などの一部の小規模プロジェクトに開発の機会がさらに与えられます。
モジュラーブロックチェーンプロジェクトの実際のニーズはまだ検証されていませんが、StarkwareのCario、Moveシリーズ言語、WasmがサポートするC、c++、C#、Goシリーズ言語など、より多くのWeb2を導入できる多様なプログラミング言語がまだ可能です。開発者。
Raas トラック分析:
Raas 自体の利点は、高度なカスタマイズ、カスタマイズされた要件 > 純粋なコストと効率にあり、コスト削減はカスタマイズされたロールアップの大きな利点です。
しかし、RAAS トラックの問題は、それが OverHype である可能性があり、RAAS トラック自体についてさえ疑問があることです。上位 5 位の Layer2 との競争やさまざまな新しい DA の出現に直面し、新しいプロジェクトが軌道に乗るかどうかには疑問符を付けざるを得ません。
まず第一に、ヘッド層 2 アプリケーション チェーンの展開の利点は、ネットワーク フレームワークの完全性とチェーン間のエコロジーのセキュリティにあり、RAAS の利点はそのカスタマイズと自由にあります。
ただし、OP および ZK シリーズの RAAS の技術的障壁は現時点では強くなく、まだ短期的にはテストネットの段階にあり、実際の製品相互作用はありません。将来のレイヤー 3 の生態学的利点は、RAAS に対する実際の需要には疑問があります。
OP シリーズ: OP スタックの基盤アップグレード +4844 により、コストと効率に若干の改善がもたらされましたが、改善の魅力はそれほど強くありません。
ZKシリーズ: 現在、多くの主要プロジェクトはZKEVMルートをたどり、イーサリアムとの互換性により注意を払っているため、回路設計は一定の効率を犠牲にしており、OPシリーズほどターゲットを絞っていません。ただし、現在市場に出ている ZKRAAS のほとんどは依然として主要なプロジェクト (ZkSync など) を使用してチェーンをフォークしており、障壁はまだ強力ではありません。
したがって、短期的には、レイヤー 3 が登場する前に OPRAAS にはまだ開発の余地が残っていますが、長期的には ZKRAAS とレイヤー 3 が将来のトレンドになる可能性があります。
ZKRAAS は 4844 以降、コスト面でのデメリットが大きくなり、OP よりもはるかに多くの計算能力を消費します。L1 へのアップロードのコストは OP よりも低いですが、これは証明プロセスのコストと比較するとバケツの一滴に過ぎません。 while OP 利点は、短期間で迅速にエコロジーを構築できることであり、レイヤー 3 が登場するまでにはまだ開発の余地があることです。
従来の DeFi アプリケーションや NFT 市場にとって、ロールアップの変革は厳密な要件ではなく、高い効率性を必要とする決済アプリケーションやゲームのみがロールアップの需要を高めています。将来的には、defi プロジェクトは l2 に、ソーシャル プロジェクトは l3 またはオフチェーンに配置される可能性があり、最終的にコア データと関係は l2 に配置される可能性があります。ゲーム プロジェクトは l3 またはロールアップに移動する必要がありますが、現在のほとんどのプロジェクトは l3 に移動する必要があります。チェーン ゲームは本質的にファンドであり、トークンが外部に流通できないことが開発のボトルネックとなっていますが、チェーン全体でのゲームの出現と相まって、l3 自体の生態学的魅力はロールアップのそれよりもはるかに大きいです。
4. カンクンのアップグレードにより、開発者とユーザーのエクスペリエンスが向上
カンクンアップグレードの 2 番目の重要な提案である SELFDESTRUCTremoval は、イーサリアムのセキュリティをさらに向上させると同時に、削除後に存在する可能性があるアカウント更新手続きの問題に対して、この状況を改善するための新しいオペレーションコード SETCODE が用意されています。
カンクンによってアップグレードされた 3 番目の提案 EIP1153 では、一時ストレージ オペコードが追加されています。これにより、まずガスが節約され、次にフレーム間通信の問題が解決され、最終的には Verkle ツリーが返金を考慮する必要がなくなるなど、将来のストレージ設計への道が開かれます。一時的なストレージに関する質問。
カンクン アップグレードの 4 番目の提案である EIP5656 では、コードワードとセンテンスをより正確にコピーできる MCOPY メモリ コピー命令が導入され、メモリ コピーのパフォーマンスが約 10% 向上します。
カンクン アップグレードの 5 番目の提案は EIP4788 です。これにより、イーサリアム ネットワーク内のさまざまなプロトコルとアプリケーション間の通信がより効率的かつ安全になり、ステーキング プール、ブリッジング、および再ステーキング プロトコルのよりトラストレスな設計も可能になります。
最新のカンクンアップグレード（6月15日、23日）では、CL中心のEIPアップグレードであるEIP6988、EIP7044、EIP7045の追加が提案されており、それぞれ誓約者のエクスペリエンスの向上やネットワークセキュリティの向上など、細部の点でイーサリアムのセキュリティと使いやすさを向上させます。等
削除されたプロポーザルのうち、SSZ->RLP 移行により、2 つの SSZEIP (EIP6475 および EIP6493) がカンクン アップグレードから削除されました。EOF 関連のプロポーザルは、上海アップグレードから削除された後、再びカンクン アップグレードから削除され、現在検討されています。可能性は、後の毎日のアップグレードで直接実装されます; EVMMAX は、EOF の実装に関連する EIP のサブセットであるため、EOF とともにアップグレードのためにカンクンからも削除されます; ETH の転送方法に存在する可能性のある潜在的な副作用を考慮して、提案を通過させる必要性 推論、テスト、セキュリティ作業のため、EIP5920 はアップグレードから削除されます。
5. zkml とアカウントの抽象化との関係
zkml への影響はほとんどありません
ZKML は、ゼロ知識証明 (ZeroKnowledge) と機械学習 (機械学習) を組み合わせたもので、ブロックチェーンと ML モデルの組み合わせにより、機械学習のプライバシー保護と検証可能性の問題が解決されます。
プライバシー保護: 入力データの機密性 (トレーニング用のマシンにフィードするデータとして大量の個人情報を使用する場合など)、個人情報の機密性は主要な要件です。または、プロジェクトの中核的な競争力としてモデル パラメーターも必要です。競争障壁を維持するために暗号化される必要があります。このような信頼性の問題が存在すると、ML モデルによる大規模なデータやアプリケーションの取得が妨げられます。
検証可能性: ゼロ知識証明技術は幅広い応用範囲があり、ZKP を使用すると、ユーザーは検証なしで情報の正しさを知ることができます。また、機械学習モデルは多くの計算を必要とするため、ML モデルは ZK-SNARK を通じて証明を生成し、証明サイズを削減し、ML の計算能力需要を軽減します。
ZKML のストレージ要件は DA とはほとんど関係がありません。Space and Time のような別個のストレージ構造が必要であり、そのコア技術は新しいセキュリティ プロトコル「SQL Proof」です。または、オンチェーンとオフチェーンのデータをシンプルな方法で接続します。 SQL 形式で結果をスマート コントラクトに直接ロードします。
ZK-SNARKs は ZKML の ZK の主要な形式であり、チェーン上の ML の計算能力要件に適応できます。暗号化の発展に伴い、特に再帰的 SNARK 証明はチェーン上の ZKML の実装に利益をもたらします。
ZK-SNARKs は高いコンパクト性が特徴です。ZK-SNARKs を使用すると、証明者は短い証明を生成でき、検証者は対話する必要がなく、その妥当性を検証するために少量の計算を実行するだけで済みます。必要な証明者は 1 人だけです。検証者との対話の性質により、ZK-SNARK は実際のアプリケーションで効率的かつ実用的なものとなり、ML のオンチェーン コンピューティング能力要件により適しています。
現時点ではチェーン上でトレーニングすることは不可能であり、チェーン上に保存できるのはオフチェーンの計算の結果のみです。
現在の ML の問題は、演算能力の要件が満たされていないことと、アルゴリズムの制限 (並列計算ができない) によって引き起こされるパフォーマンスの低下によるものです。大規模モデル ZK は、より高い演算能力が必要であることを証明していますが、チェーン上でそれをサポートすることはできません。 ZK-SNARK は小規模な ML ゼロ知識証明と少量の計算のみをサポートします。つまり、コンピューティング能力の制限は、ZKML ブロックチェーン アプリケーションの開発に影響を与える重要な要素であり、チェーンはオフの結果のみを保存できます。 -チェーン計算。
優れたアカウントの抽象化
まず第一に、カンクンのアップグレードにより、ZKrollup 証明のコストをある程度削減できます。
現在の zkSync トランザクション手数料は 3 つの側面によって異なります。
SNARK 証明書を生成して検証するために検証者が消費する固定リソース コストは比較的高くなります。
検証者がSNARK証明をイーサリアムメインネットに送信するときのガス料金。料金のこの部分は、メインネットの混雑によりそれに応じて増加します。
トランザクション確認、メッセージブロードキャストなどを含む、ユーザーが検証者に支払うサービス料金。
したがって、4844 が導入されれば、幹線ネットワークの混雑によるガス料金の増加の問題が緩和され、ZKP 証明のコストもある程度削減できるため、ZK シリーズの開発動向は決して過小評価すべきではありません。
次に、アカウントの抽象化により、従来の TX トランザクションがユーザー操作に変換され、ECDSA を使用してユーザー操作がブロックにパックされます。これにより、チェーン上で以前よりも多くのストレージが占有されるため、ストレージ要件が高くなります。
次に、アカウントの抽象化と ZKrollup は相互に補完できます。
現時点でのアカウント抽象化の問題点は、GasFee が高価であること、手順が多すぎてスマートコントラクトが関与しているため、データ量が多く高価になっていることですが、ZKRollup の利点はデータを削減できることです。
アカウントの抽象化によりセキュリティの確保が困難：AA は複数のコントラクトを伴うためセキュリティが問題となるが、今後徐々に L2 が形成されると、コンセンサス層は変更されなくなり、スマートコントラクトの用途が広がり、セキュリティが確保されるアカウント抽象化の可能性も高まり、それが保証され、ZKrollupの信頼できる検証により、セキュリティがさらに向上します。
最後に、AI テクノロジーの台頭を考慮すると、オンチェーン コントラクトのセキュリティを強化し、オンチェーン トランザクションやアクティビティ ステップを最適化するのに役立ちます。
AI とセキュリティ: AI テクノロジーを使用すると、オンチェーン トランザクションのセキュリティとプライバシー保護を強化できます。たとえば、Web3 セキュリティ プラットフォーム SeQure は、AI を使用して悪意のある攻撃、詐欺、データ漏洩を検出および防止し、リアルタイムの監視および警報メカニズムを提供して、チェーン上のトランザクションのセキュリティと安定性を確保します。
AI とオンチェーン アクティビティの最適化: ブロックチェーン上のアクティビティには、トランザクション、契約の実行、データ ストレージが含まれます。 AI のインテリジェントな分析および予測機能を通じて、オンチェーンのアクティビティをより適切に最適化し、全体的な効率とパフォーマンスを向上させることができます。 AI は、トランザクション パターンを特定し、異常なアクティビティを検出し、データ分析とモデル トレーニングを通じてブロックチェーン ネットワークのリソース割り当てを最適化するためのリアルタイムの推奨事項を提供します。
したがって、カンクンのアップグレードは、ストレージ容量の拡大から ZKrollup との補完性、そして AI テクノロジーとの組み合わせに至るまで、アカウント抽象化の将来の開発に徐々に利益をもたらします。
6. イーサリアムのロードマップを振り返ると、次は何になるのか
現時点では、Layer2 は Solana と同様のパフォーマンス (レイテンシとスループットの点で) を持たず、Near のような断片化パフォーマンスも、Sui や Aptos のような並列実行パフォーマンスもありません。リーダー;
カンクンのアップグレード後、いくつかの主要な開発期間は、完全なダンクシャーディング (2 ～ 5 年)、MEV および PBS の着陸 (1 ～ 3 年)、アカウントの抽象化 (1 ～ 2 年)、ZK のすべて (3 ～ 3 年) と推定されています。 6 年) )、EOF および開発者の経験 (拡張機能を何回見たことがありますか?)。
ザ・スカージ
目標: MEV の問題の解決に重点を置きます。
解決策: 「プロポーザーとビルダーの分離 (PBS)」を通じてアプリケーション層で MEV を最小化します。この時点で、BLOB が最適化され、事前確認サービスまたはプリエンプション保護が導入される可能性があります。
PBS は、ブロック作成者とソーターを分離したものです。ソーターはチェーンに関係なくソートのみを担当し、ブロック作成者はトランザクションを気にせず、ソーターが作成したパッケージを直接選択してチェーンに置きます。このプロセスにより、プロセス全体がより公平になり、MEV の外部化というアイデアである MEV の問題が軽減されます。
PBS の完成度は現時点ではまだ非常に低く、より成熟しているのは外部 MEV ソリューションとの連携、つまりフラッシュボットの mevboost です。
先進版の「Enshrined Proposer-Builder Separation (ePBS)」は完成度が低くサイクルが長く、短期的には実装されないと予想されています。 PBS フレームワークの柔軟性と適応性を強化するオプティミスティック リレー
ザバージ
目標: Verkel ツリーを使用して Merkle を置き換え、信頼最小化ソリューションを導入し、ライト ノードがフル ノードと同じセキュリティを取得できるようにし、ブロック検証を可能な限りシンプルかつ移植可能にします。
同時に、L1 の ZK 化が Verge のロードマップに明確に追加され、ZK は将来の拡張と高速化の一般的な傾向となるでしょう。
解決策: zk-SNARK を導入して、SNARK ベースのライト クライアント、コンセンサス状態変更を伴う SNARK、EnshrinedRollups などの古いプルーフ システムを置き換えます。
Verkle ツリーは、状態固有の Merkle ツリーに代わるより効率的な代替手段であり、各姉妹ノード (同じ親を共有するノード) から選択したノードへのパスを提供する必要がなく、証明としてパス自体のみを提供する必要があります。マークル証明よりも 3 倍効率的です。
EnshrinedRollup は、L1 上で何らかのコンセンサス統合を持つロールアップを指します。利点は、L1 のコンセンサスを継承し、ロールアップ アップグレードを実行するためにガバナンス トークンを必要としないことです。同時に、チェーンの外側で計算を実行し、パブリッシュのみを行うことで、その結果をブロックチェーンに変換すると、トランザクション数を増やすことができますが、実装の技術的な難易度は比較的高くなります。将来的にこれらのロールアップを組み合わせることで、今後数十年間のブロックチェーン エコシステムのニーズのほとんどを満たすことができるようになります。
ザパージ
ThePurge は、ネットワークの検証に参加するためのストレージ要件を削減することでプロトコルを簡素化するという目標を指します。これは主に、冬眠と履歴と状態の管理によって実現されます。履歴データの休眠 (EIP-4444) により、クライアントは 1 年以上古い履歴データを削除し、P2P レベルでのサービスの提供を停止できます。
休眠状態。状態の増大の処理に関しては、主に 2 つの目標があります: 弱いステートレス性 (状態を使用してブロックを構築するだけで検証はしないという目標を指します)、もう 1 つはアクセスされる状態です。状態の休止状態により、状態ノードが保存する必要がある状態が合計 20 ～ 50 GB 削減されるはずです。
パージの第 5 段階では、EIP4444 がロードマップに明示的に書き込まれます。EIP-4444 では、クライアントが 1 年以上古いデータを消去する必要があります。同時に、この段階では、EVM のメカニズムの簡素化など、いくつかの EVM 最適化タスクがあります。 GAS および EVM のプリコンパイルなど。
ザ・スプラージ
Splurge の最終第 6 段階では、EIP4337 についても言及されており、ウォレット エコロジーの長期的なレイアウト提案として、アカウントの抽象化により、ガソリンやソーシャル リカバリー ウォレットの支払いにステーブルコインを使用するなど、将来的にウォレットの使いやすさがさらに向上します。 、など。