比特币核心默认不把对端 IP 写进 debug.log，控制开关是 -logips。v31.0 源码显示其机制是"不拼接"而非"抹除"。本文拆解实现方式、排障时的正当用法、与 debug 类别的正交关系以及日志身份自查三步。

比特币核心 UTXO 落盘路径上藏着三个非常规参数：进入仅调试帮助表的 dbbatchsize，以及只存在于源码隐藏名单的模拟崩溃开关 dbcrashratio 与启动压缩开关 forcecompactdb。本文按 v31.0 源码说明作用点与误配后果。

挖矿 RPC 客户端组装区块时，比特币核心用 -blockreservedweight 预先保留一段权重给后续的 coinbase 交易。v31.0 默认 8000、安全下限 2000，越界直接拒绝启动。本文拆解它与 blockmaxweight 的相互作用与调参场景。

比特币核心的 -rpcwhitelist 给指定用户圈定可调用的 RPC 方法，而真正的杀招是配对开关 rpcwhitelistdefault：只要写过一条白名单，未登记用户默认全部吃 403。本文按 v31.0 源码拆解判定顺序、批量请求处理与部署清单。

v31.0 比特币核心的 -walletrbf 默认开启，历史上有过从关到开的翻转，且帮助文本标注 RPC only。本文核对 0.14 至 24.0 的默认值时间线、replaceable 选项的优先级与 bip125-replaceable 字段的读法。

比特币核心 v27 起新增 -persistmempoolv1 过渡开关，控制 mempool.dat 写旧版还是当前格式，读端则两种通吃。本文按 v31.0 源码拆解格式兼容设计、降级场景的正确操作顺序与文件容错边界。

比特币核心的 -seednode 让新节点用手动指定的对端取回地址清单，v31.0 源码规定它先于 dnsseed 尝试、列表启动时洗牌，且与 -connect 互斥。本文拆解语义边界、启动节拍与验证方法。

以太坊协议从未规定执行层客户端必须保留多深的可重建状态，重组一来，有的客户端能就地重放、有的只能重新同步。EIP-8252 在 2026 年 4 月提出一个协议级底线：REORG_RETENTION_WINDOW 等于 262144 个区块（8192 个纪元乘每纪元 32 槽，约 36.4 天），要求客户端以快照、反向状态差分或等价表示，保证窗口内每个规范区块的状态可重建，从而覆盖不活跃漏泄约束下的最长非最终期。本文拆解这个常数的来路，以及它为什么只锁窗口不锁手段。

以太坊节点今天校验一个区块，必须先把它带的交易全部执行一遍，才知道状态承诺对不对。EIP-7886 在 2025 年 2 月提出一个颠倒顺序的方案：延迟执行。区块先交上一个执行结果的承诺，节点用前一个状态做少量静态检查就能出证明，真正的执行推迟到之后的区块里完成。这份提案要求 EIP-1559、2930、4844、7623、7702 在前，目前状态是 Stagnant（停滞）。本文解释它想给谁来减负、预收费与快照在结构里扮演什么角色，以及为什么这条路长期停在图纸上。

EIP-8188 在 2026 年 3 月提议给以太坊账户与存储槽的编码加一个 last_written_block 字段，记录这段状态最近一次被改写于哪个区块；写时更新、读时不动，也不改任何 Gas 价格。这份草案想回答一个一直没被直接回答的问题：哪些状态还活着、哪些已经沉睡了很多个区块。本文解释它为什么不翻历史就能知道写入时间、读取为什么不刷新它，以及这份元数据与状态创建成本提案（EIP-8037）怎么互相咬合。