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

第 4 讲:BTC 协议 2——共识问题与投票方案的局限

依据:课程文字稿 ,笔记生成指南 。

1. 本节主线

  1. 区块链是一个去中心化账本,但账本内容必须在全网形成统一说法,否则每个节点各记各的账,系统就失去意义。
  2. 本节从“谁决定下一个区块写什么”出发,引出区块链中的**共识(consensus)**问题。
  3. 传统分布式系统中有 FLP impossibility result、CAP theorem、Paxos 等理论和协议,但 Bitcoin 面对的是开放网络,不能直接照搬。
  4. 简单投票方案在联盟链中可以考虑,但在 Bitcoin 这种任何人都能创建账户的系统中,会受到 Sybil Attack 的威胁。
  5. 本节的核心作用是说明: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. 知识结构图

这张图的主线是:交易广播之后,系统必须决定哪些交易进入下一个区块;这个决定不能由每个节点各自独立完成,而要形成账本层面的共识。传统分布式系统提供了一些理论背景,但 Bitcoin 是开放系统,membership 不可控,所以简单投票会被 Sybil Attack 破坏。

4. 课程内容详解

4.1 为什么区块链需要共识

每个 Bitcoin 节点都可能接收到很多交易,其中有些交易合法,有些交易非法。问题是:

  • 哪些交易应该被写入下一个区块?
  • 这些交易应该按什么顺序写入?
  • 如果多个节点都想打包区块,以谁的区块为准?

如果每个节点都自己决定,那么每个节点本地维护的区块链可能不同。这样就会出现一个根本问题:账本不统一

区块链作为账本,最重要的不是“每个节点都能记账”,而是“所有诚实节点最终认可同一本账”。如果我记录的账和你记录的账不同,那么之后判断余额、验证交易、防止 double spending 都会失去统一依据。

所以本节课首先强调:Bitcoin 需要解决的是账本内容的共识问题。

4.2 共识问题的直观类比:分布式哈希表

老师用一个全局哈希表作为类比:

假设系统中有很多台机器,它们共同维护一个 key-value table。某个用户在机器 A 上写入:

1
2
key = x
value = 12345

那么另一个用户在机器 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 直接投票方案为什么直观

一个很自然的想法是:既然假设大多数节点是好的,那能不能直接投票?

大致流程如下:

  1. 某个节点提出一个 candidate block。
  2. 该节点把自己认为合法的交易打包进区块。
  3. 它把这个候选区块广播给其他节点。
  4. 其他节点验证区块中的交易是否合法。
  5. 如果都合法,就投赞成票。
  6. 如果发现非法交易,就投反对票。
  7. 如果赞成票超过某个阈值,这个区块就被接受。

这个方案看起来符合“大多数诚实”假设:只要多数人投赞成,区块就进入链中。

但课程接着说明:这个方案有很多问题,其中最大的问题是 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 直接投票方案流程

这张图展示的是一种直观但不适合 Bitcoin 的方案。它的问题不在于“验证交易是否合法”这一步,而在于投票权本身无法可靠分配。Bitcoin 是开放系统,账户可以任意创建,所以无法简单认为“账户多数”就代表“诚实多数”。

5.2 简单投票被 Sybil Attack 破坏

这张图说明了 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. 本节小结

  1. 区块链虽然是去中心化账本,但仍然必须形成统一账本历史,否则系统无法判断交易和余额。
  2. 共识问题在分布式系统中本来就很困难,FLP、CAP、Paxos 都说明了其中的理论限制和工程权衡。
  3. Bitcoin 的共识问题更加特殊,因为它处在开放网络中,节点可能恶意,身份也没有中心化准入控制。
  4. 直接投票方案看起来自然,但会遇到 DoS、节点不投票、网络延迟等问题。
  5. 更根本的问题是 membership:如果不知道谁有投票权,就无法设计可靠投票。
  6. 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 不能依靠账户数量投票,因为账户身份可伪造。后续需要寻找一种更有成本、更难伪造的方式来决定记账权。