原題:Ethereum All Core Developers Consensus Call #123 Writeupクリスティン・キムによるオリジナル記事オリジナルコンピレーション:Luccy、BlockBeats**編集部注:**ETH Workshop All Core Developer Consensus Calls (ACDC) は隔週で開催され、ETH Workshop の Consensus Layer (CL) の変更について議論し、調整します。 これはACDCの123回目の電話会議であり、Cancun/DenebとDevnet #12のテストアップデートの評価と、Devnet #11で浮上したバリデーターの出口問題の解決に焦点を当てました。 さらに、開発者は、ネットワーク仕様の明確化、アップグレード計画プロセス、およびEIPステータスについて詳細な議論を行いました。Cancun/Denebの議論の中で、開発者は安定性を強調し、Goerliシャドウフォークを開始するかどうかについて議論しました。 しかし、Prysmクライアントはテストの準備ができていなかったため、準備が整うのを待つことにしました。 テストツールとチェーンの再構築に関する議論では、より包括的なテストカバレッジの必要性が強調され、HiveおよびKurtosisテストスイートの使用に関する推奨事項が作成されました。 EIPステータスとCFIラベルの問題について、Beikoはこれらのタグを保持すべきかどうかについて懸念を表明し、開発者はまだこの問題について明確なコンセンサスに達していません。Galaxy DigitalのリサーチVPであるChristine Kim氏は、BlockBeastsがまとめた会議のハイライトについて詳細にメモしました。2023 年 11 月 30 日、ETH 開発者が Zoom に集まり、All Core Developers Consensus (ACDC) コール #122 セッションを開催しました。 ACDCの電話会議は、ETH Workshop Foundationの研究者であるDanny Ryan氏が主導する隔週の一連の会議で、開発者がETH Workshop Consensus Layer(CL)の変更について議論し、調整します。 今週、開発者はカンクン/デネブテストの最新動向に焦点を当てました。· Devnet #12のローンチ:Devnet #12では、Teku、Lodestar、Lighthouseのクライアントソフトウェア、およびすべての実行レイヤー(EL)クライアントソフトウェアのテストが進行中です。 Prysmチームは、2〜3週間以内に最新のDevnetでソフトウェアをテストできるようになると予想しています。· Devnet #11 でのバリデーター終了の問題: Devnet #11 で、開発者はバリデーターの終了に関連する問題を特定し、現在 Nimbus クライアント チームによって解決されています。 Devnet #11 は、問題が解決されるまで正常に機能し続けます。· ネットワーク仕様の明確化: 開発者は、"BlockByRoot" と "BlobSidecarsByRoot" 要求の仕様を明確にし、コンセンサス層 (CL) ノードがこれらの要求に特定の順序で応答する必要があるかどうかを明確にすることについて議論しました。カンクン/デネブのアップデートに加えて、開発者は、ETH Foundationのプロトコルサポート責任者であるTim Beikoが提起したプロセスの問題のいくつかについて議論し、ETHワークショップのアップグレードの調整を改善しました。### デブネット #122023 年 11 月 30 日 (水) に、カンクン/デネブのアップグレードが Devnet #12 で正式に開始されました。 ETH財団のテストチームのMario Vega氏は、現在テストネット上で稼働している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シャドウフォークの計画を保留にすることを決定しました。 Beikoは、年末までに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のテストスイートを組み合わせて、このようなツールを構築することを推奨しています。カンクン/デネブのアップグレードのための新しいテストツールについて、Jayanthi氏は、開発者がDevnetとテストネットでチェーンの再結合を確実に活性化するためのツールに取り組んでいると述べた。 ツールが機能することを確認するために、Jayanthiは開発者に、ETHでチェーンの再編成を引き起こした既知のバグの詳細を共有するように依頼しました。 Jayanthi氏は、これらのバグを使用してツールをテストし、再編成がいつ発生し、いつ解決されるかを確実に識別できることを確認すると説明しました。### ネットワーク仕様の明確化開発者は、ETH Foundationの研究者であるJustin Tragliaが提案した、CLクライアントが「BlockbyRoot」または「BlobSidecarsByRoot」リクエストを受け取ったときに返す応答の順序について簡単に説明しました。 Ryan は、さまざまな CL クライアント チームがこの機能をどのように実装しているかを尋ねます。 電話会議の開発者は誰もこの質問に答えませんでした。 Ryan氏は、ETH Research & DevelopmentのDiscordチャンネルでの議論を復活させ、より幅広いクライアント開発者を巻き込むことを提案した。 ライアンは、2つのリクエストの仕様に曖昧さがあり、それが「問題や奇妙なエッジケースの原因である可能性がある」ことを認めており、「明確化され、整理されるに値する」と断言しています。Ryan氏はまた、今後数日中にCL仕様の新しいバージョンをリリースすると述べた。 最新バージョンでは、CLクライアントが「byRoot」RPCリクエストを介してブロックとブロックを提供できる場合に関する仕様が大幅に追加されています。 不足しているチャンクやチャンクを "byRoot" RPC リクエストで取得する方法の背景については、前の呼び出しログを参照してください。 Ryan氏は、最新バージョンに含まれるCL仕様への新しい追加は、Devnet #11または#12ですでに実行されているバリデータのコードに影響を与えるような、コードに対する破壊的変更ではないことを強調している。### アップグレード計画プロセス次に、Beikoが提案するさまざまなプロセス項目について、開発者が議論しました。 Beiko氏によると、Goerliテストネットユーザーに、GoerliでCancun/Denebのアップグレードがアクティブ化されてから3か月以内、またはETHメインネットでアップグレードがアクティブ化されてから1か月以内のいずれか遅い方で、廃止が差し迫っていることを警告するブログ投稿が、11月30日にETH財団のブログで公開されます。 電話会議の終了後、上記のブログ記事が公開され、ここで読むことができます。Beiko は、ETH "pm" リポジトリの下にアップグレード専用のフォルダを作成し、特定のアップグレードに関連するさまざまなファイルを 1 つのフォルダに整理して、後で使用することを推奨しています。 電話会議の開発者は、Beikoの提案に同意しました。Beikoが提案した2つ目のプロセス項目は、ETHで完了したネットワークアップグレードの全範囲を追跡するための「Meta EIP」文書を作成することでした。 「ネットワークのアップグレードをデプロイしてブログ記事で発表する前に、その全容を追跡するのに適した場所はありません」と、Beiko氏はMetaのEIP提案に関する投稿に書いています。 「Dencunの場合、EL EIPは見つけにくいマークダウンファイル7にあり、CL EIPはBeacon Chain Specification 3の一部です。 どちらも見つけるのが少し難しく、それぞれが異なる「形式」を使用しており、重複につながるため、これはあまり良くありません。 ERCとEIPは分離されたため、Meta EIPを使用してネットワークアップグレードに含まれるEIPを追跡することをお勧めします。 開発者は、これらのドキュメントの作成に賛成していました。 ベイコ氏は、今週、カンクン/デネブのアップグレードを検討するための文書を起草すると述べた。最後に、Beiko氏は、提案されたコード変更、ETH改善提案(EIP)を「含めると見なされる」(CFI)とマークすることの有用性について疑問を呈した。 Beiko氏によると、CFIは開発者が歴史的に「ソフトシグナル」として使用してきた状態であり、EIPの作成者は将来のハードフォークに含まれる可能性のある提案に引き続き懸命に取り組む必要があることを示しています。 これは、ELに重点を置いたコードの変更とアップグレードにのみ使用されます。 「[CFI] 無作為な人々からの無作為なアイデアよりも高いが、それがフォークで受け入れられる前だ」とベイコは言った。以前は、ラベル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 関連かにかかわらず、すべての EIP のプレースホルダー フィールドを作成し、CFI ステータスを含むレビュー プロセス中のステータスを識別するというアイデアを思いつきました。 この電話会議では、EIPステータスとCFIラベルのトピックに関する明確な決定はありませんでした。
ETH Placeのコア開発者の最新の会議の概要:Devnet 12が開始され、アップグレード計画プロセスがアップグレードされています
原題:Ethereum All Core Developers Consensus Call #123 Writeup
クリスティン・キムによるオリジナル記事
オリジナルコンピレーション:Luccy、BlockBeats
編集部注:
ETH Workshop All Core Developer Consensus Calls (ACDC) は隔週で開催され、ETH Workshop の Consensus Layer (CL) の変更について議論し、調整します。 これはACDCの123回目の電話会議であり、Cancun/DenebとDevnet #12のテストアップデートの評価と、Devnet #11で浮上したバリデーターの出口問題の解決に焦点を当てました。 さらに、開発者は、ネットワーク仕様の明確化、アップグレード計画プロセス、およびEIPステータスについて詳細な議論を行いました。
Cancun/Denebの議論の中で、開発者は安定性を強調し、Goerliシャドウフォークを開始するかどうかについて議論しました。 しかし、Prysmクライアントはテストの準備ができていなかったため、準備が整うのを待つことにしました。 テストツールとチェーンの再構築に関する議論では、より包括的なテストカバレッジの必要性が強調され、HiveおよびKurtosisテストスイートの使用に関する推奨事項が作成されました。 EIPステータスとCFIラベルの問題について、Beikoはこれらのタグを保持すべきかどうかについて懸念を表明し、開発者はまだこの問題について明確なコンセンサスに達していません。
Galaxy DigitalのリサーチVPであるChristine Kim氏は、BlockBeastsがまとめた会議のハイライトについて詳細にメモしました。
2023 年 11 月 30 日、ETH 開発者が Zoom に集まり、All Core Developers Consensus (ACDC) コール #122 セッションを開催しました。 ACDCの電話会議は、ETH Workshop Foundationの研究者であるDanny Ryan氏が主導する隔週の一連の会議で、開発者がETH Workshop Consensus Layer(CL)の変更について議論し、調整します。 今週、開発者はカンクン/デネブテストの最新動向に焦点を当てました。
· Devnet #12のローンチ:Devnet #12では、Teku、Lodestar、Lighthouseのクライアントソフトウェア、およびすべての実行レイヤー(EL)クライアントソフトウェアのテストが進行中です。 Prysmチームは、2〜3週間以内に最新のDevnetでソフトウェアをテストできるようになると予想しています。
· Devnet #11 でのバリデーター終了の問題: Devnet #11 で、開発者はバリデーターの終了に関連する問題を特定し、現在 Nimbus クライアント チームによって解決されています。 Devnet #11 は、問題が解決されるまで正常に機能し続けます。
· ネットワーク仕様の明確化: 開発者は、“BlockByRoot” と “BlobSidecarsByRoot” 要求の仕様を明確にし、コンセンサス層 (CL) ノードがこれらの要求に特定の順序で応答する必要があるかどうかを明確にすることについて議論しました。
カンクン/デネブのアップデートに加えて、開発者は、ETH Foundationのプロトコルサポート責任者であるTim Beikoが提起したプロセスの問題のいくつかについて議論し、ETHワークショップのアップグレードの調整を改善しました。
デブネット #12
2023 年 11 月 30 日 (水) に、カンクン/デネブのアップグレードが Devnet #12 で正式に開始されました。 ETH財団のテストチームのMario Vega氏は、現在テストネット上で稼働している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シャドウフォークの計画を保留にすることを決定しました。 Beikoは、年末までに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のテストスイートを組み合わせて、このようなツールを構築することを推奨しています。
カンクン/デネブのアップグレードのための新しいテストツールについて、Jayanthi氏は、開発者がDevnetとテストネットでチェーンの再結合を確実に活性化するためのツールに取り組んでいると述べた。 ツールが機能することを確認するために、Jayanthiは開発者に、ETHでチェーンの再編成を引き起こした既知のバグの詳細を共有するように依頼しました。 Jayanthi氏は、これらのバグを使用してツールをテストし、再編成がいつ発生し、いつ解決されるかを確実に識別できることを確認すると説明しました。
ネットワーク仕様の明確化
開発者は、ETH Foundationの研究者であるJustin Tragliaが提案した、CLクライアントが「BlockbyRoot」または「BlobSidecarsByRoot」リクエストを受け取ったときに返す応答の順序について簡単に説明しました。 Ryan は、さまざまな CL クライアント チームがこの機能をどのように実装しているかを尋ねます。 電話会議の開発者は誰もこの質問に答えませんでした。 Ryan氏は、ETH Research & DevelopmentのDiscordチャンネルでの議論を復活させ、より幅広いクライアント開発者を巻き込むことを提案した。 ライアンは、2つのリクエストの仕様に曖昧さがあり、それが「問題や奇妙なエッジケースの原因である可能性がある」ことを認めており、「明確化され、整理されるに値する」と断言しています。
Ryan氏はまた、今後数日中にCL仕様の新しいバージョンをリリースすると述べた。 最新バージョンでは、CLクライアントが「byRoot」RPCリクエストを介してブロックとブロックを提供できる場合に関する仕様が大幅に追加されています。 不足しているチャンクやチャンクを “byRoot” RPC リクエストで取得する方法の背景については、前の呼び出しログを参照してください。 Ryan氏は、最新バージョンに含まれるCL仕様への新しい追加は、Devnet #11または#12ですでに実行されているバリデータのコードに影響を与えるような、コードに対する破壊的変更ではないことを強調している。
アップグレード計画プロセス
次に、Beikoが提案するさまざまなプロセス項目について、開発者が議論しました。 Beiko氏によると、Goerliテストネットユーザーに、GoerliでCancun/Denebのアップグレードがアクティブ化されてから3か月以内、またはETHメインネットでアップグレードがアクティブ化されてから1か月以内のいずれか遅い方で、廃止が差し迫っていることを警告するブログ投稿が、11月30日にETH財団のブログで公開されます。 電話会議の終了後、上記のブログ記事が公開され、ここで読むことができます。
Beiko は、ETH “pm” リポジトリの下にアップグレード専用のフォルダを作成し、特定のアップグレードに関連するさまざまなファイルを 1 つのフォルダに整理して、後で使用することを推奨しています。 電話会議の開発者は、Beikoの提案に同意しました。
Beikoが提案した2つ目のプロセス項目は、ETHで完了したネットワークアップグレードの全範囲を追跡するための「Meta EIP」文書を作成することでした。 「ネットワークのアップグレードをデプロイしてブログ記事で発表する前に、その全容を追跡するのに適した場所はありません」と、Beiko氏はMetaのEIP提案に関する投稿に書いています。 「Dencunの場合、EL EIPは見つけにくいマークダウンファイル7にあり、CL EIPはBeacon Chain Specification 3の一部です。 どちらも見つけるのが少し難しく、それぞれが異なる「形式」を使用しており、重複につながるため、これはあまり良くありません。 ERCとEIPは分離されたため、Meta EIPを使用してネットワークアップグレードに含まれるEIPを追跡することをお勧めします。 開発者は、これらのドキュメントの作成に賛成していました。 ベイコ氏は、今週、カンクン/デネブのアップグレードを検討するための文書を起草すると述べた。
最後に、Beiko氏は、提案されたコード変更、ETH改善提案(EIP)を「含めると見なされる」(CFI)とマークすることの有用性について疑問を呈した。 Beiko氏によると、CFIは開発者が歴史的に「ソフトシグナル」として使用してきた状態であり、EIPの作成者は将来のハードフォークに含まれる可能性のある提案に引き続き懸命に取り組む必要があることを示しています。 これは、ELに重点を置いたコードの変更とアップグレードにのみ使用されます。 「[CFI] 無作為な人々からの無作為なアイデアよりも高いが、それがフォークで受け入れられる前だ」とベイコは言った。
以前は、ラベル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 関連かにかかわらず、すべての EIP のプレースホルダー フィールドを作成し、CFI ステータスを含むレビュー プロセス中のステータスを識別するというアイデアを思いつきました。 この電話会議では、EIPステータスとCFIラベルのトピックに関する明確な決定はありませんでした。