密码学（Cryptography）

约 1893 字大约 6 分钟

2026-05-12

Web3 里的“账户”“签名”“地址”“所有权”都建立在密码学之上。你不需要先成为密码学研究者，但必须知道哪些动作是在证明身份，哪些动作是在授权资产，哪些东西一旦丢失就无法恢复。

为什么要学这个

很多 Web3 新手会把钱包理解成账号系统，把签名理解成登录确认，把地址理解成用户名。这样学到后面会很危险，因为链上系统没有传统互联网那种中心化客服和密码找回。

密码学在这里不是抽象理论，而是产品边界：私钥控制资产，签名表达授权，哈希固定数据，Merkle Tree 让大量数据可以被高效验证。

理解密码学基础，是为了知道什么时候不能“点确认”。

这部分不要求你手推椭圆曲线公式。更现实的目标是：看到钱包弹窗、签名请求、交易哈希、Merkle proof 或合约验证时，能判断它们分别在证明什么。

链上身份不是由平台发给你的，而是由你能否证明自己控制某个私钥决定的。

Web3 的账户系统把“谁有权限”从中心化数据库转成了可验证的数学关系。好处是开放、可组合、无需平台许可；代价是用户和应用都要承担更明确的密钥与签名风险。

难度：初级。 先理解哈希是把任意数据变成固定长度指纹，用来验证数据是否一致。

Hash 函数会把输入数据映射成一段固定长度输出。理想情况下，哪怕输入只改一个字符，输出也会完全不同。链上常用哈希来标识交易、区块、数据承诺和合约字节码。

哈希不是加密。它通常不能被“解密回原文”，用途是验证同一性和完整性。比如你拿到一份合约源码，可以通过哈希或编译结果去检查它是否和链上部署代码一致。

常见用途包括：

难度：初级。 公钥可以公开，用来推导地址或验证签名，但它不是你的登录密码。

Public Key 是和私钥成对出现的公开信息。别人可以用公钥验证某个签名确实来自对应私钥，但不能从公钥反推出私钥。

在以太坊语境里，用户常看到的是地址，而不是完整公钥。地址可以理解成从公钥进一步处理得到的短标识。地址可以公开，私钥绝不能公开。

地址不是身份本身，只是一个可验证控制关系的标识。某个地址“看起来像官方地址”没有意义，真正重要的是它是否来自可信来源、是否和合约文档、官网、区块浏览器验证信息一致。

难度：初级。 私钥是账户控制权本身，任何把私钥暴露给网页、截图、日志或聊天工具的行为都极其危险。

Private Key 用来生成签名，从而证明你控制某个账户。传统互联网里密码泄漏后可以找回或重置，但 Web3 里私钥一旦泄漏，攻击者可以直接转走资产或授权恶意合约。

所以钱包、助记词、硬件钱包、多签和账户抽象，本质上都在解决同一个问题：如何让密钥控制权更安全、更可恢复、更适合真实用户。

私钥管理的基本规则很朴素：

难度：中级。 签名不是“登录弹窗”，而是对某段具体消息或交易内容的授权证明。

Signature 由私钥对消息生成。验证者可以用公钥或地址检查签名是否有效，从而确认这段授权确实来自对应账户。

签名最容易出问题的地方是用户看不懂自己签了什么。产品应该尽量展示可读内容，例如签名目的、域名、链 ID、合约地址、额度、过期时间和风险提示。对 Agent 来说，签名更要有权限边界，不能让模型随意触发高风险授权。

难度：中级。 Merkle Tree 用一组哈希把大量数据组织起来，让你只拿到少量证明也能验证某条数据属于整体。

Merkle Tree 会把很多数据逐层哈希，最后得到一个 root。只要 root 被可信记录下来，某个用户就可以用 Merkle proof 证明“我的数据在这批数据里”，而不用下载全部数据。

它常见于空投名单、轻客户端、状态证明和可验证数据结构。理解 Merkle Tree，有助于理解为什么区块链可以把大量状态组织成可验证结构。

AI Agent 如果要解释交易、判断授权、生成链上操作或帮助用户管理权限，就必须理解签名和密钥的边界。模型可以解释“这笔授权看起来在批准某个 token 额度”，但不能替用户保管私钥，也不能在用户不理解内容时推动签名。

更进一步，AI 输出本身也可能需要被签名、哈希或记录，作为后续审计的证据：某个 Agent 在什么输入下给出了什么建议，用户是否确认，执行结果是否和建议一致。

做一个签名观察练习：

不要用主钱包做练习，不要把助记词或私钥粘贴到任何网页、聊天工具或代码仓库。