支撑每条区块链的核心密码学原语
介绍支撑区块链运作的核心密码学原语:哈希函数、数字签名、Merkle 树、椭圆曲线密码学和承诺方案。
- guide
区块链的每一项主张——“这笔交易已最终确定”“这个地址拥有这项资产”“这段历史没有被篡改”——归根结底都依赖于少数几种职责明确的密码学原语。它们没有一项是区块链的发明;哈希函数、数字签名和 Merkle 树都比 Bitcoin 早了几十年。区块链所做的,是把它们组合成一个系统,让这些主张成立时不必信任任何单一方。
本指南会逐一说明真正承担关键作用的原语:为数据生成指纹的哈希函数、授权交易的数字签名、让庞大数据集能够分段验证的Merkle 树、这些签名所依赖的椭圆曲线数学,以及承诺方案——它是通向零知识证明的基础构件。理解每一种原语,是弄清区块链底层实际在做什么的最快途径。
密码学哈希函数(SHA-256、Keccak)

哈希函数接收任意大小的输入,并以确定性的方式生成固定大小的输出,即“摘要”。只要翻转输入中的一个比特,输出就会完全混乱;而要找到两个哈希值相同的不同输入,在计算上不可行。这种抗碰撞性使哈希可作为任意大型数据的紧凑、防篡改指纹。
Bitcoin 在各处使用 SHA-256:每个新区块头都会嵌入前一个区块头的 SHA256(SHA256()) 哈希,因此篡改任何历史区块都会改变其哈希,并破坏后续的每一个区块头(Bitcoin Developer Guide)。同样的双重 SHA-256 构造还会将交易哈希进区块的Merkle 树(Bitcoin.org 参考资料)。
Ethereum 则以 Keccak-256(最初提交的 Keccak 方案,与之后的 NIST SHA-3 标准不同)作为通用哈希标准。每个账户地址都由该账户公钥的 Keccak-256 哈希的最后 20 个字节推导而来(ethereum.org);同一函数也是存储 Ethereum 状态的 Merkle Patricia Trie 中键/值内容寻址的基础。
哈希还会把区块头连接成一条链,而不是一组松散的记录:更改某个区块头会改变其哈希,并使后续区块头中的引用失效。重做后续工作并赶超诚实网络这一额外要求,特指 Bitcoin 的工作量证明共识:攻击者若要更改过去的区块,就必须重做该区块及其后所有区块的工作量证明,再追上诚实链(Bitcoin 白皮书,第 4 节)。其他区块链依据不同的共识规则验证并最终确定历史记录,因此仅靠哈希链接并不会产生这种工作量证明成本。区块头哈希之间的这种直接链接,正是该数据结构被称为区块链的原因。
公钥密码学与数字签名(ECDSA、EdDSA、BLS)

区块链没有登录表单,因此需要另一种方式证明“这笔交易确实来自该账户的拥有者”。公钥密码学通过一对密钥解决这个问题:可以自由分享的公钥以及必须保密的私钥。用私钥为交易签名会生成一份数字签名,任何人都能用公钥验证它——在从不暴露私钥本身的前提下证明授权。
Ethereum 账户使用 secp256k1 曲线上的椭圆曲线数字签名算法(ECDSA)从私钥推导公钥——Bitcoin 使用的也是同一条曲线(ethereum.org 账户文档;EIP-2:secp256k1 签名可塑性修复)。ECDSA 的验证速度快,且经历了数十年的审视;但它有一个与新型设计相关的实际弱点:单份 ECDSA 签名无法高效聚合,所以验证数千份签名就意味着分别进行数千次检查。
EdDSA 和 BLS 签名正是为填补这一空白而生。EdDSA(Solana、Stellar 等链采用)使用不同的曲线构造,具有确定性,并能避免某些过去曾导致 ECDSA nonce 重用漏洞的实现陷阱。BLS 签名更进一步:由于所用曲线具备数学配对性质,许多 BLS 签名可以合并为一份聚合签名,同时验证全部签名。Ethereum 的权益证明共识层恰好依赖这一点——验证者用 BLS 密钥签署证明,让信标链能够把数十万验证者的投票聚合成足够紧凑、能快速验证的签名;这正是大规模权益证明得以实际运行的原因(ethereum.org,《The Beacon Chain》)。Ethereum 还将 BLS12-381 曲线操作作为 EVM 预编译合约公开提供,专门用于支持智能合约中的 BLS 签名验证(EIP-2537)。
Merkle 树

Merkle 树让区块链能将数千笔交易汇总为单个 32 字节哈希,而不必强迫每名参与者存储每一笔交易。叶节点是单个数据项(交易、账户状态)的哈希;每对哈希会连接起来再做一次哈希,如此重复,直到只剩一个哈希,即根节点(Bitcoin Developer Guide)。该根直接存储在区块头中,因此全节点只用几乎不额外占用空间,就能对一个区块的全部内容作出承诺。
其价值在于证明大小。要证明一笔交易被包含在某个区块中,不需要整个区块——只需该交易以及一条“Merkle 分支”,即从该叶节点到根节点路径上的相邻哈希。对于 n 笔交易,通常只需约 log₂(n) 个哈希。这是简化支付验证(SPV)的基础:仅保存区块头的轻量客户端,无须下载整个区块链,也能通过对照区块头根节点检查 Merkle 分支,验证某笔特定交易确实发生过(Bitcoin Developer Guide)。
Ethereum 用 Merkle Patricia Trie 扩展了这一思路。它是 Merkle 树与前缀(基数)Trie 的混合结构,用于存储整个账户状态,而不仅是一张交易列表。每个区块头都携带三个独立的 Trie 根:stateRoot、transactionsRoot 和 receiptsRoot,且每个都可独立证明(ethereum.org)。因此,智能合约或轻客户端无需重放整条链,就能验证单个账户余额或单个存储槽位。
椭圆曲线密码学
椭圆曲线密码学(ECC)是 ECDSA、EdDSA 和 BLS 所共同依赖的数学基础。传统 RSA 依赖大整数分解的难度,而 ECC 依赖椭圆曲线离散对数问题的难度:给定曲线上通过将一个基点反复与自身相加得到的点,要反推出加了多少次在计算上不可行;即使正向计算这个点很容易。正是这种不对称性(一个方向容易、逆向困难)让私钥可以安全地用于签名,同时由其推导的公钥也能安全公开。
具体选择哪条曲线和哪种签名方案很重要。Bitcoin 和 Ethereum 都使用 secp256k1,这是一条由 Standards for Efficient Cryptography Group 标准化、参数经过充分研究的 Koblitz 曲线(SEC 2:推荐椭圆曲线域参数)。其他生态系统会做出不同取舍:Ed25519 是在 Edwards25519 曲线上实例化的具体 EdDSA 签名方案(RFC 8032,§5.1),RFC 8032 认为其经典安全级别约为 128 位(§8.5);BLS12-381 是一条配对友好曲线,为 BLS 签名聚合等运算而选用,EIP-2537 对其安全性的描述是 120 位以上(EIP-2537)。这些估算并不意味着它们具有相同的“每密钥位安全性”:这些系统使用不同的群、编码和假设,名义密钥长度本身也不等于安全强度。例如,NIST 将 128 位经典安全对应到 256–383 位的普通 ECC 密钥,却对应到 3072 位的 RSA 密钥(NIST SP 800-57 Part 1 Rev. 5,表 2)。这有助于解释为何椭圆曲线系统成为区块链账户的默认选择。
承诺方案:通向零知识的桥梁
承诺方案让你能够“锁定”一个值:公开某样能将你绑定到特定数据的东西,却不揭示数据本身;之后再“打开”这项承诺以证明其中是什么。日常类比是一封密封的信:你今天可以把密封信封交给某人,证明你已经决定了答案,而无需让对方看到内容;等你选择日后打开它时,对方才会知道答案,而且一旦封好,你就无法调换其中的答案。
这听上去像一种小型原语,却是大多数零知识证明系统底下真正承重的部分。以 Ethereum 的基于 blob 的数据可用性设计为例:它使用 KZG 多项式承诺,将每个 blob 缩减为一项小型密码学承诺。KZG 证明可以根据该承诺验证某个求值或被抽样的数据单元,但它本身不能证明完整 blob 可用:可用性来自共识层的分发与抽样规则,而 KZG 负责检查所接收数据的完整性(EIP-4844;EIP-7594,PeerDAS)。这种职责分离让验证者能够检查 blob 的一小部分,同时不会把紧凑的求值证明误认为所有 blob 数据已经发布的证明。事实上,Merkle 根本身就是一种简单的承诺方案:它通过根哈希承诺整个数据集,而 Merkle 分支则是揭示其中一部分的“打开”方式。ZK-rollup 在更高级的承诺方案(多项式承诺和向量承诺)之上构建,将整批交易执行压缩为一项可在链上低成本验证的证明;完美零知识与计算零知识会深入讲解这个主题。
对比:区块链密码学原语
| 原语 | 提供的属性 | 链上用途 | 经典密码学与后量子风险 |
|---|---|---|---|
| 哈希函数(SHA-256、Keccak-256) | 抗碰撞的指纹;将区块链接起来 | 区块哈希、地址推导、Merkle 根 | 在当前输出长度下对经典攻击很强;基于哈希的方案通常被认为比当今椭圆曲线签名更能抵御量子攻击 |
| 数字签名——ECDSA | 通过私钥/公钥密钥对授权交易 | Bitcoin 和 Ethereum 的账户签名 | 在经典环境中安全;预计足够强大的大规模量子计算机会攻破基于椭圆曲线的方案,因此 NIST 已标准化后量子替代方案(NIST,2024) |
| 数字签名——EdDSA / BLS | 确定性签名(EdDSA);高效签名聚合(BLS) | Solana/Stellar 签名(EdDSA);Ethereum 验证者证明(BLS) | 与 ECDSA 具有相同的底层椭圆曲线假设,因此面临相同的长期量子暴露风险 |
| Merkle 树 | 对大型数据集的紧凑承诺;小型包含证明 | 区块头、轻客户端(SPV)验证、Ethereum 的状态/交易/收据 Trie | 只依赖底层哈希函数的抗碰撞性,因此继承该哈希的量子安全态势,不会增加新的暴露面 |
| 椭圆曲线密码学 | 紧凑密钥和签名的数学基础 | secp256k1(Bitcoin、Ethereum)、Ed25519、BLS12-381 | 与 ECDSA/EdDSA/BLS 一样会受到未来大规模量子计算机的威胁;这正是后量子迁移研究的主要动力 |
| 承诺方案 | 现在绑定一个值,之后揭示/证明它,同时不预先暴露它 | Ethereum 数据可用性中的 KZG 承诺;作为简单承诺的 Merkle 根;ZK-rollup 的基础构件 | 安全性取决于用来构建方案的底层哈希或椭圆曲线假设 |
这与代币化域名有何关联
当你将一个域名代币化时,这些原语中的每一种都会直接出现。代表所有权的NFT(非同质化代币)受链上账户和代币授权规则保护。若由外部拥有账户(EOA)持有,该账户的私钥可授权账户操作;合约账户没有私钥,而是由代码控制(ethereum.org,Ethereum 账户)。对于 ERC-721 代币,获批地址或操作员也可以发起转移(ERC-721)。因此,如果资产由自行控制的 EOA 持有,硬件钱包以及对助记词(恢复短语)的谨慎保管非常重要;而智能合约钱包和托管钱包会引入不同的授权与信任边界。域名的所有权记录存在于同一个由 Merkle 承诺保护的状态中,该状态也保障着链上所有其他账户余额和智能合约;这正是代币化域名能拥有与任何其他链上资产同样的防篡改证据的原因——可转让、可验证,且无需把注册商的数据库作为唯一的可信来源就能证明所有权。
理解这些原语还能厘清代币化改变了什么、没有改变什么:域名的 DNS 记录和注册局状态仍遵循 ICANN 规则,但其所有权证明现在运行在上述密码学之上,而不再依赖受登录保护的注册商账户。想了解更完整的图景,请参阅区块链共识机制和区块链扩展方案;或直接在 namefi.io 开始代币化。
来源与延伸阅读
- Bitcoin Developer Guide — Block Chain,通过前一个区块头的 SHA256(SHA256()) 实现链式连接
- Bitcoin — Bitcoin: A Peer-to-Peer Electronic Cash System,工作量证明下的历史改写与累计工作量
- Bitcoin Developer Reference — Block Chain,Merkle 根的构造
- Bitcoin Developer Guide — Operating Modes,SPV 与 Merkle 分支
- ethereum.org — Ethereum Accounts,ECDSA 与 Keccak-256 地址推导,EOA 与合约账户的控制方式
- ethereum.org — Merkle Patricia Trie,状态/交易/收据根
- ethereum.org — Danksharding,KZG 多项式承诺
- EIP-4844 — Shard Blob Transactions,blob 承诺、证明与共识层可用性
- EIP-7594 — PeerDAS,数据单元证明与数据可用性抽样
- ERC-721 — Non-Fungible Token Standard,代币所有权、授权与操作员
- EIP-2 — Homestead Hard-fork Changes,secp256k1 签名约束
- EIP-2537 — Precompile for BLS12-381 curve operations
- RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA),Ed25519 的签名方案、曲线与安全级别
- SEC 2: Recommended Elliptic Curve Domain Parameters — secg.org
- NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management,ECC 与 RSA 的可比安全强度
- The Eth2 Book — Signatures and BLS aggregation
- NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards
贡献者
Aileen Wright 是一名二十多岁的学生,现居纽约。在这里,从博物馆的展墙走到图书馆阅览室 不过几步之遥,却足以度过一个漫长的下午。她通过艺术和历史走进了有关名字的写作领域: 一幅肖像、一枚硬币或手稿页边的一行字,都能让一个名字跨越数个世纪,并在流传中改变含义。
大多数时候,你会看到她拿着一本平装书待在中央公园,或是在安静的公共阅览室里追查一个名字 的真正出处,而不是照搬名字清单声称的含义。她还在自学编程,这让她对拼写、排序,以及决定 一个名字能否经得住时间考验的细微之处格外严谨。
她为 Namefi 撰写域名背后的历史与文化、品牌更名时所承载的故事,以及好故事与可靠来源之间 的区别等相关文章。
Victor Zhou 是一位专注于数字身份与信任的科技创业者和标准编辑。他创办了 Namefi,编辑 以太坊改进提案,此前还曾在 Google Labs 负责智能合约架构工作。
他的工作位于命名、所有权,以及人们用来建立网络身份的系统三者交汇之处。这一视角让他尤其 关注名字如何在个人意义、公众认知和数字基础设施之间流转。
在 Namefi,Victor 把域名视为持久的数字身份,并围绕这一主题编辑和撰写内容:名字如何成为 可拥有的链上资产,代币化如何改变托管与信任,以及命名可以从人们建立网络身份所使用的系统 中学到什么。
卞芬薇是一名三十多岁的软件开发者,工作时间泡在 pull request 里,周末双手不是沾着 泥土,就是沾着木屑。多年参与 GitHub 开源项目的经历让她明白,名字就是接口:好名字清晰, 如实说明自己的作用,也为下一位使用它的人着想。
她喜欢园艺,因为它奖赏耐心,也会惩罚一厢情愿;她也做木工,因为接合处要么严丝合缝, 要么就是不合。这两种习惯同样体现在她关于命名的写作中:量两遍,核实来源,别把粗糙处 磨平后就指望没人注意到。
她为 Namefi 撰写域名市场实际如何运转、域名代币化与转手交易的现实取舍,以及如何选择一个 二十年后仍会庆幸自己拥有的域名。
相关指南
- 如何在 Namefi 上通过 AI 智能体注册域名通过 MCP、REST 或钱包结账,使用 Claude、Codex、Cursor 等任意 AI 智能体在 Namefi 注册域名的权威指南。
- 面向 AI 智能体的域名平台:2026 年指南汇总 2026 年所有可让 AI 智能体搜索、查询价格并注册域名的平台——Cloudflare、Name.com 和 Namefi;按接口、支付方式与自主程度比较。
- 使用 Claude 购买域名:Namefi MCP 分步指南将 Claude 连接到 Namefi MCP 服务器,在一次对话中注册真实域名。包含精确配置、带注释的对话记录和故障排查。
- Namefi MCP 快速入门:Claude Code、Cursor 与 Windsurf分别为 Claude Code、Cursor 和 Windsurf 配置 MCP,并通过 5 个步骤将新应用接入已上线的自定义域名,全程无需离开编辑器。