比特币节点之间服务紧凑区块过滤器同步的三对消息如何分工，1000与2000两条请求红线为什么直接断连，过滤器头哈希链如何让轻客户端敢信过滤器。以比特币核心v31.0源码为准。

EIP-8146把EIP-7928的区块访问列表从执行载荷里搬出来，走专属gossip主题作为侧车传播，搭建者以keccak256哈希在竞价中承诺，侧车须比载荷早至少一秒可用，同步约72.4KiB对71.7KiB的体量对半砍。

EIP-8101提出把执行载荷拆成自包含的执行块，配合Chunk Access Lists实现乱序到达下的并行流式验证：第N块只要拿到零到N的CAL即可校验，坏块在第一处无效块即刻拒收。本文拆解CAL结构、常量与分叉原子性保证。

EIP-8159在eth p2p协议上新增GetBlockAccessLists与BlockAccessLists两种消息，让同步中的节点能从对等节点取回区块级访问列表BAL，从而复用并行读盘与并行执行能力。本文拆解区块头新增字段、BAL编码与校验规则。

以太坊节点之间广播新交易时，过去只发哈希，接收方往往取回交易才发现类型不支持或体积超限。EIP-5793给eth/68的新交易哈希公告消息加上了交易类型与大小字段。本文拆解这项已生效的网络协议改动解决了什么带宽浪费，以及节点如何据此做拉取决策。

比特币节点同步时不是一块一块排队要数据，而是给每个邻居维持一条在途请求窗口，乱序收块、按高度顺序校验。窗口多大、活怎么派、迟迟不回块的对端怎么处理，本文按比特币核心源码里的调度逻辑逐层拆开。

布隆过滤收款让轻钱包少下载数据，但也给节点带来拒绝服务风险与隐私争议。BIP-111 定义 NODE_BLOOM 服务位，让节点公开声明是否支持过滤，不支持的节点收到过滤请求直接断开对端。本文讲这个 2015 年提案的来龙去脉、协议版本号的配合方式与今天的残局。

轻客户端不下载全链，怎么快速确认某个输出是否仍未被花掉？2014 年提出的 BIP-64 给比特币设计了一条 getutxos 查询消息：按输出点批量提问，节点回一张命中位图和未花费用明细。提案最终关闭从未部署，但它的思路活在比特币核心的 REST 接口里。本文讲清这条消息的结构、能查什么、为什么不可全信。

闪电网络规范里两条长得几乎一样的示警消息：error会让指定通道立刻进入失败流程，warning只要求对方记日志。两者都带通道编号和一段可读文字，用错场景的代价完全不同，这篇文章讲清它们的分工。