Java实战：web3j助记词派生以太坊地址与节点查余额

简介：这是一份基于 Java web3j 的以太坊助记词地址生成与余额查询工程，面向区块链技术学习者、数字货币安全研究者及需要理解 HD 钱包派生机制的开发者。工程支持直连自建或免费以太坊节点，按助记词生成规则做部分反推判断，将单词组约 4.8 亿种情况压缩至 0.3 亿种，缩短约 16 倍，再据此生成地址并与节点交互查询余额、记录结果，相当于一套可运行的硬破解实验环境。压缩包共 53 个文件，以 29 个 jar 依赖库、7 个 java 源码、7 个 class 字节码为主，另含 properties、cofig、txt 等配置与词表文件，整体约 19.79MB，依赖涵盖 web3j、bitcoinj、spongycastle 等，便于在 Eclipse 中直接导入运行。目前已有 4183 人学习下载，适合想深入理解助记词派生、地址生成与节点交互流程的读者参考。

1. 从一份 Java 工程说起：web3j 助记词派生地址与节点查余额到底怎么落地

前阵子拆了一个 Java 工程包，目录里躺着web3j-core-3.6.0.jar、bitcoinj-core-0.14.7.jar、bcprov-jdk15on-1.54.jar这一串依赖，外加一个btceth 2048.txt词表文件。第一眼看上去像是普通的区块链工具集，跑起来才发现它的主线很明确：用助记词按派生规则生成以太坊地址，再直连节点查余额并落库记录。说白了，这是一套把「助记词 → 地址 → 余额」串成流水线的 Java 实现，适合想搞懂 web3j 派生逻辑、想自己搭一套地址批量校验流程的开发者。它不依赖任何第三方托管服务，节点地址写在url.cofig里，自建或公共节点都能接。下面我按「这东西怎么跑起来 → 派生逻辑怎么理解 → 坑在哪」的顺序，把拆包过程里真正有用的部分摊开讲。

2. 工程结构与依赖梳理：先搞清楚每个 jar 在干什么

2.1 目录里到底有什么

拿到压缩包解压后，根目录下是标准的 Eclipse 工程结构：.project、.classpath、.settings三个配置项，src放源码，bin放编译产物，lib放全部第三方 jar，log4j.properties管日志，url.cofig存节点连接信息，btceth 2048.txt是助记词词表。这个布局说明它原本是在 Eclipse 里开发调试的，导入时直接按 Existing Projects into Workspace 走就行。

lib目录里的 jar 可以按职责分成四组，理清楚之后排查问题会快很多：

这里有个细节值得注意：rxjava同时出现了 1.2.4 和 2.2.19 两个版本。web3j 3.6.0 内部用的是 RxJava 1.x 的Observable，而工程里又引入了 2.x，说明业务代码里可能混用了两套异步 API。导入后如果报io.reactivex.Observable和rx.Observable类型冲突，八成就是这里来的。

2.2 导入工程与依赖校验

导入之后第一件事不是急着跑主类，而是确认 classpath 完整。Eclipse 里右键工程 → Build Path → Configure Build Path，检查 Libraries 页签下是否所有lib里的 jar 都被引用。常见做法是直接 Add JARs 把整个 lib 目录勾上，避免漏掉某个间接依赖。

# 如果不用 IDE，纯命令行编译，先把 lib 下所有 jar 拼成 classpath CP=$(find lib -name "*.jar" | tr '\n' ':') javac -encoding UTF-8 -cp "$CP" -d bin $(find src -name "*.java") # 运行主类，注意把 src 下的资源文件目录也加进 classpath java -cp "bin:src:$CP" com.yourpackage.MainClass

这段命令的逻辑是：find lib -name "*.jar"把所有依赖 jar 找出来，tr '\n' ':'把换行替换成 classpath 分隔符，拼成一个长字符串。编译时用-encoding UTF-8是因为源码里大概率有中文注释，不加会报编码错误。运行时把src也加进 classpath，是因为url.cofig、log4j.properties、btceth 2048.txt这些资源文件是按相对路径读取的，工作目录不对就会报 FileNotFoundException。

参数上要留意两点：一是 JDK 版本，web3j 3.6.0 和 bitcoinj 0.14.7 都是比较老的库，用 JDK 8 编译最稳，JDK 11 以上可能碰到模块化相关的反射限制；二是mysql-connector-java-8.0.18对应的驱动类名是com.mysql.cj.jdbc.Driver，如果配置文件里还写着老的com.mysql.jdbc.Driver，连接会直接失败。

2.3 节点配置文件的读法

url.cofig这个文件名是拼错的，正确拼写应该是 config，但代码里读的就是这个名，改文件名反而会找不到。里面通常是一行节点 RPC 地址，格式类似http://127.0.0.1:8545或某个公共节点域名。web3j 通过HttpService或Web3j.build(new HttpService(url))建立连接，走的是标准 JSON-RPC over HTTP。

// 读取节点配置并构建 Web3j 实例 Properties props = new Properties(); try (InputStream in = new FileInputStream("url.cofig")) { props.load(in); } String nodeUrl = props.getProperty("node.url"); // 键名以实际文件为准 Web3j web3j = Web3j.build(new HttpService(nodeUrl)); // 验证连通性：查最新区块号，返回说明节点可用 BigInteger blockNumber = web3j.ethBlockNumber().send().getBlockNumber(); System.out.println("当前区块高度: " + blockNumber);

这段代码的关键在于ethBlockNumber()这个探活调用。很多人上来就直接查余额，结果节点没连上，报的却是余额查询失败，排查方向就偏了。先查区块号，能返回数字说明 HTTP 通、节点同步正常，再去查余额才有意义。HttpService默认超时较短，公共节点响应慢的时候会抛SocketTimeoutException，可以在构造时传入自定义的 OkHttpClient 调大超时时间。

3. 助记词派生地址的核心逻辑：BIP39 与 BIP32/BIP44 怎么串起来

3.1 从助记词到种子的两步走

助记词生成地址不是一步到位的，中间隔着「种子」和「派生路径」两个环节。第一步是 BIP39：把 12 或 24 个单词按词表映射成熵，再经过 PBKDF2-HMAC-SHA512 算出 64 字节的种子。第二步是 BIP32/BIP44：用种子作为根密钥，按m/44'/60'/0'/0/index这条路径逐层派生，最终得到以太坊地址对应的私钥。

btceth 2048.txt就是 BIP39 的英文词表，2048 个单词，每个单词对应 11 位。12 个单词是 132 位，去掉 4 位校验位剩 128 位熵；24 个单词是 264 位，去掉 8 位校验位剩 256 位熵。工程里说的「将单词组 4.8 亿种情况缩短至 0.3 亿种」，本质是在遍历时先做校验位过滤——随机拼出来的单词组合里，绝大多数校验位不通过，直接跳过，不用进入昂贵的 PBKDF2 计算。

// BIP39：助记词 -> 种子 // password 通常为空字符串，除非用户设置了额外的 passphrase byte[] seed = MnemonicCode.toSeed(mnemonicWords, ""); // BIP32：种子 -> 根密钥 -> 按路径派生 DeterministicSeed deterministicSeed = new DeterministicSeed(seed, null, "", 0); DeterministicKeyChain chain = DeterministicKeyChain.builder() .seed(deterministicSeed) .build(); // BIP44 以太坊路径：m/44'/60'/0'/0/0 DeterministicKey key = chain.getKeyByPath( HDPath.parsePath("44'/60'/0'/0/0"), true); ECKey ecKey = ECKey.fromPrivate(key.getPrivKey()); String address = Keys.getAddress(ecKey); // 不带 0x 前缀的地址

逻辑说明：MnemonicCode.toSeed内部做的是 PBKDF2，迭代 2048 次，这是整个流程里最耗 CPU 的一步。DeterministicKeyChain负责 BIP32 的层级派生，HDPath.parsePath把字符串路径解析成层级索引。Keys.getAddress拿到的是 20 字节地址的十六进制表示，前面要补0x才是完整的以太坊地址格式。

参数上最容易搞错的是派生路径。以太坊标准是m/44'/60'/0'/0/index，其中 60 是以太坊的 coin type。有些钱包用m/44'/60'/0'/0/0，有些用m/44'/60'/0'/0，还有的用m/44'/60'/0'。路径不同，派生出来的地址完全不同。如果你拿一个已知助记词在别的钱包里能查到余额，在这个工程里查不到，第一件事就是核对派生路径。

3.2 遍历策略与校验位过滤

工程的核心卖点是把遍历空间压缩了 16 倍，靠的就是 BIP39 的校验位机制。12 个单词的组合理论上是 2048^12，但只有校验位正确的组合才是合法助记词。校验位占 4 位，也就是说大约 1/16 的组合能通过校验。先做校验位判断，再走 PBKDF2 派生，能省掉 15/16 的无效计算。

// 校验位过滤的简化逻辑：先判断助记词是否合法，再决定是否派生 public boolean isValidMnemonic(List<String> words) { try { // MnemonicCode.check 会校验单词是否在词表内、校验位是否正确 new MnemonicCode().check(words); return true; } catch (MnemonicException e) { return false; // 校验失败，直接跳过，不进入 PBKDF2 } }

这个过滤放在派生之前，收益非常明显。PBKDF2 迭代 2048 次，单次耗时在毫秒级，如果对每个组合都跑一遍，CPU 很快就打满了。先做一次纯字符串和位运算的校验，成本可以忽略不计。实际跑的时候建议把过滤和派生拆到不同线程池，过滤线程负责快速筛，派生线程负责重计算，避免快慢任务互相阻塞。

3.3 地址生成后的余额查询

地址生成出来之后，查余额走的是eth_getBalance这个 RPC 方法。web3j 里对应web3j.ethGetBalance(address, DefaultBlockParameterName.LATEST).send()，返回的是以 wei 为单位的 BigInteger。

// 查询余额，注意地址要带 0x 前缀 String addressWithPrefix = "0x" + address; EthGetBalance balanceResp = web3j.ethGetBalance( addressWithPrefix, DefaultBlockParameterName.LATEST).send(); BigInteger balanceWei = balanceResp.getBalance(); // 转成 ether 便于阅读：1 ether = 10^18 wei BigDecimal balanceEther = new BigDecimal(balanceWei) .divide(new BigDecimal("1000000000000000000"), 18, RoundingMode.DOWN); if (balanceWei.compareTo(BigInteger.ZERO) > 0) { // 有余额，落库记录 System.out.println(addressWithPrefix + " -> " + balanceEther + " ETH"); }

参数说明：DefaultBlockParameterName.LATEST表示查最新区块状态下的余额，也可以传具体区块号做历史查询。返回的balanceWei是 wei，除以 10^18 才是 ether。判断余额是否大于零用compareTo，不要用equals，因为 BigInteger 的equals会比较数值和精度，容易出玄学问题。

批量查询时不要一个地址一个请求地串行发，公共节点对请求频率有限制，串行跑几千个地址会被限流甚至封 IP。常见做法是用 RxJava 的flatMap做并发，控制并发数在 5 到 10 之间，配合失败重试。

4. 避坑与常见问题排查

4.1 节点连不上，报 Connection refused 或超时

现象：程序启动后立刻抛ConnectException，或者卡很久之后抛SocketTimeoutException。

原因：url.cofig里的节点地址不可达。自建节点没启动、端口没开、防火墙拦截，或者公共节点已经下线，都会导致这个问题。

解决：先用 curl 手动打一次 JSON-RPC，确认节点本身可用。命令是curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://你的节点地址。能返回区块号说明节点没问题，问题在 Java 侧的配置或网络；返回不了就先解决节点本身。

4.2 派生出来的地址和别的钱包对不上

现象：同一个助记词，在这个工程里生成的地址，在 MetaMask 或其他钱包里查不到，或者地址完全不一样。

原因：派生路径不一致。不同钱包默认路径可能是m/44'/60'/0'/0/0、m/44'/60'/0'/0、m/44'/60'/0'，甚至有些用m/44'/60'/0'/0/0之外的变体。

解决：先确认目标钱包用的是哪条路径，把HDPath.parsePath里的字符串改成对应路径。如果不知道路径，可以遍历几条常见路径，看哪条能派生出已知地址。

4.3 批量查询被节点限流

现象：跑了几百个地址之后，请求开始大量失败，返回 429 或直接超时。

原因：公共节点对单位时间内的请求数有硬限制，串行或高并发都会触发限流。

解决：降低并发数，在请求之间加延迟，或者换自建节点。用 RxJava 的话，flatMap加一个delay操作符，或者用zip配合定时发射来控制速率。自建节点没有这个限制，但要注意节点本身的--rpc.allow-unprotected-txs之类的配置。

4.4 数据库写入报驱动类找不到

现象：余额查到之后落库时报ClassNotFoundException: com.mysql.jdbc.Driver。

原因：mysql-connector-java-8.0.18的驱动类名是com.mysql.cj.jdbc.Driver，配置文件里如果还写着老版本的名字就会找不到。

解决：把 JDBC URL 和驱动类名都改成 8.x 的写法，URL 里加上serverTimezone=UTC避免时区报错。

4.5 内存溢出或 GC 频繁

现象：跑一段时间后抛OutOfMemoryError，或者 GC 日志刷屏，吞吐骤降。

原因：遍历过程中不断创建DeterministicKeyChain、ECKey等对象，没有及时释放；或者把大量地址和余额结果全塞在内存里。

解决：每处理完一批就清理引用，结果直接落库不要攒着。JVM 参数加上-Xmx限制堆大小，配合-XX:+UseG1GC减少 Full GC 频率。如果单机跑不动，考虑把遍历范围分片到多台机器。

5. 进阶技巧：把派生和查询拆成可验证的两段

拆到这个程度，工程的主线已经清楚了。但真正让我觉得值得记一笔的，是它把「派生」和「查询」这两件事解耦得很干净——派生只依赖助记词和路径，查询只依赖地址和节点。这意味着你可以单独验证每一段，而不用每次都跑全流程。

我一般会先写一个最小验证：拿一个已知助记词，用工程里的派生代码生成地址，和 MetaMask 里导入同一个助记词得到的地址比对。地址一致，说明派生逻辑没问题；不一致，就调路径。这一步能排掉八成的「查不到余额」问题，因为很多时候根本不是节点的事，是地址本身就派生错了。

// 最小验证：已知助记词 -> 地址，和钱包比对 String testMnemonic = "your twelve word mnemonic here ..."; List<String> words = Arrays.asList(testMnemonic.split(" ")); byte[] seed = MnemonicCode.toSeed(words, ""); DeterministicSeed ds = new DeterministicSeed(seed, null, "", 0); DeterministicKeyChain chain = DeterministicKeyChain.builder().seed(ds).build(); // 依次试几条常见路径，看哪条能对上 String[] paths = {"44'/60'/0'/0/0", "44'/60'/0'/0", "44'/60'/0'"}; for (String p : paths) { DeterministicKey k = chain.getKeyByPath(HDPath.parsePath(p), true); String addr = "0x" + Keys.getAddress(ECKey.fromPrivate(k.getPrivKey())); System.out.println(p + " -> " + addr); }

这段代码的价值在于把「路径」这个变量单独拎出来试。跑一次就能看到三条路径分别派生出什么地址，和钱包里的地址一比对，路径就确定了。确定之后再回到主流程，把路径写死，后面就不用再纠结。

查询这一段也有个验证技巧：拿一个余额已知的地址，比如某个公开的捐赠地址，用工程的查询代码跑一次，看返回的余额和区块浏览器上的是否一致。一致说明节点和查询逻辑都没问题，不一致就检查节点是不是同步到了最新区块，或者地址前缀有没有漏掉0x。

还有一个容易被忽略的点是助记词的编码。MnemonicCode.toSeed的第二个参数是 passphrase，大多数钱包默认是空字符串，但有些钱包允许用户设置额外的 passphrase，这时候同一个助记词会派生出完全不同的地址。如果你确认路径没错、词也没错，但地址就是对不上，检查一下是不是有 passphrase。

最后说个实操习惯：每次改完路径或节点配置，先跑单条验证，确认无误再开批量。批量跑的时候把日志级别调到 INFO，只记录有余额的地址和失败请求，不要把每个地址的查询结果都打出来，否则日志文件几分钟就上 G。有余额的地址单独落一张表，方便后续复查。从那以后我每次动派生路径或者换节点，都强制先跑一遍单条验证，确认地址和余额都对得上，再放开批量。希望帮到你。

本文还有配套的精品资源，点击获取