用 Geth 创世文件搭一条隔离链：chainId、alloc 与 enode 各防什么

接手一个新合约项目，或者想复现某条链上才有的故障，最踏实的做法不是在主网测试网反复横跳，而是用 Geth 在自己机器上拉起一条完全隔离的链。这件事在 Geth 官方文档里有专页讲解，核心工具只有两样：一个创世文件，一套节点互联参数。它们各自防住的错误并不相同，值得分开拆开。

创世文件是一条链的出生证明

搭链的第一现场往往枯燥：一份两三百行的 JSON、一条初始化命令、两三行启动参数。但这份文件之后的每一次改动都会被节点用哈希一票否决，因此团队里通常要求创世文件进版本库、与启动脚本一起评审。本节按字段拆开这份”出生证明”各自绑定了什么。

私有链的第一份文件是 JSON 格式的创世配置：config 段的 chainId 定下这条链的编号，也是交易签名绑定的数字；coinbase 指定出块奖励归属；alloc 段直接把预挖地址与余额写进创世状态，省掉启动后手动发币的循环；difficulty 与共识段落决定出块快慢与出块者规则。用初始化命令把这份 JSON 写进数据目录后，节点才算”有了一条链”。任何字段改动都意味着换了一条链——两个节点只要创世哈希对不上，握手时的分叉标识就不匹配，连同步协商都不会开始。这是第一道隔离：链与链的物理墙。

网络层再补一道：别让你的节点被别人的链找到

创世不同已经保证数据不同步，但节点发现机制还是会让你的节点在公网日志里刷陌生对等点。测试环境通常把发现协议关掉，改用静态对等点列表：每个节点的地址写成 enode 形式，即公钥加主机加端口，运维手工把两三台机器的 enode 填进各自的启动参数。这样网络拓扑小得可以逐个排查，一笔交易从提交到落块的路径完全可控。还有一个常被混淆的双闸设计：网络编号管 P2P 层握手，链编号管签名与 RPC 层的链身份，两者应当保持一致并与公链错开，只改其一会出现”连得上却不同步”或”同步正常但交易被链编号拒签”这类怪现象。

把整套动作连起来看，Geth 私有链的隔离逻辑是分层的：创世哈希决定两条链是不是”同一个宇宙”，链编号决定签名与交易在哪个宇宙里有效，静态 enode 决定这个宇宙里有几台机器。三层各管一段，缺一层就会出现看起来像灵异事件的故障。对只是借用别人测试网的普通用户，同样的三层对照也成立：先对创世哈希与链编号，再确认自己连的端点属于谁，最后才看余额。测试币来得再容易，签名上下文错了，付出的代价却是真实的密钥暴露面。

重放的背面：钱包最该核对的两件事

EIP-155 之后，交易签名绑定的只有链编号，不绑创世哈希。推论值得每个测试环境记住：如果你用同一份 alloc、同一批私钥搭出两条链编号相同的私有链，一条链上的已签名交易可以原样在另一条上重放生效。隔离两条私有链的正确做法是链编号与创世内容都不同。普通用户偶尔也会踩进同构的坑——把钱包 RPC 指向了某个忘记改链编号的公开测试项目，签出的消息和交易从此带着错误上下文。自查只需要两个动作：在钱包里核对当前链编号与预期是否一致，再用节点或浏览器的创世哈希与官方公布值对一次。这两项都匹配，才谈得上后面的余额与授权。（风险提示：本文仅为节点操作与机制说明，不构成任何资产操作建议；在私有链上的任何资产均为测试用途，无真实价值。）