3.4 数字签名（Digital Signature）
3.4 数字签名（Digital Signature）
本节摘要：数字签名是区块链交易的"电子盖章"——用私钥签名、公钥验签，同时实现数据完整性、身份认证与抗抵赖三大保证。本节详解签名的生成与验证流程、ECDSA 与 Schnorr 签名算法对比、交易签名的实际步骤，以及多重签名等进阶形态。
上手前先明确
阅读完本节，你应当能够：
- 描述数字签名生成与验证的完整流程
- 解释签名如何同时保证完整性、认证与抗抵赖
- 对比 ECDSA 与 Schnorr 签名的差异
- 说明一笔交易签名与验签的具体步骤
- 理解多重签名（MultiSig）的应用场景
问题与直觉：电子世界怎么"盖章"
现实合同靠签名盖章防抵赖——但纸质签名可以模仿。电子世界里怎么证明"这确实是某人授权的，且内容没被改过"？数字签名就是答案：它用数学把"身份"和"内容"焊在一起。
关键设计：签名不是"签在内容旁边"，而是"签在内容的哈希上"。验签时不仅要验证签名属于谁，还要验证被签的哈希是否等于当前内容的哈希——任何一方不对，验签就失败。所以签名天然绑定了"谁签的"和"签了什么"两件事。
核心原理：签名流程解剖
签名生成（发送方）
- 对交易内容计算哈希（如 SHA-256）
- 用私钥对哈希进行椭圆曲线运算，得到签名（r, s）两个值
- 广播：交易内容 + 签名 + 公钥/地址
验签（任何节点）
- 对收到的交易内容重新计算哈希
- 用发送方公钥 + 签名 (r, s) + 哈希做椭圆曲线验证
- 验证通过 → 交易确实是私钥持有者签名、且内容未篡改
三大保证如何实现
| 保证 | 机制 | 反例 |
|---|---|---|
| 完整性 | 签名绑定内容哈希，内容改→哈希变→验签失败 | 篡改交易金额 |
| 身份认证 | 只有私钥持有者能生成有效签名 | 冒充他人转账 |
| 抗抵赖 | 私钥唯一，签名即铁证 | 事后赖账"我没发过" |
工程实践要点：算法与形态
ECDSA vs Schnorr
| 维度 | ECDSA | Schnorr |
|---|---|---|
| 签名大小 | 64~65 字节 | 64 字节 |
| 批量验证 | 不支持（逐条验） | 支持（聚合加速） |
| 多重签名 | 复杂（需脚本） | 原生支持密钥聚合 |
| 隐私性 | 普通 | 签名聚合可隐藏参与者 |
| 代表链 | 比特币（历史）、以太坊 | 比特币 Taproot、部分新链 |
Schnorr 的"签名聚合"让多签像单签一样小、一样快，是新一代链的升级方向。
一笔比特币交易的签名过程
- 钱包选出要花的 UTXO
- 构造交易：输入（引用 UTXO）+ 输出（收款地址+金额）
- 用私钥对交易内容签名，填入输入的签名脚本
- 广播；节点用公钥验签并检查 UTXO 未花
⚠️ 常见坑：以为"签名=加密"。签名不隐藏内容（交易数据仍公开可见），它只证明"内容是真的、授权是真的"。保密与认证是两件事，别混。
💡 关键直觉：验签不需要"信任"任何一方——任何节点拿到公钥都能独立验证。这就是"无需许可的信任"：不靠关系、不靠身份认证机构，只靠数学。
进阶形态：多重签名（MultiSig）
要求 M-of-N 个签名才能花一笔资产：比如 2-of-3（三人中两人签名才能转账）。用途：共管资金（公司账户）、双因素安全（硬件+软件）、继承方案（家人共同接管）。比特币的 Taproot、以太坊的多签合约都实现了这个模式。
深入：为什么"签哈希"而非"签内容"
数字签名不是直接对长消息签名，而是先哈希再签名，原因有三个：
- 性能：椭圆曲线运算对大数据的开销线性增长，签名 64 字节的哈希比签名几 KB 的交易快得多
- 兼容性：哈希统一了签名对象的长度与格式，算法设计更简单
- 安全性：哈希的雪崩效应保证了"内容任何变化→哈希变化→签名失效"，防篡改更彻底
理解这一点，就能明白为什么"先哈希再签名"是密码学的标准做法，而不只是工程习惯。
数字签名的安全实践
| 场景 | 正确做法 | 常见错误 |
|---|---|---|
| 验签 | 用官方公钥/已验证公钥 | 用攻击者提供的公钥 |
| 签名 | 在可信设备上签 | 在线签名被木马劫持 |
| 随机数 | 每次签名用新随机数 | 复用随机数（可反推私钥！） |
| 时间戳 | 配合可信时间戳 | 无时间戳难防重放 |
| 私钥保管 | 硬件钱包隔离 | 私钥存联网设备 |
⚠️ 常见坑：ECDSA 的随机数必须每次新鲜——历史上多次安全事故（如索尼 PS3 私钥泄露、部分加密货币钱包被盗）都是因为随机数复用，攻击者能从两个签名反推出私钥。这是签名实现里最容易出致命 bug 的地方。
💡 关键直觉：验签是"无需信任"的——任何节点、任何时间、任何机器，只要拿到公钥都能独立验证签名真伪。把"验证"与"信任"解耦，是区块链去信任体系的基石。
数字签名在链外的应用
签名技术远超区块链范畴，在现实世界里同样关键：
| 应用 | 说明 |
|---|---|
| 软件签名 | 操作系统/浏览器校验安装包真伪 |
| 电子合同 | 法律效力的电子签署 |
| 代码签名 | 开发者签名防止代码被篡改 |
| 证书体系 | TLS 证书签发与验证（PKI） |
| 金融交易 | 银联/网银交易的签名验签 |
| 区块链 | 交易授权与身份证明 |
洞察：数字签名是"电子世界的公证章"。你在银行转账、安装软件、登录网站的每个动作背后，几乎都有签名在默默工作。理解它，就是理解互联网信任体系的核心。
签名的工程最佳实践清单
落地签名方案时，把这份清单当安全检查表：
- 算法选型：优先 Ed25519/Schnorr 类现代算法，避免兼容旧坑
- 随机数安全：每次签名新随机数，绝不复用（血泪教训最多的坑）
- 密钥分级：大额/高权限用独立密钥，别一把钥匙走天下
- 验签必做：任何收到的数据先验签再处理，不验签=裸奔
- 失败处理：验签失败要记录日志并告警，不能静默忽略
- 审计留痕：签名动作要可追溯、可审计
一句话：签名是"容易写错、代价致命"的密码学组件——宁可多花时间在随机数与验签流程上，也别省。
数字签名常见疑问速答
问：签名被复制了怎么办（重放攻击）？
签名绑定了具体消息内容，复制签名去签别的消息会验签失败；但若攻击者原样重放同一笔交易（双花场景），就需要"交易序号/nonce"机制防重放——链上协议都有此设计。
问：验签一定需要联网吗？
不需要。验签是纯本地计算，拿到公钥+签名+消息就能验证——这就是"离线验证"能力的来源，也是区块链无需信任第三方的关键。
问：签名会不会泄露私钥信息？
正常实现不会——签名输出与私钥无直接可逆关系。但若随机数使用不当（复用/弱随机），多个签名可反推出私钥，这是实现层面的经典陷阱。
问：量子计算能伪造签名吗？
能威胁基于离散对数的签名（ECDSA、Ed25519）。行业正在向抗量子签名（如基于格的 Falcon、Dilithium）迁移，但工程落地尚需时日。
签名方案选型参考
给设计者一份签名选型速查：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 公链交易（比特币/以太坊） | ECDSA/secp256k1 | 生态兼容、已有验证 |
| 新公链/新钱包 | Schnorr/Ed25519 | 聚合、防侧信道 |
| 多签/共管 | Schnorr 聚合 / 阈值签名 | 签名短、隐私好 |
| 联盟链内部 | Ed25519/BLS | 性能与聚合 |
| 抗量子（前瞻） | 格基签名（Falcon 等） | 后量子安全 |
选型原则：先看生态兼容（链上协议已定），再看性能与隐私需求，最后考虑未来迁移成本。签名算法一旦上线，迁移极难——选型时要往前看十年。
签名完整流程示意
把"签名-验签"的完整数据流画成一张图，作为本节收尾：
图：数字签名完整流程——签名与验签
这张流程图是全章（3.3+3.4）的浓缩：上半部分是签名生成（私钥侧），下半部分是验签（公钥侧）。看懂这张图，就掌握了数字签名的全部要点——生成靠私钥、验证靠公钥、绑定靠哈希。
数字签名概念自检
用这组自检题巩固本节：
- 签名生成与验证各用什么密钥？（私钥签、公钥验）
- 三大保证是什么？（完整性、认证、抗抵赖）
- 为什么先哈希再签名？（性能、兼容、安全）
- ECDSA 与 Schnorr 的差异？（聚合、批量验证）
- 随机数复用的后果？（反推私钥）
自检通过的标准：能画出签名-验签流程图，并解释"为什么签名绑定内容哈希能防篡改"。
数字签名学习小结
把数字签名压缩成一句话记忆卡：
"签名是私钥写给内容的骑缝章"——签名绑定内容的哈希，内容变则验签失败；签名只有私钥能产生，公钥可验证。一个签名同时完成"内容没改+确实是你发的+你不能赖账"三件事。
对比记忆：纸质签名可以被模仿，数字签名无法伪造（数学保证）；纸质签名的真伪靠机构鉴定，数字签名任何人都能验（无需信任）。这就是"去信任化"在身份环节的体现——不需要认证机构，数学就是公证员。
核心回顾
- 签名流程：私钥签哈希→(r,s)，公钥验哈希→通过/拒绝
- 三大保证：完整性、身份认证、抗抵赖一次搞定
- 签哈希的原因：性能、兼容、安全三者兼顾
- ECDSA vs Schnorr：后者支持聚合、批量验证、多签更优
- 交易签名：签名的是交易哈希，节点人人可验
- 随机数纪律：每次签名必须新鲜随机数，复用即泄露私钥
- 签名≠加密：签名不隐藏内容，只证明真实与授权
- 多签应用：共管、双因素、继承，M-of-N 灵活控制
单笔交易签名验签没问题，但一个区块几千笔交易，难道逐笔验证？下一节看 Merkle 树——怎么用一棵树把"验证几千笔交易"压缩成"验证一条路径"。