欢迎阅读 ChainFeeds PRO # 136。本次内容包含每周更新内容：比特币协议进展、以太坊治理相关、最新研究和进展，和最新论文。
重点
Encrypted frame transactions
以太坊研究员 soispoke 提出了一种同槽（same-slot）加密执行的交易设计，目标是在区块内容与交易顺序已经被 builder 锁定之后，再揭示那些真正会暴露 MEV 机会的执行参数。这样一来，builder 无法在看到明文后临时调整排序、插入策略交易，从而降低抢跑、三明治等 MEV 提取空间。其核心可以概括为三点：
第一、先排序，后执行。
Builder 需要在密钥揭示之前，对完整且有序的交易集合做出承诺（即锁定交易内容与顺序）；随后在同一 slot 内，随着解密密钥的发布，再按照既定顺序执行交易。这一机制使得 builder 在排序阶段无法获取交易的真实执行语义，从而难以基于明文信息进行插单、重排或三明治攻击。需要注意的是，builder 仍然可以看到部分公开信息（如 gas、fee cap、VERIFY 逻辑等），因此该设计主要抑制的是基于执行内容的顺序型 MEV，而并非完全消除所有 MEV。
第二、无需把区块拆分为加密区和明文区。
这一区别于 LUCID 一类本槽提交、下槽解密、并在下一槽区块顶部专门开辟加密执行 lane的方案。soispoke 的设计允许加密交易与普通交易在同一个区块中交错排列，并且在同一个 slot 内完成 reveal 和 execution。这意味着它不依赖额外的专用执行区，而是试图把加密执行更自然地嵌入现有区块构建流程之中。第三、建立在 Frame Transaction（EIP-8141）之上。
该方案将交易拆分为公开的 VERIFY 部分与隐藏的加密执行部分。其中，公开部分负责预先可验证的授权与合法性检查；隐藏部分则把真正敏感的执行参数——例如 target、calldata、priority fee 等——封装并加密，直到 reveal 阶段才被解开。这样设计有两层意义：
为未来的可编程验证逻辑以及后量子签名兼容路径预留空间；
避免将哪些字段必须公开、哪些字段必须隐藏永久写死在交易格式中，而是借助 frame 结构实现更灵活的字段级披露与扩展。
比特币协议进展
共识规则清理：修复比特币核心共识协议中的四个未解决漏洞
前 Wizardsardine 联合创始人 Antoine Poinsot 介绍了软分叉提议 BIP 54（Consensus Cleanup，共识规则清理） 的核心内容。该提议旨在修补比特币共识层中几个长期存在、却常被普通比特币用户忽视的漏洞。这些问题从长期看，可能削弱网络安全性、破坏资源约束，并影响协议的可验证性，因此有必要尽早处理。
重点讨论了四类问题。第一类是时间扭曲攻击：掌握多数算力的矿工可以利用难度调整机制中的实现缺陷，持续压低挖矿难度、异常加快出块速度，极端情况下甚至可能在数十天内拖垮网络。第二类是 超长验证区块：攻击者能够构造验证成本极高的区块，从而拖慢竞争矿工，甚至压垮性能较弱的全节点。第三类是 伪造 SPV 支付证明：由于交易默克尔树存在设计弱点，特殊构造的 64 字节交易可能被用来伪造「已确认付款」的证明，进而误导轻节点或桥接系统。第四类是 重合交易（UTXO 分身）问题：历史上的 coinbase 交易可能出现相同的交易 ID，破坏交易唯一性的基础假设，而既有补丁也并不彻底。
针对上述四类风险，BIP 54 分别提出了相应的规则约束，如限制难度调整周期边界的时间戳、精确定义有害脚本行为、禁用 64 字节交易，以及通过 coinbase 时间锁规则彻底消除重复交易 ID 的风险。整体来看，BIP 54 体现的是一种更偏审慎的协议开发思路：在问题尚未全面爆发之前，先对比特币底层共识中的历史遗留隐患进行清理。
Bitcoin Optech Newsletter #397
暂无重要内容更新
以太坊
研究和进展
Why Ethereum Needs a Dynamically Available Protocol
以太坊基金会成员 Luca Zanolini 论证了下一代以太坊共识协议中的第一层 heartbeat 必须将「动态可用性」（dynamic availability）设为硬性要求。所谓动态可用性，是指只要当前在线并实际参与协议的质押中，大多数是诚实的，链就应继续安全推进并保持活性。这里衡量的标准并不是全部注册验证者中是否有多数在线，而是当下真正醒着的那部分验证者中，诚实者是否占多数。也就是说，即便大量验证者因客户端 bug、云服务故障或网络中断而暂时离线，只要仍在线的多数是诚实的，以太坊就不应停链。动态可用性之所以必须成为硬要求，并不只是出于理论上的完美追求，更因为它直接关系到以太坊最核心的现实目标。
首先，它关系到系统的韧性与自恢复能力。以太坊历史上虽经历过 Merge、客户端故障、云服务商异常等事件，但始终没有真正停机。这是协议设计长期发挥作用的结果。若未来协议仍具备动态可用性，那么即使出现大规模验证者离线，链也能继续出块；待运维问题修复后，参与率自然恢复，系统无需依赖链下协调或人工重启。
其次，动态可用性也是抗审查能力的重要前提。如果一个掌握多数质押的攻击者开始实施交易审查，诚实的少数派必须能够先行构建一条替代分叉，并随着更多参与者识别异常后逐步汇聚共识。动态可用的链为这种抵抗提供了基础；反之，如果协议在少数派场景下直接停摆，诚实方几乎没有自发组织替代链的空间。
最后，动态可用性对应用层连续性至关重要。DeFi、Rollup、跨链桥和预言机等上层应用都建立在 L1 持续运行的前提之上。一旦底层链停摆，清算无法执行、价格无法更新、桥接状态变得不确定、Rollup 证明也无法提交，整个生态都会陷入冻结。因此，对应用而言，最关键的并不是立刻获得终局性，而是 heartbeat 必须持续提供一条可运行、可依赖的可用链。
Revisiting Falcon signature aggregation for PQ mempools
以太坊研究员 Antonio Sanso 和 soispoke 等人讨论了一个很具体的问题：如果以太坊未来采用 Falcon 这类后量子签名方案，签名聚合究竟能否显著降低交易数据体积。为回答这个问题，Antonio Sanso 等人把 Falcon 在以太坊交易中的三种使用方式放在一起比较，并统一从总数据大小的角度分析它们对带宽和存储成本的影响。
第一种是带密钥恢复、不做聚合。在这种方案下，每笔交易使用支持密钥恢复的 Falcon 签名。虽然这种签名本身更大，但验证时可以直接从签名中恢复出公钥和地址，因此交易里不需要额外存储完整公钥。这种思路与当前以太坊通过 ECDSA 签名恢复发送者地址的机制最为接近。
第二种是不带密钥恢复、也不做聚合。这种情况下，单个 Falcon 签名会更小，但由于无法从签名中恢复公钥，每笔交易都必须显式携带完整公钥。因此，尽管签名本身变小了，整体数据开销反而是三种方案中最高的。
第三种是不带密钥恢复，但进行聚合。在这一方案中，每笔交易仍然要包含公钥和 salt，但原本每笔交易各自携带的签名，可以被一个统一的聚合证明替代。因此，当交易数量足够多时，这种方案的边际成本会逐渐下降，并开始体现出体积优势。
最终得出的结论是：
在当前以太坊典型区块规模下，最实用的方案反而是密钥恢复 + 不聚合。因为它不需要复杂的聚合基础设施，且总体体积已经比较低。
聚合并不是没用，但它只有在交易数量足够大时才开始占优。文中的测算显示，大概要到 N≈200 左右，聚合方案才开始比密钥恢复、不聚合更省空间。
即便超过这个拐点，在当前常见的每块约 250 笔交易附近，聚合带来的节省也只是小幅领先，并没有大到足以压倒性胜出。
更关键的是，聚合会引入额外系统复杂度：需要有人生成聚合证明，证明生成和验证也有额外开销；如果想在 mempool 传播阶段真正省带宽，还可能需要更复杂的递归证明式网络架构。
Antonio Sanso 等人认为以今天的参数和以太坊现实场景看，Falcon 签名聚合的收益没有直觉中那么大，短期更现实的折中方案可能是直接采用支持密钥恢复的 Falcon 交易，而不是急着上复杂聚合。
Outcome Preconfs: Verifying Block Commitments Without the Block
jvranek 讨论了在 ePBS 时代，如何让 proposer 在不查看完整区块内容的前提下，确认 builder 是否兑现了预确认承诺。传统方案要么依赖 relay 作为可信中介，要么要求 builder 为每项约束生成 Merkle 或 ZK 证明；但前者与 ePBS 去中介化的方向相违背，后者不仅会增加关键路径延迟，也难以表达更复杂的状态型约束。
为此，jvranek 提出将 EIP-7928 的 Block Access List（BAL）作为统一的验证对象。BAL 是区块执行过程中生成的完整状态写入记录，天然包含账户余额、nonce、存储槽、代码更新及其全局顺序索引等信息。因此，proposer 无需查看交易本身，只要检查 BAL 是否满足相应条件，就可以验证 inclusion、ordering、execution、exclusion 等不同类型的预确认。
在此基础上，jvranek 进一步主张将预确认从保证某笔交易被执行转向保证某种状态结果发生，即 outcome 预确认。这样一来，builder 不必拘泥于某条固定的执行路径，只要最终实现了承诺的状态结果即可。由于 BAL 中每条记录的结构是统一的，任何这类结果约束都可以被写成针对 BAL 的一阶逻辑（FOL）公式，并由同一个 verifier 统一判断真假。这样，新增 preconf 类型时，只需增加新的公式，而不必重写验证器或升级 slashing 基础设施。
总体来看，BAL 有潜力成为 ePBS 时代预确认的一种通用、低延迟、且无需信任中介的验证基础设施。
MEV 相关
The MEV Letter #130
Flashbots 团队推出垂直于 MEV 研究领域的 Newsletter，以下是一些重点摘录：
文章《The Ethereum Foundation Mandate》阐述了以太坊基金会的角色、原则与使命，强调要让 Ethereum 保持无需信任、无需许可，并具备通过「walkaway test」的韧性。
文章《Proof-of-Time: From Trust-Based to Physics-Based Transaction Ordering》提出 OpenTTT，尝试以加密方式证明交易到达顺序，从而减少构建者任意重排带来的 MEV 问题。
文章《Rational Finality Stalls and the Risks of Pre-Finality Actions in Ethereum-Anchored Systems》描述了一种「理性终局停滞」情形：验证者联盟可通过暂时 withholding attestations 来延迟以太坊终局，而不直接破坏共识。
文章《Encrypted frame transactions》提出同 slot 加密执行设计，通过先承诺交易顺序、后公开解密密钥，把排序与执行拆开，以降低排序阶段的可操纵空间。
文章《FOCIL Native Account Abstraction》解释了 FOCIL 与 Frame Transaction 的交互方式，并定义了一个可进入公共内存池、且 omission check 更严格的 FrameTx 子集。
文章《What does the Ethereum Foundation even do?》总结了以太坊基金会对生态长期健康的支持方式，包括资助核心基础设施、研究、教育与开发工作。
视频《All Core Devs - Execution (ACDE) #232, March 12, 2026》讨论了 Glamsterdam devnet 的进展、Hegotá 头部提案选择、Engine API 上的 SSZ，以及其他执行层相关更新。
视频《Glamsterdam Repricings #4, Mar 18, 2026》讨论了 EIP-8037（State Creation Gas Cost Increase）、基准测试更新，以及其他 repricing 相关议题。
视频《Fast Confirmation Rule (FCR) #5, March 17, 2026》围绕 FCR 的规范更新、客户端实现进度与测试情况展开讨论。
📑论文
Open vs. Sealed: Auction Format Choice for Maximal Extractable Value
作者来自：NuConstruct
作者研究了以太坊 MEV 拍卖市场的最优拍卖机制设计，并基于 220 万笔交易数据发现：1. 提取价值分布很不均衡：大多数 MEV 收益不高，但少数机会价值极大，呈现明显的右尾集中。2. 不同类型的 MEV，竞争激烈程度差异很大：有的机会很多搜索者抢，有的竞争较弱。3. 传统收益等价定理不再成立：因为搜索者的估值并不是彼此独立的，而是存在相关性。
