————————————————————
従来のブロックチェーンのフォークはしばしばコミュニティの分裂を伴い、例えばイーサリアムとイーサリアムクラシック（ETC）のフォークは「ハッキングされたDAO契約をロールバックすべきか」という主観的判断に起因している。
このフォークは社会的コンセンサスに依存している——誰がより多くの人を説得できるか、その人のチェーンが「生き残る」。
Eigenlayerの定義はこの状況を変えることを試みており、「事前定義」と「自己検証」という2つのキーワードを通じて、フォークのトリガー条件を曖昧な道徳的または経済的議論から明確な技術的ルールへとシフトさせようとしている。
——事前定義：これはフォークの条件が事後の争いの結果ではなく、あらかじめプロトコルに書き込まれ、法律条項のように明確であることを意味する。これにより、臨時の決定による不確実性が減少する。
——自己検証：イベントの検証可能性は分散化されなければならず、どのノード（軽ノードでさえ）もフォーク条件に達しているかどうかを独立して判断できるようにし、中央集権的な「権威」の解釈に依存しないようにする。
1）イーサリアムの既存のルールの可能性と限界🔻
イーサリアムには既に無効ブロックの拒否、タイムアウトの再構成の否決など、フォークの根拠となる「事前定義されたイベント」がいくつかある。
これらのルールは確かに一定の「自己検証」特性を示しており、特に最初の3点（無効ブロックの拒否、タイムアウト再構成の拒否、使用不可ブロックの拒否）は、ノードのローカルチェックによって独立して完了できるからだ。しかし、検証者のレビューとクライアントのバグは現在のルールの限界を明らかにしている。
1、検証者によるレビューの検証の難題：
あなたが言ったように、検証者のレビューは現在「間接的な証拠」に依存するしかない、例えばソーシャルメディア上の苦情。これは明らかに「自己検証」には不十分で、操作されやすい（例えば誰かが悪意を持って嘘をつく）し、アルゴリズム化できない。レビューをフォークの根拠とするには、「連続してX個のブロックに特定の取引が含まれていない」という可観察基準のような技術的指標を設計する必要がある。これによりノードは独立して判断できるようになり、外部情報に依存しない。
2、クライアントバグの複雑性：
クライアントバグは擬似コード仕様によって検証できるが、実際の操作ではノードの運営者の技術能力はまちまちである。大多数のノードがバグを迅速に特定し合意できない場合、フォークの実行段階は混乱に陥る可能性がある。これがクライアントの多様性（client diversity）の重要性であり、単一クライアントの支配は「バグが運命」という状況を引き起こしやすく、実際の多様性はリスクを分散させる。
2）フォークに含まれない🔻
1、フォーク提案者によってレビューされる状況、例えばブロック提案者が特定の内容をレビューする場合。
2、Lido、Coinbase、または誰かが33%のステークを持っていることを理由にフォーク。
3、アプリケーションまたはユーザーのレベルのエラーによるフォーク。
フォークはプロトコルレベルの核心的な問題に焦点を当てるべきであり、外部要因や二次的なエラーには焦点を当てるべきではない。これは実際にはフォークの境界を定め、政治的な道具として濫用されるのを防ぐ。
——もしLidoやCoinbaseが33%の持株を持っていることを理由にフォークが行われるなら、これは本質的に経済的な権力に対するものであり、技術的な故障ではなく、明らかに「自己検証」の原則から逸脱している。
——アプリケーションレベルのエラー（例えば特定のDAppがクラッシュしたなど）はフォークを引き起こすべきではない、なぜならそれはブロックチェーンの基盤の責任を超えているから。
この境界設定は非常に重要であり、フォークが「声が大きい方が正しい」というゲームに変わるのを防ぎ、イーサリアムの分散化の精神を保護する。
3）準備から実行まで：フォークの理想的なプロセス🔻
ホワイトペーパーで言及された2つの段階：
——準備段階：イーサリアムコミュニティはコンセンサスに達し、フォーク条件をプロトコルコードに書き込み、チェーン上で公開透明にする必要がある。これは単なる技術的な課題ではなく、ガバナンスの課題であり、各方面の利益をバランスさせる必要がある。
——実行段階：一度条件がトリガーされると、ノードはローカル検証に基づいて自動的にフォークを実行し、人為的な介入は不要である。これは条件の設計が十分に正確であり、あいまいさを避ける必要がある。
しかし現実には、準備段階でのコンセンサスの達成が最大の難点となる可能性がある。イーサリアムのアップグレード（例えばPoSへの移行）は、技術的改善でさえも、利害の不一致により何年も遅延することを示している。フォーク条件の策定は、より大きな論争に直面する恐れがある。
📍結論：
イーサリアムのフォークの本質はネットワークのセキュリティ、信頼性、分散化を維持することであり、「事前定義された自己検証」フレームワークはこのプロセスをより客観的かつ自動化することを試みている。
既存のルールは良い出発点であるが、このビジョンを実現するためには、技術設計（特にレビュー検出）やコミュニティガバナンスにおいて、さらなる努力が必要である。将来的には、フォークはコミュニティを引き裂く「内戦」ではなく、プロトコルの自己修復の「メス」となる可能性がある——前提は、我々がルールを十分に良く設定できることである。
🔹原文翻訳リンク：https://x.com/sreeramkannan/status/1893361540759433558?t=nQp5B8x78sBq6Wp9GAewEA&s=19