EIP-695 解读为 JSON-RPC 引入eth_chainId方法让链身份可查询【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-695 是在以太坊改进提案EIP体系中确立eth_chainIdJSON-RPC 方法的接口标准。它补上了此前 JSON-RPC 无法直接查询 EIP-155 链 IDChain ID的空缺使客户端、钱包与 DApp 能够在连接到任意节点后可靠地识别当前所处区块链。读完本文你将完整掌握eth_chainId的规范定义、调用方式、与net_version的区别以及它在 EIP-1193 Provider、wallet_addEthereumChain等生态标准中的落地形态。一、背景为什么需要一个新的 RPC 方法在 EIP-695 之前JSON-RPC 生态中虽然已有net_version可以用来获取网络 IDNetwork ID却没有一个标准方法可以直接查询链 IDChain ID。二者的语义差异在 EIP-155 提出重放攻击防护后变得至关重要。EIP-155 规定在计算交易签名哈希时除原有的六个 RLP 编码元素(nonce, gasprice, startgas, to, value, data)之外还应追加(chainid, 0, 0)三个元素签名v值取{0,1} CHAIN_ID * 2 35。由于v中编码了链 ID一条在以太坊主网签名的交易无法在 ETC 或其他链上重放这就是重放保护交易的由来。问题在于客户端虽然内部持有CHAIN_ID配置RPC 层却没有暴露它的通道。正如 EIP-695 的 Motivation 所述虽然我们可以用net_version拿到当前网络 ID但没有 RPC 可以查询链 ID这使得通过 RPC 无法确定当前实际运行的区块链。一个 ETH 客户端可能意外连接到了 ETC 的 RPC 端点而不自知——除非它尝试签名交易或获取一条已知带链 ID 签名的交易。这个问题曾给 MetaMask 等应用开发者在实现多链支持时带来实际困扰。二、规范定义EIP-695 属于 Standards Track / Interface 类别状态为 Final要求实现 EIP-155。其核心规范如下。2.1 方法语义eth_chainId返回当前配置的链 ID——即 EIP-155 中用于重放保护交易签名的那一数值。规范中有两条关键约束返回值必须始终对应当前已知头部区块head block中的信息。这保证调用方拿到的链 ID 可以用于在 head 之上构建交易签名不会出现配置值与实际链不一致的窗口。如果当前已知 head 区块没有指定链 ID客户端应将所有eth_chainId调用视为方法不受支持并返回合适的错误。这为不支持 EIP-155 的链/区块阶段保留了明确的行为边界。2.2 参数与返回值Parameters无None。ReturnsQUANTITY类型——当前链 ID 的整数按 JSON-RPC 十六进制编码规则序列化为带0x前缀的字符串。2.3 官方示例规范给出的curl调用示例curl -X POST --data {jsonrpc:2.0,method:eth_chainId,params:[],id:83} // Result { id: 83, jsonrpc: 2.0, result: 0x3d // 61 }注意三点实操细节params必须传空数组[]因为该方法不接受任何参数result是十六进制字符串0x3d对应十进制61——这是当时某条测试链的链 ID也印证了链 ID 不一定是 1的事实返回编码遵循标准 JSON-RPC 十六进制编码规则EIP-695 的 Reference 部分对此有专门说明与eth_getBlockByNumber等方法的QUANTITY编码保持一致。2.4 常见链 ID 速查链 ID 的取值由 EIP-155 统一定义并分配其文档中的链 ID 列表如下CHAIN_IDChain(s)1Ethereum mainnet2Morden (disused), Expanse mainnet3Ropsten4Rinkeby5Goerli42Kovan1337Geth private chains (default)用curl验证主网节点即可得到0x1curl -X POST --data {jsonrpc:2.0,method:eth_chainId,params:[],id:1} node-rpc-url # 期望结果: result: 0x1三、设计动机与安全性为什么消费方应优先使用eth_chainIdEIP-695 的 Rationale 明确指出ETH/ETC 客户端可能在不自知的情况下连接到 ETC/ETH 的 RPC 端点除非它尝试签名或读取一条已知带链 ID 签名的交易这一问题曾给应用开发者如 MetaMask增加多链支持造成麻烦。eth_chainId正是为此提供一个主动、廉价的探测手段。Security Considerations 部分给出了两个方向的指引消费方Consumers应优先使用eth_chainId而非net_version以便可靠地识别正在通信的链。实现方Implementers应正确实现eth_chainId并推动其使用因为链 ID 是 EIP-155 重放攻击防护的关键消费方将依赖它来识别通信对象。换句话说net_version返回的网络 ID 只是历史遗留的网络标识而eth_chainId返回的链 ID 直接参与签名与重放防护语义二者不可混用。四、实现参考与向后兼容EIP-695 的 Implementation 部分列出了三个早期参考实现Parity 的合并请求PR 6329go-ethereum 的合并请求PR 17617go-ethereumClassic 分支的合并请求PR 336。Backwards Compatibility 部分给出的结论是不相关Not relevanteth_chainId是一个新增方法不改变任何既有 RPC 的语义也不与现有方法冲突因此引入它是无破坏性的。但正如上文所述对于不支持 EIP-155 的链或尚未配置链 ID 的区块头规范要求客户端把eth_chainId当作未支持的方法处理并返回错误——这一异常路径是兼容性上的唯一注意事项。五、生态落地从 Provider 到钱包方法的联动eth_chainId并非孤立标准它在仓库中多个后续 EIP 中被直接引用构成了链身份识别的公共底座。这一点从依赖关系即可看出EIP-1193 的requires字段明确列出155, 695。5.1 EIP-1193Provider API 中的 chainIdEIP-1193Ethereum Provider JavaScript API把eth_chainId作为 Provider 层链身份的标准来源connect事件的参数ProviderConnectInfo.chainId必须按eth_chainIdRPC 方法以十六进制字符串指定所连接链的整数 IDchainChanged事件的chainId同样按eth_chainId编码在其request调用示例中DApp 通过Provider.request({ method: eth_chainId })获取链 ID并用parseInt(chainId, 16)转回十进制。// EIP-1193 Appendix II 示例浏览器环境 const ethereum window.ethereum; ethereum .request({ method: eth_chainId }) .then((chainId) { console.log(hexadecimal string: ${chainId}); console.log(decimal number: ${parseInt(chainId, 16)}); }) .catch((error) { console.error(Error fetching chainId: ${error.code}: ${error.message}); });EIP-1193 的 Security Considerations 还强调Provider 必须准确反映客户端配置的链包括保证eth_chainId返回值正确并在该值变化时发出chainChanged事件。可见eth_chainId已成为钱包/Provider 生态中当前链状态的事实标准载体。5.2 EIP-3085 与 EIP-2015钱包方法用它做校验EIP-3085wallet_addEthereumChain钱包必须校验请求中的chainId是否为合法的十六进制字符串、是否为合法链 ID并且必须在chainId与所给 RPC URL 上eth_chainId方法的返回值不一致时拒绝请求。这里eth_chainId被用作这条 RPC 端点到底属于哪条链的权威判据。EIP-2015wallet_updateEthereumChain同样要求钱包在使用rpcUrls前先净化并校验每个 URL包括确保它正确响应net_version和eth_chainId方法。EIP-3326wallet_switchEthereumChain其chainId字段的规范直接引用eth_chainId规定其必须按eth_chainIdEthereum RPC 方法指定链的整数 ID 十六进制字符串。这一联动关系清晰表明凡是涉及当前在哪条链、能否切换/添加链的接口都建立在eth_chainId的可信返回值之上。另外在 EIP-1474RPC 方法总规范的 EIP-712 类型化数据签名示例中chainId也是域分隔domain separator的必要字段进一步说明链 ID 已深入签名与多链交互的各个层面。六、实践建议与小结综合 EIP-695 及其生态引用给出可落地的实践要点识别链优先用eth_chainIdDApp 或钱包在连接节点后先调用eth_chainId确认链身份再决定后续交易、签名与 UI 展示逻辑不要依赖net_version推断链。注意返回编码result是0x前缀的十六进制字符串QUANTITY跨语言处理时需自行完成 hex → 十进制的转换。处理不支持的情况对不支持 EIP-155 或未配置链 ID 的节点eth_chainId会按规范返回方法不支持类错误消费方应给出降级提示。在多链钱包中保持一致性eth_chainId返回值应与 Provider 的chainChanged事件、wallet_switchEthereumChain/wallet_addEthereumChain的chainId参数保持严格一致参见 EIP-1193、EIP-3326、EIP-3085、EIP-2015。EIP-695 用最简洁的方式补全了 JSON-RPC 的链身份能力一个无参数、返回QUANTITY的eth_chainId方法。它源自 EIP-155 的重放防护需求又为后续 Provider 标准化、多链钱包协议奠定了公共基础——这正是它在 EIP 体系中小而关键的地位所在。版权说明本文内容基于 EIP-695 与 EIP-155 等提案整理相关版权按 CC0 协议放弃参见 LICENSE.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-695 解读：为 JSON-RPC 引入 `eth_chainId` 方法，让链身份可查询
EIP-695 解读为 JSON-RPC 引入eth_chainId方法让链身份可查询【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-695 是在以太坊改进提案EIP体系中确立eth_chainIdJSON-RPC 方法的接口标准。它补上了此前 JSON-RPC 无法直接查询 EIP-155 链 IDChain ID的空缺使客户端、钱包与 DApp 能够在连接到任意节点后可靠地识别当前所处区块链。读完本文你将完整掌握eth_chainId的规范定义、调用方式、与net_version的区别以及它在 EIP-1193 Provider、wallet_addEthereumChain等生态标准中的落地形态。一、背景为什么需要一个新的 RPC 方法在 EIP-695 之前JSON-RPC 生态中虽然已有net_version可以用来获取网络 IDNetwork ID却没有一个标准方法可以直接查询链 IDChain ID。二者的语义差异在 EIP-155 提出重放攻击防护后变得至关重要。EIP-155 规定在计算交易签名哈希时除原有的六个 RLP 编码元素(nonce, gasprice, startgas, to, value, data)之外还应追加(chainid, 0, 0)三个元素签名v值取{0,1} CHAIN_ID * 2 35。由于v中编码了链 ID一条在以太坊主网签名的交易无法在 ETC 或其他链上重放这就是重放保护交易的由来。问题在于客户端虽然内部持有CHAIN_ID配置RPC 层却没有暴露它的通道。正如 EIP-695 的 Motivation 所述虽然我们可以用net_version拿到当前网络 ID但没有 RPC 可以查询链 ID这使得通过 RPC 无法确定当前实际运行的区块链。一个 ETH 客户端可能意外连接到了 ETC 的 RPC 端点而不自知——除非它尝试签名交易或获取一条已知带链 ID 签名的交易。这个问题曾给 MetaMask 等应用开发者在实现多链支持时带来实际困扰。二、规范定义EIP-695 属于 Standards Track / Interface 类别状态为 Final要求实现 EIP-155。其核心规范如下。2.1 方法语义eth_chainId返回当前配置的链 ID——即 EIP-155 中用于重放保护交易签名的那一数值。规范中有两条关键约束返回值必须始终对应当前已知头部区块head block中的信息。这保证调用方拿到的链 ID 可以用于在 head 之上构建交易签名不会出现配置值与实际链不一致的窗口。如果当前已知 head 区块没有指定链 ID客户端应将所有eth_chainId调用视为方法不受支持并返回合适的错误。这为不支持 EIP-155 的链/区块阶段保留了明确的行为边界。2.2 参数与返回值Parameters无None。ReturnsQUANTITY类型——当前链 ID 的整数按 JSON-RPC 十六进制编码规则序列化为带0x前缀的字符串。2.3 官方示例规范给出的curl调用示例curl -X POST --data {jsonrpc:2.0,method:eth_chainId,params:[],id:83} // Result { id: 83, jsonrpc: 2.0, result: 0x3d // 61 }注意三点实操细节params必须传空数组[]因为该方法不接受任何参数result是十六进制字符串0x3d对应十进制61——这是当时某条测试链的链 ID也印证了链 ID 不一定是 1的事实返回编码遵循标准 JSON-RPC 十六进制编码规则EIP-695 的 Reference 部分对此有专门说明与eth_getBlockByNumber等方法的QUANTITY编码保持一致。2.4 常见链 ID 速查链 ID 的取值由 EIP-155 统一定义并分配其文档中的链 ID 列表如下CHAIN_IDChain(s)1Ethereum mainnet2Morden (disused), Expanse mainnet3Ropsten4Rinkeby5Goerli42Kovan1337Geth private chains (default)用curl验证主网节点即可得到0x1curl -X POST --data {jsonrpc:2.0,method:eth_chainId,params:[],id:1} node-rpc-url # 期望结果: result: 0x1三、设计动机与安全性为什么消费方应优先使用eth_chainIdEIP-695 的 Rationale 明确指出ETH/ETC 客户端可能在不自知的情况下连接到 ETC/ETH 的 RPC 端点除非它尝试签名或读取一条已知带链 ID 签名的交易这一问题曾给应用开发者如 MetaMask增加多链支持造成麻烦。eth_chainId正是为此提供一个主动、廉价的探测手段。Security Considerations 部分给出了两个方向的指引消费方Consumers应优先使用eth_chainId而非net_version以便可靠地识别正在通信的链。实现方Implementers应正确实现eth_chainId并推动其使用因为链 ID 是 EIP-155 重放攻击防护的关键消费方将依赖它来识别通信对象。换句话说net_version返回的网络 ID 只是历史遗留的网络标识而eth_chainId返回的链 ID 直接参与签名与重放防护语义二者不可混用。四、实现参考与向后兼容EIP-695 的 Implementation 部分列出了三个早期参考实现Parity 的合并请求PR 6329go-ethereum 的合并请求PR 17617go-ethereumClassic 分支的合并请求PR 336。Backwards Compatibility 部分给出的结论是不相关Not relevanteth_chainId是一个新增方法不改变任何既有 RPC 的语义也不与现有方法冲突因此引入它是无破坏性的。但正如上文所述对于不支持 EIP-155 的链或尚未配置链 ID 的区块头规范要求客户端把eth_chainId当作未支持的方法处理并返回错误——这一异常路径是兼容性上的唯一注意事项。五、生态落地从 Provider 到钱包方法的联动eth_chainId并非孤立标准它在仓库中多个后续 EIP 中被直接引用构成了链身份识别的公共底座。这一点从依赖关系即可看出EIP-1193 的requires字段明确列出155, 695。5.1 EIP-1193Provider API 中的 chainIdEIP-1193Ethereum Provider JavaScript API把eth_chainId作为 Provider 层链身份的标准来源connect事件的参数ProviderConnectInfo.chainId必须按eth_chainIdRPC 方法以十六进制字符串指定所连接链的整数 IDchainChanged事件的chainId同样按eth_chainId编码在其request调用示例中DApp 通过Provider.request({ method: eth_chainId })获取链 ID并用parseInt(chainId, 16)转回十进制。// EIP-1193 Appendix II 示例浏览器环境 const ethereum window.ethereum; ethereum .request({ method: eth_chainId }) .then((chainId) { console.log(hexadecimal string: ${chainId}); console.log(decimal number: ${parseInt(chainId, 16)}); }) .catch((error) { console.error(Error fetching chainId: ${error.code}: ${error.message}); });EIP-1193 的 Security Considerations 还强调Provider 必须准确反映客户端配置的链包括保证eth_chainId返回值正确并在该值变化时发出chainChanged事件。可见eth_chainId已成为钱包/Provider 生态中当前链状态的事实标准载体。5.2 EIP-3085 与 EIP-2015钱包方法用它做校验EIP-3085wallet_addEthereumChain钱包必须校验请求中的chainId是否为合法的十六进制字符串、是否为合法链 ID并且必须在chainId与所给 RPC URL 上eth_chainId方法的返回值不一致时拒绝请求。这里eth_chainId被用作这条 RPC 端点到底属于哪条链的权威判据。EIP-2015wallet_updateEthereumChain同样要求钱包在使用rpcUrls前先净化并校验每个 URL包括确保它正确响应net_version和eth_chainId方法。EIP-3326wallet_switchEthereumChain其chainId字段的规范直接引用eth_chainId规定其必须按eth_chainIdEthereum RPC 方法指定链的整数 ID 十六进制字符串。这一联动关系清晰表明凡是涉及当前在哪条链、能否切换/添加链的接口都建立在eth_chainId的可信返回值之上。另外在 EIP-1474RPC 方法总规范的 EIP-712 类型化数据签名示例中chainId也是域分隔domain separator的必要字段进一步说明链 ID 已深入签名与多链交互的各个层面。六、实践建议与小结综合 EIP-695 及其生态引用给出可落地的实践要点识别链优先用eth_chainIdDApp 或钱包在连接节点后先调用eth_chainId确认链身份再决定后续交易、签名与 UI 展示逻辑不要依赖net_version推断链。注意返回编码result是0x前缀的十六进制字符串QUANTITY跨语言处理时需自行完成 hex → 十进制的转换。处理不支持的情况对不支持 EIP-155 或未配置链 ID 的节点eth_chainId会按规范返回方法不支持类错误消费方应给出降级提示。在多链钱包中保持一致性eth_chainId返回值应与 Provider 的chainChanged事件、wallet_switchEthereumChain/wallet_addEthereumChain的chainId参数保持严格一致参见 EIP-1193、EIP-3326、EIP-3085、EIP-2015。EIP-695 用最简洁的方式补全了 JSON-RPC 的链身份能力一个无参数、返回QUANTITY的eth_chainId方法。它源自 EIP-155 的重放防护需求又为后续 Provider 标准化、多链钱包协议奠定了公共基础——这正是它在 EIP 体系中小而关键的地位所在。版权说明本文内容基于 EIP-695 与 EIP-155 等提案整理相关版权按 CC0 协议放弃参见 LICENSE.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考