EIP-7639 提议给以太坊节点通信加一个 eth/70 版本：在这个版本上，节点不再请求也不再回答巴黎升级（合并）之前区块的正文与收据查询。提案给出的直接动机是数据体积——2024 年前后客户端历史数据约 500 GB，其中近 400 GB 来自合并前。本文讲清这条历史停供线划在哪里、影响哪些 p2p 消息、为什么以合并为界，以及全量同步将因此改走哪条路。

简化支付验证依赖默克尔证明，常规证明要把兄弟哈希一路带到根。BIP-98 提出快速默克尔树：用零哈希约定与跳过规则，让证明省略可复原的空子树分支。本文拆解常规证明的体积账、压缩成立的数学条件、边界情况的坑，以及这条草案至今没有部署的原因。

以太坊合约之间送 ETH 历来要经过调用语义，而 EIP-5920 草案提出一个 PAY 操作码：弹出地址和金额直接加余额，跳过合约代码执行，也不触发接收方逻辑。提案 2022 年 3 月起处于 Draft 状态。本文讲它与 CALL 的价值转移部分差在哪、为什么不可拒收的进账值得单独立法，以及它和空账户清理提案的牵连。

2015 年的一份提案 BIP-131 想给比特币加一种交易：不逐个列碎inputs，而是声明一个脚本、把链上所有同脚本的旧输出合并花掉，专治收款地址攒出的粉尘堆。提案状态是 Closed，从未进协议。本文讲这个方案的设计、为什么当时不成立，以及它牵出的 UTXO 膨胀问题后来走了别的出路。

BIP114 把一笔输出的多条解锁条件组织成默克尔树：链上只承诺一个根哈希，花币时揭示所用分支加哈希路径，其余条件不上链。本文按体积账、隐私账、计费账拆解 MAST 默克尔化抽象语法树的机制，讲清单元素五百二十字节等脚本上限怎么逼出这套设计，BIP114 为何关闭，以及 Taproot 与 Graftroot 各自接过了哪一半。