EIP プロセス改善のアイデア: RFC および W3C プロセスからの借用
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
、著者：Alex Beregszaszi、翻訳および校正：Min Min & A Jian、Odaily の許可を得て転載。
一文の要約: まず、2019 年の EIP プロセスとその調整について概説します。次に、主に RFC プロセスと W3C プロセスからインスピレーションを得た、新しい EIP プロセスを提案します。
2016年からEIP（イーサリアム改善提案）に携わっています。私はコントリビューターとしてスタートし、その後「AllCoreDev プロセス」に参加し、編集業務を引き受けました。
現在のプロセス
現在の EIP ライブラリには 2 つの異なるプロセスがあります。
仕様
ネットワーク全体の実装（ハードフォーク計画）
EIP-1 と EIP 233 は、両方のプロセスの一部を定義します。その後、EIP-2378 がこれに基づいて拡張されました。
2019 年にいくつかの変更が提案されましたが、そのうち 4 つは提案のステータスに関連するものでした。
「レビュー」ステータスの導入
「承認済み」の名前を「準備完了」に変更します
「放棄」ステータスの導入
「延期」ステータスを削除する
最初の 2 つの変更を導入する動機は似ていますが、少し異なります。 「レビュー」状態は、より広範なレビューの余地がある明確な提案はあるものの、提案が緊急に実行されるわけではない新しい段階です。 「準備完了」ステータスはほんの少しの増分変化であり、トーンは「受け入れ済み」よりも穏やかですが、EIP-1 のハード フォーク プロセスはまだ保持されています。
「放棄」ステータスは、多くの放棄されたドラフトを整理するために導入されました。どうやら、以前は使用されていなかった「Withdrawn」状態が削除されたようです。
EIP-233 および EIP-2378 の変更により、「延期」ステータスは廃止され、削除されました。
「承認済み」や「拒否済み」などの他のハードフォーク状態を削除する提案もあります。
以下の図では、各状態が何を意味するかについては詳しく説明しませんのでご了承ください。各コーナーケースについては EIP-1 をお読みください。ただし、以下の「提案されたプロセス」は合理的な説明を提供します。 」
2019 年 6 月に、EIP プロセスの複雑さについて詳しく議論しました。各状態を考慮すると、EIP フロー全体 (「遅延」状態が削除される前) が次の図に示されます。
当時、ドキュメントには書かれていませんでしたが、EIPは「Last Call（コメントの最終回）」状態から「Abandoned」状態に遷移する可能性があると考えていました。
言及しなかったのは、プロセスが異なる 2 つの EIP があり、上記のすべての組み合わせが有効であるわけではないということです。
「コア」EIP の流れは次のとおりです。
ここで、「コア」EIP は最近まで「Last Call」状態を導入していなかったことに注意してください。
「非コア」EIP のプロセスは次のとおりです。
2020 年 5 月に、私はよりシンプルなプロセスを提案しました。
この点についてはすでに議論しました。しかし、EIPプロセスを経ている多くの提案と同様に、この提案も前進しませんでした。
ハードフォーク
また、「撤退」と「放棄」の２つの州を統合すべきかどうかも議論の的となっている。これについては最近の号で明確に説明されています。
電話会議では、「アクティブ」の代わりに「リビング」という言葉を使うことも提案されました。前者は最良の選択ではないかもしれませんが、後者よりは良いように聞こえます。
ハードフォーク
私はハードフォーク管理と正規管理の 2 つのプロセスを分離することに賛成です。今ではそう思っている人も多いようです。これにより、プロセスがはるかに簡単かつスムーズになります。
全コア開発者会議からの新しいニュースによると、提案の追跡と管理、およびいわゆる「YOLO」一時テストネットでのテスト専用の ETH 1.0 仕様リポジトリが存在するようです。
最後に残ったハード フォーク プロセスが EIP ライブラリから削除されたとしても、既存のハード フォークをメタ ドキュメントに記録する (ハード フォークと同じファイルに置く) という EIP-233 の当初のアイデアは依然として合理的であると思います。仕様変更を記載したEIPも合わせて）
しかし、当初の EIP-233 のアイデアからはさらに一歩進んで、クライアントごとに異なる名前が使用されるため、ハード フォークの名前を明確にするためにできるだけ早くメタ ドキュメントを作成することがルールになりました。しかし、命名メカニズムが合意された後は、この問題は問題ではなくなりました。
最後に、EIP-233 のアイデアは再び拡張され、計画と調整のプロセスにおけるハード フォークを追跡するプロセスが拡張されます。幸いなことに、今後、これは ETH 1.0 仕様によって処理される予定です。
ハードフォークが発生すると、すべてのデータが「ハードフォークメタ」に記録されます。ハードフォードメタは非常に有用なリソースであることが証明されています。
私が提案したプロセス
巨人の肩に立つために、私たちが見つけた最良のリソースは、RFC プロセスと W3C プロセスです。これら 2 つのプロセスに関係する仕様は一般的に EIP よりもはるかに大きくなりますが、そこから学ぶことができると思います。
ここでは、W3C プロセスから個人的に気に入っている用語をいくつか借用しています。ただし、上の図には、既存の用語または提案された用語の両方に他のオプションが示されています。個人的には「候補者」という言葉の方が好きです。
アイデア
提案を送信する前に、ドラフトを作成するプル リクエスト (プル リクエスト) を送信する前に、慎重なフェーズが必要です。 Ethereum Magicians、ethresear.ch、Gitter または Discord のチャンネルでアイデアについて議論したり批評したりできます。
下書き
アイデアが興味を引いたと仮定すると、EIP テンプレートに基づいてそのアイデアのドラフトを作成する必要があります。この草案が基本的な文法要件を満たしている限り、それを統合する必要があります。
質問: 編集者が提案をレビューするためにどの程度の権限を持つべきかについては意見が異なり、明確な答えはありません。失敗した EIP を削除する適切なプロセスがある場合、ドラフトを早期にマージすることは確かに正しいことです。
現段階では、草案は関心のある参加者からなる少人数のグループによって議論される予定です。
「ドラフト」ステータスに期限はありませんが、妥当な期間 (数か月) を超えないようにすることをお勧めします。
候補（候補）/レビュー（レビュー）
この段階は、草案が十分に安定し、さらなる大幅な改訂が期待されなくなった時点で開始する必要があります。
この段階では、より多くの参加者がフィードバックを提供します。この時点で、参加者は仕様が突然大幅に変更されることはないと信じる理由があるため、仕様の確認と議論に時間を費やす可能性が高くなります。
フィードバックを収集できるよう、このフェーズは少なくとも 45 日間続く必要があります。
Proposed（提案）/Last Call（最終コメント募集）
このフェーズは、参加者が仕様が十分に安定しており、これ以上の変更は行われないと感じた時点で開始する必要があります。
この段階では、仕様はコメントを求めてより多くの参加者にプッシュされます。その後、仕様が確定し、変更することはできません。 【「正誤表（漢）」を除く、詳細は下記参照】
このフェーズは少なくとも 14 日間続く必要があります。
軽微な調整が必要な場合は、現在の状態を変更せずに行うことができます。そうでない場合は、「候補」状態に戻す必要があります。
特別な要件: レビュー終了日フィールドはフロントマターに含める必要があります。
最後の
「提案」状態の仕様が無事に通過すると、仕様が確定します。
引きこもった
「Final」と「Living」を除く他のすべての状態がこの状態になる可能性があります。
特別な要件: 次の状況では「撤回」状態になる可能性がありますが、理由フィールドが必要です。
著者による撤回: 著者はいずれかの段階で撤回の決定を下しました。
活動がないため撤回されました: 著者は、指定された期間 (180 日間) 活動がありませんでした。
リビング/アクティブ
レジストリとしての EIP-1 やその他の特別な EIP は最終化されないため、このステータスがマークされます。
新しい登録書類はすべて、「生存」ステータスになる前に完全な EIP プロセスを通過する必要があります。
アーカイブ済み
これは状態ではありませんが、この方法により、長期間にわたって取り消された EIP を削除して、EIP ライブラリがいっぱいになることを回避できます。詳細については、ここをクリックしてください。
廃止
これは状態ではなく、RFC から借用した段階的廃止プロセスです。このプロセスでは、次の 2 つのフィールドが導入されます。
obsoleted-by: 現在の EIP を廃止する EIP 番号が含まれています
obsoletes: 現在の EIP によって廃止された EIP 番号のセットが含まれます
現在の EIP は、Final または Withdrawn 状態にある場合にのみ、obsoleted-by フィールドを使用できます。
現在の EIP は、参照される EIP の「obsoleted-by」フィールドが現在の EIP を指している場合にのみ、obsoletes フィールドを持つことができます。
これは、排除される当事者としての EIP の作成者と排除される当事者が合意に達する必要があることを意味します。より良い排除プロセスの提案により、これは将来変更される可能性があります。
Remark
正誤表（正誤表）
軽微な誤字は、慣例により編集者によって修正される場合があります。
軽微な修正については正誤表セクションで説明できるため、元の提案を認識できないほど変更しない限り、仕様の明確化に役立つ修正はおそらく許容されます。大幅な変更が必要な場合は、対応する EIP を廃止し、新しい EIP を作成する必要があります。
resolution
次のフロントマター フィールドは、指定されていない、または使用されていないため、削除されました。
置き換える（削除プロセスによって置き換えられます）
superseded-by (消去プロセスによって置き換えられます)
Rejected
Accepted
次の状態が削除されます。
道具
放棄（「撤退」に名前変更）
置き換えられました (削除プロセスによって置き換えられました)
道具
しかし、EIP が直面する最大の課題は人材の必要性です。
