文章基于 Terence 2024 年在 ETH Chicago 的演讲内容整理。
自 2024 年「Electra」升级计划提上日程以来，关于 以太坊升级路径 的种种猜测纷至沓来。Deneb 中的 EIP-4844（Proto-danksharding）尚未完全落地，社区已将目光锁定在 共识层稳定性、抗审查强度、可扩展性 与 客户端代码健康 四大主题。本文尝试用更贴近中文读者的语言，系统梳理 Post-Deneb 时代潜在路线、技术博弈点与落地时间表，帮你快速抓住下一次升级的脉搏。
Phase 回顾：从 Capella 到 Deneb，再到 Electra
Capella：提现为第一需求
2023 年 4 月的 Capella 只允许 ETH 质押者 提取本金及收益，兑现信标链 2020 年的承诺。这时社区把「提款自由」放在升级首位，为 EIP-4844 让路。
Deneb：Blob 让 Layer2 便宜再便宜
Deneb 最大亮点 EIP-4844 引入「blob 事务」，显著降低 Rollup 转账费用。外加提案者标识根暴露、验证者激活率平滑机制，是对用户、开发者都友好的版本升级。
Electra：真正的十字路口
Electra 没有单一的“决策主线”。目前社区集中讨论的三大领域：
- 增强共识层稳定性
- 继续向上扩展可扩展性
- 清理客户端技术债务
下文带你逐一拆解。
Electra 七项关键技术展望
1. 最大有效质押额度升级（Shared MAX EFFECTIVE BALANCE）
痛点：超过 32 ETH 的验证者需要拆分成多条验证记录，导致广播消息数量暴增至 90 万+。
方案：提高单验证者上限至 2,048 ETH，一机多签一键搞定，降低 PeerDAS 与 验证者索引 重组的复杂度。
潜在收益
- 信标链消息总量下降 10～20 倍，节省网络 I/O。
- 客户端内存占用及哈希计算量同步下降，提升验证者节点性能。
- 承接 ePBS（Enshrined PBS） 与 单槽终局性 升级，路线图更加清晰。
👉一文看懂 2024 验证者奖励变化，提前布局 Electra
2. Inclusion List（包含名单）
抗审查 是目前以太坊对监管焦虑最直接的技术回应。当区块建构者（Builder）故意拖慢某些交易时，Inclusion List 强制要求区块必须打包名单中的交易，否则会被分叉链拒绝。
- 早期版本主打 Builder Override Flag，共识客户端优先处理本地交易。
- 进一步优化 gas 金额限制、边缘博弈，推动无信任化实施落地。
- 开放市场：MEV-boost、PEPC 都需要基于同一个名单标准做配套升级。
3. Secret Single Leader Election（SSLE）
直接应对「大玩家抢 DEX 流动性」的前置抢跑。凭借 Whisk 算法，排出一位秘密提案者（proposer），使其身份直到区块真正创建前都处于盲区，从而切断 MEV 窃取链路。
- 当前规范已完成，测试网已在跑。
- 实现复杂度适中，对现网经济安全反哺明显。
4. 分叉选择算法加固（Fork Choice）
2024 年所有客户端（Lighthouse、Prysm、Lodestar）将统一「迟交区块剔除」策略。更激进方案包括：
- View-merge：避免高开销 view-state 运算。
- RLMD-GHOST：降低长距分叉概率。
- 超越 LMD-GHOST：将委员会权重动态化，提高抵抗攻击的成本。
5. ePBS（将中继角色写入协议）
现实：约 95% 区块通过 MEV-boost 小区块提案。中心化着的「白名单中继」成为潜在风险点。
目标：把中继逻辑写进协议层，让构建者（Builder）同时成为质押验证者，彻底杜绝交易审查。
- 设计约束：需要触发 PTC 委员会、引入 Builder 质押池、强制 Inclusion List。
- 落地时间：最早在「F-Star」升级中实现，当前仍在分支设计 & 测试翻山越岭阶段。
👀加密研究员必读：ePBS 的经济模型如何抗住 51% 攻击
6. Danksharding Phase 0.5
数据可用性采样（DAS）与缺失样本重建 是 Danksharding 的「神秘之门」。简单路径：
PeerDAS
- 扔掉了全节点沉重的大型样本桶，采用 P2P 局部采样 化解扩展障碍。
- Benchmark 通过后，即可通过「最小可行网」快速上线，免去了「一步到 Danksharding」的巨大风险。
7. 客户端代码大扫除
当 2,500 万 ETH 的 TVL 正保护着 DeFi、NFT、L2 天量资产时，代码健康 是生命线。为此：
- 六个月的「大扫除工作坊」：所有客户端共同锁定周期处理技术债。
- 重写共识数据转换层，把 2019/2020 年陈旧写法淘汰。
- 弃用 Legacy Merkle 结构，优化哈希树高度与内存占用。
小结：Electra 的「优先级坐标系」
| 组合策略 | 动机 | 潜在实施阶段 |
|---|---|---|
| Inclusion List + 质押上限调整 | 立刻改善 UX 且推迟中心化威胁 | Electra |
| Fork Choice 优化 + SSLE | 提前锁定最终性，防监测抢跑 | Electra |
| ePBS + Danksharding 增量 | 构筑长期技术护城河 | F-Star |
| Client Health Sprint | 守底线，防黑天鹅 | 独立推进 |
一句话总结：Deneb 之后，先把共识层打牢；F-Star 再向上叠加 Danksharding 与 ePBS。如果市场需求激增，先用 EIP-4844+ 涨 blob 容量卡位，再循序完成端到端可用性采样。
FAQ
Q1：升级名字为什么总是看不懂的单词？
这是「星座命名法」。Capella 指御夫座 α，Deneb 是天鹅座 α，Electra 是昴宿星团七姐妹之一。如此命名能防止「数字版本」引发的硬性分叉思想。
Q2：提高质押上限是否助长中心化？
更大上限会 降低小型节点数量；但同时减少了 验证者集合膨胀，让轻节点跑得动。未来可调参数+复利曲线自动缓解这一矛盾。
Q3：Inclusion List 如何防止「名单超载」？
有两个限制：
- 对名单总 Gas 设置硬顶，防止掉包。
- 强制最小价格，垃圾交易会被高必要交易挤掉。
Q4：PeerDAS 到底减少了多少节点负荷？
测试网早期数据显示，在全采样情况下，节点网络同步带宽下降 80%，重建延迟稳定在 < 400 ms/1 MiB，一组 128 kB blobs 对硬件几乎无感知。
Q5：客户端代码“大扫除”会影响普通质押者吗？
多数变化对 共识外部接口 保持兼容，无需重新质押或迁移密钥。若出现 Non-breaking HALF-API，会提前三个月公告，统一在窗口期内热升级。
Q6：F-Star 可能再推迟吗？
社区提出「并行渠道」模式：Blob 扩容放在 Electra，ePBS 与 Danksharding 持续跑测试网。即使最后一刻打包拆 X/Y，也不会互卡主网节奏。