以太坊节点之间那条看起来只是 TCP 的连接，其实包着一层完整的传输协议：RLPx。它的名字不是缩写——前半段来自以太坊的序列化格式 RLP，后半段照字面写 transport 的 x，规范原文承认它“没有特别含义”。但这层管道的活儿很重：把两个只互相知道公网地址和公钥的陌生进程，变成能加密对话、并行跑多个子协议的伙伴。
握手：先证明你是你
每个节点维护一把静态 secp256k1 私钥，连接的认证围绕它做 ECIES 加密——曲线 secp256k1、拼接式密钥派生、HMAC-SHA256 做认证、AES-128-CTR 做加密，这套密码参数组合在规范开头列得很整齐。发起方先用节点身份签名再套 ECIES 封好第一份认证包；接包方解开后回一份确认包。此后的流量用握手派生的密钥加密，双方各自给出去的每个加密帧都带序号和校验和，一旦校验不过连接即告失败。整套流程里先验 MAC、后信内容，公开信道上的第三方既读不了也插不了。
历史注脚：版本 4 那次修订就是 EIP-8，把握手载荷改成 RLP 并给消息与 Hello 加了“忽略多余列表项”的兼容规则；版本 5 则是 EIP-706 的 snappy 压缩。规范页目前标注当前版本为 5。
能力协商：先摊开要聊什么
握手密文被验通之后、业务开始之前，双方交换一个不含序号、不加密的明文包，俗称 Hello：报自己的客户端名、监听端口、节点公钥，再列一张能力清单——每项能力是一个协议名加版本号，比如 eth/69、snap/2 这样的写法，并各自声明共享内存额度。协商规则简单：两边清单取交集，交集里每一项按顺序拿到一个子协议编号，之后所有帧的头两个字节填这个编号，几百种子协议的消息在同一条 TCP 上互不踩踏。没进交集的协议连帧都不该出现，出现即拆线。
帧的世界
之后的数据被切成帧：载荷超过一定长度就分片，帧头带载荷长度和位置信息，帧体加密、尾部是序号与大端异或后的校验。这套设计的收益是单连接多路复用：同步区块、广播交易、快照加速共用一条链路，不必为每件事另开端口。开销是调试时肉眼读不懂——抓包只能看到密文，网络排障基本要靠客户端自己的日志层。
帧头的校验链
握手完成后双方各自派生出加密与认证密钥，之后每帧的校验和取序号的大端编码前四个字节与上一帧校验值做异或。这个链式设计让丢帧、重复帧和乱序帧不可能被静默吞掉——任何错位都会立刻污染下一个校验值，连接随即断开重来。规范还写明校验失败必须断连：它宁可付一次重连的成本，也不在一根已经歪掉的管线上继续搬运共识数据。
快速问答
问：RLPx和节点发现协议什么关系？
答：发现协议负责“知道有哪些节点、公钥和地址是什么”，RLPx负责“和某个公钥对应的节点把加密会话建起来然后传数据”，一前一后，一个像黄页一个像加密电话线。
问：能力清单谈崩了会怎样？
答：交集为空就没有子协议可跑，规范的处理是发完Hello后断开。现实中常见于版本跨代太久的两台老节点互连。
常见误区
一是以为流量全程加密就包括一切，Hello 握手后的第一个明文包是规范明文规定的例外；二是把能力协商当版本强制门槛，它只是集合求交，谈不拢只是没话可说，不是错误判罚；三是以为一条节点连接天生只对应一个区块链网络，协议族本身把自己定位成服务于以太坊系应用的通用管道，并不绑定某条链。
风险提示：本文为协议机制科普，不构成任何投资建议；自建节点联网配置请遵循官方文档。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。