（1）中心化拓扑（Centralized Topology）—— 第一代P2P网络#

• 结构： 一台中心索引服务器 + 多个客户端节点
• 特点： 并非纯粹的P2P网络；中心索引服务器仅保存接入节点地址信息、提供地址索引服务（区别于C/S架构中服务器提供所有服务）
• 经典案例：Napster 音乐共享软件
  • 中心服务器登记接入节点信息
  • 用户查询 → 通过中心服务器检索 → 得到资源拥有者信息 → 直接连接资源拥有者进行传输
• 优点： 文件查询和传输分离，维护简单，查询高效复杂，资源发现率高；文件传输直接通过P2P，节省中央节点带宽，缩短传输时延
• 缺点： 扩展性非常有限；中心索引服务器一旦故障 → 整个网络无法工作

（2）全分布式非结构化拓扑（Decentralized Unstructured Topology）#

• 结构： 无中心索引服务器，节点拥有真正的对等关系，通过邻居节点通信接入网络
• 组织方式： 随机图
• 数据广播方式： 洪泛（Flooding） —— 节点将接收到的消息向邻居节点转发，直到所有节点都收到或达到TTL限制
• TTL（Time To Live）： 通过设置消息的存活时间来控制消息传播深度
• 查询流程： 节点向邻居发送查询 → 邻居有资源则建立连接传输；否则继续向自己的邻居扩散 → 直到找到资源
• 优点： 可以很快找到源节点到目标节点的路径，实现快速消息传播和资源查找
• 缺点： 可能出现广播风暴（Broadcast Storm）——随网络规模扩大，广播数据急剧增加，低带宽节点因网络资源过载而失效，导致网络分区、断链，资源查询范围受限，网络性能下降

（3）全分布式结构化拓扑（Decentralized Structured Topology）#

• 核心技术： 分布式哈希表（Distributed Hash Tables, DHT）
• 原理： 将存储网络中所有资源信息的哈希表划分成很多不连续的小块，分散存储在多个节点上，每一块由一个节点维护。每个对象的名字/关键词通过加密哈希函数映射为128位或160位的哈希值
• 查询流程： 节点请求资源 → 找到包含对应资源关键词的哈希表所处节点 → 获取资源地址信息 → 连接对应节点实现资源请求与传输
• 优点： 自适应节点加入/退出，均匀分配节点ID，精准查询结果，良好的健壮性、可扩展性和动态适应性；以太坊采用这种拓扑
• 缺点： DHT中的Key是对象的名字或关键词 → 只支持精准关键词匹配查询，不支持模糊语义查询；节点频繁加入/退出造成网络波动，增加DHT维护代价

（4）半分布式拓扑（Partially Decentralized Topology）#

• 结构： 综合中心化和全分布式非结构化的优点
  • 选择网络中性能较高（处理、存储、带宽等）的机器作为超级节点
  • 超级节点存储系统中其他部分节点的文件信息，维护地址、文件索引
  • 超级节点之间形成高速转发层
  • 与接入的普通节点形成自治的簇，簇内采用中心拓扑的P2P网络
• 查询流程： 先在簇内进行 → 超级节点查到资源在相邻叶子节点则转发；否则超级节点间进行有限的洪泛
• 优点： 容易管理，消除网络拥塞隐患，性能与可扩展性有一定优势
• 缺点： 对超级节点依赖性较大，容易受到攻击，影响容错性

按数据内容和验证能力划分#

按承载功能划分（四种功能）#

节点可承载以下四种功能：

1. 钱包（Wallet）： 支持比特币交易、查询等
2. 矿工（Miner）： 运行工作量证明算法争夺创建新块资格，赚取系统奖励和交易手续费
3. 完整区块数据存储（Full Blockchain）： 存储完整数据，独立验证所有交易，无需借助外来参考
4. 网络路由（Network Routing Node）： 所有节点均具有，帮助转发交易和区块数据，发现和维护节点间连接

基础比特币网络四种节点类型#

1. 节点发现（两种方式）#

• DNS种子（DNS seeds）： 客户端维护长期稳定运行节点的列表（种子节点），种子节点提供比特币节点IP地址列表
• -seednode 命令： 指定一个比特币节点的IP地址作为种子节点

2. 握手连接（version/verack）#

节点A向节点B发送version信息，包含以下字段：

• nVersion：客户端采用的比特币P2P协议版本
• nLocalServices：节点支持的本地服务列表（当前仅支持NODE_NETWORK）
• nTime：当前时间
• addrYou：当前节点可见的远程节点IP地址（节点B的IP）
• addrMe：当前节点的IP地址（节点A的IP）
• subver：节点运行的软件类型子版本号
• BestHeight：当前节点区块链的区块高度（初始为0，即只包含创世区块）

节点B收到version后发送verack确认建立连接。

3. 地址传播（addr/getaddr）#

节点A发送包含自己IP地址的addr消息 → 节点B转发给相邻节点 → 节点A信息广播出去。 节点A可向节点B发送getaddr请求，要求发送已知的其他节点IP地址。

4. 地址管理（tried列表和new列表）#

tried列表： 包含64个桶，每个桶存储成功建立过人连接或出连接的64个不同地址。保存最近一次成功连接到该节点的时间戳。桶满时：地址已存在则更新时间戳；否则随机选4个节点，最远一次成功连接的被替换并插入new列表。

new列表： 包含256个桶，每个桶可保存64个尚未成功发起连接的节点地址。利用种子节点或addr消息学习的信息填充。桶满时：遍历所有节点，将时间戳超过30天或多次尝试连接不成功的节点移出桶。

5. 全节点区块同步（getblocks/inv/getdata）#

1. 初始握手version消息含BestHeight字段，节点了解对等节点区块高度
2. 交换getblocks消息（含本地区块链顶端区块的哈希值）
3. 拥有较多区块的一方识别缺少的区块，通过inv消息分批传播（每个inv消息只包含500个区块的Hash信息）
4. 拥有较少区块的一方向所有已连接节点发送getdata请求全区块数据
5. 根据inv消息的哈希值找到缺少的区块数据进行读取

6. SPV节点通信（简易支付验证）#

SPV节点只存区块头部信息。验证步骤：

1. 区块头同步
2. 寻找包含该交易哈希值的区块，验证区块头是否包含在最长链中
3. 获取构造默克尔树所需的交易哈希值，计算默克尔树根的哈希值
4. 若计算出的哈希值与区块中默克尔树根的哈希值相等 → 交易存在于区块中
5. 根据区块头所处位置判断交易确认数——经过6次确认即完成验证

隐私保护： 通过Bloom过滤器从交易集合中过滤选择SPV节点感兴趣的交易，不泄露SPV感兴趣的交易信息，保护隐私。

SPV请求头部： 使用getheaders消息请求区块头部，收到请求的节点用headers消息发送多达2000个区块头。

7. 加密和认证连接#

Tor网络（洋葱路由器）：

• 对传输数据加密和封装，隐藏信息发布者
• 数据链路：用户 → 入口节点（Guard Node）→ 中继节点（多次解密转发）→ 出口节点（Exit Node）
• 入口节点知道发送方地址，出口节点知道目的地地址，中继节点仅知道前后跳
• 每一跳都有独立密钥，保证安全性和无法追踪性

BIP-0150和BIP-0151：

• BIP-0150：定义节点间的对等认证
• BIP-0151：定义两个对等体间的协商加密通信方式
• BIP-0150要求认证前按BIP-0151建立加密通信
• 认证流程：创建密钥对 → 建立加密信道 → AUTHCHALLENGE → AUTHREPLY → AUTHPROPOSE → 验证授权

8. 交易池（Transaction Pool）#

每个节点本地维护一个记录已被网络发现但未被区块链记录的交易的临时列表。

• 交易池： 初始化时为空，只包含未确认交易
• 孤立交易池（Orphan Pool）： 父交易未被节点所知的且未上链的交易；父交易被添加入交易池后，孤立交易移出并加入交易池
• UTXO池（UTXO Pool）： 初始化时已包含很多UTXO条目，只包含已确认交易

节点ID与二叉树#

• 每个节点分配一个随机生成的160位的节点ID
• 网络表示为具有160层的二叉树，所有节点为叶子节点
• 位置由节点ID的最短唯一前缀每一位的值（0或1）确定
• 160位空间非常大，即使有几百个节点也仅占一个小子集 → 节点ID可被视作高度随机

异或距离#

两个节点之间的距离通过对两个节点ID进行异或（XOR） 运算来衡量，异或结果越小，距离越近。

例：3位ID空间，ID为001和100的节点距离：(001 XOR 100) = 101 = 5

子树拆分#

任一节点以自己的视角将二叉树拆分为一系列连续的不包含自己的子树：

• 最高层子树：整棵树中不包含自己的另一半
• 下一层子树：剩下部分中不包含自己的部分
• 以此类推，直到分割完整棵树

通过知道每个子树中至少一个节点，可以通过递归路由不断逼近并最终到达目标节点。

K桶（K Bucket）——路由表#

• 每个节点需要记录每个子树的k个节点（k是平衡系统性能和网络负载的常数）
• 记录一棵子树中k个节点的列表称为一个K桶
• 如果节点ID空间为n位，最多得到n个子树，需要维护n个K桶
• K桶存储与节点距离在[2^i, 2^{i+1}]范围内的k个节点的状态信息（节点ID、UDP端口、IP地址）
• K桶内部按上次访问时间顺序排列：最早访问在头部，最新访问在尾部

以太坊的Kad实现#

• 对节点ID（Eckey算法生成的512位网络节点公钥）使用SHA3算法生成256位哈希码
• 节点距离 = 两个哈希码异或计算结果的1位最高位的位数
• 每个节点有256个K桶，k值 = 16
• K桶中记录节点ID、distance、endpoint、ip等信息，按与目标节点的距离排序

节点加入#

1. 新节点获取任一已加入Kad网络中节点信息，加入对应K桶，向该节点针对自己的ID发起查询请求
2. 对等节点按距离更新自己的K桶，返回k个与新节点最近的节点
3. 新节点将返回节点加入K桶，向这些节点发送查询请求，如此往复建立路由表

节点退出#

不需要任何操作——节点维护K桶时主动把没响应的节点从K桶中删除。当节点信息不存在于任何一个节点的K桶时，相当于退出网络。

K桶更新#

遵循抛弃最近最少访问节点原则：

1. 计算节点本身与新节点的距离，选择对应K桶操作
2. 若新节点信息已在K桶中 → 移动到列表尾部
3. 若不在K桶中：
   • K桶未满 → 直接添加到列表尾部
   • K桶已满 → 检查列表头部最早访问的节点：
     • 有响应 → 头部节点移到尾部，忽略新节点
     • 无响应 → 抛弃头部节点，新节点添加到尾部
   • 保留在线时间长的节点：因为在线时间长的节点继续保持在线概率更大

Kad网络节点查询#

已知某个节点ID，查找当前节点与目标节点距离最短的k个节点的网络信息的过程。

查询流程：

1. 从K桶中选出若干距离目标节点最近的节点，同时发送异步查询请求
2. 收到请求的节点从K桶中找出自己知道的距离目标节点最近的若干节点信息返回
3. 查询发起者收到后更新K桶，从目前已知的较近节点中选出若干没被请求过的节点发送查询请求
4. 重复步骤2和3，直到第n次和第n-1次查询返回结果相等

discv4协议——节点发现#

定义了4种报文命令：

节点生命周期（6种状态）：

节点发现过程： 以随机生成节点ID为目标ID → 从K桶找距离目标节点较近的节点 → 选择离本地节点距离大于离目标节点距离的K桶节点 → 发送FindNode请求 → 用响应的Neighbors报文中节点更新K桶。

rlpx协议——加密和认证连接#

实现完备的前向安全性（每次连接使用不同密钥，即使现有密钥泄露也不会导致之前信道信息被破解）。

两个阶段：

1. 密钥交换（ECDH算法）：
   • 每个节点有自己的公钥和私钥，通信时各自生成临时随机密钥对
   • 通过ECDH算法，使用私钥和对方公钥计算共享密钥
   • ECDH(A私钥, B公钥) = ECDH(B私钥, A公钥)
   • 经过交换后双方都知道共享密钥和随机数
   • 随机数用于生成消息认证码保证消息完整性
2. 身份认证与协议握手：
   • 双方用共享密钥加密hello报文（含P2P版本号、端口号、ID等）
   • 校验协议版本 → 若双方都接受 → 开始建立通信

区块同步#

1. 握手连接（HandShake）→ 节点B将交易池中的交易信息同步给节点A
2. 节点A发送GetBlockHeadersMsg获取同步区块的区块头信息
3. 节点A依次发送GetBlockBodiesMsg、GetReceiptsMsg、GetNodeDataMsg请求获取block body、receipt（合约执行后的结果）和state（储存所有账号状态，包括余额等）
4. 被动同步： 如节点B挖出新区块，发送NewBlockMsg或NewBlockHashesMsg
   • NewBlockMsg → A直接验证并存入本地
   • NewBlockHashesMsg → A通过请求获取区块头和区块体，再组织成完整区块存入本地