区块链共识机制基础知识

区块链共识协议: 从 PoW 到 BFT

多个互不信任的节点，怎么对同一份账本达成一致？为什么有的链 6 个区块才"安全"，有的链 1 个区块就 final？为什么有的链能 5 万 TPS 而比特币只有 7 TPS？

1. 共识到底要解决什么

1.1 拜占庭将军问题

经典模型: 一群将军围城，必须达成一致 (“一起进攻 OR 一起撤退”)。但其中可能有叛徒故意发错消息让大家不一致。问题是:诚实将军们怎么在有叛徒的情况下达成一致？

这就是拜占庭容错 (BFT, Byzantine Fault Tolerance)。Lamport 1982 年证明: 在异步网络下，叛徒比例 ≥ 1/3 时不可能达成一致 (FLP impossibility 的延伸)。所以所有共识协议都是在"假设至多 f 个作恶节点"下设计的，常见门槛: 总节点 ≥ 3f+1。

1.2 区块链版本的问题

把"将军"换成"全网节点"，把"进攻 / 撤退"换成"打包哪笔交易、按什么顺序"，问题变成:

在没有可信中心、节点可能作恶/掉线的前提下，如何让全网就账本顺序达成一致？

具体要保证三件事:

这三个性质在不同共识里取舍不同。比如 PoW (BTC) 牺牲严格 finality 换简单和去中心化; BFT 类 (Tendermint) 严格 finality 但活性容忍度低。

2. 记账基础: 账本怎么存、区块怎么链

共识协议解决"谁来记"，本节先讲清楚"怎么记"—— 区块链的账本到底长什么样、区块之间怎么连、轻节点怎么验证。这部分和共识算法相互正交: BTC = UTXO + PoW，ETH = Account + PoS，Cosmos = Account + Tendermint，自由组合。

2.1 两种账本模型: UTXO vs Account

UTXO (Unspent Transaction Output) — Bitcoin 风格

账本不是"谁有多少钱"的余额表，而是一堆未花费的输出 (UTXO)。每笔交易消费若干 UTXO 作为 input，产生若干新 UTXO 作为 output。

Tx_A: Tx_B (Alice 转 7 BTC 给 Bob): inputs: 5 BTC, 3 BTC inputs: UTXO_X (8 BTC, 来自 Tx_A) outputs: ─→ 8 BTC (Alice) outputs: ─→ 7 BTC (Bob) └→ 0.99 BTC (Alice, 找零) └→ 0.01 BTC 作为矿工费 (隐式)

• 余额= 我控制的所有 UTXO 之和 (链上计算出来的，不直接存)
• 像现金交易: 拿出 50 元 + 20 元，找回 5 元；不会把"账户余额从 100 改成 65"
• 一旦被消费，UTXO 就消失，不可重复使用 (天然防双花)

Account — Ethereum 风格

账本是一张全局状态表:address → {balance, nonce, code, storage}。转账 = 直接修改这张表。

转账前: Alice: {balance: 8 ETH}, Bob: {balance: 0 ETH} 转账后: Alice: {balance: 1 ETH}, Bob: {balance: 7 ETH} ↑ 直接改字段

• 像银行账户: 账户 A 减 100，账户 B 加 100
• 合约 = 一种特殊账户 (code != 0)，state 在合约的storagemap 里
• 同一地址多次交易，依靠 nonce (见 §10) 保证顺序

对比表

变种:

• Solana: 名义上 Account 模型，但每笔交易必须显式声明读写哪些 account，运行时可大量并行 (Sealevel 引擎)
• Sui / Aptos (Move): object-centric，每个 object 独立可寻址，介于 UTXO 和 Account 之间

2.2 区块怎么"链"起来

每个区块的 header 里有prev_block_hash字段，指向前一个区块的 hash。任何篡改一个老区块 → 它的 hash 变 → 后面所有区块的 prev_block_hash 都得跟着改。

• PoW 链: 篡改后要重新挖所有后续区块，算力代价天文数字
• PoS 链: 重签会触发 slashing (验证者被罚)

这就是"区块链"名字的由来 —— 一条hash 单向链表。

[Genesis] [Block 1] [Block 2] [Block 3] hash = 0x00... ←── prev = 0x00... ←── prev = 0xab... ←── prev = 0xcd... hash = 0xab... hash = 0xcd... hash = 0xef... merkle_root = ... merkle_root = ... merkle_root = ... state_root = ... state_root = ... state_root = ...

2.3 区块内交易完整性: Merkle Tree

一个区块包含 N 笔交易 (主网 ETH 约 100~300 笔/区块，BTC 约 2000~3000 笔)。header 不可能存全部交易 —— 只存一个 32 字节的Merkle Root。

Merkle Root = 所有交易 hash 两两组合往上 hash 一层层归并，最终剩一个 root hash。任何一笔交易被篡改 → 这个 root 变 → 与 header 不符 → 全网拒绝。

Merkle Root (32 B, 写在 block header) / \ H(AB) H(CD) / \ / \ H(A) H(B) H(C) H(D) | | | | Tx1 Tx2 Tx3 Tx4

用处: 轻节点 (SPV) 想验证"Tx2 是不是真的在 Block 5 里"，只要从全节点拿一条Merkle Path(H(A), H(CD)) + Block 5 的 header，就能本地算出 root 对照，无需下载整个区块。

2.4 状态承诺: State Root (Account 模型特有)

ETH 区块 header 除了 Merkle Root (交易树根)，还有State Root(状态树根)。这是 Patricia Merkle Trie 的 root，承诺"全网所有账户在这一刻的状态快照"。

任何账户余额、合约 storage 改一个字节 → State Root 变 → 与 block header 不符。

用处:

• 轻节点查任何账户余额: 拿一条 Trie 证明 (~几 KB) 即可，无需下载几百 GB 全状态
• State Root 被全网共识 → 状态历史不可篡改
• 不同节点 fork 同步时，比较 State Root 即可知道是否一致

UTXO 模型没有显式 State Root —— 因为状态就是 UTXO 集合本身，UTXO 树 (UTXO Set commitment) 是后来才有的可选优化。

2.5 节点类型: 谁存了多少账本

→ 普通钱包 (MetaMask / Phantom 等)没有完整的区块链—— 它信任后端 RPC 提供商。"看到的余额"是 RPC 告诉它的。这是去中心化用户的隐性中心化点。

2.6 安全视角

做案件分析时:

• 看 BTC 案件 → 跟 UTXO 流向 (一笔 UTXO 在哪些 tx 中流转)
• 看 EVM 案件 → 跟 account state 变化 (Etherscan 的 State Changes Tab)
• Solana 案件 → 看每笔 tx 涉及的 account list (logMessages+accountKeys)

3. PoW (Proof of Work)

3.1 机制

矿工反复改区块头的 nonce 字段，对区块头做 hash，要求 hash 值 < target:

SHA256(SHA256(blockHeader || nonce)) < target

没有数学捷径，只能穷举。第一个碰中的矿工广播区块，全网验证后接受。难度 (target) 自动调整保证出块时间稳定。

3.2 为什么"长链原则" = 共识

PoW 没有"投票"步骤，规则只有一条:接受累积工作量最大的链。两条链分叉时，大家最终会都看到更长的那条 → 自动收敛。

(本地短链被丢弃) ▲ │ ┌── B1' ── B2' ────────┘ │ ─ A │ └── B1 ── B2 ── B3 ── B4 ── B5 ──── (全网最长链, 本地接受)

3.3 Finality 是概率性的

PoW 没有"绝对" final 这一说。攻击者只要算力够大就能造一条更长的链覆盖现有的。但每多一个区块覆盖在你的交易上面，攻击代价指数级增加。所以业界约定:

• BTC 6 个确认 ≈ “极不可能被翻盘”
• ETH (合并前) 12~30 个确认

CEX 充值 N 个确认才到账就是这个原因。

3.4 51% 攻击

一旦单一实体掌握 ≥ 51% 算力，他可以:

• 双花: 在主链上花一笔，私下挖另一条更长的链覆盖掉
• 审查: 拒绝打包某些地址的交易
• 重组 (reorg): 把已确认的若干区块作废

BTC 全网算力价值天文数字，攻击成本极高 → 安全。但小币 (ETC、BSV、Verge 等) 历史上多次被 51% 攻击。

3.5 PoW 代价

• 极高耗电: BTC 全网年耗电 ≈ 阿根廷整国
• 军备竞赛 → 中心化: 几个大矿池占绝大多数算力
• TPS 极低: BTC ~7 TPS, ETH (合并前) ~15 TPS

4. PoS (Proof of Stake)

4.1 机制

抛弃算力，改靠资本质押。验证者把代币锁进合约，按质押量加权随机选下一个出块人。被选中者打包、签名、广播；其他验证者投票确认。

+--- 验证者 A (32 ETH stake) | 所有验证者 ──→ 加权随机算法 ──→ +--- 验证者 B (320 ETH stake) ← 中选概率高 10 倍 | +--- 验证者 C (32 ETH stake)

4.2 Slashing (经济惩罚)

PoS 安全的核心: 你作恶或长时间离线就会被罚没一部分质押代币。例如以太坊:

• 同一高度签两个不同区块 (double sign / equivocation) → slash 大量
• 长时间离线 → slash 少量
• 协调式作恶 (correlated slashing) → 罚得更狠

经济激励让你只能诚实。

4.3 Finality

不同 PoS 实现的 finality 模型不一样:

→ 以太坊"6 confirmations" 概念在 PoS 后变成"等到 finality checkpoint"，而 Cosmos 类链 1 个块就 final。

4.4 PoS 的代价

• 资本中心化: 大户质押多 → 奖励多 → 滚雪球。Lido 单一协议占 ETH 质押 ~30%
• 门槛: ETH 自跑节点要 32 ETH (~10 万美金)；普通人通过 Lido / Rocket Pool / 交易所间接参与
• “Nothing at Stake” 问题(理论上的): 早期 PoS 设计中，分叉时验证者两边都签代价为零，易作恶。现代 PoS 都用 slashing 解决

5. PoS 的变种

5.1 DPoS (Delegated Proof of Stake)

代币持有者投票选出 N 个超级节点 (validator)，由这 N 个轮流出块。

特点:非常快、非常中心化。21 个节点串通就能改账本。BSC 实际就是 BNB Chain Foundation 控制的超级节点联盟链，性能换去中心化。

5.2 PoA (Proof of Authority)

直接固定一组已知身份的权威节点轮流出块，没有质押也没有选举。常见于联盟链 / 私链 / 测试网:

• ETH 旧测试网 (Ropsten / Rinkeby / Kovan)
• BSC 测试网
• 各种企业内部链

不算严格意义上的"区块链共识" —— 因为它依赖信任锚点，去中心化程度极低。

5.3 PoH (Proof of History) — Solana 特有

不是独立共识，而是 PoS 的加速器。Solana 让 leader 节点用 SHA256 不停 hash 自己的输出，形成可验证的"时间序列":

hash_0 → hash_1 = SHA256(hash_0) → hash_2 = SHA256(hash_1) → ...

任何事件被 hash 进序列后，就有了一个不可伪造的时间戳。其他验证者可以并行验证 (因为 SHA256 单向但可重算)，省掉传统共识里"对时间达成一致"那部分开销。

PoH + PoS (Solana 的 Tower BFT) 让 Solana 达到几万 TPS，但代价是节点硬件要求极高、网络偶尔停摆。

5.4 PoSpace / Proof of Capacity (Chia)

矿工预先分配硬盘空间绘制 plot 文件。出块时从 plot 中找到符合条件的"答案"。比 PoW 省电，但有"绿色挖矿"翻车 (硬盘消耗惊人)。Chia / Burst 用过。

5.5 PoB (Proof of Burn)

往一个不可花费的地址烧币换出块权。用得很少 (Slimcoin)。

6. BFT 家族 (Byzantine Fault Tolerance)

PoS 链常见底层共识其实是BFT 协议。BFT 协议保证: 只要作恶节点 < 1/3，全网严格一致。

6.1 PBFT (Practical BFT)

1999 年 Castro & Liskov 提出的经典算法。流程: pre-prepare → prepare → commit 三阶段，每阶段所有节点广播签名，达到 2f+1 票就进入下一阶段。

Client Leader (Primary) Replica 1 Replica 2 Replica 3 │ │ │ │ │ ├─ request ───────►│ │ │ │ │ ├── pre-prepare ────►│ │ │ │ ├── pre-prepare ─────────────────►│ │ │ ├── pre-prepare ─────────────────────────────►│ │ │◄── prepare ────────┤ │ │ │ │◄── prepare ────────────────────┤ │ │ │◄── prepare ──────────────────────────────┤ │ ├── commit ─────────►│ ←──────────►│ ←──────────►│ │◄─── reply ──────┴────────────────────┴─────────────┴─────────────┘

特点:

• 即时 finality: commit 后不可逆
• 通信复杂度 O(N²): 节点多了消息爆炸 → 不适合大规模
• 适合 50~100 个验证者级别的链

6.2 Tendermint (Cosmos)

PBFT 的工程化升级，把 prepare/commit 改成 prevote/precommit，加超时重试，落地为完整的区块链共识。

特点:

• 即时 finality(1 个块即 final)
• 2f+1 投票要求(恶意节点 < 1/3 才安全)
• leader 轮转: 每 round 换 proposer
• liveness 牺牲: 如果 1/3 节点离线，链停摆 (相比 PoW 永远不停)

代表: Cosmos Hub、Binance Chain (BNB Beacon Chain，已废弃)、Terra Classic、Osmosis…

6.3 HotStuff (Diem / Aptos)

Tendermint 的优化版，把通信复杂度从 O(N²) 降到O(N)(利用 BLS 阈值签名聚合)。能支持几百~上千个验证者。

代表:

• Diem(前 Libra, Meta 已放弃)
• Aptos(用了 AptosBFT, HotStuff 变种)
• Sui(Narwhal+Bullshark, DAG 思路类似)

6.4 Avalanche Consensus

完全不同思路:重复亚抽样投票 (repeated subsampled voting)。每个节点随机问 K 个邻居"你支持哪边？"，循环若干轮直到意见收敛。

特点:

• 概率性 finality (亚秒级)
• 通信复杂度 ~O(K log N)
• 三链结构 (X-Chain DAG / C-Chain EVM / P-Chain platform)

7. CFT vs BFT (题外话)

Crash Fault Tolerance (CFT)是另一类协议，假设节点只会宕机但不会作恶。比 BFT 弱很多。

→ Raft 不能直接用于公链，因为它假设没有恶意节点，公链恶意节点遍地跑。

8. 共识协议对比

→没有最好的共识，只有最适配场景的共识。BTC 要"全球抗审查货币"选了 PoW。Cosmos 要"App-chain 互操作"选了即时 finality 的 Tendermint。Solana 要"高频金融"选了 PoH + PoS。

9. 现实链的对照表

10. Nonce: 账户层的顺序保证

共识协议解决的是全网对区块顺序达成一致；但同一个用户在同一个区块内塞两笔互相依赖的交易，谁先谁后？这是另一层问题，由nonce 机制解决。可以把它理解为"账户内部的小型共识"。

每个外部账户 (EOA)都有一个nonce—— 单调递增的计数器，从 0 开始，每发出一笔交易加 1。它是每笔交易的必填字段，签名时一并签进去。

10.1 它解决两个问题

(a) 防止重放攻击

没有 nonce 的话，攻击者抓到你已经签好名的转账就能反复广播让你重复扣钱。

有了 nonce 后:

• 你签名时把nonce=5写进交易
• 链上执行后，账户 nonce 跳到 6
• 同一笔交易再广播，链上看到nonce=5 < 6，直接拒绝
• 签名覆盖 nonce 字段，攻击者改不了

(b) 决定交易顺序

同一个地址的交易严格按 nonce 升序执行，与共识协议无关。即使矿工/验证者想改变顺序也不行 —— 协议层强制。如果你连发 nonce=5、6、7:

矿工/验证者先收到 6 和 7 → 不能立刻打包, 因为 5 还没确认 矿工/验证者后收到 5 → 5 上链, 6/7 立刻可以接着打包

这就是为什么 nonce=5 卡住时 6/7 也跟着卡 —— 不是网络慢，是nonce 间隙在等。

10.2 常见场景

10.3 ⚠️ 别把两种 nonce 搞混

“nonce” 在区块链里有两个完全不同的含义:

名字一样，没有关系。挖矿那个见第 3 节。

10.4 合约账户的 nonce

合约地址也有 nonce，但语义不同:

• EOA nonce = 已发交易数
• 合约 nonce = 这个合约部署过多少子合约(CREATEopcode 次数)

合约本身不主动发交易，所以"防重放"含义对它不适用。但新合约地址 =keccak256(deployer, deployer_nonce)取后 20 字节，所以 deployer 的 nonce 决定下一个部署合约的地址。

安全含义: 攻击者可以预测某个 deployer 在 nonce=5 时要部署到哪个地址，然后预先转钱进去等收割，或在 deployer 还没上链前往那个预测地址放陷阱合约 (CREATE2用 salt 而不是 nonce 进一步加大可预测性 → 钓鱼合约常用)。

11. 安全视角

11.1 51% / 33% 攻击

历史案例:

• ETC 多次被 51% 重组双花交易所充值
• Verge / Bitcoin Gold 多次 51%
• Solana 历次停摆 (验证者 bug 触发 → liveness 丢失)
• Terra 崩盘期间 validator 投票冻结链

11.2 长程攻击 (Long-Range Attack) — PoS 专属

攻击者拿到很久以前的私钥 (验证者已退出但密钥泄漏)，重新挖一条从早期分叉的"假链"。PoW 没这问题 (重新挖整条链算力不够)，PoS 通过weak subjectivity checkpoint解决: 新节点同步必须信任一个最近的"主链锚点"。

11.3 MEV (Maximal Extractable Value)

不论哪种共识，出块人对交易顺序有完全控制权。只要有套利机会，出块人就能抽走价值:

• 抢跑买入 → 高价卖给用户 (sandwich)
• 重排清算交易吃清算奖金
• 把仅自己见过的高 tip 交易优先打包

PoS 时代 MEV 更严重 (出块时间确定、API 稳定，bot 容易算)。MEV-Boost把出块权拍卖给 builder，让验证者参与利润分配。

11.4 Finality 反转风险

PoW 概率性 finality 最严重:

• 短重组: 1~2 个块经常发生 (网络分区)
• 中重组: 3~6 个块罕见但发生过
• 长重组 (>6): 罕见, 通常意味着攻击或链分裂

做案件分析时: 如果用户报"已确认的转账消失了"，先看这笔交易是不是在 reorg 中被剔除 (Etherscan 上会变成 dropped)。

11.5 验证者 / 矿池中心化

→ 单点故障/合谋风险。机构持币、托管、监管协调都可能成为攻击向量。

12. 名词速查

13. 进阶 (后续可以读)

• Casper FFG + LMD-GHOST(ETH PoS 详细机制)
• GRANDPA + BABE(Polkadot 双层共识)
• Narwhal + Bullshark(Sui / Aptos 用的 DAG-based mempool + BFT)
• CometBFT(Tendermint 的 fork, 现在 Cosmos 主推)
• OP Stack / Arbitrum Nitro 的 Sequencer + Fault/Validity Proof—— L2 怎么"借用" L1 共识
• Restaking (EigenLayer)—— 把 ETH staked 资产再质押给其他协议提供安全
• Shared Security (Cosmos ICS, Polkadot Parachain)—— 用一条主链的验证者集合保护多条子链
• Single Slot Finality (SSF)—— ETH 未来路线图: 1 个 slot 内 final, 取代 32-slot epoch