不用研究数学证明，但必须知道每个原语解决什么问题、你的地址/签名/跨链证明分别靠哪个原语撑着。 与 notes/02-密码学三原语.md（哈希/公私钥/数字签名）互补：那篇讲原理，本篇讲"套利工程师视角的取舍与应用"。

0. 一句话本质

密码学四件套在链上分别扮演四个角色：Hash 让数据"不可伪造地代表自己"， Merkle Tree 让"证明一笔交易在一堆数据里"变得高效，ECDSA 让"一个私钥能不可抵赖地授权一笔交易"， BLS 让"多个验证者的签名能压缩成一个"——后者正是 LayerZero/Beacon Chain 这类多验证者系统的效率根基。

1. Hash：SHA256 / Keccak256

是什么：把任意长度输入映射成固定长度输出的单向函数，满足：

  1. 确定性（同输入必同输出）
  2. 雪崩效应（输入差 1 bit，输出几乎全变）
  3. 单向性（不能从输出反推输入）
  4. 抗碰撞（找不到两个不同输入产生相同输出，在计算上不可行）

为什么套利工程师要懂：

  • 地址生成：以太坊地址 = Keccak256(公钥) 取后 20 字节。这意味着地址本身不携带任何"谁拥有"的信息， 只是公钥的哈希——你分析一个陌生地址时，链上唯一能确认的是"能对这个地址签名的人拥有它"， 除此之外的身份都要靠链下信息或行为模式推断（对应 notes/18-链上核查方法论.md）。
  • 交易哈希/区块哈希：任何链上数据被引用（txHash、blockHash）都是靠 Hash 做"指纹"； 篡改一个字段，指纹就变，这是"链不可篡改"的直接来源（见 notes/03-区块与链式结构.md）。
  • CREATE2 地址预测（见 04-Solidity进阶.md）：合约地址可以由 Keccak256(部署者, salt, 字节码) 提前算出—— 这是很多套利/跨链合约"预知未来地址"技巧的数学根。
  • 两种哈希的区别：SHA256 是比特币/通用密码学常用；以太坊生态几乎全用 Keccak256（注意不是标准化后的 SHA3， 以太坊用的是 SHA3 定案前的 Keccak 版本——这个历史细节导致"网上很多 SHA3 库算出来的哈希和链上不一致"， 是新手最容易踩的坑之一）。

2. Merkle Tree：为什么能高效证明"交易存在"

是什么：把一堆数据两两哈希、层层向上聚合，最终得到一个根哈希（Merkle Root）。

        Root = H(H(H(A)+H(B)) + H(H(C)+H(D)))
              /                          \
       H(H(A)+H(B))                H(H(C)+H(D))
        /        \                  /        \
     H(A)        H(B)            H(C)        H(D)
      |            |               |            |
      A            B               C            D

为什么重要：

  • 区块头只存一个 Merkle Root，不存所有交易明细——轻客户端只需下载区块头 + 一条"Merkle 证明路径" （log₂N 个哈希），就能验证某笔交易确实被打包进了这个区块，而不需要下载整个区块的所有交易。
  • 跨链桥的"轻客户端验证"方案（见 09-跨链生态.md）本质就是：B 链验证一个来自 A 链的 Merkle 证明， 确认"A 链确实发生了这个事件"，而不需要 B 链跑一个完整的 A 链全节点。
  • 以太坊状态本身也是 Merkle Patricia Trie 结构——账户余额、合约 Storage 都可以被"轻量证明"， 这是 eth_getProof RPC 方法、以及许多 Layer2 State Proof 方案的基础。

3. ECDSA：为什么钱包签名成立

是什么：Elliptic Curve Digital Signature Algorithm——基于椭圆曲线的数字签名算法。 以太坊用的曲线是 secp256k1（和比特币相同）。

核心流程：

  1. 私钥 d（一个大随机数）→ 通过椭圆曲线乘法生成公钥 Q = d·G（G 是曲线上的固定生成点）。 这个方向"私钥→公钥"极快，反方向"公钥→私钥"（椭圆曲线离散对数问题）在现有计算能力下不可行—— 这就是私钥能保密的数学基础。
  2. 对消息哈希 H(m) 用私钥签名，输出 (r, s)（以太坊交易签名再加一个 v，用于从签名恢复出公钥/地址， 即 ecrecover）。
  3. 任何人拿 (r, s, v) 和消息，通过 ecrecover 就能算出"是哪个地址签的"，不需要公钥单独传输。

套利工程师必须知道的细节：

  • ecrecover 是 Solidity 内置的合约级操作——这是链上验证签名（比如 Permit、多签验证）的基础， 会在 06-Token标准.md（Permit/Permit2）和 05-钱包与账户.md（EIP712）反复出现。
  • 签名的 s 值可延展性（malleability）：ECDSA 签名 (r,s) 和 (r, n-s) 都是有效签名， 这曾是很多合约（尤其早期多签/交易所热钱包）被攻击的漏洞点；EIP-2 规定 s 必须取"低半区"值来消除这一歧义。
  • 每次签名必须使用不同的随机数 k：如果两次签名复用同一个 k，攻击者可以直接解出私钥 （历史上 Sony PS3 私钥泄露、部分早期比特币钱包被盗都是这个原因）。

4. BLS：为什么 LayerZero、以太坊信标链要用它

是什么：Boneh–Lynn–Shacham 签名方案，基于双线性配对（pairing）的椭圆曲线密码学。

和 ECDSA 最大的区别——可聚合性：

  • ECDSA：N 个人签名，就有 N 份独立签名，验证要验 N 次。
  • BLS：N 个人的签名可以聚合成一个签名，验证者只需验证这一个聚合签名， 就能确认"这 N 个人都签了"——验证成本从 O(N) 降到 O(1)。

为什么这对跨链/共识重要：

  • 以太坊信标链：每个 slot 有成百上千验证者对区块投票，如果每个都用 ECDSA 独立验证， 验证开销无法承受；用 BLS 聚合，全部验证者的证明压缩成一个签名上链。
  • LayerZero 的 DVN（去中心化验证者网络）/ 多签跨链桥：多个验证者对同一条跨链消息签名， 用 BLS 聚合能显著降低目标链上验证 gas 成本——这是"未来很多协议"选择 BLS 而非纯 ECDSA 多签的效率原因。

5. 前置名词小词典

  • 椭圆曲线离散对数问题（ECDLP）：已知 Q = d·G 求 d，无高效算法——ECDSA/BLS 安全性的共同数学基础。
  • 公私钥对：私钥保密、公钥公开；公钥可推出地址，私钥推出公钥（单向）。
  • 签名可延展性（Malleability）：同一份签名存在多个数学等价形式，需规范化处理。
  • 配对友好曲线（Pairing-friendly curve）：BLS 依赖的特殊椭圆曲线（如 BLS12-381），支持双线性映射运算。
  • Merkle 证明（Merkle Proof）：从叶子到根路径上的兄弟节点哈希列表，用于证明某叶子属于该树。

6. 常见误区

  • ❌ "地址就是身份" → 地址只是公钥的哈希，谁控制对应私钥谁就是"所有者"，链上无法验证背后的真实身份。
  • ❌ "哈希可以反推" → 单向函数在计算上不可逆，"反推"只能靠碰撞/彩虹表等穷举手段，对 256 位哈希不可行。
  • ❌ "SHA3 和 Keccak256 是一回事" → 标准化的 SHA3 和以太坊用的 Keccak256 在填充规则上不同，输出不一致，混用会导致签名/哈希校验失败。
  • ❌ "BLS 比 ECDSA 更安全" → 二者安全性假设不同（BLS 依赖配对困难问题），BLS 的优势是可聚合性带来的效率，不是"更安全"。

7. 与套利实践的对应 / 自检问题

对应：05-钱包与账户.md（签名生成交易）、06-Token标准.md（Permit 用 ECDSA 离线签名）、 09-跨链生态.md（Merkle 证明/BLS 聚合签名是多数跨链协议验证层的核心）。

自检：

  1. 你的机器人钱包地址是怎么从私钥一步步推出来的？
  2. 为什么轻客户端跨链桥只需要一个 Merkle 证明就能验证"某笔交易在 A 链发生过"？
  3. ecrecover 需要哪三个参数？它验证的是什么？
  4. 为什么以太坊信标链和 LayerZero 的多验证者场景更倾向用 BLS 而不是让每个验证者各自出一份 ECDSA 签名？

── Q&A / 更正记录区（按日期追加）──

原始讨论记录见 Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见 Q&A/README.md。

  • (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)