第 4 讲:BTC 协议(二):共识问题与投票方案的局限性

第 4 讲:BTC 协议(二):共识问题与投票方案的局限性
agsd第 4 讲:BTC 协议 2——共识问题与投票方案的局限
依据:课程文字稿 ,笔记生成指南 。
1. 本节主线
- 区块链是一个去中心化账本,但账本内容必须在全网形成统一说法,否则每个节点各记各的账,系统就失去意义。
- 本节从“谁决定下一个区块写什么”出发,引出区块链中的**共识(consensus)**问题。
- 传统分布式系统中有 FLP impossibility result、CAP theorem、Paxos 等理论和协议,但 Bitcoin 面对的是开放网络,不能直接照搬。
- 简单投票方案在联盟链中可以考虑,但在 Bitcoin 这种任何人都能创建账户的系统中,会受到 Sybil Attack 的威胁。
- 本节的核心作用是说明:Bitcoin 不能按“账户数量”投票,必须寻找另一种决定记账权的机制。
2. 核心概念速览
| 概念 | 简要理解 | 在本节中的作用 |
|---|---|---|
| 共识(consensus) | 多个节点对某个系统状态达成一致 | 解决“下一个区块写什么、账本以谁为准”的问题 |
| 去中心化账本 | 没有单一中心服务器维护的账本 | 需要所有诚实节点最终认可同一条账本历史 |
| 分布式哈希表例子 | 多台机器共同维护一个 key-value table | 用来类比“系统状态需要一致” |
| FLP impossibility result | 异步系统中,只要存在一个 faulty 节点,就无法保证一定达成共识 | 说明分布式共识本身存在理论困难 |
| CAP theorem | Consistency、Availability、Partition tolerance 三者最多同时满足两个 | 说明分布式系统设计中存在根本权衡 |
| Paxos | 经典分布式共识协议 | 能保证一致性,但在某些情况下可能无法推进 |
| 投票方案 | 节点对候选区块投赞成票或反对票 | 一个直观但不适合 Bitcoin 的共识思路 |
| membership | 谁有资格参与系统、谁有投票权 | 投票方案必须先解决的问题 |
| 联盟链(consortium blockchain) | 参与者身份受限制的区块链 | 因为 membership 明确,可以采用投票类方案 |
| Hyperledger Fabric | 一个典型联盟链系统 | 用来说明“有准入门槛的链”和 Bitcoin 不同 |
| 女巫攻击(Sybil Attack) | 攻击者伪造大量身份,操纵按身份计票的系统 | 解释为什么 Bitcoin 不能简单按账户投票 |
3. 知识结构图
flowchart TD
A[交易被广播] --> B[谁决定写入下一个区块]
B --> C[需要全网账本共识]
C --> D[传统分布式共识]
D --> D1[FLP]
D --> D2[CAP]
D --> D3[Paxos]
C --> E[Bitcoin 共识]
E --> F[直接投票方案]
F --> G[需要 membership]
G --> H[联盟链可行]
G --> I[Bitcoin 不可行]
I --> J[账户可自由创建]
J --> K[Sybil Attack]
K --> L[不能按账户数决定记账权]
这张图的主线是:交易广播之后,系统必须决定哪些交易进入下一个区块;这个决定不能由每个节点各自独立完成,而要形成账本层面的共识。传统分布式系统提供了一些理论背景,但 Bitcoin 是开放系统,membership 不可控,所以简单投票会被 Sybil Attack 破坏。
4. 课程内容详解
4.1 为什么区块链需要共识
每个 Bitcoin 节点都可能接收到很多交易,其中有些交易合法,有些交易非法。问题是:
- 哪些交易应该被写入下一个区块?
- 这些交易应该按什么顺序写入?
- 如果多个节点都想打包区块,以谁的区块为准?
如果每个节点都自己决定,那么每个节点本地维护的区块链可能不同。这样就会出现一个根本问题:账本不统一。
区块链作为账本,最重要的不是“每个节点都能记账”,而是“所有诚实节点最终认可同一本账”。如果我记录的账和你记录的账不同,那么之后判断余额、验证交易、防止 double spending 都会失去统一依据。
所以本节课首先强调:Bitcoin 需要解决的是账本内容的共识问题。
4.2 共识问题的直观类比:分布式哈希表
老师用一个全局哈希表作为类比:
假设系统中有很多台机器,它们共同维护一个 key-value table。某个用户在机器 A 上写入:
1 | key = x |
那么另一个用户在机器 B 上读取 key = x 时,也应该读到 value = 12345。
这说明分布式系统要解决的问题不是“某一台机器自己知道什么”,而是“所有机器对系统状态有一致认识”。
对应到区块链中:
| 分布式哈希表 | Bitcoin |
|---|---|
| key-value pair | 交易、区块、UTXO 状态 |
| 全局表状态 | 全网账本状态 |
| 多台机器维护同一张表 | 多个节点维护同一条区块链 |
| 读到一致结果 | 验证余额和交易时得到一致判断 |
所以,区块链中的共识可以理解为:多个节点对“当前账本应该是什么样子”达成一致。
4.3 分布式共识为什么困难
传统分布式系统中,共识问题已经研究了很多年,而且有不少“不可能结论”(impossibility result)。
4.3.1 FLP impossibility result
FLP impossibility result 讨论的是异步系统(asynchronous system)中的共识问题。
所谓异步系统,核心含义是:网络消息传输时间没有确定上限。
也就是说,一个消息迟迟没有到达时,节点无法判断:
- 对方是不是宕机了?
- 消息是不是还在路上?
- 网络是不是暂时拥塞?
FLP 的结论可以简化理解为:
在一个完全异步的系统中,只要存在一个 faulty 节点,就不可能设计出一个总能保证达成共识的确定性协议。
这里的 faulty 节点可以理解为出故障或行为异常的节点。
这个结论说明:分布式共识不是简单工程问题,而是存在理论边界。
4.3.2 CAP theorem
CAP theorem 涉及分布式系统想要同时满足的三个性质:
| 字母 | 英文 | 含义 |
|---|---|---|
| C | Consistency | 一致性,所有节点看到的状态一致 |
| A | Availability | 可用性,请求总能得到响应 |
| P | Partition tolerance | 分区容忍性,网络分裂时系统还能继续运行 |
CAP theorem 的核心结论是:
一个分布式系统无法同时完全满足 Consistency、Availability、Partition tolerance 三者,最多只能同时满足其中两个。
比如:
- 想保证 Consistency 和 Availability,就很难容忍网络分区。
- 想保证 Availability 和 Partition tolerance,就可能牺牲 Consistency。
- 想保证 Consistency 和 Partition tolerance,就可能在网络异常时拒绝服务,从而牺牲 Availability。
这说明分布式系统不是单纯追求“全部最好”,而是要在不同性质之间做权衡。
4.3.3 Paxos 的作用与限制
Paxos 是经典分布式共识协议。它的重要特点是:
- 如果 Paxos 达成了共识,那么这个共识一定是一致的。
- 不会出现一个节点认为结果是 A,另一个节点认为结果是 B 的情况。
- 但是在某些情况下,Paxos 可能一直无法达成共识。
也就是说,Paxos 更强调 safety,即“只要有结果,结果就不会错”;但它不一定在所有情况下都能保证快速推进。
课程这里没有深入 Paxos,因为 Bitcoin 的共识机制和传统 Paxos 类协议的应用背景差别很大。
4.4 Bitcoin 共识面对的特殊问题
Bitcoin 中,共识要解决的问题不仅是普通故障,还包括恶意行为。
课程中的基本假设是:
- 系统中可能有恶意节点。
- 但大多数节点是诚实的。
- 共识协议要在这种环境下仍然维持账本可信。
这和传统企业内部系统不同。企业内部的分布式系统中,节点通常是预先登记、受管理的;而 Bitcoin 是开放网络,任何人都可以参与。
因此,Bitcoin 的难点不是“节点之间怎么通信”这么简单,而是:
在没有中心机构、没有准入审批、存在恶意节点的情况下,如何决定谁有权把交易写入区块链?
4.5 直接投票方案为什么直观
一个很自然的想法是:既然假设大多数节点是好的,那能不能直接投票?
大致流程如下:
- 某个节点提出一个 candidate block。
- 该节点把自己认为合法的交易打包进区块。
- 它把这个候选区块广播给其他节点。
- 其他节点验证区块中的交易是否合法。
- 如果都合法,就投赞成票。
- 如果发现非法交易,就投反对票。
- 如果赞成票超过某个阈值,这个区块就被接受。
这个方案看起来符合“大多数诚实”假设:只要多数人投赞成,区块就进入链中。
但课程接着说明:这个方案有很多问题,其中最大的问题是 membership。
4.6 投票方案的细节问题
直接投票方案至少有几个实际问题。
4.6.1 Denial of Service Attack
如果某个恶意节点不断提出包含非法交易的候选区块,其他节点就要不断验证、投票、否决。
这样虽然非法区块不会被接受,但系统资源会被消耗,区块链可能难以前进。
这就是一种 Denial of Service Attack,即通过制造大量无效请求或无效提案,让系统陷入处理垃圾信息的状态。
4.6.2 节点不投票导致系统停滞
投票方案还隐含一个前提:节点会积极参与投票。
但在开放系统中,无法强迫每个节点投票。如果很多节点不投票,系统可能一直达不到通过阈值。
这会导致区块无法被确认,账本无法继续增长。
4.6.3 网络延迟影响投票效率
投票还需要等待消息传播。问题是网络延迟无法完全预测:
- 每轮投票等多久?
- 等太短,可能很多诚实节点的票还没到。
- 等太长,系统效率很低。
因此,直接投票在开放网络中效率和可推进性都存在问题。
不过这些仍然不是最根本的问题。更根本的问题是:谁有投票权?
4.7 membership:投票权从哪里来
任何投票方案都必须先解决 membership 问题。
membership 指的是:
- 谁是系统成员?
- 谁有投票权?
- 一个成员对应几票?
- 如何防止一个人伪装成多个成员?
在联盟链(consortium blockchain)中,membership 是明确的。比如 Hyperledger Fabric 这类系统,只有符合条件的组织或公司才能加入。
这种情况下,投票方案是可行的,因为:
- 成员身份是受控的。
- 参与者数量相对明确。
- 一个组织不能随便伪造大量身份。
- 可以假设大多数成员是诚实的。
但 Bitcoin 不是联盟链。
4.8 Bitcoin 为什么不能按账户投票
Bitcoin 的账户创建非常容易。
用户只需要在本地生成一对 public key 和 private key,就可以得到一个账户。这个过程:
- 不需要中心机构批准。
- 不需要实名注册。
- 甚至不需要告诉其他节点。
- 只有当这个账户参与交易时,其他人才知道它的存在。
这带来一个严重问题:如果按账户数投票,攻击者可以在本地生成大量账户。
比如,攻击者用一台性能很强的机器不断生成 public key / private key pair,制造出超过全网一半数量的账户。这样它就可以在“按账户投票”的系统中获得多数票,操纵区块接受结果。
这就是女巫攻击(Sybil Attack)。
4.9 Sybil Attack 的本质
Sybil Attack 的本质是:
在一个身份创建成本很低的系统中,攻击者可以伪造大量身份,从而破坏“按身份投票”的公平性。
这里要注意,问题不在于“账户本身不安全”。public key / private key 机制仍然可以保证账户控制权。问题在于:
- 账户太容易创建。
- 一个真实攻击者可以对应大量账户。
- 所以“一个账户一票”并不等于“一个真实参与者一票”。
因此,Bitcoin 不能使用简单的“多数账户同意”来决定下一个区块。
本节课到这里实际上是在为后续机制铺垫:Bitcoin 需要一种不依赖真实身份数量的共识方式。
5. 关键机制图解
5.1 直接投票方案流程
sequenceDiagram
participant Proposer as 提议节点
participant Network as Bitcoin 网络
participant Node as 其他节点
participant Chain as 区块链
Proposer->>Proposer: 收集交易并构造 candidate block
Proposer->>Network: 广播候选区块
Network->>Node: 转发候选区块
Node->>Node: 验证交易是否合法
Node->>Network: 投赞成票或反对票
Network->>Chain: 若赞成票超过阈值则接受区块
这张图展示的是一种直观但不适合 Bitcoin 的方案。它的问题不在于“验证交易是否合法”这一步,而在于投票权本身无法可靠分配。Bitcoin 是开放系统,账户可以任意创建,所以无法简单认为“账户多数”就代表“诚实多数”。
5.2 简单投票被 Sybil Attack 破坏
flowchart TD
A[按账户投票] --> B[每个账户一票]
B --> C[Bitcoin 账户可自由创建]
C --> D[攻击者批量生成密钥对]
D --> E[伪造大量账户身份]
E --> F[获得多数票]
F --> G[操纵候选区块是否被接受]
G --> H[投票共识失效]
这张图说明了 Sybil Attack 的关键逻辑:只要身份创建成本足够低,攻击者就可以把“一个人”伪装成“很多人”。因此,在 Bitcoin 中不能把账户数直接当作投票权来源。
6. 易混点与常见误解
| 易混点 | 正确理解 |
|---|---|
| 区块链是去中心化的,所以每个节点想怎么记账都可以? | 不可以。去中心化不等于各记各的账,区块链仍然需要全网对账本内容形成共识。 |
| 重复打包同一笔交易一定是好事吗? | 如果同一笔交易出现在不同候选区块中,不一定立即是问题;真正的问题是全网最终要认可同一条账本历史,避免账本分裂。 |
| 共识就是大家都完全同时得到一样的信息吗? | 不是。共识强调最终对某个状态达成一致,不要求所有节点在任意时刻看到完全相同的信息。 |
| Paxos 能解决所有区块链共识问题吗? | 不能。Paxos 适合特定分布式系统背景,而 Bitcoin 是开放、匿名、可能有恶意节点的网络,membership 问题完全不同。 |
| 投票方案为什么在联盟链中可以,在 Bitcoin 中不行? | 联盟链有明确 membership,成员身份受控;Bitcoin 账户可自由创建,按账户投票会被 Sybil Attack 攻击。 |
| 一个 public key / private key pair 是不是就代表一个真实用户? | 不是。一个真实用户可以生成任意多组密钥对,所以账户数量不能代表真实人数。 |
| Sybil Attack 是破解私钥吗? | 不是。Sybil Attack 不是破解密码学,而是利用低成本身份创建来伪造大量投票身份。 |
| “大多数节点是好的”是否足够支持按节点投票? | 不一定。首先要定义什么是“节点”或“成员”。如果身份可以随便伪造,多数节点这个假设就没有意义。 |
7. 课堂外补充理解
7.1 safety 和 liveness
理解共识协议时,经常会区分两个性质:
| 性质 | 含义 | 简单理解 |
|---|---|---|
| safety | 系统不会产生错误结果 | 不要错 |
| liveness | 系统最终会继续推进 | 不要卡住 |
Paxos 的特点可以粗略理解为:如果它达成结果,结果不会互相矛盾,所以 safety 很强;但在某些极端情况下,系统可能迟迟无法决定结果,因此 liveness 可能受影响。
这和课程中提到的“Paxos 可以保证一致,但可能一直无法达成共识”是同一个方向。
7.2 为什么 Bitcoin 需要把“投票权”变贵
直接投票失败的根本原因是身份太便宜。
如果账户可以免费或低成本生成,那么“一个账户一票”就没有意义。要解决这个问题,开放系统通常需要让投票权和某种难以伪造的资源绑定。
在 Bitcoin 后续机制中,这个资源不是账户数量,而是计算能力。也就是说,Bitcoin 后续会从“按身份投票”转向“按工作量竞争记账权”的思路。
这里不展开后续内容,只需要先记住本节结论:
Bitcoin 不能相信身份数量,因为身份可以伪造;它必须寻找一种更难伪造、更有成本的权重来源。
7.3 联盟链和公有链的核心区别
| 维度 | 联盟链 | Bitcoin 这类公有链 |
|---|---|---|
| 加入方式 | 需要许可 | 通常无需许可 |
| membership | 明确 | 不明确 |
| 身份管理 | 可由组织或证书系统控制 | 账户可自由创建 |
| 投票方案 | 可以较自然地设计 | 容易被 Sybil Attack 破坏 |
| 信任基础 | 对参与组织有一定信任假设 | 尽量减少对身份和组织的信任 |
这个区别是理解本节课的关键。不是“投票机制一定不好”,而是“在 Bitcoin 这种开放系统里,简单投票不适用”。
8. 本节小结
- 区块链虽然是去中心化账本,但仍然必须形成统一账本历史,否则系统无法判断交易和余额。
- 共识问题在分布式系统中本来就很困难,FLP、CAP、Paxos 都说明了其中的理论限制和工程权衡。
- Bitcoin 的共识问题更加特殊,因为它处在开放网络中,节点可能恶意,身份也没有中心化准入控制。
- 直接投票方案看起来自然,但会遇到 DoS、节点不投票、网络延迟等问题。
- 更根本的问题是 membership:如果不知道谁有投票权,就无法设计可靠投票。
- Bitcoin 账户可以自由创建,所以按账户投票会遭遇 Sybil Attack,这也是后续引出 PoW 类机制的原因。
9. 自测问题
1. 为什么不能让每个节点独立决定自己的本地区块链内容?
参考答案:因为这样每个节点的账本可能不同,系统无法形成统一账本历史。区块链作为账本,必须让诚实节点最终认可同一套交易记录。
2. 分布式哈希表例子想说明什么?
参考答案:它说明分布式系统中的多个节点需要对全局状态达成一致。某台机器写入的 key-value pair,在另一台机器上也应该能读到对应结果。
3. FLP impossibility result 的核心含义是什么?
参考答案:在完全异步系统中,只要存在一个 faulty 节点,就不存在一个确定性协议能够保证一定达成共识。它说明共识问题存在理论上的困难。
4. CAP theorem 中 C、A、P 分别代表什么?
参考答案:C 是 Consistency,一致性;A 是 Availability,可用性;P 是 Partition tolerance,分区容忍性。CAP theorem 表明三者不能同时完全满足。
5. 为什么直接投票方案在 Bitcoin 中不可靠?
参考答案:因为 Bitcoin 没有受控 membership,账户可以自由创建。攻击者可以伪造大量账户,从而操纵按账户计票的结果。
6. 什么是 Sybil Attack?
参考答案:Sybil Attack 指攻击者伪造大量身份,使系统误以为有很多独立参与者,从而破坏按身份投票或按身份分配权力的机制。
7. 为什么联盟链可以更自然地使用投票类共识?
参考答案:联盟链的成员身份通常是明确且受控制的,参与者不能随意伪造大量成员身份,因此 membership 问题相对容易解决。
8. 本节课如何为后续 Bitcoin 共识机制做铺垫?
参考答案:本节说明了 Bitcoin 不能依靠账户数量投票,因为账户身份可伪造。后续需要寻找一种更有成本、更难伪造的方式来决定记账权。









