共识层
含AI生成内容
第5章 区块链共识层
一、考点速览
| 编号 | 考点 | 重要程度 |
|---|---|---|
| 1 | 分布式系统一致性的三个要求（可终止性/约同性/合法性） | ★★★★★ |
| 2 | 活性(Liveness)与安全性(Safety)的定义与通俗表述 | ★★★★★ |
| 3 | 线性一致性 vs 顺序一致性 vs 弱一致性（含最终一致性子类） | ★★★★ |
| 4 | FLP不可能原理（定义、含义、两种折中方向） | ★★★★★ |
| 5 | 同步与异步传输模型 | ★★★★ |
| 6 | CAP原理（定义、常见误解、区块链中的应用） | ★★★★★ |
| 7 | 拜占庭将军问题（N ≥ 3F+1 有解条件） | ★★★★★ |
| 8 | PBFT三阶段流程（预准备/准备/提交）及复杂度O(N²) | ★★★★★ |
| 9 | PBFT视图切换、日志压缩（检查点机制）、高低水位区间 | ★★★★ |
| 10 | 比特币PoW流程、难度调整、双花攻击概率分析 | ★★★★★ |
| 11 | Ethash（抗ASIC设计、DAG组织dataset、cache/dataset、FNV哈希） | ★★★★ |
| 12 | 权益证明(PoS)的两大挑战：长程攻击、无利害关系 | ★★★★★ |
| 13 | Casper FFG（合理检查点/确定检查点、罚没两条件、容错率1/3） | ★★★★★ |
| 14 | DPoS与BFT-DPoS（传统→初级→升级版的演进、交易确认时间） | ★★★★ |
| 15 | Monoxide分片（连弩挖矿、跨共识组交易解耦、中心化风险） | ★★★ |
二、详细笔记
5.1 分布式系统的一致性问题
5.1.1 问题与挑战
分布式系统中容易出现的四类问题：
- 节点间网络通信不可靠 — 消息延迟、乱序、出错甚至丢失
- 节点处理时间无法保障 — 处理结果可能错误，节点自身可出现系统中断
- 节点可以是恶意的 — 通过各种手段破坏系统一致性
- 同步调用降低可扩展性 — 可能退化为单点系统，带来单点故障
三种避免冲突的方案（本质是将并行操作串行化）：
| 方案 | 思路 | 缺陷 |
|---|---|---|
| ① 同步调用询问 | 收到交易时先询问其他节点是否已收到同样交易及执行顺序 | 未考虑请求和答复消息失败的情况 |
| ② 令牌机制 | 约定时间段内由特定节点决定交易执行顺序，轮流负责 | 同上 |
| ③ 第三方机构 | 成立专门机构负责处理交易执行顺序 | 退化为中心化单点系统 |
5.1.2 一致性的三个要求
| 要求 | 对应英文 | 含义 | 对应系统属性 | 通俗表述 |
|---|---|---|---|---|
| 可终止性 | Termination | 一致性结果在有限时间内能完成 | 活性(Liveness) | 好事总会发生 |
| 约同性 | Agreement | 不同节点最终完成决策的结果相同 | 安全性(Safety) | 坏事不会发生 |
| 合法性 | Validity | 决策的结果必须是某个节点提出的提案 | 正确性(Correctness) | — |
关键理解：安全性是区块链共识算法的重点，通常归约为给区块内交易定一个全局的序号。没有合法性约束的共识机制变得荒谬——例：无论发生何种交易都给所有银行账户余额增加1，具有强活性和强安全性，但不是”正确”的。
5.1.3 不同的一致性要求
核心规律：越强的一致性要求 → 越弱的处理性能 + 越差的可扩展性。
三类一致性：
| 一致性类型 | 要求①（读） | 要求②（顺序） |
|---|---|---|
| 线性一致性（强一致性） | 任何一次读都能读到某个数据的最近一次写的数据 | 所有进程看到的操作顺序都和全局时钟下的顺序一致 |
| 顺序一致性 | 同上 | 所有进程看到的操作顺序一致且合理，无需和全局时钟下的顺序一致 |
| 弱一致性 | 适当放宽要求 | 包括最终一致性等 |
图5.1 要点（P1/P2为进程1/2）：
- (a) P1: Write(z,4) 发生在 P2: Read(z,0) 之前 → 不满足线性一致性（P2应为Read(z,4)），但满足顺序一致性（每个进程看来有一个合理的全局顺序即可）
- (b) 满足顺序一致性和线性一致性
- (c) 经过推导不能得到一个自洽的全局顺序 → 连顺序一致性都不满足
谷歌Spanner采用基于原子钟和GPS的TrueTime方案，将不同数据中心的时间偏差控制在10ms以内。
最终一致性子类：
| 子类 | 定义 | 关键点 |
|---|---|---|
| 因果一致性 | 有因果依赖关系的进程之间保持数据一致 | 进程A通知进程B → B后续基于新值；进程C可能看到旧值（不一致窗口） |
| 读你所写一致性 | 因果一致性的特例：进程A依赖于自身 | A更新z后自身后续操作基于新值，其他进程不受影响 |
| 会话一致性 | 读你所写一致性建立在某个会话中 | 会话终止后可能读出旧值 |
| 单调读一致性 | 如果某进程读到数据z的版本v2，则所有进程后续不能读出比v2更旧的版本 | — |
| 单调写一致性 | 同一个进程的写操作必须串行完成 | 保证客户端写操作是串行的 |
上述一致性可根据不同场景要求组合使用（如单调读+会话一致性），根据其严格程度形成包含关系（图5.7）。
5.2 共识设计的理论限制
5.2.1 FLP不可能原理
核心结论：分布式系统的共识问题在推广到任意情形时无通用解。
FLP不可能原理（1982/1983，Fischer, Lynch, Paterson）：
在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性算法。
论文：Impossibility of Distributed Consensus with One Faulty Process
本质：不要浪费时间设计能在任意情形都实现共识的异步分布式确定性算法。
传输模型
| 模型 | 定义 | 特点 |
|---|---|---|
| 同步(Synchrony) | 各节点时钟误差存在上界；消息在确定时间内肯定到达目标节点（传输时间有上界且上界已知） | 可容易判断消息是否丢失 |
| 异步(Asynchrony) | 各节点可能存在较大时钟差异；消息不能确定一定到达目标节点，可能丢失（传输时间无上界） | 无法判断未响应是目标节点故障还是传输故障 |
现实生活中，大多数系统都是异步系统。
FLP的另一种表述：异步的分布式系统不能同时保证活性和安全性。
两种折中方向：
| 折中方向 | 代表算法 | 具体表现 |
|---|---|---|
| 弱化活性的异步假设 → 同步假设以实现活性 | PBFT | 安全性在异步网络中保证；活性不能，需同步模型达成 |
| 弱化安全性的异步假设 → 同步假设以实现安全性 | 比特币PoW | 活性在异步网络中保证；安全性不能保证（分叉），是概率上的安全性；Casper FFG也属此类型，但实现的是确定性的安全性 |
5.2.2 CAP原理
CAP原理：分布式计算系统不可能同时确保一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)三个特性。设计需弱化对某个特性的保证。
- 2000年ACM研讨会猜想，后由Lynch等证明
- 被认为是分布式系统领域的重要原理之一
| 特性 | 英文 | 定义 |
|---|---|---|
| 一致性 | Consistency | 每次读操作都能得到最近写的结果或者返回错误 |
| 可用性 | Availability | 每次请求都能返回一个非错误结果（但结果不需要是最近写的） |
| 分区容忍性 | Partition Tolerance | 任意节点间的连接中断或大大延迟，系统仍然能够工作 |
关键：分区容错性是所有分布式系统必须满足的。
常见误解澄清：CAP原理经常被误解为在所有时间上需要抛弃某一个性质。如果没有发生网络分区，分布式系统正常运行，即同时满足可用性和一致性。
区块链中的CAP应用：
| 系统 | 侧重点 | 网络分区时的表现 | 分区消失后 |
|---|---|---|---|
| 比特币(PoW) | 可用性 | 每个网络分区仍能生成区块打包交易，但会出现分叉（账本不一致） | 一致性达到，分叉收敛，可用性和一致性都达到 |
| PBFT | 一致性 | 若不能得到2/3投票则不能生成区块打包交易；不同分区不会出现分叉 | 可用性达到，生成区块打包交易，可用性和一致性都达到 |
5.3 区块链共识算法
区块链共识算法本质上是为了解决拜占庭问题。
5.3.1 拜占庭问题
两将军问题（Two General Paradox）：
- 两个将军通过信使达成进攻还是撤退的约定
- 信使可能被阻拦或迷路导致消息无法送达（信息丢失或伪造）
- 根据FLP不可能定理，无通用解
拜占庭将军问题（Leslie Lamport等，1982年提出）：
- 多个将军（节点）通过信使传递消息，对军事活动（提案）达成一致决定
- 将军中可能存在叛徒（恶意节点），向不同将军传递不同消息试图干扰共识达成
核心结论（论文 Reaching Agreement in the Presence of Faults）：
假设节点总数N，叛变将军数F，则当 N ≥ 3F + 1 时，问题才有解，由BFT算法保证。
- N=4, F=1 ✓（4 ≥ 3×1+1=4）
- N=7, F=2 ✓（7 ≥ 3×2+1=7）
- N=3, F=1 ✗（3 < 3×1+1=4）— 无解
N=3, F=1时无解的两种情况：
- 提案者A（忠诚）发送”进攻”给B和C；叛徒C向B宣称收到”撤退”；B收到两个相反提案，无法判断谁是叛徒
- 提案者A（叛徒）分别发送”进攻”和”撤退”给B和C；B和C都收到两个相反提案，无法判断
Lamport等人证明：当叛徒不超过1/3时，存在有效的拜占庭容错算法；叛徒超过1/3则无法保证一定能达到一致。
5.3.2 实用拜占庭容错算法(PBFT)
PBFT首次将拜占庭容错算法的复杂度从指数级降低到多项式级 O(N²)。
PBFT不适用于公有链的三个原因：
- 网络不稳定情况下延迟很高
- 基于投票机制，投票集合有限（否则无法满足少数服从多数原则）
- 通信复杂度O(N²)过高，可拓展性低（节点数达100左右时性能下降非常快）
基本角色
| 角色 | 职责 |
|---|---|
| 客户端(Client) | 向主节点发起请求（区块链中通常与主节点合二为一） |
| 主节点(Primary) | 提案发起者（区块发起者），收到客户端请求后生成新区块并广播 |
| 验证节点(Backup) | 提案投票者（区块验证者），收到区块后验证并广播验证结果 |
| 视图(View) | 一个主节点 + 多个备份形成一个视图；不同视图的主节点一般不同（轮流） |
| 编号(Sequence Number) | 主节点指定的提案编号（相当于区块高度） |
| 检查点(Checkpoint) | 某编号n对应的提案收到超过2/3确认 |
核心三阶段流程
消息格式：<PRE-PREPARE, v, n, d>, m> 、 <PREPARE, v, n, d, i> 、 <COMMIT, v, n, d, i>
| 阶段 | 过程 | 关键点 |
|---|---|---|
| 预准备阶段 | 主节点构造PRE-PREPARE消息并签名后广播给其他节点 | v: 视图编号; n: 唯一递增编号; d: 消息摘要; m: 客户端消息 |
| 验证节点进行4项检验：① 摘要一致性 ② 视图编号一致性 ③ 序号n在高低水位区间[h, H]内 ④ 不重复处理 | — | |
| 准备阶段 | 验证通过后广播PREPARE消息（含节点编号i），记录到本地日志 | 当收到2F+1个（含自己）通过检验的PREPARE消息后进入COMMIT阶段 |
| 构造并广播COMMIT消息 | 此时消息达到PREPARED状态 | |
| 提交阶段 | 当收到2F+1个通过检验的COMMIT消息 | 说明全网大部分节点已达成共识 |
| 按序号n从小到大执行操作，返回结果给客户端 | 客户端收到F+1个相同结果时，说明全网达成共识 |
设计原理：预准备+准备阶段确保同一视图下消息顺序一致；准备+提交阶段确保不同视图之间消息顺序一致。
日志压缩（垃圾回收）
- 每执行K个请求后，节点i创建检查点并广播：
<CHECKPOINT, n, d, i> - 收到2F+1个通过检验的检查点消息后 → 清除序号小于n的消息 → 该检查点变为稳定检查点
- 高低水位区间：[h, H]，其中h = 上一个稳定检查点的高度，H = h + L（L = 3K）
- 当节点处理的请求序号到达H时暂停，直到稳定检查点发生变化再继续
视图切换
触发条件：主节点系统中断或作恶，或全网超过1/3的节点系统中断时
- 节点i超时后广播：
<VIEW-CHANGE, v+1, n, C, P, i>- C：经过2F+1个节点确认的稳定检查点消息集合
- P：已到达PREPARED状态消息的集合
- 新视图主节点收到2F+1个VIEW-CHANGE消息后广播：
<NEW-VIEW, v+1, V, O>- V：有效的VIEW-CHANGE消息集合
- O：从P中已到达PREPARED状态的消息转换来的PRE-PREPARE消息集合
- C确保最新稳定点之前的状态安全；P和O确保视图切换中已达PREPARED状态的消息能重放而不会丢失
PBFT关键思考
1. 为什么容错性是1/3？
- 假设全网节点总数N，拜占庭节点F个
- 拜占庭节点可故意不回复 → 节点必须在收到N-F个回复后做出决策
- N-F个回复中可能包含F个拜占庭节点回复 → 正确消息 = N-F-F
- 为遵循少数服从多数：N-F-F > F → N > 3F → N ≥ 3F+1
- 容错性 = F/N ≈ F/(3F+1) ≈ 1/3
2. 为什么需要提交阶段？（能否简化为两个阶段？）
- 不能。节点A收到2F+1个PREPARE消息不代表其他节点也收到足够的PREPARE消息
- 若A收到2F+1个PREPARE就执行请求并返回结果给客户端，但部分节点发生视图切换 → 被认为达成共识的请求其实没有达成共识
- 简化会导致状态机二义性
3. 通信复杂度
- 预准备和准备阶段每个节点都需向其他节点广播消息
- 通信开销 = N(N-1) → O(N²)
- 一般节点数不超过100个
节点状态流转
等待请求 → 预准备（主节点专属） → 准备 → 等待2F+1个PREPARE确认 → 提交 → 回复客户端 超时时进入：视图切换 → 等待2F+1个VIEW-CHANGE消息 → 新视图共识
5.3.3 比特币的工作量证明共识机制
核心特点
- 容错阈值：恶意节点算力不超过系统总算力的 1/2
- 容错原因（vs BFT类的1/3）：BFT类通过投票方法实现；PoW通过争夺记账权而非合作投票的方式解决
工作量证明流程（图5.9）
- 矿工基于自身打包的区块进行工作量证明
- 独立矿工并行遍历区块头的随机值字段 Nonce
- 每次遍历对区块头进行两轮SHA256哈希算法（隶属SHA2，避免延展性攻击）
- 映射到32B的二进制空间中
- 当区块头两轮运算后得到的值小于工作量目标值 → 矿工完成工作量证明
- 哈希速率越快 → 碰撞次数越多 → 达到所需工作量的概率越大
- 率先完成的矿工广播该区块；其他矿工验证Nonce → 验证通过插入本地数据库，进入下一轮共识
- 依据最长链被认可为全局账本的原则（最长链承载着次数最多的工作量证明）
难度调整
- 通过控制哈希运算后得到的值的大小（前方0的个数）来控制一次哈希运算后就能满足难度要求的概率
- 网络算力大 → 提升全网难度；网络算力小 → 降低全网难度
- 目标：保证网络出块速度及算力竞争程度的可控性
比特币区块头的6个主要字段（表5.1）
| 字段 | 大小(bits) | 描述 |
|---|---|---|
| Version | 32 | 区块的版本信息 |
| hashPrevBlock | 256 | 上一个区块的哈希值 |
| hashMerkleRoot | 256 | 比特币交易构造的默克尔树的根 |
| Timestamp | 32 | 区块的时间戳（秒级别） |
| Target | 32 | 当前的区块目标值 |
| Nonce | 32 | 用于工作量证明生成合法区块 |
注意：工作量证明中比特币对区块头字段进行小端编码。
双花攻击及概率分析
攻击过程：攻击者付钱购买商品，商家等待交易所在区块N被后续区块引用后发货；攻击者同时在暗地里用自己算力支持双花交易从高度N制造分叉；分叉链长度大于当前主网链时广播，使付费交易失效、双花交易成功。
概率模型：
- 诚实矿工算力 p，攻击者算力 q，p+q=1
- 利用泊松过程模型和二项随机游走模型分析
- 攻击者在落后z个区块的情况下追上诚实矿工的概率（赌徒破产模型）：
- 当 p≤q 时，Q(z)=1（必定追上）
- 当 p>q 时，Q(z)=(q/p)^z
- 比特币中确认数常取6（即6个区块确认）
- 随着确认数增大，攻击成功概率呈指数级别下降
5.3.4 以太坊共识算法 Ethash
设计目标：抵抗ASIC
- 让更多人能利用普通计算机设备及通用型GPU参与共识，无须购买ASIC矿机
- ASIC矿机提高节点参与共识的门槛（哈希速率高于普通设备几个数量级）
抗ASIC原理
- 设计为I/O密集型工作量证明共识机制
- 个人计算机中CPU或GPU对I/O操作已得到较好优化，通过制造ASIC矿机进一步优化I/O技术难度大且成本高
- 比特大陆的Ethash矿机并没有带来几个数量级的性能提升
算法摘要
| 要点 | 说明 |
|---|---|
| Nonce + MixDigest | 矿工不仅需要找到合适的Nonce，还需填充一个MixDigest字段（内存消耗证明） |
| 种子生成 | 根据区块高度生成seed → 生成约16MB的cache |
| dataset | 全节点根据cache生成GB级别的dataset（以DAG形式组织的随机数序列），大小随时间增长（抵消摩尔定律下硬件性能提升） |
| epoch | 每30,000个区块（一个纪元）重新计算cache和dataset，新的seed仅与区块高度相关，dataset可预生成 |
| 轻节点验证 | 验证工作可在低内存环境下通过使用cache生成所需特定片段，轻节点主要存储cache即可 |
挖矿流程（图5.12）
- 依据区块头和Nonce通过Keccak256（隶属SHA3）生成哈希值a
- 将a整合为包含32个Uint32元素的数组 Mix(0)（共128B）
- 将Mix(0)映射到dataset中，抓取dataset某个片段数据data
- 将data和Mix(0)通过FNV哈希算法混合，得Mix(1)
- 基于Mix(1)再去抓取dataset中某个片段，继续混合操作
- 循环混合64次后得Mix(64)
- 将Mix(64)整合为32B的digest，依据a和digest用Keccak256生成最终result
- 与目标值比对 → 满足条件则将digest和Nonce分别填充到MixDigest字段和Nonce字段
FNV哈希（Fowler-Noll-Vo Hash）：
- 非密码学哈希函数，逻辑简单，快速对大量数据哈希并保持较小冲突率
- 基于一个质数来做哈希操作，32位数据的FNV哈希质数为 0x01000193
比特币PoW vs Ethash 本质对比
| 维度 | 比特币PoW | Ethash |
|---|---|---|
| 侧重点 | 哈希速率 | 快速I/O能力 |
| 哈希算法 | 两轮SHA256 (SHA2) | Keccak256 + FNV (SHA3) |
| 抗ASIC | 否 | 是（I/O密集型） |
| 本质 | 均为计算能力的特例 | 均在消耗无意义的哈希运算或I/O |
5.3.5 以太坊共识算法 Casper FFG
权益证明(PoS)基础
- 公有链共识机制主要有PoW和PoS两种
- PoW问题：能源消耗巨大（2018年数据，比特币电力消耗可排世界第21位）
- PoS中的稀缺资源为权益（表现形式：持币量、币龄等）
- 公有链共识泛化模型：基于某种稀缺资源对记账权进行竞争，形成攻击门槛（获取稀缺资源的难度）
PoS两大核心挑战：
| 挑战 | 描述 | 严重原因 |
|---|---|---|
| 长程攻击 (Long Range Attack) | 验证者退回保证金后，从历史上某区块开始重写后续区块；系统不能惩罚（已无保证金） | 攻击者获得早期投资人卖出的私钥成本很低（只需该私钥在历史上某一时刻控制超过51%权益） |
| 无利害关系 (Nothing at Stake) | PoS矿工每份权益可同时在所有分叉上押宝，无论哪条链被确认为主链都能获得收益 | 追求收益最大化的矿工最优策略是在所有分叉中投票 → 导致分叉长时间维持 |
PoW矿工 vs PoS矿工策略与期望收益对比：
| 策略 | PoW期望收益（图5.14） | PoS期望收益（图5.15） |
|---|---|---|
| 两边都不选 | EV=0 | EV=0 |
| 选择p=0.9的分叉 | EV=0.9 | EV=0.9 |
| 选择p=0.1的分叉 | EV=0.1 | EV=0.1 |
| 同时选两边 | EV=0.5（需平分算力） | EV=1.0（无需额外消耗） |
PoW中同时选两边需平分算力 EV=0.5，不是最优；PoS中同时选两边EV=1.0，是最优策略。
长程攻击只可缓解不可解决，可称为权益证明的达摩克利斯之剑。
Casper FFG 核心机制
- 拜占庭容错风格的权益证明
- 容错率：1/3
- 区块生成仍依靠底层矿工，验证者集合用于确认区块链的主链
- 验证者是对检查点(Checkpoint)进行确认，不是对每个区块确认（当前每100个区块为一个检查点）
投票形式：<v, s, t, h(s), h(t)>
| 字段 | 含义 |
|---|---|
| v | 投票者的ID |
| s(source) | 投票的源——合理检查点的哈希值 |
| t(target) | 投票的目标——源s的某个后代检查点的哈希值 |
| h(s) | 源的高度 |
| h(t) | 目标的高度 |
罚没条件（投票者触犯以下任一条件即罚没全部保证金）：
- h(t1) = h(t2) 但 s1 > s2 — 对同一高度认可了两个不同的检查点
- h(s1) < h(s2) < h(t2) < h(t1) — 投票者同时认可s2→t2及s1→t1，且后者在区块链中完全包含前者（有潜在作恶动机）
检查点的关键状态：
| 状态 | 定义 | 相当于PBFT |
|---|---|---|
| 合理检查点(Justified) | 有2/3以上权益的投票为c’→c，c’是合理检查点，则c也成为合理检查点 | PREPARED |
| 确定检查点(Finalized) | 有2/3以上权益的投票为c’→c，c是c’的直接子检查点（h(c)=h(c’)+1），则c成为确定检查点 | COMMITTED |
根节点既是合理检查点，又是确定检查点。
为什么确定检查点必须对应直接子检查点？（图5.18）：若不要求h(c)=h(c’)+1，则可能出现相互矛盾的检查点a1和b1均被确认为确定检查点，系统无法确定哪个分支是合理的。
Casper FFG保证金解决无利害关系（图5.16）：
- 若矿工同时在两个互不兼容的分叉投票，保证金被罚没
- 设罚金为5倍收益：同时选两边的EV = 0.9×1 + 0.1×1 - 5 = -4（亏损状态）
- 矿工的最优策略变为努力选择一个正确的分叉投票
应对长程攻击：验证者离开验证者集合拿回保证金前必须经过解冻期（如4个月）
- 节点在首次加入区块链网络时，或离线时间超过4个月时，会进入”错误”的链
- 只是缓解，并非从根本上解决
Casper FFG的层叠共识：若在某高度达不成共识，可继续往前共识，在后面高度上达成共识进而确定前面高度 → 在保证活性的前提下一致性也可以得到保证。
5.3.6 EOSIO共识算法 BFT-DPoS
委托权益证明(DPoS)基础
- DPoS基于权益争夺记账权，通过选举出若干（奇数个）代表节点，在代表节点间进行投票选举新区块创建者
- 避免了全网全部节点之间进行选择，大幅提升选举效率
- 在几十个到上百节点之间进行一致性投票，一般可在秒级完成
- 通过减少投票节点数量或采用令牌环机制甚至可以降低到毫秒级
EOSIO的BFT-DPoS演进
| 版本 | 出块速度 | 交易确认时间 | 核心改进 |
|---|---|---|---|
| 传统DPoS | 3s | 45s | 21个见证人随机出块；需14个(2/3)见证人确认 → 需等轮流出块至13个区块后 |
| 初级BFT-DPoS | 3s | ~3s | 借鉴PBFT：其他见证人收到新区块后立即验证签名并返回给出块者，不需等待自己出块时再确认 |
| 升级BFT-DPoS | 0.5s | ~1s | ① 出块顺序由商议确定（低延迟见证人相邻）② 每个见证人连续生产6个区块（仍负责3s）③ 大部分交易1s内确认 |
升级版解决网络延迟问题：
- 0.5s出块速度下，中国见证人后面可能是英国见证人，中英网络延迟有时高达500ms → 英国见证人可能略过中国见证人的区块导致分叉
- 解决方案：将随机出块顺序改为商议后确定（如日→中→俄→英），每个见证人连续生产6个区块 → 前几个区块有足够时间传递给下一个见证人
5.3.7 Monoxide 分片共识
- 论文：Monoxide: Scale Out Blockchains with Asynchronized Consensus Zones（NSDI 2019）
- 利用分片思想把区块链划分为多个共识组（N个），线性地提升交易处理速度与吞吐量
两个核心问题及解决方案
问题1：跨共识组交易
- 方案：解耦交易 — 将A转账B的交易TX拆分为两个原子交易
- TX_0: A = A-X（在A的共识组中共识）
- TX_1: B = B+X（作为接力交易在B的共识组中共识）
- 效果：吞吐量和TPS约为原来的N倍
- 局限：跨共识组的智能合约仍是很大问题（内存落盘、状态写入顺序依赖性等），未给出可靠解决方案
问题2：算力稀释导致安全性下降
- N个共识组下，单共识组总算力 = HashRate/N
- 攻击单个共识组仅需 HashRate/(2N)（而非原来单链的HashRate/2）
连弩挖矿(Chu-ko-nu Mining) — 解决方案：
- 受联合挖矿概念启发，矿工不直接在某个共识组上做PoW，而是基于一个主区块头
- 各共识组的信息（当前区块的区块头）通过默克尔根传递到主区块头
- 矿工基于主区块头做PoW相当于基于多个共识组同时进行PoW
- 极端情况：矿工为得到全部区块奖励会基于所有共识组共识 → 不存在算力分散问题，攻击者仍需获得全网半数以上算力
潜在的中心化问题
- 基于N个共识组连弩挖矿的矿工期望收益 = 基于单个共识组的N倍
- 连弩挖矿需要存储多个共识组信息，一般由矿池等机构运行
- 个体加入矿池不仅获得更平稳收益，还得到成倍收益 → 矿工加入矿池的意愿强烈很多
- 导致整个网络由矿池维护，中心化程度大幅提升
三、名词解释
| 术语 | 英文 | 释义 |
|---|---|---|
| 可终止性 | Termination | 一致性结果在有限时间内能完成 |
| 约同性 | Agreement | 不同节点最终完成决策的结果相同 |
| 合法性 | Validity | 决策结果必须是某个节点提出的有效提案 |
| 活性 | Liveness | 好事总会发生 — 来自客户端的请求最终会被处理 |
| 安全性 | Safety | 坏事不会发生 — 处理请求后不存在不一致状态 |
| 线性一致性 | Linearizability | 任何读都能读到最近写的数据，且操作顺序与全局时钟一致 |
| 顺序一致性 | Sequential Consistency | 任何读能读到最近写的数据，操作顺序一致且合理，无需与全局时钟一致 |
| 最终一致性 | Eventual Consistency | 总存在某一时刻（非立刻）让系统达到一致状态 |
| 因果一致性 | Causal Consistency | 有因果依赖关系的进程之间保证数据一致 |
| FLP不可能原理 | FLP Impossibility | 网络可靠但允许节点失效的纯异步系统中，不存在确定性共识算法 |
| CAP原理 | CAP Theorem | 分布式系统不可能同时确保一致性、可用性和分区容忍性 |
| 同步模型 | Synchrony | 时钟误差有上界，消息传输时间有上界且已知 |
| 异步模型 | Asynchrony | 时钟差异可能较大，消息传输时间无上界，可能丢失 |
| 拜占庭将军问题 | Byzantine Generals Problem | 存在叛徒传递虚假消息时，如何让忠诚将军达成行动一致 |
| PBFT | Practical Byzantine Fault Tolerance | 首次将BFT复杂度从指数级降到多项式级O(N²)的实用拜占庭容错算法 |
| 检查点 | Checkpoint | 某编号n对应提案收到超过2/3确认 |
| 稳定检查点 | Stable Checkpoint | 收到2F+1个检查点消息后形成，可安全清除之前日志 |
| 视图切换 | View Change | 主节点故障或作恶时切换到新视图继续共识 |
| 工作量证明 | Proof of Work (PoW) | 要求获取服务前进行适当复杂计算证明真实需求；容错阈值1/2 |
| 权益证明 | Proof of Stake (PoS) | 基于权益（持币量/币龄）而非算力竞争记账权；容错率1/3（BFT风格） |
| 委托权益证明 | DPoS | 选举若干代表节点进行投票共识，提升效率 |
| 长程攻击 | Long Range Attack | 验证者退回保证金后从历史区块开始重写后续区块 |
| 无利害关系 | Nothing at Stake | PoS矿工可在所有分叉同时投票而无需额外成本 |
| 合理检查点 | Justified Checkpoint | 有2/3以上权益投票确认的检查点（≈PBFT PREPARED） |
| 确定检查点 | Finalized Checkpoint | 有2/3以上权益投票确认且为直接子检查点（≈PBFT COMMITTED） |
| Casper FFG | Casper the Friendly Finality Gadget | BFT风格的PoS，将以太坊从PoW迁移到PoS的核心机制 |
| 连弩挖矿 | Chu-ko-nu Mining | 基于主区块头同时为多个共识组进行工作量证明 |
| MixDigest | — | Ethash中矿工挖矿过程中计算出的内存消耗证明字段 |
| DAG | Directed Acyclic Graph | Ethash中dataset以有向无环图形式组织的随机数序列 |
| FNV哈希 | Fowler-Noll-Vo Hash | 非密码学哈希函数，快速对大量数据哈希且保持较小冲突率 |
| Keccak256 | — | 以太坊使用的哈希算法（隶属SHA3家族） |
| 双花攻击 | Double Spend Attack | 攻击者同时支持两条链，使付费交易失效、双花交易成功 |
| 分片 | Sharding | 把区块链划分为多个共识组以线性提升交易处理速度与吞吐量 |
| 解冻期 | Unbonding Period | Casper FFG中验证者拿回保证金前的等待期（如4个月），缓解长程攻击 |
四、核心对比表格
4.1 同步模型 vs 异步模型
| 维度 | 同步(Synchrony) | 异步(Asynchrony) |
|---|---|---|
| 时钟误差 | 存在上界 | 可能存在较大差异 |
| 消息到达 | 确定时间内肯定到达 | 不确定一定到达，可能丢失 |
| 传输时间 | 有上界且已知 | 无上界 |
| 丢包判断 | 容易判断 | 无法判断（节点故障 or 传输故障） |
| 现实占比 | 少数 | 大多数系统 |
4.2 PBFT vs 比特币PoW
| 维度 | PBFT | 比特币PoW |
|---|---|---|
| 解决方式 | 投票方法 | 争夺记账权 |
| 容错阈值 | 1/3（需 N≥3F+1） | 1/2（需算力<50%） |
| 安全性保证 | 确定性的，在异步网络中保证 | 概率性的，不能保证 |
| 活性保证 | 不能在异步网络中保证 | 在异步网络中保证 |
| CAP侧重 | 一致性 | 可用性 |
| 分叉 | 不会出现分叉 | 会出现分叉 |
| 通信复杂度 | O(N²) | 广播O(N) |
| 适用场景 | 联盟链 | 公有链 |
| 能源消耗 | 低 | 高 |
| 最终性 | 确定性 | 概率性（6区块确认） |
4.3 比特币PoW vs 以太坊Ethash
| 维度 | 比特币PoW | 以太坊Ethash |
|---|---|---|
| 哈希算法 | 两轮SHA256 (SHA2) | Keccak256 + FNV (SHA3) |
| 侧重点 | 哈希速率 | 快速I/O能力 |
| 抗ASIC | 否 | 是 |
| 内存需求 | 低（仅区块头80B） | 高（16MB cache + GB级dataset） |
| DAG | 无 | 有 |
| Epoch | 无 | 每30,000个区块 |
| 额外字段 | Nonce | Nonce + MixDigest |
| 轻节点验证 | — | 仅需16MB cache |
4.4 PoW vs PoS vs DPoS
| 维度 | PoW | PoS | DPoS |
|---|---|---|---|
| 稀缺资源 | 算力/电力 | 权益（持币/币龄） | 权益+投票选举 |
| 能源消耗 | 巨大 | 极低 | 极低 |
| 容错阈值 | 1/2 | 1/3（BFT风格） | 1/3（BFT风格） |
| 交易确认时间 | ~60分钟 | 秒到分钟级 | 秒级甚至毫秒级 |
| 代表节点数 | 无限制 | 无限制 | 有限（如EOSIO为21个） |
| 长程攻击 | 不存在 | 存在 | 存在 |
| 无利害关系 | 不存在 | 存在 | 存在 |
| 去中心化程度 | 高（矿池带来中心化） | 中 | 低（少数代表节点） |
| 安全性类型 | 概率性 | 确定性（Casper FFG） | 确定性 |
4.5 EOSIO共识演进：传统DPoS vs 初级BFT-DPoS vs 升级BFT-DPoS
| 维度 | 传统DPoS | 初级BFT-DPoS | 升级BFT-DPoS |
|---|---|---|---|
| 出块速度 | 3s | 3s | 0.5s |
| 交易确认时间 | 45s | ~3s | ~1s |
| 确认方式 | 等待轮流出块确认 | 立即签名返回 | 立即签名返回 |
| 出块顺序 | 随机 | 随机 | 商议确定（低延迟相邻） |
| 连续出块数 | 1个/轮 | 1个/轮 | 6个/轮 |
| 核心借鉴 | 纯DPoS | PBFT思想 | PBFT + 网络优化 |
4.6 Casper FFG 合理检查点 vs 确定检查点
| 维度 | 合理检查点(Justified) | 确定检查点(Finalized) |
|---|---|---|
| 条件 | 2/3以上权益投票 c’→c，c’已是合理检查点 | 2/3以上权益投票 c’→c，c是c’的直接子检查点 |
| 高度关系 | 无要求 | h(c) = h(c’)+1 |
| 相当于PBFT | PREPARED | COMMITTED |
| 含义 | 2/3节点都认可这个检查点 | 2/3节点都知道有2/3节点认可 |
| 是否可逆 | 可能 | 不可逆 |
五、可能考题
选择题（答案用 粗体 标注）
-
PBFT需要（ ）个阶段。 A. 2 B. 3 C. 4 D. 5
-
PBFT的通信复杂度是（ ）。 A. N² B. N C. N³ D. N^N
-
CAP理论不包括的以下特性是（ ）。 A. 一致性 B. 分区容忍性 C. 扩展性 D. 可用性
-
以太坊中工作量证明的共识算法叫（ ）。 A. POS B. Ethash C. PBFT D. BFT
-
常见的区块链分片方案不包括（ ）。 A. 交易分片 B. 状态分片 C. 网络分片 D. 密码分片
-
比特币矿工在挖矿时，以下方法能改变区块Hash值的是（ ）。 A. 改变区块中交易顺序 B. 将接受挖矿奖励的地址改成自己的另一个地址 C. 改变Nonce值 D. 以上都能
-
拜占庭将军问题解决的是（ ）。 A. 分布式通信 B. 内容加密 C. 投票机制 D. 一致性问题
-
分布式一致性应该满足的三个特性中不包括（ ）。 A. 可扩展性 B. 可终止性 C. 约同性 D. 合法性
-
共识机制主要是为了保证账本的正确性和（ ）。 A. 真实性 B. 可靠性 C. 确定性 D. 一致性
-
以太坊动态调整挖矿难度的原理是（ ）。 A. 统计过去一段时间的出块速度，若太快则调难，若太慢则调简单 B. 统计矿工们的挖矿设备性能，若矿工挖矿设备性能强，则将难度调难 C. 每个区块的难度都可以在其父区块基础上调整难度 D. 根据过去一段时间的用户交易数量调整，若用户交易量大，则降低出块难度
填空题
- Proof of Stake共识算法的中文名称是 权益证明。
- 在分布式系统中，传输模型主要分为两种，其中一种是 同步 模型，指系统中各个节点的时钟误差存在上限；节点所发出的消息，在一个确定的时间内，肯定会到达目标节点（传输时间有上界，且上界已知）。
- Casper FFG 是目前比较有潜力的权益证明共识机制，并会在未来以太坊2.0中采用。该机制是一种拜占庭容错(BFT)风格的权益证明，其目前容错率也为 1/3。
- 工作量证明共识机制的容错性为 1/2。
- 与比特币的工作量证明相比，以太坊的工作量证明算法能 抵抗ASIC。
简答题
1. 目前有哪些提出的共识算法可以缓解工作量证明算法的能源浪费问题？
答：① 权益证明(PoS) — 基于权益（持币量/币龄等）而非算力争夺记账权，消除能源消耗；② 委托权益证明(DPoS) — 选举少数代表节点进行投票共识，大幅提升效率、降低能耗；③ Casper FFG — BFT风格的权益证明，以太坊2.0采用，通过保证金和罚没机制保障安全；④ PBFT — 基于投票而非算力竞争，无能源浪费，但受限于节点数量，适用于联盟链而非大规模公有链。
2. 什么是拜占庭将军问题？经典解法有哪些？
答：拜占庭将军问题是Leslie Lamport等人于1982年提出的一致性问题虚构模型：多个将军（节点）通过信使传递消息，需对军事活动（提案）达成一致决定，但将军中可能存在叛徒（恶意节点），向不同将军传递不同消息试图干扰共识。核心结论：当 N ≥ 3F+1 时问题有解。经典解法包括：实用拜占庭容错算法(PBFT)（三阶段投票，容错率1/3）、工作量证明(PoW)（争夺记账权，容错率1/2）、权益证明/Casper FFG（BFT风格PoS，容错率1/3）。
3. 比特币与以太坊的工作量证明机制有何不同？
答：① 哈希算法不同 — 比特币使用两轮SHA256(SHA2)，以太坊使用Keccak256+FNV(SHA3)；② 设计目标不同 — 比特币侧重哈希速率，以太坊Ethash侧重快速I/O能力以抵抗ASIC；③ 内存需求不同 — 比特币仅需约80B区块头，以太坊需要16MB cache和GB级dataset；④ 数据结构 — 以太坊引入DAG组织的dataset，比特币无；⑤ 纪元机制 — 以太坊每30,000个区块重新计算cache和dataset；⑥ 区块头字段 — 以太坊额外含MixDigest字段（内存消耗证明）；⑦ 轻节点验证 — 以太坊轻节点仅需16MB cache。
4. 共识机制的设计中有哪些理论上不可能的限制？
答：① FLP不可能原理：网络可靠但允许节点失效（即便只有一个）的异步模型中，不存在确定性共识算法；另一种表述为异步分布式系统不能同时保证活性和安全性；需在两个方向折中：弱化活性→同步假设（PBFT），或弱化安全性→同步假设（PoW、Casper FFG）。② CAP原理：分布式系统不可能同时确保一致性、可用性和分区容忍性；分区容忍性必须满足，需在一致性和可用性间取舍；比特币侧重可用性，PBFT侧重一致性。③ 拜占庭问题阈值：叛徒超过1/3时无法保证一定能达到一致结果。
5. 以太坊PoS机制的核心思想是什么？
答：核心思想是将共识的稀缺资源从算力（电力）转变为权益（持币量/币龄等），公有链共识泛化为”基于某种稀缺资源对记账权竞争”。Casper FFG作为BFT风格的PoS实现：① 通过保证金机制和罚没条件（同一高度双投、嵌套投票）解决无利害关系问题，使恶意投票导致亏损；② 通过解冻期（如4个月）缓解长程攻击（首次加入或离线超4个月的节点可能进入错误链）；③ 通过合理检查点→确定检查点两阶段确认机制实现确定性安全性。
论述/计算题
1. PBFT为什么需要三个阶段？为什么容错率是1/3？
为什么需要三个阶段：预准备和准备阶段确保同一视图下消息顺序一致；准备和提交阶段确保不同视图间消息顺序一致。若简化为两个阶段（去掉提交阶段），节点A收到2F+1个PREPARE消息就认为共识达成并执行请求，但其他节点可能尚未收到足够PREPARE消息；此时若发生视图切换，A已执行的结果需要在新视图中重播，导致状态机二义性（A已执行过一次但收到重播消息时不知是否需再次执行）。
为什么容错率是1/3：设N个节点中F个拜占庭节点。拜占庭节点可故意不回复，因此节点须在收到N-F个回复后做出决策。N-F个回复中可能含F个拜占庭节点回复，正确消息数为N-F-F。为遵循少数服从多数原则：N-F-F > F ⇒ N > 3F ⇒ N ≥ 3F+1。容错性 = F/(3F+1) ≈ 1/3。
2. 分析PoW矿工与PoS矿工在分叉时的策略差异，解释”无利害关系”问题及Casper FFG的解决。
策略差异：PoW中每份算力只能投入一个分叉（物理限制），同时选两边需平分算力导致EV=0.5（非最优）；最优策略为将全部算力投入最大概率分叉（EV=0.9）。PoS中每份权益可同时在所有分叉押宝（无额外成本），同时选两边EV=1.0（最优策略）。这就是无利害关系问题——追求收益最大化的矿工会同时在所有分叉投票，导致分叉长期维持。
Casper FFG解决：引入保证金和罚没机制。罚没条件：① 同一高度投两个不同检查点；② 嵌套投票(h(s1)<h(s2)<h(t2)<h(t1))。若罚金远大于投票收益（如罚金=5倍收益），同时选两边的EV=0.9+0.1-5=-4，处于亏损状态，矿工的最优策略变为努力选择一个正确的分叉投票。
3. 解释FLP不可能原理及其对区块链共识设计的启示。
FLP不可能原理：在网络可靠但允许节点失效（即便只有一个）的异步模型中，不存在确定性共识算法。另一种表述：异步分布式系统不能同时保证活性和安全性。
启示：需要在活性和安全性间权衡折中。① 弱化活性假设→同步假设：以PBFT为代表，安全性在异步网络中能保证，但活性需要同步模型（若网络变为异步可能永远不能完成客户端请求处理）；② 弱化安全性假设→同步假设：以比特币PoW为代表，活性在异步网络中保证，但安全性不能保证（分叉/账本不一致），是概率上的安全性（随时间被回滚概率越来越低），安全性依赖同步模型（只有10min内完成全网广播才能保证不发生分叉）。Casper FFG也属此类型但实现的是确定性而非概率性的安全性。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
评论区
