区块链技术之所以被称为"信任机器"，核心在于其巧妙结合了密码学、分布式系统与博弈论。本文将深入剖析区块链的三大基石：哈希链、默克尔树、非对称加密，以及两种账户模型的设计哲学。
一、区块链的本质：链式哈希结构
经典区块结构
每个区块包含三个核心部分：
- 区块头：前一区块哈希、Merkle 根、时间戳、难度目标、Nonce
- 区块体：交易列表（原始数据）
- 区块元数据：区块高度、大小等
┌─────────────────────────────────────┐
│ Block N │
│ ┌──────── ──────────────────────┐ │
│ │ prevHash = H(Block N-1) │ │
│ │ merkleRoot = M(tx1,tx2,...) │ │
│ │ timestamp = 1733800000 │ │
│ │ nonce = 98237 │ │
│ │ difficulty = 0x0000... │ │
│ └───────────────────────────────┘ │
│ [tx1] [tx2] [tx3] ... [txN] │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Block N+1 │
│ prevHash = H(Block N 的完整头部_hash) │
└─────────────────────────────────────┘
哈希运算的一步改、一动全链变
若某恶意节点欲修改 Block 2 中一笔交易，则：
Block 2中 Merkle 根会改变 →Block 2的区块哈希改变Block 3的前一区块哈希不匹配 →Block 3的哈希改变- 以此类推，后面所有区块都需重新计算
- 鉴于 PoW 中的算力竞争，除非攻击者掌握全网 51% 算力，否则无法追上主链
// 简化版区块哈希计算示意
func calcBlockHash(prevHash, merkleRoot []byte, timestamp int64, nonce uint64) []byte {
data := append(prevHash, merkleRoot...)
data = append(data, int64ToBytes(timestamp)...)
data = append(data, uint64ToBytes(nonce)...)
return sha256.Sum256(data)[:]
}
非对称加密：身份与所有权的基础
区块链使用椭圆曲线加密（ECDSA / EdDSA）生成公私钥对：
- 私钥：256 位随机数，是身份的唯一凭证
- 公钥：从私钥通过 ECC 公式生成，可公开
- 地址：对公钥进行 Keccak256 哈希 + 取后 20 字节（以太坊：
0x...）
核心特性：
- 仅拥有私钥者才能对交易签名
- 任何人可用公钥验证签名有效性
- 钥匙配对之间不存在反向推导的数学可能（基于离散对数问题）
from eth_account import Account
import secrets
# 生成随机私钥
private_key = '0x' + secrets.token_hex(32)
account = Account.from_key(private_key)
print(f"私钥: {private_key}")
print(f"地址: {account.address}")
二、Merkle 树：高效的数据完整性证明
为什么需要 Merkle 树？
如果仅有简单的交易列表，验证一笔交易是否存在于区块中，需要传输全部交易（成本极高）。Merkle 树通过将数据逐层哈希，仅需 log₂(N) 个哈希值即可验证任意一笔交易。
Merkle 树的构建过程
交易: TX1, TX2, TX3, TX4
Step 1: 计算叶子节点哈希
H1 = H(TX1), H2 = H(TX2), H3 = H(TX3), H4 = H(TX4)
Step 2: 逐层向上配对哈希
H12 = H(H1 + H2)
H34 = H(H3 + H4)
Step 3: 最终 Merkle 根
MerkleRoot = H(H12 + H34)
结构示意:
┌─────────────────┐
│ Merkle Root │ ← 写入区块头
└────────┬────────┘
│
┌─────────────┴─────────────┐
│ │
┌─────┴───┐ ┌─────┴────┐
│ H12 │ │ H34 │
└─────┬───┘ └─────┬────┘
│ │
┌───────┴───────┐ ┌────────┴────────┐
│ │ │ │
┌──┴──┐ ┌─────┴────┐ ┌───┴───┐ ┌──────┴──────┐
│ H1 │ │ H2 │ │ H3 │ │ H4 │
└──┬──┘ └─────┬────┘ └───┬───┘ └─────────────┘
│ │ │
TX1 TX2 TX3 TX4
Merkle Proof: 轻节点的福音
轻客户端（如手机钱包）无需下载完整区块，只需：
- 获取区块头（包含 Merkle Root）
- 接收验证路径（H2, H3 等对应位置兄弟节点哈希）
- 自底向上重新计算哈希，若结果 == Merkle Root，则交易确实存在于该区块
| 方法 | 完整节点 | 轻节点（SPV） |
|---|---|---|
| 数据量 | 全账本 | 仅区块头（~80 字节 × 区块数） |
| 验证信任 | 自验证 | 需假设诚实节点占多数 |
三、UTXO vs 账户模型：两种记账哲学
UTXO 模型（比特币）
核心概念：每一笔比特币都是"未花费的输出"（Unspent Transaction Output），没有"余额"概念。
交易输入（使用已有 UTXO） 交易输出（创建新 UTXO）
┌──────────────┐
│ UTXO_A=0.5 BTC │──┐
└──────────────┘ │ │ ┌────────────────┐
├──► │ send 0.3 BTC │──► Alice（新 UTXO）
┌──────────────┐ │ │ ┌────────────────┐
│ UTXO_B=0.1 BTC │──┘ │ change 0.29 BTC │──► 自己找零
└──────────────┘ │ fee = 0.01 BTC │ → 支付给矿工
└────────────────┘
优点：
- 天然支持并行验证（不同 UTXO 无状态冲突）
- 隐私性较好（每次找零到新地址，难以追踪"余额"归属）
- 易于验证无双重花费
缺点：
- 复杂业务逻辑支持困难（无状态合约）
- 难以表达"账户余额"这种直观概念
账户模型（以太坊）
核心概念：每个地址对应一个全局状态中的账户对象，包含 balance 和 nonce（交易计数器）。
type Account struct {
Nonce uint64 // 交易序号，防重放攻击
Balance *big.Int // 余额（Wei）
StorageRoot []byte // 合约存储树根节点
CodeHash []byte // 部署的合约字节码哈希
}
优点：
- 空间效率高（无需管理大量碎片化 UTXO）
- 天然支持复杂智能合约状态
- 余额查询 O(1)，交易概念符合人类直觉
缺点：
- 需要全局状态维护（MPT 树）
- 需要顺序执行处理同一地址的多笔交易
关键对比
| 维度 | UTXO | 账户模型 |
|---|---|---|
| 状态表示 | 离散输出列表 | 全局账户映射 |
| 并行性 | 天然高 | 同地址需串行 |
| 智能合约 | 有限（Stateless） | 完善（Stateful） |
| 隐私 | 较高（地址隔离） | 较低（余额公开） |
| 可编程性 | 低 | 极高（图灵完备 EVM） |
四、密码学原语速览
| 原语 | 作用 | 比特币 | 以太坊 |
|---|---|---|---|
| 共识签名 | 交易授权 | ECDSA (secp256k1) | ECDSA (secp256k1), 支持 EIP-155 |
| 地址哈希 | 公钥 → 地址 | RIPEMD160(SHA256(PK)) | Keccak256(PK)[12:] |
| 交易哈希 | 唯一标识 | Double SHA256 | Keccak256 |
| 默克尔树 | 交易完整性 | 二叉树 | 二叉树 |
以太坊已逐步引入 BLS 签名（用于 PoS 验证人聚合签名）和 SNARK/STARK 零知识证明，但基础层仍保持向后兼容。
五、本章小结
区块链的三个核心密码学组件（哈希链、默克尔树、非对称加密）共同构建了无需信任第三方即可验证数据完整性与所有权的能力。UTXO 与账户模型代表了两条不同的状态管理路径——前者更适合价值传递场景，后者则在可编程性上展现了巨大的生态优势。理解这些基础，是深入学习共识机制与智能合约开发的必要前提。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。