比特币节点的内存池不是无限大的收件箱。本文拆解 Bitcoin Core 0.12 引入的内存池限制机制：容量上限、按费率驱逐、min relay fee 的动态抬升，以及排队中的交易实际面对的门槛是怎么算出来的。

替换机制从"自愿打信号"走到"节点默认接受任何替换"，只用了几个版本。本文按版本梳理 BIP125 信号规则、Bitcoin Core 28.0 把 mempoolfullrbf 默认值改为开启、29.0 移除该选项的过程，并说明收款方在零确认场景下的现实风险。

节点不必等低费交易送上门再拒绝。BIP133 的 feefilter 消息让节点把自己当前的最低接收费率提前告诉对端，省掉一轮无效的邀请与请求。本文拆解它的动机、量化加噪的隐私考量，以及这个机制会暴露什么。

节点分"只出门"和"待客"两种姿态，区别在入站端口是否可达。本文解释默认出站连接与监听模式的意义、路由器端口映射与UPnP的做法边界、用RPC核对连接数的方法，并划清P2P端口与RPC端口的安全红线。

“客户端多样性”指全网由多套各自独立实现的节点软件共同验证区块。它防的不是对手，而是自己：一套代码里的 bug 一旦被大多数节点执行，就可能让全网络对同一个错误达成共识。本文用 2010 年比特币整数溢出、2018 年 BCH 双重支付事件和 2021 年 Geth 停摆解释为什么这个指标被写进以太坊客户端团队的路线图，并给出个人跑节点时的选择思路。

区块链的安全不靠信任某台服务器，而靠一套同样输入必得同样输出的确定性执行：每个全节点独立重放每一笔交易，核对彼此的状态是否一致。本文解释这个约定如何塑造了合约的能力边界，以及它的代价。

minimumLedgerSlot和getFirstAvailableBlock可以帮助判断Solana RPC节点保留了多少历史。本文区分本地账本裁剪、最早可查区块、跳过slot和归档节点，提供可监控的历史查询分流法。

新节点首次同步最耗时的往往是逐块验签。本文拆解 Bitcoin Core 的 assumevalid 参数：它凭什么跳过历史区块的脚本与签名校验，哪些校验一项没少，和旧式 checkpoints、AssumeUTXO 有何不同，以及想把这点信任也清零的人该怎么设置。

传统的新区块公告是先喊哈希、再等对方来要清单，一来一回多耗一圈。BIP130 允许节点声明偏好，让对方直接把区块头推过来。本文解释这节省下的一个往返在传播链上值多少，以及它和压缩区块、孤块率的关系。

Bitcoin Core 从 0.14.0 起提供 assumevalid 选项并内置默认值：给一个较老的区块哈希，节点跳过该区块及更早区块的脚本验证，只照常检查结构与工作量规则，从而大幅加快初次同步。本文讲清这个假设为什么是安全的（因为之后的工作量是证据）、同步到那个高度附近时校验如何自动恢复，以及什么情况下应该关掉它。