以太坊协议从未规定执行层客户端必须保留多深的可重建状态，重组一来，有的客户端能就地重放、有的只能重新同步。EIP-8252 在 2026 年 4 月提出一个协议级底线：REORG_RETENTION_WINDOW 等于 262144 个区块（8192 个纪元乘每纪元 32 槽，约 36.4 天），要求客户端以快照、反向状态差分或等价表示，保证窗口内每个规范区块的状态可重建，从而覆盖不活跃漏泄约束下的最长非最终期。本文拆解这个常数的来路，以及它为什么只锁窗口不锁手段。
2023 年 4 月上海升级允许验证者把 BLS 提款凭证一次性升级为指向执行层地址的 0x01 型凭证，但改完之后这块信息就锁死了。EIP-7804 提出一种新的执行层请求类型 0x03，让验证者签名请求修改自己的提款凭证——换执行地址，或在 0x01 与 0x02 前缀之间调整。本文解释凭证格式的前缀设计、为什么 Capella 时代选择只给一次性机会，以及把「可改」重新放回协议的安全权衡。
对共识层客户端来说，SSZ 结构的哈希函数 hash_tree_root 是性能瓶颈：它把数据切成 32 字节块、两两递归 SHA-256 合并成树根。EIP-7797 观察到树哈希里每个输入块经填充后消息长度恒为 512 位，于是提出定制版的 SHA-256（SHA256-512）：既然长度已知，就不必走通用实现的完整填充流程。这份 2024 年 10 月的提案目前状态是 Stagnant。本文解释树哈希为什么是瓶颈、定制哈希在什么条件下安全，以及性能路线为什么停在图纸上。
以太坊的 Blob 通道（EIP-4844 体系）按区块现买现走：打包者临时决定带多少 blob，费用随拥堵实时波动。EIP-8256 在 2026 年 5 月提出 Blob Streaming：通过一个叫票据合约（ticket contract）的系统合约提前预订区块容量，让 blob 的传播和费用像预订运输班次一样可预期。它要求 EIP-2935、4788、4844、7002、7594、7732、7918 在前，目前是草案。本文解释提前预订对谁有价值、票据合约与统一费用机制是什么形状，以及即时容量与预订容量两条车道怎么分配。
以太坊的存款合约把执行层付款地址与共识层验证者公钥绑在同一条记录里，任何链上观察者都能拼出谁在质押的对应关系。EIP-8222 提出 Lean Staking：把质押拆成两段——先把 ETH 存入一张待领取存款树、用零知识证明领取——让存款地址与验证者密钥在协议层不再互相指认。这份 2026 年 4 月的草案要求 EIP-6110 与 7251 在前，目前是草案状态。本文解释这个两段流程的形状、失效集合怎么长出来，以及隐私与可审计之间的边界。
比特币核心提供 -stopatheight 与 -stopafterblockimport 两个调试类启动参数，让节点在指定区块高度或磁盘区块导入完成时自动退出。本文依据 v31.0 源码说明两者语义差异、帮助隐藏原因与脚本使用注意事项。
比特币核心 v31.0 移除了 -maxorphantx 启动参数，残留配置会让节点拒绝启动。本文按发布说明与源码梳理该参数原本控制的孤儿交易缓存、失效与删除的时间线，以及升级前的参数自查方法。
比特币核心默认在数据目录写 bitcoind.pid，-pid 参数可改路径。本文依据 v31.0 源码说明相对路径如何按网络隔离、为什么它不承担防止重复启动的职责，以及多实例运维时脚本读 PID 文件的正确姿势。
比特币核心 v31.0 在检测到总内存不低于 4096 MB 时把状态数据库缓存默认值从 450 MB 抬到 1024 MB。本文依据源码梳理这条条件默认值、它与内存池共享内存的关系，以及不同内存机器的取值建议。
比特币核心 v28.0 起，getblockchaininfo、getnetworkinfo、getmininginfo 的 warnings 字段返回全部生效告警的数组，不再只挑一条。本文按发布说明与源码梳理数组化理由、-deprecatedrpc=warnings 临时退路的两个陷阱，以及脚本改造三原则。
