EIP-1459 详解基于 DNS 的以太坊节点发现enrtree 方案【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-1459Node Discovery via DNS定义了如何通过 DNS 分发、验证与更新以太坊节点列表node list的标准化方案。该方案在以太坊 P2P 网络中充当客户端内置 bootstrap 节点列表的替代品使用enrtreeURL 引用节点列表、以 Merkle 树组织 DNS TXT 记录、并用 secp256k1 签名保证列表真实性与完整性。读完本文你将掌握enrtree-root/enrtree-branch/enrtree/enr四类 TXT 记录的格式与含义、DNS zone 文件的实际写法、客户端解析与验证的完整流程以及该设计背后的安全权衡。背景与动机为什么要用 DNS 分发节点列表大多数以太坊客户端内部都硬编码了一批 bootstrap 节点列表作为新节点加入网络的初始入口。EIP-1459 的作者指出这一做法存在三个痛点更新需要发版列表一旦变更必须通过客户端软件升级才能生效节奏慢、成本高列表规模过小现有硬编码列表只包含少量节点新节点几乎没有选择初始入口的余地缺乏弹性无法支撑包含数百个节点、且可定期维护更新的大型列表。EIP-1459 提出的方案用 DNS 节点列表替代客户端 bootstrap 列表具备等价的安全性同时带来额外收益通过遍历节点发现 DHT 而构建的大规模列表可以作为因受限网络策略而无法加入 DHT 的节点的回退选项DNS 列表对以太坊 peering 服务提供商也有价值——他们的客户可以直接把客户端配置成使用该服务商的列表。总体设计认证、可更新的 DNS 节点列表节点列表与enrtreeURL一个节点列表是由任意数量的节点记录node record定义于 EIP-778构成的列表。列表之间可以通过链接link互相引用整个列表使用一把 secp256k1 私钥签名客户端必须持有对应的公钥才能校验列表。客户端通过带enrtreescheme 的 URL 引用某个 DNS 节点列表URL 中包含DNS 名称该列表所在域名签署列表的公钥公钥放在 URL 的 username 部分是压缩后的 32 字节二进制公钥的 base32 编码RFC-4648。官方示例enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2nodes.example.org该 URL 指向 DNS 名称nodes.example.org下的节点列表由公钥0x049f88229042fef9200246f49f94d9b77c4e954721442714e85850cb6d9e5daf2d880ea0e53cb3ac1a75f9923c2726a4f941f7d326781baa6380754a360de5c2b6签名。与 EIP-778 ENR 的关系列表中的每个节点都是一条 EIP-778 定义的以太坊节点记录ENR。ENR 是一种开放的 p2p 连接信息格式其内容为[signature, seq, k, v, ...]形式的 RLP 列表键值对包括id身份方案名如v4、secp256k133 字节压缩公钥、ip、tcp、udp、ip6、tcp6、udp6等详见 EIP-778 的键表。ENR 的文本编码是 RLP 表示的 URL-safe base64 编码并加enr:前缀最大编码大小 300 字节——EIP-1459 中 DNS TXT 记录里出现的enr:叶子条目正是这一文本编码。值得注意的是EIP-778 的作者 Felix Lange 同时也是 EIP-1459 的作者之一两份规范在设计上是一脉相承的。DNS 记录结构把节点列表编码为 Merkle 树列表中的节点被编码为一棵 Merkle 树通过 DNS 协议分发。树的条目存放在 DNS TXT 记录中任意条目的子域名是其文本内容的缩写keccak256 哈希的 base32 编码——这正是 Merkle 树子节点哈希即父节点指针的体现只有内容与哈希对得上条目才被认可。根记录enrtree-root树的根是一条内容如下的 TXT 记录enrtree-root:v1 eenr-root llink-root seqsequence-number sigsignature各字段含义字段说明enr-root包含节点ENR的子树的根哈希link-root包含链接link子树的根哈希sequence-number树的更新序号十进制整数signature对记录内容不含sig部分的 keccak256 哈希所做的 65 字节 secp256k1 EC 签名采用 URL-safe base64RFC-4648编码三种树条目类型子域名上的其余 TXT 记录把哈希映射到以下三种条目类型之一enrtree-branch:h₁,h₂,...,hₙ中间树条目包含若干子树条目的哈希列表enrtree://keyfqdn叶子条目指向位于另一个完全限定域名FQDN上的不同列表。注意此格式与 URL 编码一致只能出现在link-root指向的子树上enr:node-record叶子条目包含一条节点记录记录以 URL-safe base64 字符串编码。注意此格式与 ENR 的规范文本编码一致只能出现在enr-root子树中。树没有规定特定的排列顺序或结构每当树更新时其序列号应递增。任何 TXT 记录的内容都应足够小以适配 UDP DNS 包 512 字节的限制——这同时限制了单个enrtree-branch条目能容纳的哈希数量。完整的 zone 文件示例EIP-1459 给出了标准 zone 文件格式的完整示例; name ttl class type content 60 IN TXT enrtree-root:v1 eJWXYDBPXYWG6FX3GMDIBFA6CJ4 lC7HRFPF3BLGF3YR4DY5KX3SMBE seq1 sigo908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA C7HRFPF3BLGF3YR4DY5KX3SMBE 86900 IN TXT enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2morenodes.example.org JWXYDBPXYWG6FX3GMDIBFA6CJ4 86900 IN TXT enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24 2XS2367YHAXJFGLZHVAWLQD4ZY 86900 IN TXT enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA H4FHT4B454P6UXFD7JCYQ5PWDY 86900 IN TXT enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI MHTDO6TMUBRIA2XWG5LUDACK24 86900 IN TXT enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o逐行解读根记录即域名本身TTL 仅为 60 秒便于列表快速更新它的sig覆盖除sig外的整行内容C7HRFPF3BLGF3YR4DY5KX3SMBE是link-root的根哈希其内容是一条指向morenodes.example.org列表的enrtree://链接叶子JWXYDBPXYWG6FX3GMDIBFA6CJ4是enr-root的根哈希内容是一个含 3 个哈希的enrtree-branch分支条目三个enr:叶子条目分别存放在各自的哈希子域名下内容为 EIP-778 的 URL-safe base64 ENR 文本编码gmlkgnY0iXNlY3AyNTZrMaE前缀对应idv4与secp256k1键值对。客户端协议如何解析并验证列表以查找域名mynodes.org下的节点为例客户端按以下步骤执行解析根记录查询该名称的 TXT 记录检查是否包含合法的enrtree-rootv1条目假设其中enr-root哈希为CFZUWDU7JNQR4VTCZVOJZ5ROV4验证根签名用已知公钥验证根上的签名并检查序列号是否大于或等于该名称此前见过的任何序列号按哈希解析子条目解析哈希子域名的 TXT 记录如CFZUWDU7JNQR4VTCZVOJZ5ROV4.mynodes.org并验证内容与哈希匹配按条目类型分派遇到enrtree-branch解析其中的哈希列表回到第 3 步继续递归解析遇到enr解码、验证节点记录导入本地节点存储。遍历过程中客户端必须跟踪已经解析过的哈希与域名以避免陷入无限循环出于健壮性考虑客户端最好以随机顺序遍历树。按需拉取是推荐的实现方式客户端实现不应在正常运行期间一次性下载整棵树更好的做法是在需要寻找 peer 的时候才按需通过 DNS 请求对应条目。设计理由为什么是 DNS Merkle 树 链接子树为什么选 DNSDNS 几乎永远可用即使在受限网络环境下也能工作查询延迟低且中间解析器可以缓存 DNS 响应无需自建服务器软件节点列表可以部署到任意 DNS 服务商如 CloudFlare DNS、dnsimple、Amazon Route 53使用它们各自的客户端库即可。为什么用 Merkle 树整棵节点列表只需对根做一次签名即可完成认证单个签名认证任意大小的列表哈希子域名保护列表完整性——中间解析器最坏只能阻断访问或阻止更新无法篡改内容序列号防止根被替换为旧版本防回滚客户端可以增量同步更新这对大列表很重要单个条目足够小能放进单个 UDP 包兼容只支持基础 UDP DNS 的环境与缓存解析器配合良好只有根需要短 TTL中间条目与叶子可以缓存数天。为什么存在链接子树链接让列表之间具备**联邦federation与信任网络web-of-trust**能力大型列表的运营者可以把维护工作委托给其他列表提供方如果两个节点列表互相链接用户使用其中任何一个列表都能同时获得两个列表中的节点。链接子树与包含 ENR 的树相互独立目的是让客户端实现可以独立同步这两棵树希望获得尽可能多节点的客户端会先同步链接树把所有被链接的名称加入同步视野sync horizon。安全考量EIP-1459 明确承认基于 DNS 的发现不如基于 DHT 的发现安全因为它依赖受信任方定期发布记录。该发布方可以轻易地只发布自己控制的节点记录从而对 bootstrap 节点实施 eclipse 攻击隔离/垄断节点对网络的视野。因此在使用 DNS 节点列表时客户端应谨慎选择信任的列表发布方并把 DNS 发现定位为 DHT 的回退补充而非唯一入口。小结EIP-1459 通过enrtreeURL、Merkle 树化的 TXT 记录与 secp256k1 根签名为以太坊客户端提供了一条无需发版即可更新、规模可达数百节点、可联邦可缓存的节点发现通道。其核心组件——ENR 叶子条目直接复用 EIP-778 的节点记录格式形成了从节点记录到 DNS 分发再到客户端验证的完整闭环。对于希望自建节点列表或理解以太坊网络引导机制的开发者掌握根记录、分支条目、链接子树与客户端四步验证流程是落地实现与排障的基础。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-1459 详解：基于 DNS 的以太坊节点发现（enrtree 方案）
EIP-1459 详解基于 DNS 的以太坊节点发现enrtree 方案【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-1459Node Discovery via DNS定义了如何通过 DNS 分发、验证与更新以太坊节点列表node list的标准化方案。该方案在以太坊 P2P 网络中充当客户端内置 bootstrap 节点列表的替代品使用enrtreeURL 引用节点列表、以 Merkle 树组织 DNS TXT 记录、并用 secp256k1 签名保证列表真实性与完整性。读完本文你将掌握enrtree-root/enrtree-branch/enrtree/enr四类 TXT 记录的格式与含义、DNS zone 文件的实际写法、客户端解析与验证的完整流程以及该设计背后的安全权衡。背景与动机为什么要用 DNS 分发节点列表大多数以太坊客户端内部都硬编码了一批 bootstrap 节点列表作为新节点加入网络的初始入口。EIP-1459 的作者指出这一做法存在三个痛点更新需要发版列表一旦变更必须通过客户端软件升级才能生效节奏慢、成本高列表规模过小现有硬编码列表只包含少量节点新节点几乎没有选择初始入口的余地缺乏弹性无法支撑包含数百个节点、且可定期维护更新的大型列表。EIP-1459 提出的方案用 DNS 节点列表替代客户端 bootstrap 列表具备等价的安全性同时带来额外收益通过遍历节点发现 DHT 而构建的大规模列表可以作为因受限网络策略而无法加入 DHT 的节点的回退选项DNS 列表对以太坊 peering 服务提供商也有价值——他们的客户可以直接把客户端配置成使用该服务商的列表。总体设计认证、可更新的 DNS 节点列表节点列表与enrtreeURL一个节点列表是由任意数量的节点记录node record定义于 EIP-778构成的列表。列表之间可以通过链接link互相引用整个列表使用一把 secp256k1 私钥签名客户端必须持有对应的公钥才能校验列表。客户端通过带enrtreescheme 的 URL 引用某个 DNS 节点列表URL 中包含DNS 名称该列表所在域名签署列表的公钥公钥放在 URL 的 username 部分是压缩后的 32 字节二进制公钥的 base32 编码RFC-4648。官方示例enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2nodes.example.org该 URL 指向 DNS 名称nodes.example.org下的节点列表由公钥0x049f88229042fef9200246f49f94d9b77c4e954721442714e85850cb6d9e5daf2d880ea0e53cb3ac1a75f9923c2726a4f941f7d326781baa6380754a360de5c2b6签名。与 EIP-778 ENR 的关系列表中的每个节点都是一条 EIP-778 定义的以太坊节点记录ENR。ENR 是一种开放的 p2p 连接信息格式其内容为[signature, seq, k, v, ...]形式的 RLP 列表键值对包括id身份方案名如v4、secp256k133 字节压缩公钥、ip、tcp、udp、ip6、tcp6、udp6等详见 EIP-778 的键表。ENR 的文本编码是 RLP 表示的 URL-safe base64 编码并加enr:前缀最大编码大小 300 字节——EIP-1459 中 DNS TXT 记录里出现的enr:叶子条目正是这一文本编码。值得注意的是EIP-778 的作者 Felix Lange 同时也是 EIP-1459 的作者之一两份规范在设计上是一脉相承的。DNS 记录结构把节点列表编码为 Merkle 树列表中的节点被编码为一棵 Merkle 树通过 DNS 协议分发。树的条目存放在 DNS TXT 记录中任意条目的子域名是其文本内容的缩写keccak256 哈希的 base32 编码——这正是 Merkle 树子节点哈希即父节点指针的体现只有内容与哈希对得上条目才被认可。根记录enrtree-root树的根是一条内容如下的 TXT 记录enrtree-root:v1 eenr-root llink-root seqsequence-number sigsignature各字段含义字段说明enr-root包含节点ENR的子树的根哈希link-root包含链接link子树的根哈希sequence-number树的更新序号十进制整数signature对记录内容不含sig部分的 keccak256 哈希所做的 65 字节 secp256k1 EC 签名采用 URL-safe base64RFC-4648编码三种树条目类型子域名上的其余 TXT 记录把哈希映射到以下三种条目类型之一enrtree-branch:h₁,h₂,...,hₙ中间树条目包含若干子树条目的哈希列表enrtree://keyfqdn叶子条目指向位于另一个完全限定域名FQDN上的不同列表。注意此格式与 URL 编码一致只能出现在link-root指向的子树上enr:node-record叶子条目包含一条节点记录记录以 URL-safe base64 字符串编码。注意此格式与 ENR 的规范文本编码一致只能出现在enr-root子树中。树没有规定特定的排列顺序或结构每当树更新时其序列号应递增。任何 TXT 记录的内容都应足够小以适配 UDP DNS 包 512 字节的限制——这同时限制了单个enrtree-branch条目能容纳的哈希数量。完整的 zone 文件示例EIP-1459 给出了标准 zone 文件格式的完整示例; name ttl class type content 60 IN TXT enrtree-root:v1 eJWXYDBPXYWG6FX3GMDIBFA6CJ4 lC7HRFPF3BLGF3YR4DY5KX3SMBE seq1 sigo908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA C7HRFPF3BLGF3YR4DY5KX3SMBE 86900 IN TXT enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2morenodes.example.org JWXYDBPXYWG6FX3GMDIBFA6CJ4 86900 IN TXT enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24 2XS2367YHAXJFGLZHVAWLQD4ZY 86900 IN TXT enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA H4FHT4B454P6UXFD7JCYQ5PWDY 86900 IN TXT enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI MHTDO6TMUBRIA2XWG5LUDACK24 86900 IN TXT enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o逐行解读根记录即域名本身TTL 仅为 60 秒便于列表快速更新它的sig覆盖除sig外的整行内容C7HRFPF3BLGF3YR4DY5KX3SMBE是link-root的根哈希其内容是一条指向morenodes.example.org列表的enrtree://链接叶子JWXYDBPXYWG6FX3GMDIBFA6CJ4是enr-root的根哈希内容是一个含 3 个哈希的enrtree-branch分支条目三个enr:叶子条目分别存放在各自的哈希子域名下内容为 EIP-778 的 URL-safe base64 ENR 文本编码gmlkgnY0iXNlY3AyNTZrMaE前缀对应idv4与secp256k1键值对。客户端协议如何解析并验证列表以查找域名mynodes.org下的节点为例客户端按以下步骤执行解析根记录查询该名称的 TXT 记录检查是否包含合法的enrtree-rootv1条目假设其中enr-root哈希为CFZUWDU7JNQR4VTCZVOJZ5ROV4验证根签名用已知公钥验证根上的签名并检查序列号是否大于或等于该名称此前见过的任何序列号按哈希解析子条目解析哈希子域名的 TXT 记录如CFZUWDU7JNQR4VTCZVOJZ5ROV4.mynodes.org并验证内容与哈希匹配按条目类型分派遇到enrtree-branch解析其中的哈希列表回到第 3 步继续递归解析遇到enr解码、验证节点记录导入本地节点存储。遍历过程中客户端必须跟踪已经解析过的哈希与域名以避免陷入无限循环出于健壮性考虑客户端最好以随机顺序遍历树。按需拉取是推荐的实现方式客户端实现不应在正常运行期间一次性下载整棵树更好的做法是在需要寻找 peer 的时候才按需通过 DNS 请求对应条目。设计理由为什么是 DNS Merkle 树 链接子树为什么选 DNSDNS 几乎永远可用即使在受限网络环境下也能工作查询延迟低且中间解析器可以缓存 DNS 响应无需自建服务器软件节点列表可以部署到任意 DNS 服务商如 CloudFlare DNS、dnsimple、Amazon Route 53使用它们各自的客户端库即可。为什么用 Merkle 树整棵节点列表只需对根做一次签名即可完成认证单个签名认证任意大小的列表哈希子域名保护列表完整性——中间解析器最坏只能阻断访问或阻止更新无法篡改内容序列号防止根被替换为旧版本防回滚客户端可以增量同步更新这对大列表很重要单个条目足够小能放进单个 UDP 包兼容只支持基础 UDP DNS 的环境与缓存解析器配合良好只有根需要短 TTL中间条目与叶子可以缓存数天。为什么存在链接子树链接让列表之间具备**联邦federation与信任网络web-of-trust**能力大型列表的运营者可以把维护工作委托给其他列表提供方如果两个节点列表互相链接用户使用其中任何一个列表都能同时获得两个列表中的节点。链接子树与包含 ENR 的树相互独立目的是让客户端实现可以独立同步这两棵树希望获得尽可能多节点的客户端会先同步链接树把所有被链接的名称加入同步视野sync horizon。安全考量EIP-1459 明确承认基于 DNS 的发现不如基于 DHT 的发现安全因为它依赖受信任方定期发布记录。该发布方可以轻易地只发布自己控制的节点记录从而对 bootstrap 节点实施 eclipse 攻击隔离/垄断节点对网络的视野。因此在使用 DNS 节点列表时客户端应谨慎选择信任的列表发布方并把 DNS 发现定位为 DHT 的回退补充而非唯一入口。小结EIP-1459 通过enrtreeURL、Merkle 树化的 TXT 记录与 secp256k1 根签名为以太坊客户端提供了一条无需发版即可更新、规模可达数百节点、可联邦可缓存的节点发现通道。其核心组件——ENR 叶子条目直接复用 EIP-778 的节点记录格式形成了从节点记录到 DNS 分发再到客户端验证的完整闭环。对于希望自建节点列表或理解以太坊网络引导机制的开发者掌握根记录、分支条目、链接子树与客户端四步验证流程是落地实现与排障的基础。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考