原題:Ethereum All Core Developers Consensus Call #123 Writeupクリスティン・キムによるオリジナル記事オリジナルコンピレーション:Luccy、BlockBeats**編集部注:**イーサリアム・オール・コア・デベロッパー・コンセンサス・コール(ACDC)は、イーサリアム・コンセンサス・レイヤー(CL)の変更について議論し、調整するために2週間ごとに開催されます。 ACDCの123回目の電話会議は、Cancun/DenebとDevnet #12のテストアップデートの評価と、Devnet #11で浮上したバリデーターの出口問題の解決に焦点を当てました。 さらに、開発者は、ネットワーク仕様の明確化、アップグレード計画プロセス、およびEIPステータスについて詳細な議論を行いました。Cancun/Denebの議論では、開発者は安定性を強調し、Goerliシャドウフォークを開始するかどうかについて議論しました。 しかし、Prysmクライアントはテストの準備ができていなかったため、準備が整うのを待つことにしました。 テストツールとチェーンの再構築に関する議論では、より包括的なテストカバレッジの必要性が強調され、HiveとKurtosisテストスイートの使用に関する推奨事項が示されました。 Beiko氏はEIPステータスとCFIラベルについて懸念を表明しており、開発者はこの問題についてまだ明確なコンセンサスに達していません。Galaxy Digitalのリサーチ担当バイスプレジデントであるChristine Kim氏は、BlockBeastsがまとめた会議の重要なポイントを詳細にメモしました。2023年11月30日、イーサリアム開発者はAll Core Developers Consensus(ACDC)コール#122ミーティングのためにZoomに集まりました。 ACDCの電話会議は、イーサリアム財団の研究者であるダニー・ライアンが司会を務める隔週の一連の会議で、開発者がイーサリアムのコンセンサスレイヤー(CL)の変更について議論し、調整します。 今週、開発者は、次のようなカンクン/デネブテストの最新動向に焦点を当てました。· Devnet #12のローンチ:Devnet #12でのTeku、Lodestar、Lighthouseクライアントソフトウェア、およびすべての実行層(EL)クライアントソフトウェアのテストが進行中です。 Prysmチームは、2〜3週間以内に最新のDevnetでソフトウェアをテストできるようになると予想しています。· Devnet #11 でのバリデーターの終了の問題: Devnet #11 で、開発者はバリデータの終了に関連する問題を特定し、現在 Nimbus クライアント チームによって解決されています。 Devnet #11 は、問題が解決されるまで正常に機能し続けます。· ネットワーク仕様の明確化: 開発者は、"BlockByRoot" と "BlobSidecarsByRoot" 要求の仕様を明確にし、コンセンサス層 (CL) ノードがこれらの要求に特定の順序で応答する必要があるかどうかを明確にすることについて議論しました。カンクン/デネブのアップデートに加えて、開発者は、イーサリアムのアップグレードの調整を改善するために、イーサリアム財団のプロトコルサポート責任者であるティム・ベイコによって提起されたプロセスの問題のいくつかについて議論しました。### デブネット #122023 年 11 月 30 日 (水) に、カンクン/デネブのアップグレードが Devnet #12 で正式に開始されました。 イーサリアム財団のテストチームのマリオ・ベガ氏は、現在テストネット上で稼働している3つのCLクライアントについて、「これまでのところ大きな問題は確認されていない」と述べています。 FoundationのDevOpsエンジニアであるBarnabas Busa氏は、Lighthouse、Teku、Lodestarの3つのノードに合計225人のバリデーターが分散していると述べました。 Devnet #12の安定性のため、FoundationのDevOpsエンジニアであるParithosh Jayanthi氏は、Cancun/DenebをさらにテストするためにGoerliシャドウフォークの計画を開始する必要があるかどうかを開発者に尋ねました。 しかし、現時点で最も人気のあるCLクライアントであるPrysmがまだDevnet #12に参加していないことを考慮し、開発者はPrysmクライアントソフトウェアのテスト準備が整うまで、Goerliシャドウフォークの計画を保留にすることを決定しました。 ベイコは、年末までにゴエルリの影の分岐点に移動することを提案しています。 Devnet #12 の安定性のため、Prysm クライアント ソフトウェアのテスト準備が整うまで、計画は保留されます。### デブネット #11「Dustin」というスクリーンネームで呼ばれるNimbus開発者は、彼のチームが取り組んでいるDevnet #11の問題の詳細を共有しています。 これらの問題は、開発者が Devnet #11 のバリデータの 3 分の 1 を終了して Devnet #12 で使用しようとしたときに最初に発見されました。 Ryan は Dustin に、追加のテストでこれらの問題を特定できないかと尋ねます。 Dustin氏は、彼の意見では、これらのエラーの性質は、コンセンサス仕様の範囲外の実装の詳細によって引き起こされたと答えた。 しかし、彼はまた、カバレッジの利点をテストするためにクライアントソフトウェアをCL仕様に厳密に記述することと、より良いノードパフォーマンスを達成するために仕様のグレーゾーンに踏み込むことの間には「明確な緊張関係」があることも認めています。「テストの数を増やすことには大切ですが、HiveやKurtosisなど、より多くのクライアント側の機能をテストの実行に組み込む方法をより体系的に考え出すことは、おそらくより自動化されるでしょう。 これらの問題を解決したり、物事をうまく分解して、これらのタスクをもっと組み込めるようになれば、確かに役立つと思います」とDustin氏は付け加え、CL開発者が対処することを検討すべきもう一つの課題は、CL仕様がノードの動作を指示し、標準化すべき詳細レベルを把握することであると付け加えました。 「ここでのもう一つの課題は、標準化の度合いです。これはソフトウェアエンジニアリングだけの問題ではなく、動作をどの程度標準化すべきかということです」 ダスティンは尋ねた。 すべての CL クライアントは、基本的な動作を検査するテストに合格しますが、これらのテストの範囲外の動作はあいまいです。 「これらは意図的に曖昧なものなのでしょうか? 何が規範によって本当に明確で、何が意図的に曖昧にされるべきか?」 ダスティンは尋ねた。少なくとも、開発者は、カンクン/デネブの多数のバリデーター出口のために、将来のDevnetとテストネットにさらにテストを追加することに同意しました。 また、Ryan氏は、CLクライアントとCL仕様の実装に関して、より厳密で包括的なテストカバレッジの余地があることを認めています。 Vega氏は、Dustin氏に、懸念事項を詳述したHackMDの投稿を作成し、次回のCancun/Denebテストコールでそのトピックについて話し合うことを提案した。 Jayanthi氏は、Cancun/Deneb Devnetsで最近特定されたいくつかの問題に基づいて、ETHの出金、バリデーターの出金など、一定数のオンチェーン統合関連の行動を体系的に実行できるツールを開発者が必要とすることは明らかであると付け加えました。 そのために、Jayanthi氏は、HiveとKurtosisのテストスイートを組み合わせて、このようなツールを構築することを推奨しています。Cancun/Denebアップグレードのための新しいテストツールについて、Jayanthi氏は、開発者がDevnetとテストネットでチェーンの再結合を確実に活性化するためのツールに取り組んでいると述べた。 このツールが確実に機能するように、Jayanthi氏は開発者に、イーサリアムのチェーン再編成を引き起こした既知のバグの詳細を共有するよう求めました。 Jayanthi氏は、これらのバグを使ってツールをテストし、再編成がいつ発生し、いつ解決されるかを確実に識別できることを確認すると説明しました。### ネットワーク仕様の明確化開発者は、イーサリアム財団の研究者であるJustin Traglia氏が提案した、CLクライアントが「BlockbyRoot」または「BlobSidecarsByRoot」リクエストを受け取ったときに返すべき応答の順序について簡単に説明しました。 Ryan は、さまざまな CL クライアント チームがこの機能をどのように実装しているかを尋ねます。 電話会議に出た開発者は誰もこの質問に答えませんでした。 ライアンは、イーサリアムの研究開発Discordチャンネルでの議論を復活させ、より幅広いクライアント開発者を巻き込むことを提案しました。 Ryan氏は、2つのリクエストの仕様に曖昧さがあり、それが「問題や奇妙なエッジケースの原因である可能性がある」ことを認めており、「明確化して整理するに値する」と断言しています。Ryan氏はまた、今後数日中にCL仕様の新しいバージョンをリリースすると述べた。 最新バージョンでは、CLクライアントが「byRoot」RPCリクエストを介してブロックとブロックを提供できる場合の仕様が大幅に追加されています。 「byRoot」RPCリクエストを介して欠落しているブロックとブロックを取得する説明の背景については、以前の呼び出しログを参照してください。 Ryan氏は、最新バージョンに含まれるCL仕様への新たな追加は、Devnet #11または#12ですでに実行されているバリデータのコードに影響を与えるコードへの破壊的変更ではないことを強調している。### アップグレード計画プロセス次に、Beikoが提案するさまざまなプロセス項目について、開発者が議論しました。 Beiko氏によると、Goerliでカンクン/デネブのアップグレードが有効化されてから3か月以内、またはイーサリアムメインネットでアップグレードが有効化されてから1か月以内のいずれか遅い方で、Goerliテストネットユーザーに差し迫った廃止について警告するブログ記事が、11月30日にEthereum Foundationのブログで公開される予定だという。 電話会議の終了後、上記のブログ記事が公開され、ここで読むことができます。Beikoは、イーサリアムの「pm」リポジトリの下にアップグレード専用のフォルダを作成し、特定のアップグレードに関連するさまざまなファイルを1つのフォルダに整理して、後で使用することを提案しています。 電話会議の開発者は、Beikoの提案に同意しました。Beiko氏が提案する2つ目のプロセス項目は、イーサリアム上で完了したネットワークアップグレードの全容を追跡するための「Meta EIP」文書の作成に関するものです。 「ネットワークのアップグレードをデプロイしてブログ記事で発表する前に、その全容を追跡するのに適した場所はありません」と、Beiko氏はMetaのEIP提案に関する投稿に書いています。 「Dencunでは、EL EIPが見つけにくいマークダウンファイル7にあり、CL EIPはBeacon Chain Specification 3の一部です。 どちらも見つけるのが少し難しく、異なる「形式」を使用しており、重複につながるため、これはあまり良くありません。 ERCとEIPは分離されたため、Meta EIPを使用してネットワークアップグレードに含まれるEIPを追跡することをお勧めします。 開発者は、これらのドキュメントの作成に賛成していました。 ベイコ氏は、今週、カンクン/デネブのアップグレードレビューのための文書を起草すると述べた。最後に、Beiko氏は、提案されたコード変更であるEthereum Improvement Proposals(EIP)を「Consider Inclusion」(CFI)とマークすることの有用性について疑問を呈しました。 Beiko氏によると、CFIは開発者が歴史的に「ソフトシグナル」として使用してきたステータスであり、EIPの作成者は将来のハードフォークに含まれる可能性のある提案に取り組み続ける必要があることを示しています。 これは、ELに重点を置いたコードの変更とアップグレードにのみ使用されます。 「[CFI] 無作為な人々からの無作為なアイデアよりも高いが、フォークで受け入れられる前に」とBeikoは言った。これまで、CFIのラベル付けは、ELのどのEIPがアップグレードで実装されるか、またはいつ実装されるかを示すのにほとんどまたはまったく努力していませんでした。 これは、さまざまなレベルのコード準備とクライアントチームからのサポートを備えた幅広いEIPに適用されています。 EVM Object Format (EOF) の提案の場合、開発者はこのタグを使用して、次のアップグレードである Cancun/Deneb で EOF を実装するというコミットメントを示します。 しかし、EOFやCFIとしてフラグが立てられている他のいくつかの提案は、カンクン/デネブから拒否されており、次のアップグレードプラハ/エレクトラでCFIとしてフラグが立てられたこれらのEIPのステータスは不明です。Beiko氏は、この状態が役に立たないのであれば、開発者はそれを削除すべきだが、もしそれを維持するつもりなら、CL開発者はCLアップグレードで実装することを検討しているコード変更にも同じラベルを使うべきだと述べた。 CL EIPのレビュープロセスがEL EIPのレビュープロセスをどの程度反映しているか、また、将来的に同じように進化する必要があるかどうかは不明です。 通常、CL仕様のコード変更案はACDC電話会議で議論され、EL仕様のEIP案はACDE電話会議で議論されます。また、Swirlds LabsのDanno Ferrin氏は、CL関連かEL関連かにかかわらず、CFIステータスを含むレビュープロセス中のステータスを識別するすべてのEIPのプレースホルダーフィールドを作成するというアイデアを思いつきました。 この電話会議では、EIPステータスとCFIラベリングのトピックに関する明確な決定はありませんでした。
最新のイーサリアムコア開発者会議の概要:Devnet 12のローンチ、アップグレード計画プロセス
原題:Ethereum All Core Developers Consensus Call #123 Writeup
クリスティン・キムによるオリジナル記事
オリジナルコンピレーション:Luccy、BlockBeats
編集部注:
イーサリアム・オール・コア・デベロッパー・コンセンサス・コール(ACDC)は、イーサリアム・コンセンサス・レイヤー(CL)の変更について議論し、調整するために2週間ごとに開催されます。 ACDCの123回目の電話会議は、Cancun/DenebとDevnet #12のテストアップデートの評価と、Devnet #11で浮上したバリデーターの出口問題の解決に焦点を当てました。 さらに、開発者は、ネットワーク仕様の明確化、アップグレード計画プロセス、およびEIPステータスについて詳細な議論を行いました。
Cancun/Denebの議論では、開発者は安定性を強調し、Goerliシャドウフォークを開始するかどうかについて議論しました。 しかし、Prysmクライアントはテストの準備ができていなかったため、準備が整うのを待つことにしました。 テストツールとチェーンの再構築に関する議論では、より包括的なテストカバレッジの必要性が強調され、HiveとKurtosisテストスイートの使用に関する推奨事項が示されました。 Beiko氏はEIPステータスとCFIラベルについて懸念を表明しており、開発者はこの問題についてまだ明確なコンセンサスに達していません。
Galaxy Digitalのリサーチ担当バイスプレジデントであるChristine Kim氏は、BlockBeastsがまとめた会議の重要なポイントを詳細にメモしました。
2023年11月30日、イーサリアム開発者はAll Core Developers Consensus(ACDC)コール#122ミーティングのためにZoomに集まりました。 ACDCの電話会議は、イーサリアム財団の研究者であるダニー・ライアンが司会を務める隔週の一連の会議で、開発者がイーサリアムのコンセンサスレイヤー(CL)の変更について議論し、調整します。 今週、開発者は、次のようなカンクン/デネブテストの最新動向に焦点を当てました。
· Devnet #12のローンチ:Devnet #12でのTeku、Lodestar、Lighthouseクライアントソフトウェア、およびすべての実行層(EL)クライアントソフトウェアのテストが進行中です。 Prysmチームは、2〜3週間以内に最新のDevnetでソフトウェアをテストできるようになると予想しています。
· Devnet #11 でのバリデーターの終了の問題: Devnet #11 で、開発者はバリデータの終了に関連する問題を特定し、現在 Nimbus クライアント チームによって解決されています。 Devnet #11 は、問題が解決されるまで正常に機能し続けます。
· ネットワーク仕様の明確化: 開発者は、“BlockByRoot” と “BlobSidecarsByRoot” 要求の仕様を明確にし、コンセンサス層 (CL) ノードがこれらの要求に特定の順序で応答する必要があるかどうかを明確にすることについて議論しました。
カンクン/デネブのアップデートに加えて、開発者は、イーサリアムのアップグレードの調整を改善するために、イーサリアム財団のプロトコルサポート責任者であるティム・ベイコによって提起されたプロセスの問題のいくつかについて議論しました。
デブネット #12
2023 年 11 月 30 日 (水) に、カンクン/デネブのアップグレードが Devnet #12 で正式に開始されました。 イーサリアム財団のテストチームのマリオ・ベガ氏は、現在テストネット上で稼働している3つのCLクライアントについて、「これまでのところ大きな問題は確認されていない」と述べています。 FoundationのDevOpsエンジニアであるBarnabas Busa氏は、Lighthouse、Teku、Lodestarの3つのノードに合計225人のバリデーターが分散していると述べました。 Devnet #12の安定性のため、FoundationのDevOpsエンジニアであるParithosh Jayanthi氏は、Cancun/DenebをさらにテストするためにGoerliシャドウフォークの計画を開始する必要があるかどうかを開発者に尋ねました。 しかし、現時点で最も人気のあるCLクライアントであるPrysmがまだDevnet #12に参加していないことを考慮し、開発者はPrysmクライアントソフトウェアのテスト準備が整うまで、Goerliシャドウフォークの計画を保留にすることを決定しました。 ベイコは、年末までにゴエルリの影の分岐点に移動することを提案しています。 Devnet #12 の安定性のため、Prysm クライアント ソフトウェアのテスト準備が整うまで、計画は保留されます。
デブネット #11
「Dustin」というスクリーンネームで呼ばれるNimbus開発者は、彼のチームが取り組んでいるDevnet #11の問題の詳細を共有しています。 これらの問題は、開発者が Devnet #11 のバリデータの 3 分の 1 を終了して Devnet #12 で使用しようとしたときに最初に発見されました。 Ryan は Dustin に、追加のテストでこれらの問題を特定できないかと尋ねます。 Dustin氏は、彼の意見では、これらのエラーの性質は、コンセンサス仕様の範囲外の実装の詳細によって引き起こされたと答えた。 しかし、彼はまた、カバレッジの利点をテストするためにクライアントソフトウェアをCL仕様に厳密に記述することと、より良いノードパフォーマンスを達成するために仕様のグレーゾーンに踏み込むことの間には「明確な緊張関係」があることも認めています。
「テストの数を増やすことには大切ですが、HiveやKurtosisなど、より多くのクライアント側の機能をテストの実行に組み込む方法をより体系的に考え出すことは、おそらくより自動化されるでしょう。 これらの問題を解決したり、物事をうまく分解して、これらのタスクをもっと組み込めるようになれば、確かに役立つと思います」とDustin氏は付け加え、CL開発者が対処することを検討すべきもう一つの課題は、CL仕様がノードの動作を指示し、標準化すべき詳細レベルを把握することであると付け加えました。 「ここでのもう一つの課題は、標準化の度合いです。これはソフトウェアエンジニアリングだけの問題ではなく、動作をどの程度標準化すべきかということです」 ダスティンは尋ねた。 すべての CL クライアントは、基本的な動作を検査するテストに合格しますが、これらのテストの範囲外の動作はあいまいです。 「これらは意図的に曖昧なものなのでしょうか? 何が規範によって本当に明確で、何が意図的に曖昧にされるべきか?」 ダスティンは尋ねた。
少なくとも、開発者は、カンクン/デネブの多数のバリデーター出口のために、将来のDevnetとテストネットにさらにテストを追加することに同意しました。 また、Ryan氏は、CLクライアントとCL仕様の実装に関して、より厳密で包括的なテストカバレッジの余地があることを認めています。 Vega氏は、Dustin氏に、懸念事項を詳述したHackMDの投稿を作成し、次回のCancun/Denebテストコールでそのトピックについて話し合うことを提案した。 Jayanthi氏は、Cancun/Deneb Devnetsで最近特定されたいくつかの問題に基づいて、ETHの出金、バリデーターの出金など、一定数のオンチェーン統合関連の行動を体系的に実行できるツールを開発者が必要とすることは明らかであると付け加えました。 そのために、Jayanthi氏は、HiveとKurtosisのテストスイートを組み合わせて、このようなツールを構築することを推奨しています。
Cancun/Denebアップグレードのための新しいテストツールについて、Jayanthi氏は、開発者がDevnetとテストネットでチェーンの再結合を確実に活性化するためのツールに取り組んでいると述べた。 このツールが確実に機能するように、Jayanthi氏は開発者に、イーサリアムのチェーン再編成を引き起こした既知のバグの詳細を共有するよう求めました。 Jayanthi氏は、これらのバグを使ってツールをテストし、再編成がいつ発生し、いつ解決されるかを確実に識別できることを確認すると説明しました。
ネットワーク仕様の明確化
開発者は、イーサリアム財団の研究者であるJustin Traglia氏が提案した、CLクライアントが「BlockbyRoot」または「BlobSidecarsByRoot」リクエストを受け取ったときに返すべき応答の順序について簡単に説明しました。 Ryan は、さまざまな CL クライアント チームがこの機能をどのように実装しているかを尋ねます。 電話会議に出た開発者は誰もこの質問に答えませんでした。 ライアンは、イーサリアムの研究開発Discordチャンネルでの議論を復活させ、より幅広いクライアント開発者を巻き込むことを提案しました。 Ryan氏は、2つのリクエストの仕様に曖昧さがあり、それが「問題や奇妙なエッジケースの原因である可能性がある」ことを認めており、「明確化して整理するに値する」と断言しています。
Ryan氏はまた、今後数日中にCL仕様の新しいバージョンをリリースすると述べた。 最新バージョンでは、CLクライアントが「byRoot」RPCリクエストを介してブロックとブロックを提供できる場合の仕様が大幅に追加されています。 「byRoot」RPCリクエストを介して欠落しているブロックとブロックを取得する説明の背景については、以前の呼び出しログを参照してください。 Ryan氏は、最新バージョンに含まれるCL仕様への新たな追加は、Devnet #11または#12ですでに実行されているバリデータのコードに影響を与えるコードへの破壊的変更ではないことを強調している。
アップグレード計画プロセス
次に、Beikoが提案するさまざまなプロセス項目について、開発者が議論しました。 Beiko氏によると、Goerliでカンクン/デネブのアップグレードが有効化されてから3か月以内、またはイーサリアムメインネットでアップグレードが有効化されてから1か月以内のいずれか遅い方で、Goerliテストネットユーザーに差し迫った廃止について警告するブログ記事が、11月30日にEthereum Foundationのブログで公開される予定だという。 電話会議の終了後、上記のブログ記事が公開され、ここで読むことができます。
Beikoは、イーサリアムの「pm」リポジトリの下にアップグレード専用のフォルダを作成し、特定のアップグレードに関連するさまざまなファイルを1つのフォルダに整理して、後で使用することを提案しています。 電話会議の開発者は、Beikoの提案に同意しました。
Beiko氏が提案する2つ目のプロセス項目は、イーサリアム上で完了したネットワークアップグレードの全容を追跡するための「Meta EIP」文書の作成に関するものです。 「ネットワークのアップグレードをデプロイしてブログ記事で発表する前に、その全容を追跡するのに適した場所はありません」と、Beiko氏はMetaのEIP提案に関する投稿に書いています。 「Dencunでは、EL EIPが見つけにくいマークダウンファイル7にあり、CL EIPはBeacon Chain Specification 3の一部です。 どちらも見つけるのが少し難しく、異なる「形式」を使用しており、重複につながるため、これはあまり良くありません。 ERCとEIPは分離されたため、Meta EIPを使用してネットワークアップグレードに含まれるEIPを追跡することをお勧めします。 開発者は、これらのドキュメントの作成に賛成していました。 ベイコ氏は、今週、カンクン/デネブのアップグレードレビューのための文書を起草すると述べた。
最後に、Beiko氏は、提案されたコード変更であるEthereum Improvement Proposals(EIP)を「Consider Inclusion」(CFI)とマークすることの有用性について疑問を呈しました。 Beiko氏によると、CFIは開発者が歴史的に「ソフトシグナル」として使用してきたステータスであり、EIPの作成者は将来のハードフォークに含まれる可能性のある提案に取り組み続ける必要があることを示しています。 これは、ELに重点を置いたコードの変更とアップグレードにのみ使用されます。 「[CFI] 無作為な人々からの無作為なアイデアよりも高いが、フォークで受け入れられる前に」とBeikoは言った。
これまで、CFIのラベル付けは、ELのどのEIPがアップグレードで実装されるか、またはいつ実装されるかを示すのにほとんどまたはまったく努力していませんでした。 これは、さまざまなレベルのコード準備とクライアントチームからのサポートを備えた幅広いEIPに適用されています。 EVM Object Format (EOF) の提案の場合、開発者はこのタグを使用して、次のアップグレードである Cancun/Deneb で EOF を実装するというコミットメントを示します。 しかし、EOFやCFIとしてフラグが立てられている他のいくつかの提案は、カンクン/デネブから拒否されており、次のアップグレードプラハ/エレクトラでCFIとしてフラグが立てられたこれらのEIPのステータスは不明です。
Beiko氏は、この状態が役に立たないのであれば、開発者はそれを削除すべきだが、もしそれを維持するつもりなら、CL開発者はCLアップグレードで実装することを検討しているコード変更にも同じラベルを使うべきだと述べた。 CL EIPのレビュープロセスがEL EIPのレビュープロセスをどの程度反映しているか、また、将来的に同じように進化する必要があるかどうかは不明です。 通常、CL仕様のコード変更案はACDC電話会議で議論され、EL仕様のEIP案はACDE電話会議で議論されます。
また、Swirlds LabsのDanno Ferrin氏は、CL関連かEL関連かにかかわらず、CFIステータスを含むレビュープロセス中のステータスを識別するすべてのEIPのプレースホルダーフィールドを作成するというアイデアを思いつきました。 この電話会議では、EIPステータスとCFIラベリングのトピックに関する明確な決定はありませんでした。