Author: Christine Kim, VP of Galaxy Digital's Research Team Translated by Good Oba, Golden Finance
2024 2月28日、イーサ開発者はZoom経由で第182回全コア開発者（ACD）カンファレンスを開催した。align: left;">2024年2月28日、Ether Developersは第182回All Core Developer (ACDE) カンファレンスコールをZoom経由で開催しました。 ACDEカンファレンスコールは、イーサネット・エグゼクティブ・レイヤ（EL）の変更について議論し、調整するための開発者向け隔週ミーティングシリーズです。 今週の会議は、イーサネット財団（EF）の研究者であるダニー・ライアンがホストを務めた。 開発者たちは、Dencunアップグレードのベータ版アップデートと、PectraのEIP候補について議論した。 Pectraに含めることが提案されたEIPの中で最も話題になったのは、アカウントの抽象化に関連するコードの変更に関するものだ。 アカウント抽象化（AA）は、スマートコントラクトのコードではなく、ユーザーがイーサ上で管理するアカウントである外部所有アカウント（EOA）に対して、より高度なプログラム可能性を導入することを目的としています。
Dencunアップデート
イーサネット財団のDevOpsエンジニアであるBarnabas Busa氏は、Dencunアップグレードの最終テストに関するアップデートを共有しました。テストの更新 イーサネット財団は2月27日（火）、アップグレードがメイン・イーサネット・ネットワーク上で2024年3月13日に正式にアクティベートされる予定であることを発表しました。 先週のACDカンファレンスコールで議論されたように、開発者はメインネットシャドーフォーク（メインイーサネット上のブロックチェーンの状態とアクティビティをミラーリングするテストネットワーク）上でクライアントソフトウェアの最終バージョンをテストしています。 ブサ氏によると、開発者はメインネットのシャドーフォークでさまざまな種類の「スパムテスト」を実施しているという。 これらのテスト中、ノードは非常に安定しており、ネットワークの参加率は100％に近い状態を維持している。 問題はありませんでしたが、Busa氏はスパムテストがコンピュータリソース、特にメモリとCPUの使用率という点でノードに大きな影響を与えたと指摘しました。
その後ブサ氏は、Goerliテストネットがまもなく廃止されることを参加者に告げました。 このテストネットを使用している人は、4月17日までに他のイーサリアムのテストネットに移行する必要があります。 Busa氏は、Goerliの大規模なバリデータノード運用者の一部がマシンを引退したことに気づいたと述べた。 このため2月28日のGoerliのネットワーク最終化は遅れたが、Goerliネットワークは回復したようだ。 ライアンは、Goerliのネットワーク参加率はかなり低く、70％前後で推移していると指摘した。 「参加率が）4月17日まで続くとは正直思っていない」とブサは言う。 「しかし、それでも懸念すべきことだ。
ブサは、クライアント側のチームがDencunのアップグレード実装をテストするために、昨年11月に開始された専用のテストネットワークであるDevnet 12をいつ停止すべきかをチームに尋ねた。 Dencun 用のクライアント側のリリースを土壇場でテストする必要があった場合に備えて、開発者たちは、Dencun アップグレードがメインの EtherNet で稼動した直後に Devnet 12 を停止することに合意しました。
Pectra アップグレードのための EIP のレトロスペクティブ
次に、ペクトラ・アップグレードのための2つのレトロスペクティブ・イーサネット改善提案 (EIP) について説明します。 レトロスペクティブEIPは、Etherプロトコルに制約を追加するコード変更で、その大部分はすでに存在していますが、特定のエッジケースに対処するために明確化が必要です。 最初のレトロスペクティブEIPであるEIP 7610は、スマートコントラクトの作成を既存のストレージを持つアドレスに制限するルールを拡張します。 このコード変更の背景については、前回の議事録をご覧ください。
EIP 7610に関する懸念の1つは、ペクトラ後のアップグレードのために開発者が準備しているコード変更であるVerkleに影響するかどうかです。 Gethの開発者であるGary Rong氏は、EIP 7610が今後のVerkleのアップグレードにどのような問題をもたらさないかを説明している。 Hedera Hashgraph Engineer兼Besu Client MaintainerのDanno Ferrinは、EIP 7610がVerkleにどのような影響を与えるかについて、いくつかの未解決の懸念を提起し、それをEther Improvement Proposal 7610 "Ether Magician "ディスカッションボードで共有すると述べた。Ether Magician" 掲示板の Ether Improvement Proposal 7610.
開発者によって議論された2つ目の遡及的EIPはEIP 7523で、これは空のアカウントがEtherとEther Test Networkの状態に現れることを正式に禁止するものです。 Ryanは、どのEtherNetネットワーク (メインまたはテスト) 上のアカウントもこのルールの実施によって影響を受けないことを確認するために、誰が分析を行っているかを再確認し、次回のACDEカンファレンスコールでこの問題を再検討すると述べました。
Account Abstraction EIP for Pectra
次に、開発者は Pectra に含まれる可能性のあるアカウント抽象化 EIP について議論しました。 2 月 28 日、開発者のサブセットは専用の AA 会議に参加しました。AAの目標について、Etherの共同創設者であるVitalik Buterin氏は次のように述べています。量子コンピューティングに抵抗できるように、一方では鍵のローテーションを可能にし、他方では鍵の破棄を可能にする。 第三に、バッチ処理を可能にすること......そして[そして]スポンサー取引を可能にすること、その他多くの小さな機能、もちろん最初の2つの目標はEOAでは明らかに達成できません。これらの目標を達成するための実際の手段や、より明確でない具体的な内容、そして短期的に人々が望む利益を提供することができ、同時に長期的な（目標と）両立することができる短期的なロードマップが実際にどのようなものであるかに議論が移ります。"
短期的には、開発者は3つの主要なAA EIP、EIP 3074、5806、7377を評価しています。 コールに参加した開発者は、EIP 3074と5806の長所と短所について意見が分かれました。 争点の1つは、EIP 3074がトランザクションの二重署名をユーザーに要求し、分散型トランザクションの開始をプロトコル外のAA標準ERC 4337に依存する程度であり、5806と比較したEIP 3074の相対的な複雑性とセキュリティに関する他の議論もあった。 EIP 7377は、ユースケースの点で他の2つのAA EIPと直交しているため、開発者は一般的に最も議論の少ないAA EIPとみなしている。 EIP 7377は、ユーザーが資産をイーサ口座から新しいスマートコントラクトウォレットに簡単に移行できるように設計されていますが、他の2つのEIPは主に、一括取引承認とガス料金スポンサーシップをサポートする新しいAA機能を作成することに重点を置いています。
開発者たちはこれら3つのEIPについて合意に至らず、今後数週間で議論を続けることで合意しました。
ペクトラの他のEIP提案
アカウント抽象化EIPに加えて、開発者はペクトラのアップグレードに含めるよう提案された他のいくつかのEIPについて簡単に議論しました:
EIP 7623: calldata gas costsの増加: この提案は、主にデータの可用性のために使用されるイーサ上の通常のトランザクションのコストの増加を提案しています。イーサ上のcalldataガスのコストを調整することで、このEIPは1ブロックに合理的に収まるコールデータトランザクションの数を減らし、それによって最大ブロックサイズを縮小する。 ブロックサイズを小さくすることで、より多くのブロブトランザクションが可能になる。
EIP 2537: BLS12-381 Curve Arithmetic Pre-compilation: この提案はイーサリアムに新しい暗号署名スキームを導入するもので、ペクトラのアップグレードに含めることが承認されています。. この提案の著者の一人であるAntonio Sanso氏は、この提案の実装についていくつかの疑問を提起しました。 ダニー・ライアンは、その質問を文書化し、コール外で開発者に配布してさらに議論することを提案した。
EIP5920：PAYオペコード：この提案は、ユーザーがアドレスの機能をトリガーすることなく、アドレスにETHを送ることを可能にする新しい操作を作成します。 Gethの開発者であるMarius van der Wijden氏は、他のチームとEIPについてさらに議論した結果、この提案のテストは予想以上に複雑だったと述べた。 また、Van der Wijden氏は、提案の仕様がまだ完成していないことも指摘した。 フェリンは、PAYオペコードは現在、別のオペコード（AUTHオペコード）と同じコード番号が割り当てられており、その作者によって修正される必要があると付け加えた。
EIP7609：一時ストレージの価格低減：この提案は、再入可能なログの維持など、スマートコントラクトの一般的なユースケースについて、一時ストレージオプコードの価格を低減することを提案しています。 Van der WijdenとRyanの両氏は、Dencunのアップグレードが本稼働したら、一時ストレージオプコードの価格を再検討する前に、一時ストレージオプコードがどのように使用されているかデータを収集することに同意しました。
EIP 7639: Proof of Equityの前に履歴データの提供を中止する: この提案は、実行レイヤー（EL）クライアントが合併アップグレードの前に履歴データの提供を中止するためのタイムラインを確立します。 このコード変更の動機は、イーサネット・ノードが永続的に保存する必要のあるデータ量を削減することである。 この提案はまた、ノードが標準化された方法で合併前の履歴データを構築し、外部ソースから取得することを約束するものでもある。 Tekuの開発者であるMikhail Kalinin氏は、このEIPが別のEIP（EIP 6110）に依存していることを指摘した。
Engine API および JSON RPC の変更
EtherCore 開発者は、上記のトピックに加えて、エンジン API および JSON RPC の変更についても議論しました。は、エンジン API と JSON RPC の変更についても説明しました。
Tekuの開発者であるMikhail Kalinin氏は、特定の仮定の下でブロックが正規のチェーンに留まるかどうかを確認し、約12秒（1スロット）でそれを確定するCLメカニズムである、確認ルールの実装に関する多くの問題を提起しました。 これは強力な機能であり、イーサ上に構築された多くのアプリケーションは、初期ブロックによって確認された情報で動作することができる。 しかし、早期ブロック確認に関するデータを一般公開するには、イーサネット・エンジンAPIとJSON RPCに変更を加える必要がある。 通話時間の制約があるため、Ryanは来週または再来週のACDカンファレンスコールで、これらの変更についてより詳細に議論することを提案しています。
ライト クライアントのブレイクアウト ルーム セッション
Ryanは、来週の水曜日（3月6日）に、Pectraアップグレード ライト クライアントのロードマップについて話し合う専用のセッションがあることを開発者に思い出させました。のロードマップについて話し合います。 ライトクライアントに関する議論の背景情報については、前回のミーティングノートを参照してください。
Etherクライアントの新バージョンの提案
最後に、van der Wijdenは、初期同期時にノードが使用する550GBの帯域幅を節約するために、Etherクライアントの新バージョンを構築する提案を行いました。初期同期時の550GBの帯域幅。 Van der Wijdenは、新バージョンの正式なEIPを準備中であることを示しましたが、仕様のドラフトはここにあります。 Ryan氏は開発者にドラフトをチェックし、質問があればDiscordで質問するよう勧めている。
JinseFinance
