比特币节点是个”重复劳动很多”的机器：同一笔交易，进内存池时要验一次签名，写进区块被别的节点重新验证时又要验一次；同一段锁定脚本，可能被成百上千笔交易反复执行。两块内存缓存就是用来省掉这些重复劳动的——签名缓存记住”哪些签名已经验过”，脚本执行缓存记住”哪些脚本已经跑过结果”。在 v31.1 里，它们共用一个内存预算，旋钮叫 -maxsigcachesize。
参数到底管多大
v31.1 源码给出的定义很直白：-maxsigcachesize=<n>，“限制签名缓存与脚本执行缓存两个体积之和为 <n> MiB”，默认值来自常量 DEFAULT_VALIDATION_CACHE_BYTES，等于 32 MiB。读取参数的那段代码把预算对半劈开：先把 MiB 换算成字节，再除以二，签名缓存和脚本执行缓存各拿一半——所以默认的 32 MiB 实际上是”每块缓存 16 MiB”。注释里还藏着两个细节：先乘后除是为了避免整数截断；把参数设成 0 不会关闭缓存，而是让两块缓存退化成”最多放两个条目”的最小可用状态——想省内存可以这么调，但别指望缓存消失。
源码的默认值注释同样值得一读：32 MiB 这个数是防 DoS 的上限设计，在 64 位系统上大约能放一百万多个条目；由于计数方式的粗疏，实际占用会比标称值略高（约 32.25 MiB）。这个参数带 DEBUG_ONLY 标记，不在 bitcoind -help 的精剪目录里，要用 -help-debug 才看得见。
两块缓存各自在防什么
签名缓存的存在理由写在头文件里：避免对同一笔交易做两次昂贵的 ECDSA 验签——一次是交易被接受进内存池时，一次是节点验证包含它的区块时。比特币脚本里”验签”通常是单笔交易中最贵的计算，缓存一个”已验证”结论等于直接跳过最重的步骤。它的效果在两种场景最明显：重放历史区块做初始同步（大量老交易被重新验证），以及你广播的交易被打包回来再验一遍时。
脚本执行缓存则是给”脚本本身”上保险：某些脚本的哈希操作、签名操作组合执行代价高，执行结果又是确定的（同输入同输出），记住结果就能让重复脚本快速通过。两类缓存都属于”验证加速器”：它们只影响快慢，不影响共识判断——缓存内容只有正确条目，不存在”缓存里存了个错误结论”的算法空间。
什么时候需要动它
绝大多数节点不需要碰这个参数。真正值得调的两类场景：
其一是低内存 VPS——有节点会同时背着 dbcache（UTXO 缓存，默认档最高到 1 GiB 级）和验证缓存，内存吃紧时把验证预算压缩有意义；但要注意两块缓存都会明显拖慢区块验证速度，省下的每一 MiB 都是用 CPU 换的。其二是多实例场景——一台机器跑多个节点容器，各自 32 MiB 的验证缓存会积少成多，统一压低到 8 或 16 MiB 是常见的收纳动作。
反方向的调高则很少有意义：缓存大到能装下几天的全部验签结论之后，命中率的增长就只剩心理安慰。真嫌同步慢，先该动的是脚本校验线程数（-par）和磁盘，而不是这块小缓存。
与 dbcache 的分寸
节点内存里有几笔常被混为一谈的账：dbcache 管 UTXO 集合的热数据，默认档已经到 GiB 级；两块验证缓存合计只有 MiB 量级，动它省不出大空间，真正的内存大头在别处。排障顺序也应如此——先确认磁盘 I/O 与 CPU 才是验证瓶颈，再考虑这类小旋钮。把 -maxsigcachesize 从 32 压到 4，省下的二十几 MiB 可能换来明显拉长的验证时间，多数场景是亏本买卖；反过来，重负载矿机提到 64 或 128 也谈不上离谱，只是别指望命中率因此质变——缓存的收益主要来自重复验证，新链段上它几乎不命中。
还有个核对入口：这个参数属于 DEBUG_ONLY 档，bitcoind -help 的精剪目录里看不见它，想确认线上节点有没有被人改过参数，要翻调试帮助或启动日志里的参数回显，别只查配置文件。
风险提示：调整验证缓存影响的是节点资源占用与同步性能，与持币安全无关；本文数据基于 v31.1 源码，升级后默认值可能变化，请以版本说明为准。本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。