被撤下的 EOF：一次技术提案如何引发以太坊治理机制的深度反思？
以太坊治理中最具影响力的决策之一，就是为网络升级选定旗舰功能。这直接关乎数十亿美元的利益。更重要的是，我们每个决策都会限制未来的设计空间，而优柔寡断将带来切实代价——以太坊并非孤立存在。
作者 | timbeiko
🔗 原文链接：https://ethereum-magicians.org/t/community-consensus-fork-headliners-acd-working-groups/24088
以太坊治理中最具影响力的决策之一，就是为网络升级选定旗舰功能。这直接关乎数十亿美元的利益。更重要的是，我们每个决策都会限制未来的设计空间，而优柔寡断将带来切实代价——以太坊并非孤立存在。如果我们因错误优先级或执行不力而踌躇不前，就可能将阵地拱手让给价值体系迥异的竞争生态。
因此，确保为硬分叉选择正确的"核心功能"，是所有核心开发者（AllCoreDevs）最需要优化的首要责任。我们不应仅凭"是否有益"来评估提案，更要衡量其在扩展网络、强化安全或简化协议等维度上的相对价值。
本文延续我此前《重构 AllCoreDevs》的提案，通过这一视角评估以太坊治理机制，并就决策流程——特别是硬分叉核心目标与旗舰功能的确定——提出切实改进方案。
（注：本文仅代表个人观点，不应视为“以太坊基金会意见”或“AllCoreDevs 共识”。我完全期待并欢迎以太坊社区的不同声音！）
01 ｜ 粗略（社区）共识
以太坊治理哲学受互联网工程任务组（IETF）启发，尤其是"粗糙共识"概念（其精妙之处在 RFC 7282 中有详尽阐述）。简言之，粗糙共识旨在通过务实迭代达成各利益相关方均可接受的方案（即使不完美），同时审慎考量所有专业意见。理想状态下，它能通过合理流程产生更优质的解决方案，同时避免"国王总统沙阿"式的独断。
"重申：达成共识本身不是目的。共识是我们为寻求最佳解决方案在流程中产生的状态。特别是'宣布共识'绝非终点——为了宣称存在共识而在讨论尾声强行宣布，往往会使我们陷入本应避免的'投票思维'。" —— RFC 7282
以太坊历来以核心开发者共识为中心，这隐含假设了更广泛社区的认同。但核心开发者虽然负责编写保障以太坊网络的代码，却非唯一话事人。以太坊治理结构包含更多利益相关方：节点运营商、应用开发者、用户等等。
为保持合法性（尤其随着生态成熟），AllCoreDevs 的决策必须积极考虑并与更广泛的以太坊社区对齐。若未能实现并清晰传达这种对齐，利益相关方可能从"发声"转向"退出"——或通过争议性升级，或逐步迁移至竞争生态。
因此，仅核心开发者间的粗糙共识虽有必要，但已不足够...对于重大协议变更，我们需要来自以太坊各受影响方的清晰、可追溯的共识记录。若无法达成完全共识，至少应透明记录反对意见，并明确解释为何接受特定权衡。
这种做法将确保以太坊继续通过合法流程实现实质性改进。
02 ｜ EOF 与 Fusaka 分叉
这一背景或许能解释我为何破例将 EOF 移出 Fusaka 分叉。
多年来，EOF 的多个变体曾被提议、纳入又最终移出网络升级（参见上海升级、Dencun 升级），这往往反映出其优先级相对于其他核心功能的共识变化。EOF 原定于 Pectra 升级，后因分叉拆分以控制范围，与 PeerDAS 一同移至 Fusaka。
虽然核心开发者普遍支持 EOF，但即便在当时也存在强烈反对声音。EOF 支持者竭力回应质疑，通过扩展技术规范、模块化提案来明晰决策点。与此同时，以太坊社区越来越清晰地意识到：Fusaka 必须优先交付 PeerDAS。
随着开发推进，来自以太坊技术栈各层的参与者再次提出复杂性担忧。核心开发者在 ACDE 208 会议上重申将 EOF 保留在 Fusaka，明确支持最完整的 EOF 版本。但众多生态参与者持续反对，理由包括具体设计选择、对复杂性的担忧、生态碎片化风险以及稀缺工程资源的分配等。
在 ACDE#210 会议前夕，部分核心开发者发现他们偏好的 EOF 方案（方案 A）意外会对开发者体验造成显著负面影响。虽然这些问题曾被提及，但其严重性未被充分认知。客户端团队同意紧急评估影响，并在下 Testing/Interop#34 会议上解决。
该会议上，客户端团队与生态参与者普遍同意转向更简化的 EOF 版本（方案 D）。但在会议尾声，Reth 团队深入理解该版本与旧合约的交互后强烈反对，暴露出方案仍存在不确定性。这种临近决策阶段的普遍困惑与观点剧烈反转，最终促使我取消 EOF 在 Fusaka 的 SFI（最终纳入）状态。
我承认临阵移除会损害当前治理流程的表面合法性。但若机械遵循现有流程"字面要求"保留 EOF，将违背我们试图建立的更包容治理精神。
换言之，仅观察 EOF 被移除的会议会得出片面结论。更全面的视角应包含：
选定升级核心功能是 AllCoreDevs 最重要的产出；
以太坊的不可变性意味着变更本质是永久的，需谨慎避免引入可能后悔的复杂性；
EOF 始终未能在更广泛社区建立坚实的"粗糙共识"，核心开发者的立场也随时间变化；
社区对 PeerDAS 作为首要优先级的共识明确且一致；
更包容、结构化的治理流程本可更早暴露问题，避免最后关头逆转。
我们的流程在多方面失败了：辜负了投入 EOF 开发的核心开发者，也让更广泛社区感到无法有效表达关切或影响优先级决策。同时未能清晰沟通决策时机与方式，为本已复杂的局面增添不必要动荡，影响开发者士气及 EVM 整体改进进程。
未来，我们必须建立更好的网络升级优先级设定机制，明确且一贯地使决策与以太坊扩展、强化、简化协议的核心目标对齐。若 EOF 确属最高优先级，改进后的流程应助其形成更清晰、更强的共识；若非如此，更好的优先级排序将明确真正重点，让核心开发者和社区能将资源投入最具杠杆效应的方向。
03 ｜ 中期优先事项：无状态验证
重申：选定网络升级旗舰功能是以太坊治理中风险最高的决策。但当前方法缺乏评估和优先排序这些关键功能的明确结构。因此我们需要更严谨、透明且社区协同的流程。
以下是我提出的改进方案，使核心功能选择更审慎聚焦，明确欢迎来自以太坊全社区（不仅是核心开发者）的结构化意见，同时恪守 AllCoreDevs 保障以太坊安全的承诺。
定义分叉核心目标
每次升级周期伊始，AllCoreDevs 应明确定义战略优先级（即"分叉核心目标"）。这为评估候选功能提供共享的、社区协同的指南。
确定该目标时应明确征集以太坊生态各方的结构化意见。虽然不必形成独立文件，但这一共享目标应提供战略清晰度与早期优先级对齐。
示例性分叉核心目标包括：
扩展性与降费：显著提升吞吐量、降低交易成本、解锁新用例
开发者与用户体验：简化协议复杂度、增强智能合约安全性、减少开发摩擦
安全与韧性：强化网络安全态势、提升抗攻击能力、应对新兴威胁（同时保持去中心化与抗审查性）
应积极寻求社区对分叉核心目标的共识，特别是最受升级影响的群体。虽然 AllCoreDevs 最终负责实现细节，但明确定义核心目标应反映来自社区的广泛可信意见，直指以太坊最紧迫需求。
收敛至核心功能
确定分叉核心目标后，可对齐具体旗舰功能。实践中这常是迭代过程——初始提案会进一步澄清和精炼整体目标。最终，AllCoreDevs 每次升级最多选择两个旗舰功能（每层一个）。
现有 PFI→CFI→SFI 框架仍适用。反直觉的是，旗舰功能的技术门槛可能低于常规 EIP，但前提是其与分叉核心目标高度契合且获坚实社区支持。某些功能（如合并升级）至关重要，即使初始规范不完美也值得全力投入；而像 EOF 这类功能，可能需以 EIP 集合形式呈现，甚至作为非核心 EIP（如涉及 Gas 限制的调整）。
若某功能未被选为核心功能，则同一升级周期内不得作为常规 EIP 重新提出，以防"后门重定优先级"。
核心功能提案（从 PFI 阶段开始）应通过以太坊魔术师论坛的标准化模板结构化呈现，例如：
核心功能提案模板
摘要（通俗解释）：用简明语言说明提案内容、意义及直接受益方
详细论证：
主要与次要收益（最好有数据或具体依据支撑）
明确"为何现在实施"——为何该功能应优先于其他事项？
论证本方案相较替代方案的优越性（更低风险/更高价值）
利益相关方影响：
积极影响：明确受益方并记录其支持
消极影响：识别潜在受损方，概述反对意见及缓解措施（或解释为何接受该权衡）
技术就绪度：评估技术成熟度（附规范文档、测试案例、客户端实现等链接）
安全与开放问题：明确记录已知安全风险、未解决问题或模糊环节（含威胁模型、初步审计计划或后续步骤）
这种结构化流程专门针对重大协议改进。小型渐进式 EIP 应继续通过现有轻量级治理流程，保持敏捷性。
04 ｜ 社区意见与迭代审核
非核心开发者的利益相关方常难把握参与治理的时机与深度。为此我提议"哑铃式"两阶段社区参与机制：在初期进行结构化意见征集，在开发末期通过社区测试网验证。
初期应积极向全生态征集核心功能提案，明确标示最有价值的意见窗口期。通过上述模板收集结构化意见，可确保核心开发者聚焦于符合以太坊战略优先级的提案。开发周期尾声的临时测试网则为社区提供实操验证变更的机会，将后期反对意见限于关键实现或安全问题。
审核与决策机制
硬分叉核心功能选择应与《重构 AllCoreDevs》中描述的升级规划周期明确衔接。通过将核心功能选择锚定在 PFI→CFI→SFI 框架，并明确其与重组后的 ACD 会议（ACD{E|C} 和 ACDT）的关系，可建立清晰可预测的治理流程。
具体流程如下：
公开提案征集：每次升级周期伊始（前一升级接近完成时），AllCoreDevs 明确宣布核心功能提案征集。提案者通过以太坊魔术师论坛异步提交结构化提案，明确说明其与分叉核心目标的对齐性。
聚焦式社区参与：核心开发者、基础设施团队、Layer2 项目、应用开发者等利益相关方提供结构化反馈，明确表达支持或关切。明确标注该审核窗口期，让各方知晓最具影响力的参与时机。
异步与同步审核：提案先经异步审核，提案者根据反馈完善方案。优化后的提案在 ACD{E|C} 路线图规划会议上同步讨论，进行直接澄清与聚焦辩论。
迭代优化与最终确认：同步讨论后，提案者根据反馈继续优化。通过异步"最终确认"环节进行全面的社区终审。
最终选定与粗糙共识：AllCoreDevs 在专项同步会议中选定核心功能，明确按各群体受影响程度及与分叉核心目标的对齐性权衡意见（例如 DeFi 相关变更应重点考量 DeFi 团队与用户的反馈）。
社区测试网
核心功能选定并初步实现后，应启动专用临时测试网（类似湄公河测试网），作为社区验证实现的最后机会。此阶段后，仅重大安全问题或未预见严重缺陷可导致延迟或终止部署。
明确决策顺序与各阶段预期能减少不必要动荡，提升合法性。如《重构 AllCoreDevs》所述，多数规划与测试将与前一升级的实现并行，确保以太坊能持续交付升级而无冗长空档。
05 ｜ ACD 工作小组制度化
以太坊重大升级（如 EIP-1559、合并升级、EIP-4844）需要多年专注开发才能主网上线。这些工作多源自非正式分组讨论，常缺乏 AllCoreDevs 的明确认可或检查点。虽然这种灵活性有价值，但也可能导致资源投入偏离核心优先级。
为此我提议将现有分组讨论制度化为明确的工作小组（WG）：受明确授权的团队，负责协调长期协议改进，并通过定期节点与 AllCoreDevs 保持对齐。
工作小组提案
希望将现有分组讨论制度化或新建 WG 的团队，需提交遵循核心功能提案模板的轻量级提案。不同于核心功能提案，WG 提案明确针对未来网络升级而非立即纳入下一硬分叉。
这些提案为工作小组提供了获取 AllCoreDevs 早期战略对齐的重要机制，同时不限制独立实验或非认可方向的开发。
AllCoreDevs 认可
AllCoreDevs 将在每次核心功能选定后审核活跃 WG，确保持续战略对齐。这种认可相当于"轻量级 CFI"，明确标志该 WG 符合以太坊战略重点。罕见的明确拒绝则意味着方向偏差或时机不成熟。
实操中，获认可的 WG 将出现在以太坊协议日历，并在 GitHub/pm 仓库拥有专属空间。未获明确认可或拒绝的尝试仍可非正式继续，但无官方日历代表或 ACD 能见度。
定期节点
获认可 WG 需定期向 AllCoreDevs 提交简明更新（理想时机在每次核心功能选定后）。这些节点用于确认持续对齐、验证方法并提供早期调整机会。
节点应保持轻量与战略性。WG 简要汇报进展、重大里程碑，并明确提出关键问题或风险。ACD 仅需重申战略对齐、提供针对性反馈或建议必要调整。
明确信号与社区信心
通过制度化 WG、提供明确战略对齐信号及保持定期轻量级节点，我们能减少以太坊长期路线图的模糊性。独立研究仍受鼓励，但正式认可的 WG 可确信其资源投入符合社区期待与以太坊优先级。
这种平衡方案解决了既往缺陷，同时不牺牲以太坊灵活、社区驱动的文化。
05 ｜ 未来方向
以太坊治理决策牵涉独特的高风险：数十亿美元资金、网络安全及整个生态的协同，都系于每次升级。我们需要清晰的护栏来管理这些不可逆变更，同时保持足够灵活性以维系以太坊务实、社区驱动的特质。
EOF 事件清晰暴露了当前流程的缺陷：升级核心目标模糊、早期结构化反馈不足、重大功能检查点不明。若不改进方法，即使参与者心怀善意，类似问题仍会重演。
为此我提议重点强化以下环节：
明确分叉核心目标：每次升级周期伊始，AllCoreDevs 应在社区意见基础上定义并传达清晰战略优先级，为升级提供共同指南。
每层至多一个核心功能：通过结构化模板与 PFI→CFI→SFI 流程，确保严格早期审核，明确禁止被拒提案以低优先级 EIP形式"复活"。
实施"哑铃式"社区审核：在变更尚灵活的最早阶段收集结构化意见，在实现末期通过社区测试网作为最终验证，将后期反对限于安全与关键实现问题。
制度化工作小组：为现有分组讨论与专项 WG 提供正式轻量级框架，包括与 AllCoreDevs 的定期节点，确保长期努力与以太坊战略优先级一致。
完整治理流程文档化：在权威位置清晰记录全流程与反馈渠道，消除利益相关方参与治理的不确定性。
这一框架不保证完美结果，但能显著减少不确定性、增强问责制，在保持以太坊独特性的前提下，赋予其坚定前行的能力。
感谢所有直接或间接为本文提供反馈的同行。虽需大量提炼工作，但你们的观点极具价值！
欢迎关注 ETHPanda 获取更多资讯！
