关键词：以太坊核心开发者会议、ProgPoW、BLS 签名、ASIC 抗性、EIP-2537、Eth 2.0、DAG 大小、社区治理
2020 年 3 月 6 日，以太坊核心开发者迎来了一场长达 3 小时的线上马拉松式会议。内容围绕两大主题展开：Eth 2.0 BLS 曲线签名预编译 与 ProgPoW（Programmatic Proof-of-Work）去留之争。本文精炼 10,000 字实录，带你迅速把握技术细节与社区心态，一次看懂争议焦点与可能的下一步。
1. BLS 曲线签名：一次还是全部？
1.1 背景：EIP-1962 家族继续扩张
主持人 Hudson Jameson 把开场 60 分钟交给了 James Hancock。议题直接锁定：
- EIP-2537（BLS12-381）
- EIP-2539（BLS12-377）
- EIP-2541（Zexe Curve）
三份提案均旨在为 Eth 2.0 Phase 0 引入更高效的 BLS 签名验证与零知识证明预编译合约。
1.2 三大曲线的抉择
Alex Vlasov 指出，实现三种曲线工程量其实不大；真正难的是安全审计与维护。他担忧：
- 多则乱：开发者会冒出 5 种以上实现方式，安全性降低。
- 节外生枝：协议复杂度上升，升级与调试都会变困难。
Vitalik 也补充：开发者对高性能隐私计算很渴求，但 真正需要的是「不要一次给太多选项」。
1.3 结论：先做一条曲线
James 总结：
- 先上一条：BLS12-381 最为成熟，也已纳入 Eth 2.0 规范。
- 推迟其余：另外两条曲线可在后续分叉中“分批发货”。
- 跟进 Eth 2.0 时间线：柏林升级不会一次性塞满所有预编译合约。
👉 想参与核心开发者对 BLS 曲线的下轮投票？点此获取实时动态。
2. ProgPoW：一场关于话语权与算力的拉锯战
2.1 技术更新：Least Authority 审计 & DAG 话题
Kristy-Leigh Minehan 代表 IfDefElse 汇报：
审计建议：
- 提高 DAG 文件项数量，为未来升级留余地。
- Keccak 填充方案必须严格对齐 NIST 标准，避免安全缺口。
新发现：
- 把 256 位种子缩减为 64 位即可覆盖全阶段安全需求。
- 预计 4 GB DAG 将导至 40 % 算力下降，但 GPU 已向 6 GB、8 GB 升级——问题不大。
- 补充：需要建立 ASIC 抗性评估框架 与持续的硬件市场监控。
2.2 社区立场
| 观点 | 代表人物 | 观点浓缩 |
|---|---|---|
| 支持 | Kristy-Leigh Minehan、Michael Carter (BBT) | GPU 矿工需要生存空间，ProgPoW 已是技术上的 “EthHash 2.0” |
| 反对 | Martin Köppelmann、Matt Luongo | 可能带来不可控的分裂，社区净收益不明确 |
| 折衷 | Ben DiFrancesco | 先代码实现，但不激活；把开关交给节点运行者 |
汇总一句话：技术可行≠社区接受。硬分叉永远不只是代码。
2.3 GPU vs ASIC 的现实博弈
- GPU 阵营：中国、北美大型农场正把 4 GB 显卡逐步替换至 8 GB，短期算力下滑温和。
- ASIC 阵营：若 40 % 算力掉线，GPU 可短期接盘，但 ASIC 制造商完全可能在 6–9 个月内推出 ProgPoW ASIC。
- 链上分叉风险：至少 2 个客户端团队表态若主网强推 ProgPoW，将保留老算法分支，可能导致 双链 局面。
2.4 折中方案浮现：Ben DiFrancesco 提案
核心思路：“准备就绪，不立即启用”
- 客户端在柏林版本中默认关闭 ProgPoW，留给矿工操作员一个 CLI 开关。
- 同时提供专用测试网：让支持者充分跑网，反对者不强制参与。
- 无需陷入不断反复的 YE/NO 表决，时间就是信任成本。
2.5 询众：下一步怎么走？
主持人 Hudson 发出开放式问题：
是直接修改 EIP-1057，还是另起“Provisional ProgPoW”新 EIP？
现场多数人赞同暂缓上线 + 重新草拟文档，给出 4–8 周 社区公开咨询期。
👉 如果你也想在硬分叉前发表意见，现在就能直达核心开发者讨论区。
3. 开发者的“其他碎活儿”
- EIP-2315：EVM 子程序更新尚未合并，仍在优化。
- EIP-2416 / 2515：难度炸弹(Difficulty Bomb) 推迟方案仍在案头，未见实质进展。
4. FAQ：关于会议你最想了解的三件事
Q1：为什么 Eth 2.0 需要 BLS12-381 而不是更通用的曲线？
A：BLS12-381 早已在 Eth 2.0 规范定稿阶段使用，标准库成熟、开源审计多，第一次落地可减少未知风险。
Q2：ProgPoW 真如宣传所言，完全防 ASIC 吗？
A：官方目标是“提高 ASIC 研发门槛”，而非绝对禁止。只要经济激励足够，ASIC 仍可出现，硬件博弈永无终点。
Q3：普通用户需要为 Berlin 升级做什么？
A：不跑节点、不挖矿可直接忽略；如果使用硬件钱包，跟进产品公告即可。交易所、DApp 需关注官方发布时间窗。
5. 总结：代码已经写完，人心尚在调试
从 19:00 的 Brussels 傍晚，到 22:00 的全球时差深夜，80 多位开发者没有在争论“谁对”，而是在寻找“怎么对”。
BLS 签名预编译的共识更清晰了——先做一条曲线，保持简洁。
ProgPoW 的共识仍在迷雾，但所有人认同：
分裂的代价，可能大于算法升级的收益。
下一幕，将在未来两个月的社区协奏曲中揭晓。