**執筆者: **クリスティン・キム****コンピレーション:Luccy、BlockBeats**開発者は、Pectra Devnet 0の長い芯のローソクの準備に加えて、新しいEIPの提案、既存のEIPの議論と分析、スマートコントラクトとトランザクションの影響分析について話し合いました。 その中で、EIP 7702の議論は参加者から多くの注目を集め、この提案はEIP 3074の潜在的な代替品と見なされました。ギャラクシーデジタルのリサーチ担当VPであるクリスティン・キムは、BlockBeastsが次のようにまとめた会議のハイライトについて詳細なメモを提供しました。2024 年 5 月 9 日、イーサリアム開発者は、オールコア開発者 (ACDE) コール #187 セッションのために Zoom に集まりました。 ACDE電話会議は、イーサリアム財団のプロトコルサポート責任者であるTim Beikoが率いる隔週の一連の会議で、開発者はイーサリアム実行レイヤー(EL)の変更について話し合い、調整します。 今週、開発者は、Pectra Devnet 0の準備、EIP 3074実装の更新、およびELのシリアライゼーションメソッドをMPTからSSZに変換する緊急性について説明しました。### Pectra Devnet-0 アップデートイーサリアム財団の開発者オペレーションエンジニアであるBarnabas Busa氏は、彼のチームは最初のPectra開発者に焦点を当てたテストネットネットワークのクライアント構成をテストしており、5月13日月曜日までにPectra Devnet 0の安定した構成を確保するために作業すると述べました。 Pectra Devnet 0 readiness trackerによると、Geth、Nethermind、EthereumJSのクライアントチームは、Pectraのコード仕様を完全に実装しています。電話会談で、Besuの開発者であるJustine Florentine氏は、すべてのPectra EIPはBesuに実装されているが、彼のチームはまだコードのデバッグに取り組んでいると述べた。 Erigonの開発者であるAndrew Ashikhmin氏は、彼のチームは、ELトリガー可能な引き出しであるEIP 7002を除くすべてのEIPの処理をすでに開始していると述べました。 Reth チームは、Zoom チャットに実装トラッカーへのリンクを投稿し、Erigon チームと同様に EIP 7002 の作業がまだ保留中であることを示しました。CLクライアント側では、Grandineの開発者であるSaulius Grigatis氏は、すべてのEIPが実装されているが、ELクライアントで実行しているときに、彼のチームはいくつかのバグに遭遇したと述べた。 Lighthouseチームの担当者は、Pectra Devnet 0の完全な実装の準備がほぼ整っていると述べ、エンジンAPIの仕様を更新する必要があると述べました。 Tekuの開発者であるMikhail Kalinin氏は、エンジンAPI仕様にこれらの更新を追加する作業に取り組んでいると述べた。EFテストチームのMario Vegas氏は、開発者はEIP 3074、AUTHおよびAUTHCALLオペレーションコード、およびその他のいくつかのEIPのテストケースの追加に取り組んでいると述べた。### EIP-3074 アップデート開発者は EIP 3074 を Pectra Devnet 0 の仕様に保持することに同意しましたが、それに代わる代替の EIP EIP 7702 が議論されています。 Gethの開発者である"Lightclient"は、EIP 3074の最新の分科会を要約し、参加者は、Pectraのアップグレードでどの変更を優先すべきかが、ユーザーコントロールアカウント プログラム可能性の改善に関連しているかについて議論しました。 Lightclientによると、すべての参加者は、完全なネイティブアカウントの抽象化がイーサリアムに実装されるまでまだ数年かかることに同意しました。 ただし、これが外部所有アカウント(EOA)への変更を優先することを意味するのか、EOAをスマートコントラクト ウォレットに移行することを意味するのかについては意見が分かれています。 このACDEコールの前日である5月8日、イーサリアム共同創設者のビタリックブテリンは、イーサリアムが新しいトランザクションタイプサポートて、EOAが単一のトランザクション中にスマートコントラクト ウォレットのように動作できるようにする新しいEIP EIP 7702を提案しました。 Lightclientによると、EIP 3074ブレイクアウトセッションの参加者は、EIP 7702について概ね肯定的でした。 しかし、彼は後に、EIP 7702について解決すべき重要な詳細がまだあると付け加えました。 たとえば、EIP 7702 トランザクションを取り消す方法や、そのようなトランザクションのガス コストをスケーリングする方法の詳細は不明のままです。EIP 7702が受け入れられ、ペクトラのアップグレードに含まれる場合、EIP 7702はEIP 3074と同様の結果を達成しますが、イーサリアム上に新しいオペレーションコードを作成せず、新しいEOA動作の静的分析の容易さを向上させるため、EIP 3074の代替と見なされます。 EFの研究者であるAnsgar Dietrichsは、Zoomチャットで、EIP 7702をPectraに含めることを検討し、EIP 3074を7702に置き換えるかどうかの正式な決定を約2〜4週間で行う必要があることを提案しました。 電話会議でのEIP 7702に関する開発者の議論から、提案が実装の準備ができていると見なす前に、さらなる作業が必要であることは明らかでした。 Nethermind の開発者である Ahmad Mazen Bitar は、EIP 3074 ですでに行われた作業を 7702 の実装に再利用できない可能性があると述べました。 Beiko氏は、開発者はDevnet 0のEIP 3074の実装を進め、後でDevnet-1仕様を再検討する必要があることを確認した。### EIP-7685、SSZ、および EIP-6110その後、開発者は、Nimbus開発者のEtan KisslingがEIP 7685、つまり一般的な実行レイヤーリクエストについて提起した懸念のいくつかについて議論しました。 今週の電話会議の議題の下にあるGitHubのコメントで、Kissling氏は、共通の実行レイヤーリクエストの提案された設計の必要性があるかどうか、そしてこの機会を利用して、開発者がMergeのアップグレード以来実行レイヤーで更新したいと思っていたシリアライゼーション形式であるSSZに切り替える方が良いかどうか尋ねました。 電話会議の最長の実行レイヤーのクライアントチームは、EIP 7685をPectraに保持することをサポートし、クライアントの楽観的同期など、EIPを運用に含めることによる障害がある場合は、設計を再検討します。SSZの話題に目を向けると、Kissling氏は、Common Execution Layerリクエストの新しい設計フォーマットは、従来のシリアライゼーションフォーマットMPTとRLPに基づいているため、開発者がSSZに移行するときに更新する必要があると説明した。 彼は、開発者が新しいMPT / RLPデータ構造を作成し続ける場合、SSZへの移行を遅らせることは、開発者にとってより多くのロング作業をもたらすだけだと指摘しています。 ただし、実行クライアントチームから、SSZ安定コンテナであるEIP 7495をPectraに含めるための強力なサポートはありませんでした。 「Dustin」という名前の開発者の1人は、Zoomチャットで、SSZ移行を延期するという決定は「クレイジー」であり、ELでSSZライブラリがうまく機能しないという問題は「深刻な問題」であると書きました。オンチェーンサプライバリデーターの入金であるEIP 6110に関して、Kisslingは入金注文について質問しました。 Kalinin氏は、この問題が「重大な懸念」であることに同意し、主要なステーキングプールと協力してより深く調査すると述べました。### EOF アップデート独立系イーサリアム プロトコル開発者の Danno Ferrin と EF Solidity のリサーチ責任者である Alex Beregszaszi が、EOF の実装作業に関する最新情報を共有します。 背景には、EOFは、開発者がPectraのアップグレードに含めることを検討しているEVM 仮想マシン(EVM)を改善するための一連のコード変更であるということです。 EOFのメタEIPが完成しました。 開発者はまた、EOFでトランザクションを作成するプロセスを簡素化し、EOFのクライアント側の実装に取り組んでいます。### EIP-7623 アップデート電話会議で「William Morris」というスクリーンネームを使用した開発者は、EIP 7623のコールデータストレージのガスコストの変更について懸念を表明しました。 彼は、この変更により、一部のユーザーは手数料を削減するために取引をドロップすることで取引できるようになり、ガス割引の流通市場の創設が促進され、第2層のロールアップ(L2)やその他の参加者がネットワーク上でより安価に取引できるようになると説明しました。 彼は、コールデータコストを定額料金で増やすことでこれらの問題に対処する代替EIPであるEIP 7703を推奨しています。Buterin氏は、Morris氏の懸念は正当なものであるが、EIP 7623の結果としてコールデータの流通市場が創出される可能性は高くなく、そのような市場に参加することを選択したユーザーの数は非常に限られていると述べた。 Buterin氏は、EIP 7623の影響を受ける主なプレーヤーは、レイヤー2開発チームのStarkwareとインスクリプション作成者であると指摘しました。 また、セカンダリーコールデータ市場のアドレス可能な市場規模は小さいものの、開発者がブロブガスの制限を増やし、L2サポート能力を拡張できるため、コールデータによる最大ブロックサイズ制限の上限ポンプ ショートイーサリアム非常に高いと付け加えました。 ヴィタリック氏はまた、モリス氏が示唆したように、通話データのコストを平坦化することは、現在のEIPよりもL2やその他の利害関係者に厳しい影響を与えるだろうと述べた。 Buterinは、電話会議に先立ってブログ投稿でブロブガスの価格設定に関する切望の考えを共有しました。EIP 7623の共著者であるToni WahrstätterはButerinに同意し、ユーティリティの観点から、最長L2はコールデータの流通市場を創出しないと信じていると述べています。 「実際的な観点からは、これはあまり現実的ではありません。特に、このような市場には参加者間の信頼と高度な調整が必要であることを考えると、これはあまり現実的ではありません。 L2 として、データを L1 に公開したいが、どのアドレスがデータを公開し、データがどこに置かれるかわからないとします。 ユーティリティの観点からは、インデックスなどをカスタマイズする必要があります。 ですから、あまり実現可能ではないと思います」とWahrstätter氏は言います。Rethの開発者であるGeorgios Konstantopoulosは、EIP 7623がPectraに含まれている場合、開発者がブロブガスの制限を増やす可能性を検討しているかどうかを尋ねました。 EIP 7623の増加に伴ってブロブガスリミットを増やさなければ、EIPは「問題の切望を解決しない」とコンスタントプロスは言う。 EFの研究者であるDankrad Feistは、イーサリアムの最大ブロックサイズが同じままになるまでブロブガスリミットを上げることを提案しています。 EFの研究者であるAnsgar Dietrichs氏は、EIPはブロブガス制限の増加と組み合わせた場合だけでなく、最大数のトランザクションとブロブを含むブロックによってネットワークが不安定にならないようにするため、セキュリティの観点からも役立つと述べています。EIP 7623がスマートコントラクトとトランザクションに与える影響の分析に関して、Wahrstätter氏は、彼の提案はユーザーの98%に影響を与えないと述べた。 Beiko氏はまた、EFの開発者オペレーションエンジニアであるParithosh Jayanthi氏が、ブロブガスの制限がどの程度具体的であるかについて、アカウント EIP 7623を用いて、より詳細な分析を行う可能性があると述べた。### EIP 7609 の新しい代替品電話会議中に、「Charles C」というスクリーンネームを持つ開発者が、スマートコントラクトでの再入攻撃を防ぐための新しいEIPを提案しました。 チャールズ氏によると、スマートコントラクトを保護するために2つの新しい操作コードを作成するこの提案は、ペクトラのTLOAD / TSTOREの基本コストを削減することを目的としたEIP 7609と呼ばれる以前に提出した提案に代わるものです。 チャールズは、EIP 7609がペクトラで検討されていない理由がわからず、費用対効果の高い方法で再入を防ぐ方法について開発者からのフィードバックを収集していると述べました。 彼は、OpenZeppelinのReentrancy GuardやTLOAD/TSTORE オペレーションコードなどの現在のソリューションは、分散型アプリケーション開発者がデフォルトで使用するには高すぎると指摘しています。 Beikoは、開発者がイーサリアムマジシャンフォーラムでこの新しいEIPについてチャールズにフィードバックを与えることを提案しました。
イーサリアムコア開発者の最新の会議の概要:EIP-7702には疑問が組み込まれており、実行層のシリアライゼーションメソッド変換が組み込まれています
**執筆者: クリスティン・キム
コンピレーション:Luccy、BlockBeats
開発者は、Pectra Devnet 0の長い芯のローソクの準備に加えて、新しいEIPの提案、既存のEIPの議論と分析、スマートコントラクトとトランザクションの影響分析について話し合いました。 その中で、EIP 7702の議論は参加者から多くの注目を集め、この提案はEIP 3074の潜在的な代替品と見なされました。
ギャラクシーデジタルのリサーチ担当VPであるクリスティン・キムは、BlockBeastsが次のようにまとめた会議のハイライトについて詳細なメモを提供しました。
2024 年 5 月 9 日、イーサリアム開発者は、オールコア開発者 (ACDE) コール #187 セッションのために Zoom に集まりました。 ACDE電話会議は、イーサリアム財団のプロトコルサポート責任者であるTim Beikoが率いる隔週の一連の会議で、開発者はイーサリアム実行レイヤー(EL)の変更について話し合い、調整します。 今週、開発者は、Pectra Devnet 0の準備、EIP 3074実装の更新、およびELのシリアライゼーションメソッドをMPTからSSZに変換する緊急性について説明しました。
Pectra Devnet-0 アップデート
イーサリアム財団の開発者オペレーションエンジニアであるBarnabas Busa氏は、彼のチームは最初のPectra開発者に焦点を当てたテストネットネットワークのクライアント構成をテストしており、5月13日月曜日までにPectra Devnet 0の安定した構成を確保するために作業すると述べました。 Pectra Devnet 0 readiness trackerによると、Geth、Nethermind、EthereumJSのクライアントチームは、Pectraのコード仕様を完全に実装しています。
電話会談で、Besuの開発者であるJustine Florentine氏は、すべてのPectra EIPはBesuに実装されているが、彼のチームはまだコードのデバッグに取り組んでいると述べた。 Erigonの開発者であるAndrew Ashikhmin氏は、彼のチームは、ELトリガー可能な引き出しであるEIP 7002を除くすべてのEIPの処理をすでに開始していると述べました。 Reth チームは、Zoom チャットに実装トラッカーへのリンクを投稿し、Erigon チームと同様に EIP 7002 の作業がまだ保留中であることを示しました。
CLクライアント側では、Grandineの開発者であるSaulius Grigatis氏は、すべてのEIPが実装されているが、ELクライアントで実行しているときに、彼のチームはいくつかのバグに遭遇したと述べた。 Lighthouseチームの担当者は、Pectra Devnet 0の完全な実装の準備がほぼ整っていると述べ、エンジンAPIの仕様を更新する必要があると述べました。 Tekuの開発者であるMikhail Kalinin氏は、エンジンAPI仕様にこれらの更新を追加する作業に取り組んでいると述べた。
EFテストチームのMario Vegas氏は、開発者はEIP 3074、AUTHおよびAUTHCALLオペレーションコード、およびその他のいくつかのEIPのテストケースの追加に取り組んでいると述べた。
EIP-3074 アップデート
開発者は EIP 3074 を Pectra Devnet 0 の仕様に保持することに同意しましたが、それに代わる代替の EIP EIP 7702 が議論されています。 Gethの開発者である"Lightclient"は、EIP 3074の最新の分科会を要約し、参加者は、Pectraのアップグレードでどの変更を優先すべきかが、ユーザーコントロールアカウント プログラム可能性の改善に関連しているかについて議論しました。 Lightclientによると、すべての参加者は、完全なネイティブアカウントの抽象化がイーサリアムに実装されるまでまだ数年かかることに同意しました。 ただし、これが外部所有アカウント(EOA)への変更を優先することを意味するのか、EOAをスマートコントラクト ウォレットに移行することを意味するのかについては意見が分かれています。 このACDEコールの前日である5月8日、イーサリアム共同創設者のビタリックブテリンは、イーサリアムが新しいトランザクションタイプサポートて、EOAが単一のトランザクション中にスマートコントラクト ウォレットのように動作できるようにする新しいEIP EIP 7702を提案しました。 Lightclientによると、EIP 3074ブレイクアウトセッションの参加者は、EIP 7702について概ね肯定的でした。 しかし、彼は後に、EIP 7702について解決すべき重要な詳細がまだあると付け加えました。 たとえば、EIP 7702 トランザクションを取り消す方法や、そのようなトランザクションのガス コストをスケーリングする方法の詳細は不明のままです。
EIP 7702が受け入れられ、ペクトラのアップグレードに含まれる場合、EIP 7702はEIP 3074と同様の結果を達成しますが、イーサリアム上に新しいオペレーションコードを作成せず、新しいEOA動作の静的分析の容易さを向上させるため、EIP 3074の代替と見なされます。 EFの研究者であるAnsgar Dietrichsは、Zoomチャットで、EIP 7702をPectraに含めることを検討し、EIP 3074を7702に置き換えるかどうかの正式な決定を約2〜4週間で行う必要があることを提案しました。 電話会議でのEIP 7702に関する開発者の議論から、提案が実装の準備ができていると見なす前に、さらなる作業が必要であることは明らかでした。 Nethermind の開発者である Ahmad Mazen Bitar は、EIP 3074 ですでに行われた作業を 7702 の実装に再利用できない可能性があると述べました。 Beiko氏は、開発者はDevnet 0のEIP 3074の実装を進め、後でDevnet-1仕様を再検討する必要があることを確認した。
EIP-7685、SSZ、および EIP-6110
その後、開発者は、Nimbus開発者のEtan KisslingがEIP 7685、つまり一般的な実行レイヤーリクエストについて提起した懸念のいくつかについて議論しました。 今週の電話会議の議題の下にあるGitHubのコメントで、Kissling氏は、共通の実行レイヤーリクエストの提案された設計の必要性があるかどうか、そしてこの機会を利用して、開発者がMergeのアップグレード以来実行レイヤーで更新したいと思っていたシリアライゼーション形式であるSSZに切り替える方が良いかどうか尋ねました。 電話会議の最長の実行レイヤーのクライアントチームは、EIP 7685をPectraに保持することをサポートし、クライアントの楽観的同期など、EIPを運用に含めることによる障害がある場合は、設計を再検討します。
SSZの話題に目を向けると、Kissling氏は、Common Execution Layerリクエストの新しい設計フォーマットは、従来のシリアライゼーションフォーマットMPTとRLPに基づいているため、開発者がSSZに移行するときに更新する必要があると説明した。 彼は、開発者が新しいMPT / RLPデータ構造を作成し続ける場合、SSZへの移行を遅らせることは、開発者にとってより多くのロング作業をもたらすだけだと指摘しています。 ただし、実行クライアントチームから、SSZ安定コンテナであるEIP 7495をPectraに含めるための強力なサポートはありませんでした。 「Dustin」という名前の開発者の1人は、Zoomチャットで、SSZ移行を延期するという決定は「クレイジー」であり、ELでSSZライブラリがうまく機能しないという問題は「深刻な問題」であると書きました。
オンチェーンサプライバリデーターの入金であるEIP 6110に関して、Kisslingは入金注文について質問しました。 Kalinin氏は、この問題が「重大な懸念」であることに同意し、主要なステーキングプールと協力してより深く調査すると述べました。
EOF アップデート
独立系イーサリアム プロトコル開発者の Danno Ferrin と EF Solidity のリサーチ責任者である Alex Beregszaszi が、EOF の実装作業に関する最新情報を共有します。 背景には、EOFは、開発者がPectraのアップグレードに含めることを検討しているEVM 仮想マシン(EVM)を改善するための一連のコード変更であるということです。 EOFのメタEIPが完成しました。 開発者はまた、EOFでトランザクションを作成するプロセスを簡素化し、EOFのクライアント側の実装に取り組んでいます。
EIP-7623 アップデート
電話会議で「William Morris」というスクリーンネームを使用した開発者は、EIP 7623のコールデータストレージのガスコストの変更について懸念を表明しました。 彼は、この変更により、一部のユーザーは手数料を削減するために取引をドロップすることで取引できるようになり、ガス割引の流通市場の創設が促進され、第2層のロールアップ(L2)やその他の参加者がネットワーク上でより安価に取引できるようになると説明しました。 彼は、コールデータコストを定額料金で増やすことでこれらの問題に対処する代替EIPであるEIP 7703を推奨しています。
Buterin氏は、Morris氏の懸念は正当なものであるが、EIP 7623の結果としてコールデータの流通市場が創出される可能性は高くなく、そのような市場に参加することを選択したユーザーの数は非常に限られていると述べた。 Buterin氏は、EIP 7623の影響を受ける主なプレーヤーは、レイヤー2開発チームのStarkwareとインスクリプション作成者であると指摘しました。 また、セカンダリーコールデータ市場のアドレス可能な市場規模は小さいものの、開発者がブロブガスの制限を増やし、L2サポート能力を拡張できるため、コールデータによる最大ブロックサイズ制限の上限ポンプ ショートイーサリアム非常に高いと付け加えました。 ヴィタリック氏はまた、モリス氏が示唆したように、通話データのコストを平坦化することは、現在のEIPよりもL2やその他の利害関係者に厳しい影響を与えるだろうと述べた。 Buterinは、電話会議に先立ってブログ投稿でブロブガスの価格設定に関する切望の考えを共有しました。
EIP 7623の共著者であるToni WahrstätterはButerinに同意し、ユーティリティの観点から、最長L2はコールデータの流通市場を創出しないと信じていると述べています。 「実際的な観点からは、これはあまり現実的ではありません。特に、このような市場には参加者間の信頼と高度な調整が必要であることを考えると、これはあまり現実的ではありません。 L2 として、データを L1 に公開したいが、どのアドレスがデータを公開し、データがどこに置かれるかわからないとします。 ユーティリティの観点からは、インデックスなどをカスタマイズする必要があります。 ですから、あまり実現可能ではないと思います」とWahrstätter氏は言います。
Rethの開発者であるGeorgios Konstantopoulosは、EIP 7623がPectraに含まれている場合、開発者がブロブガスの制限を増やす可能性を検討しているかどうかを尋ねました。 EIP 7623の増加に伴ってブロブガスリミットを増やさなければ、EIPは「問題の切望を解決しない」とコンスタントプロスは言う。 EFの研究者であるDankrad Feistは、イーサリアムの最大ブロックサイズが同じままになるまでブロブガスリミットを上げることを提案しています。 EFの研究者であるAnsgar Dietrichs氏は、EIPはブロブガス制限の増加と組み合わせた場合だけでなく、最大数のトランザクションとブロブを含むブロックによってネットワークが不安定にならないようにするため、セキュリティの観点からも役立つと述べています。
EIP 7623がスマートコントラクトとトランザクションに与える影響の分析に関して、Wahrstätter氏は、彼の提案はユーザーの98%に影響を与えないと述べた。 Beiko氏はまた、EFの開発者オペレーションエンジニアであるParithosh Jayanthi氏が、ブロブガスの制限がどの程度具体的であるかについて、アカウント EIP 7623を用いて、より詳細な分析を行う可能性があると述べた。
EIP 7609 の新しい代替品
電話会議中に、「Charles C」というスクリーンネームを持つ開発者が、スマートコントラクトでの再入攻撃を防ぐための新しいEIPを提案しました。 チャールズ氏によると、スマートコントラクトを保護するために2つの新しい操作コードを作成するこの提案は、ペクトラのTLOAD / TSTOREの基本コストを削減することを目的としたEIP 7609と呼ばれる以前に提出した提案に代わるものです。 チャールズは、EIP 7609がペクトラで検討されていない理由がわからず、費用対効果の高い方法で再入を防ぐ方法について開発者からのフィードバックを収集していると述べました。 彼は、OpenZeppelinのReentrancy GuardやTLOAD/TSTORE オペレーションコードなどの現在のソリューションは、分散型アプリケーション開発者がデフォルトで使用するには高すぎると指摘しています。 Beikoは、開発者がイーサリアムマジシャンフォーラムでこの新しいEIPについてチャールズにフィードバックを与えることを提案しました。