区块链密码学【免费下载链接】bitcoinjs-libA javascript Bitcoin library for node.js and browsers.项目地址https://gitcode.com/gh_mirrors/bi/bitcoinjs-lib点击查看免费下载本指南以仓库内 test/fixtures/core/README.md 为主体系统解析 bitcoinjs-lib 测试体系中最特殊的一块直接移植自 Bitcoin Core 官方的数据驱动测试数据fixtures。你将了解到这批数据文件各自验证了库的哪些能力、其 JSON 格式如何被测试代码消费以及 bitcoinjs-lib 刻意排除tx_invalid.json、script*.json、alertTests.raw三类数据的深层原因——这背后是只做交易/区块的解析与签名不做脚本虚拟机与网络交互的架构边界。一、core 夹具目录的定位数据驱动的互操作测试按照 test/fixtures/core/README.md 的说明test/fixtures/core/目录保存的是面向 Bitcoin 各个方面的数据驱动测试data-driven tests for various aspects of Bitcoin。所谓数据驱动指的是测试逻辑与测试数据彻底分离被测的输入/期望输出全部以 JSON 形式存放在数据文件中测试代码只需加载这些文件、逐条断言即可。这批数据的来源不是 bitcoinjs-lib 团队自行编造而是从 Bitcoin Core 官方测试集移植而来因此它们天然承担着互操作性验证的职责只要 bitcoinjs-lib 能通过 Bitcoin Core 社区公认的样本数据就说明其编码/解码行为与比特币主网实际生态保持一致。这也是该目录位于test/fixtures/而非test/integration/的原因——它不依赖任何真实节点或网络属于纯离线、确定性的单元级测试。二、目录内容总览7 个数据文件与对应被测能力目录中除 README 外共有 7 个 JSON 数据文件它们与测试文件 test/bitcoin.core.spec.ts 中的导入一一对应数据文件覆盖主题对应被测 APIbase58_encode_decode.jsonBase58 编解码bs58库编码/解码base58_keys_valid.json合法 Base58Check 地址address.toBase58Checkbase58_keys_invalid.json非法 Base58Check 地址address.fromBase58Check应抛错blocks.json区块序列化解析Block.fromHex/Block#getIdtx_valid.json合法交易反序列化Transaction.fromHexsighash.json签名哈希计算Transaction#hashForSignature/hashForWitnessV0sig_canonical.json/sig_noncanonical.jsonDER 签名的规范/非规范编码script.signature.decode/encode这一对应关系在 test/bitcoin.core.spec.ts 顶部可直观看到8 行 import 语句恰好对应上述 7 类数据sig_canonical与sig_noncanonical合并为一组 DER 测试。三、逐个解析数据文件格式与对应测试3.1 base58_encode_decode.json最朴素的编解码对拍该文件是纯[hex, base58]二元组数组。以 test/fixtures/core/base58_encode_decode.json 开头几行为例[ [, ], [61, 2g], [626262, a3gV], [73696d706c792061206c6f6e6720737472696e67, 2cFupjhnEsSn59qHXstmK2ffpLv2], [00000000000000000000, 1111111111] ]其中既有空串、单字节这样的边界情况也有0000...这样能验证 Base58 算法前导零用1字符表示特性的样本。测试代码test/bitcoin.core.spec.ts对每个二元组做双向断言base58.decode(fb58)的十六进制结果必须等于fhexBuffer.from(fhex, hex)经base58.encode后必须等于fb58。注意这里直接使用第三方bs58库而非 bitcoinjs-lib 自身 API说明该夹具主要用于校验依赖库行为为上层 Base58Check 提供地基保障。3.2 base58_keys_valid.json / base58_keys_invalid.json地址版本字节的验证合法地址文件采用三元组结构[Base58Check 地址, 十六进制 payload, 参数对象]。例如 test/fixtures/core/base58_keys_valid.json 中的[ 1AGNa15ZQXAZUgFiqJ2i7Z2DPU2J6hW62i, 65a16059864a2fdbc7c99a4723a8395bc6f188eb, { addrType: pubkey, isPrivkey: false, isTestnet: false } ]参数对象的三个字段含义addrTypepubkeyP2PKH或scriptP2SH决定使用网络的哪个版本字节isPrivkey是否为私钥格式测试中遇到isPrivkey: true会直接return跳过因为本库的toBase58Check面向地址哈希isTestnet选择bitcoin.networks.testnet还是bitcoin.networks.bitcoin。测试代码test/bitcoin.core.spec.ts先建立映射pubkey → pubKeyHash、script → scriptHash再按网络取版本字节最终断言address.toBase58Check(hash, version)与期望地址一致。版本字节的实际取值可在 ts_src/networks.ts 中查到主网pubKeyHash: 0x00、scriptHash: 0x05测试网pubKeyHash: 0x6f、scriptHash: 0xc4。非法地址文件则是纯字符串数组test/fixtures/core/base58_keys_invalid.json包含空串、单字符x、超长字符串、错误校验和等多种畸形输入。测试断言test/bitcoin.core.spec.tsaddress.fromBase58Check必须抛出匹配/Invalid (checksum|network)|too (short|long)/的错误。与之对应的实现位于 ts_src/address.tsfromBase58Check内部先做 Base58Check 解码校验再readUInt8取出版本字节返回{ version, hash }。3.3 blocks.json区块级解析与哈希验证该文件是对象数组每个对象含id、transactions交易数量与hex完整区块十六进制三个字段。例如 test/fixtures/core/blocks.json 中第一个样本{ id: 0000000000013b8ab2cd513b0261a14096412195a72a0c4827d229dcc7e0f7af, transactions: 9, hex: 0100000090f0a9f110702f80... }测试test/bitcoin.core.spec.ts调用bitcoin.Block.fromHex(f.hex)断言block.getId()等于id、block.transactions!.length等于transactions。getId()的实现位于 ts_src/block.ts它将区块头做双 SHA-256 后按字节反转得到区块 ID——这正是比特币区块浏览器中区块哈希的展示形式。3.4 tx_valid.json只解码、不验证tx_valid.json是这批数据中信息密度最高的文件其头部注释test/fixtures/core/tx_valid.json完整说明了条目格式[[[prevout hash, prevout index, prevout scriptPubKey], [input 2], ...], serializedTransaction, verifyFlags]且只含单个字符串的对象会被忽略Objects that are only a single string are ignored。文件中还包含若干真实历史交易样本的注释说明例如第一个样本对应交易23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63——它包含一个OpenSSL 能接受的非规范编码签名同时是历史上第一笔标准形式的 OP_CHECKMULTISIG 交易。测试消费逻辑test/bitcoin.core.spec.tsif (f.length 1) return;与数据文件头部注释严格呼应跳过纯注释条目用Transaction.fromHex(fhex)解析交易对每个输入断言prevOutHash需先将测试数据reverse()再与txIn.hash比较文件注释明确说明 test data is reversed即测试数据按显示字节序存储而库内部按内部字节序输入索引用txIn.index 0xffffffff与期望值比较库以 UInt32 读取而非 Int32。verifyFlags如P2SH、P2SH,NULLDUMMY字段在测试中被刻意忽略源码中保留了一行 TODO 注释因为 bitcoinjs-lib 不做脚本验证这正呼应了下一节的主题。3.5 sighash.json签名哈希的黄金样本sighash.json以一行表头开头test/fixtures/core/sighash.json[raw_transaction, script, input_index, hashType, signature_hash (result)]每条记录为五元组原始交易 hex、赎回脚本 hex、输入索引、签名哈希类型、期望的签名哈希注意期望值同样是反转后的显示字节序。样本中的hashType既有正数也有负数如-1391424484这是因为原始数据按有符号 32 位存储而库内部按无符号处理。对应测试test/bitcoin.core.spec.ts做了四层验证Transaction.fromHex(txHex)后再toHex()必须原样还原保证解析无损赎回脚本经script.decompile→script.compile往返后字节一致transaction.hashForSignature(inIndex, script, hashType)的结果反转后与期望哈希相等用hashForWitnessV0以hashType 0 ? 0x100000000 hashType : hashType转成 UInt32 后调用确保不抛异常。其中hashType的语义在 ts_src/transaction.ts 有完整定义SIGHASH_ALL 0x01、SIGHASH_NONE 0x02、SIGHASH_SINGLE 0x03、SIGHASH_ANYONECANPAY 0x80另有SIGHASH_OUTPUT_MASK 0x03与SIGHASH_INPUT_MASK 0x80用于位运算提取类型。测试代码还会把 hashType 解析成SIGHASH_ALL | SIGHASH_ANYONECANPAY这类可读名字作为用例标题。3.6 sig_canonical.json / sig_noncanonical.jsonDER 签名的严格性测试sig_canonical.json是规范 DER 签名的十六进制列表test/fixtures/core/sig_canonical.json如300602010002010001及两条完整的 P2PKH 签名样本。测试test/bitcoin.core.spec.ts对每条做decode → encode往返结果必须与原始 hex 完全一致。sig_noncanonical.json则采用描述字符串与 hex 交替排列的结构test/fixtures/core/sig_noncanonical.json每条非法样本前用一句话说明违规点too short:, 30050201FF020001, too long:, 30470221005990e0584b2b238e1dfaad8d6ed69ecc1a4a13ac85fc0b31d0df395eb1ba6105022200002d5876262c288beb511d061691bf26777344b702b00f8fe28621fe4e566695ed01, hashtype:, 304402205990e0584b2b238e1dfaad8d6ed69ecc1a4a13ac85fc0b31d0df395eb1ba610502202d5876262c288beb511d061691bf26777344b702b00f8fe28621fe4e566695ed11, R padded:, 30450221005990e0584b2b238e1dfaad8d6ed69ecc1a4a13ac85fc0b31d0df395eb1ba610502202d5876262c288beb511d061691bf26777344b702b00f8fe28621fe4e566695ed01覆盖的违规类型包括DER 序列过长/过短、hashType 非法、R/S 长度为零、R/S 为负数、R/S 过度填充excessively padded等。测试test/bitcoin.core.spec.ts只取奇数索引的 hexi % 2 ! 0并断言script.signature.decode抛出匹配Expected DER (integer|sequence)|(R|S) value ...|Invalid hashType的错误。底层的严格性来自 ts_src/script_signature.tsdecode先读取末字节作为 hashType用isDefinedHashType校验仅允许0x01/0x02/0x03/0x81/0x82/0x83再交给bip66.decode解析 DER 结构encode则将 64 字节签名拆分 R/S 做 DER 编码后拼接 hashType 字节。整个编解码链路与 Bitcoin Core 的严格 DER 规则保持一致。四、bitcoinjs-lib notes哪些 Bitcoin Core 测试被刻意排除为什么README 明确声明该目录并不包含全部 Bitcoin Core 测试并逐条解释了三个缺失项的取舍理由。这一小节是理解 bitcoinjs-lib 架构边界的关键也是本文档区别于普通测试说明的核心价值所在。4.1 alertTests.raw不直连网络的取舍alertTests.raw是 Bitcoin Core 用于测试系统警报消息处理的数据。README 给出的理由是Bitcoin-js 不直接与比特币网络交互。Bitcoin-js does not interact with the Bitcoin network directly.bitcoinjs-lib 定位是纯客户端密码学/数据结构库它只负责在本地构造、解析、签名和编码数据不实现 P2P 协议、不维护节点状态、不处理网络消息。因此与网络消息层绑定的警报测试对它毫无意义。想要在真实网络上验证行为的用户可以借助仓库 test/integration/_regtest.ts 中的 regtest 集成测试框架另行搭建环境但那不属于 core 夹具的职责范围。4.2 tx_invalid.json无脚本虚拟机Bitcoin Core 的tx_invalid.json专门存放应被判定为无效的交易通常带脚本验证失败原因。README 的解释分两层bitcoinjs-lib 无法执行脚本cannot evaluate Scripts因此测试这个没有意义但它可以解码合法交易所以保留了tx_valid.json。这解释了为什么两个文件一留一删tx_valid.json只要求反序列化能力bitcoinjs-lib 的 Transaction.fromHex 完全可以胜任而tx_invalid.json的判定核心在于脚本执行失败这需要完整的脚本虚拟机Script VM与共识规则引擎超出了本库范围。同理tx_valid.json中的verifyFlags字段如P2SH在测试中也被显式忽略——验证标志本来就是为脚本解释器准备的。4.3 script*.json脚本执行非本库职责script*.json系列Bitcoin Core 中的脚本解释器测试被排除的理由与tx_invalid.json一致bitcoinjs-lib 无法执行脚本使测试失去意义。需要澄清的是bitcoinjs-lib 并非完全没有脚本能力——ts_src/script.ts 提供了脚本的反序列化/再序列化decompile/compile、操作码定义ts_src/ops.ts等工具并用于构建p2pkh、p2sh、p2wpkh等支付模板见 ts_src/payments 目录。它缺少的是在栈上逐条执行操作码并判定真伪的解释器。这三条排除项共同勾勒出 bitcoinjs-lib 的能力边界解码与构造做得到、执行与验证刻意不做。五、从文档到测试bitcoin.core.spec.ts 如何消费这些数据文档描述的数据与测试代码之间是严丝合缝的契约关系。整个测试文件 test/bitcoin.core.spec.ts 按数据文件组织为 5 个 describe 块base58遍历base58_encode_decode.json做双向编解码断言address.toBase58Check / address.fromBase58Check分别消费base58_keys_valid.json与base58_keys_invalid.json前者验证版本字节映射后者验证畸形输入抛错Block.fromHex消费blocks.json断言区块 ID 与交易数量Transaction.fromHex / Transaction消费tx_valid.json与sighash.json验证交易反序列化与签名哈希计算含hashForWitnessV0script.signature.decode消费sig_canonical.json往返一致与sig_noncanonical.json严格抛错。运行方式与仓库其他测试一致例如执行npm test或针对该文件的npx mocha即可在本地复现全部断言。整个套件零网络依赖、零节点依赖这正是数据驱动测试的核心收益任何一次修改若破坏了与 Bitcoin Core 数据的兼容性会立刻被这些黄金样本捕获。六、许可证与引用注意事项README 的最后一部分明确了这批数据文件的版权归属目录中的数据文件版权归The Bitcoin Core developers2012-2014按MIT/X11 软件许可证分发见随附的 COPYING 文件或 opensource.org 的 MIT 许可文本。这意味着虽然数据被嵌入 bitcoinjs-lib 仓库用于测试但其上游著作权仍归 Bitcoin Core 开发者所有任何将这批夹具数据二次分发或引入其他项目的行为都应保留该版权声明并遵循 MIT/X11 条款。这也是在文档中单独开辟 License 小节、而非混入通用项目 LICENSE 的原因——它是对第三方数据来源的诚实标注。总结test/fixtures/core/目录是 bitcoinjs-lib 与比特币生态官方标准之间的校验锚点7 个 JSON 数据文件覆盖 Base58、Base58Check 地址、区块解析、交易反序列化、签名哈希与 DER 签名六大能力全部由 test/bitcoin.core.spec.ts 以数据驱动方式消费README 则用三条简明结论划清了架构边界——不直连网络排除alertTests.raw、不执行脚本排除tx_invalid.json与script*.json、只解码合法交易保留tx_valid.json。理解这份文档及其背后的取舍既能帮你快速上手为 bitcoinjs-lib 贡献新测试也能让你更准确地判断这个库在真实项目中的适用边界。赞分享区块链密码学【免费下载链接】bitcoinjs-libA javascript Bitcoin library for node.js and browsers.项目地址https://gitcode.com/gh_mirrors/bi/bitcoinjs-lib点击查看免费下载相关推荐Bitcoin Core TestGen地址与私钥测试向量的数据驱动生成指南Bitcoin Core TestGen地址与私钥测试向量的数据驱动生成指南 本文围绕 contrib/testgen/README.md https://l区块链金融科技网络密码学BackstopJS 单元测试深度解析test/core 目录下验证逻辑与断言设计指南BackstopJS 单元测试深度解析test/core 目录下验证逻辑与断言设计指南 BackstopJS 是业界领先的视觉回归测试工具专门用于捕获 CS测试前端开发工具Zod测试驱动开发从测试出发设计验证逻辑Zod测试驱动开发从测试出发设计验证逻辑 你是否在开发中遇到过数据验证逻辑漏洞导致的生产事故是否经历过修改验证规则却意外破坏现有功能的痛苦本文将带你通过测后端前端上一篇Backstage v1.31.0 版本深度解析Backend System 1.0 稳定发布与新前端系统演进下一篇DeepChat 部署指南三步跑通三平台的多模型 AI 助手客户端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考