区块链技术的核心在于其共识算法，它决定了分布式网络中如何达成信任与一致性。从比特币的工作量证明（PoW）到以太坊2.0的Casper权益证明（PoS），共识算法的演进始终围绕安全性、效率与去中心化的平衡展开。本文将深入解析九种主流共识算法——包括PoW、PoS、PBFT、Raft、DPoS、PoA及Casper——从实现原理到实际应用案例，剖析其设计哲学与技术挑战。

在公链与联盟链并行发展的今天，共识算法的选择直接决定了系统的性能边界与适用场景。例如，PoW通过算力竞争保障比特币的安全性，却面临高能耗争议；而PoS与DPoS则通过经济激励降低能耗，但需解决“无利害攻击”等新问题。本文不仅涵盖经典算法的理论基础，还将结合Hyperledger Fabric的PBFT等前沿实践，探讨共识算法如何适配不同场景需求。如果你希望理解区块链底层逻辑，或在实际项目中设计高效共识机制，本文将为你揭示关键答案。

一、工作量证明（PoW）

Pow共识算法（Proof of Work）是一种共识算法，通过算力的比拼来选取一个节点，由该节点决定下一轮共识的区块内容（记账权）。节点消耗自身算力尝试不同的随机数（nonce），从而寻找符合算力难度要求的哈希值，不断重复尝试不同随机数直到找到符合要求为止，此过程称为“挖矿”。Pow是比特币等区块链网络使用的共识算法，是一种去中心化的共识机制，安全性较高，但需要大量能源和计算资源。

PoW算法的原理

PoW（Proof of Work工作量证明）是一种通过算力竞争达成共识的机制，其核心思想是让节点（矿工）通过解决一个计算难题来争夺记账权，以此确保区块链网络的安全性和去中心化。具体实现分为以下步骤：

  1. 区块构造 每个区块包含交易数据、前一个区块的哈希值PrevHash、时间戳Timestamp和一个随机数Nonce。矿工需将待打包的交易数据组合成候选区块。
  2. 哈希计算与难度目标 矿工通过不断调整Nonce值，对区块头进行哈希运算，直到找到一个哈希值满足网络设定的难度目标，例如，哈希值前导零的数量。这一过程称为“挖矿”。若Nonce溢出仍未找到解，需修改Coinbase交易中的ExtraNonce字段以生成新的Merkle根，重新开始计算。
  3. 难度动态调整 网络通过算法定期调整难度值，确保平均出块时间稳定，比特币约10分钟。若算力增加导致出块过快，难度自动提升；反之则降低。
  4. 验证与广播 成功找到符合条件的哈希值的矿工将新区块广播至全网，其他节点通过验证哈希值是否符合难度要求来确认区块的有效性。验证过程仅需一次哈希计算，成本极低。

Nonce与挖矿

Nonce（Number only used once）是一个一次性使用的随机数，存储在区块头中。它的唯一目的是通过调整数值，使得区块头的哈希值满足网络设定的难度目标。Nonce的调整是矿工参与算力竞争的核心手段。

Nonce递增

  1. 区块头构造 矿工将待打包的交易数据、前一个区块的哈希值PrevHash、时间戳Timestamp等信息组合成区块头。Nonce是区块头中的一个字段，初始值通常设为0。
  2. 哈希计算与难度验证 矿工对区块头进行哈希运算，生成一个固定长度的哈希值。若哈希值的数值小于等于当前网络的目标值Target，则该Nonce有效，区块被成功挖出。 例如：若目标值要求哈希值前导零达到18位，矿工需不断调整Nonce，直到找到符合条件的哈希。
  3. 试错循环 若当前Nonce无法生成有效哈希，矿工会递增Nonce值，递增范围从0到2^32，递增后重新计算哈希，直到满足条件。这一过程可能需要尝试数十亿次。 代码逻辑示意：
while True:
    block.nonce += 1
    hash = SHA256(block.header)
    if hash < target:
        break

难度目标与Nonce的关系

  • 动态调整机制：网络每隔一定时间（比特币每2016个区块）调整目标值，以维持平均出块时间稳定（比特币约10分钟）。目标值越低，找到有效Nonce的难度越高。
  • 算力竞争 ：Nonce的调整速度直接反映矿工的算力。高算力矿工单位时间内可尝试更多Nonce值，提升挖矿成功率。

为什么需要调整Nonce？

  • 防止篡改：若攻击者想修改历史区块，需重新计算该区块及其后续所有区块的Nonce，成本极高。
  • 公平性保障：Nonce的试错过程依赖算力，确保所有矿工在相同规则下竞争，避免作弊。

实际案例

  • 比特币挖矿：矿工通过ASIC矿机高速调整Nonce，寻找符合当前难度的哈希值。
  • 以太坊（PoW阶段）：Ethash算法要求矿工同时调整Nonce和混合数据集（DAG），进一步增加计算复杂度。

难度动态调整机制

  1. 调整周期：每生成2,016个区块（约两周）进行一次难度调整。这一周期设计基于每个区块平均10分钟的生成时间，2,016个区块总耗时约为20,160分钟（14天）。
  2. 调整目标：核心目标是维持全网平均出块时间稳定在10分钟左右。无论网络算力如何波动，系统通过调整难度确保出块速度的稳定性。
  3. 计算依据：
    • 难度调整基于前一个周期的实际出块时间与理论时间（20160分钟）的比率。若实际耗时短于理论值（算力增加），难度上升；反之则下降。
    • 公式为：新目标值 = 当前目标值 × (2016个区块实际耗时 / 20160分钟)
  4. 实施方式：
    • 每个完整节点独立执行难度调整，无需中心化协调。节点根据链上历史数据自动计算新难度，确保全网一致性。
    • 若节点未按规则调整，可能因与其他节点的难度不一致而被网络排斥。
  5. 动态响应：
    • 算力激增时，难度随之上升以防止出块过快；算力下降时，难度降低以避免出块停滞。这种机制保障了比特币网络的长期稳定运行。

二、权益证明（PoS）

PoS共识算法（Proof of Stake）是一种通过代币质押和随机选择验证者来达成共识的机制，旨在解决PoW的高能耗问题。验证者根据其质押的代币数量和时间竞争记账权，无需消耗大量算力。PoS在保障安全性的同时显著降低能耗，被以太坊2.0、Cardano等主流区块链采用。

PoS算法的原理

PoS的核心思想是“质押代币即权力”，通过经济激励约束参与者行为。其运作分为以下步骤：

  1. 验证者注册与质押
    • 节点需质押一定数量的代币（以太坊2.0要求32 ETH）作为保证金，成为验证者。
    • 质押量越高，被选为区块提议者的概率越大，类似PoW中算力占比决定出块概率。
  2. 验证者选择
    • 网络通过随机算法（如RANDAO）结合质押权重，从活跃验证者池中选出区块提议者和委员会成员。
    • 例如，以太坊2.0的信标链每一个Epoch，即6.4分钟分配一次验证者角色。
  3. 区块生成与验证
    • 被选中的提议者打包交易并生成新区块，委员会成员投票确认区块有效性。
    • 若区块获得2/3以上质押权重的验证者同意，则被添加到链上。
  4. 奖励与惩罚
    • 奖励：诚实的验证者按质押比例获得区块奖励和交易手续费，年化收益率通常为4-10%。
    • 惩罚（Slashing）：若验证者提交冲突区块或离线，部分质押代币将被没收。例如，双签行为可能导致质押量的1-100%被罚没。

验证者选择机制

PoS验证者选择通过质押权重与随机算法结合实现，确保公平性与安全性。具体机制如下：

1. 质押权重决定基础概率

验证者需质押一定数量的代币（以太坊2.0要求32 ETH），质押量越高，被选为区块提议者的概率越大。例如，质押100 ETH的验证者比质押32 ETH的验证者更可能获得出块机会。

2. 随机算法确保不可预测性

以太坊使用RANDAO（可验证延迟函数与哈希混合）生成随机数，避免验证者提前预知选举结果。具体流程：

  1. 参与者提交哈希承诺 每个验证者或参与者在本地生成一个随机数secret，并计算其哈希值hash(secret)，将哈希值提交至区块链。此过程称为“承诺阶段”，确保随机数在生成前无法被他人知晓。
  2. 逐步揭示原始随机数 在后续的区块中，参与者需逐步揭示其原始随机数secret，验证者通过比对哈希值确认其真实性。例如，以太坊2.0中验证者需在多个Epoch内分层提交随机数的Hash Onion。
  3. 混合生成最终随机数 将所有参与者提交的原始随机数进行异或或哈希组合，生成最终的全局随机数。 例如：final_random = hash(secret_1 || secret_2 || ... || secret_n)

验证者提前两个Epoch被固定为候选者，防止恶意节点操控选举时机。

3. 信标链协调验证者分配

信标链作为以太坊2.0的协调层，通过以下步骤管理验证者：

  • 分片分配：验证者被随机分配到不同分片或委员会，每个委员会负责验证特定区块。
  • 角色轮换：每个Epoch重新分配验证者角色，避免权力集中。

4. 委员会投票与最终敲定

  • 委员会构成：每个分片的区块需由至少128名验证者组成的委员会投票。
  • 敲定条件：区块需获得2/3以上质押权重的验证者投票才能被最终确认，防止分叉。

5. 验证者类型

  • 提议者（Proposer）：负责生成新区块，由随机算法选出。
  • 委员会（Committee）：验证区块有效性，投票权重与质押量成正比。
  • 见证者（Attestor）：在分片链中验证特定分片的状态

三、实用拜占庭容错（PBFT）

PBFT（Byzantine Fault Tolerance）是一种解决分布式系统中拜占庭将军问题 的共识算法，允许系统在存在恶意节点或故障节点的情况下，仍能达成一致性和正确性。与PoW/PoS依赖算力或质押不同，BFT通过多轮投票和节点协作实现高效共识，适用于联盟链和私有链场景。

拜占庭将军困境

拜占庭将军问题描述了分布式系统中，如何在部分节点失效或作恶时达成一致行动。例如：

  • 场景：多个将军围困一座城市，需通过信使协调进攻时间。若存在叛徒发送错误信号，如何确保忠诚的将军仍能达成一致？
  • 映射到区块链：节点可能因网络延迟、硬件故障或恶意行为发送错误信息，BFT需在此类情况下保证共识正确性。

PBFT算法的核心机制

节点角色划分

  • 主节点（Leader）：负责发起提案，通常按轮询策略轮换以避免单点故障。
  • 副本节点（Replica）：验证提案并参与投票，通过多阶段消息传递达成共识。

投票流程（以PBFT为例）

  • 提案阶段：客户端向主节点发送提案请求。
  • 预准备阶段：主节点广播提案给所有副本节点。
  • 投票阶段：副本节点接收到提案后投票支持或拒绝，并将投票结果给其他所有节点，
  • 收集阶段：节点收集其他节点的投票信息，收集到足够投票（通常需2/3以上节点同意）后锁定提案。
  • 提交阶段：节点锁定提案后，将提案最终结果广播给其他节点，最终达成全网一致性。

视图切换机制

当主节点失效或作恶时，PBFT通过视图切换选举新主节点，确保系统持续运行。

视图切换触发条件

  • 超时机制：副本节点维护定时器，若在预设时间内未收到来自主节点的提案或响应，则触发视图切换。
  • 显式检测恶意行为：副本节点检测到主节点发送冲突提案或无效消息时，则主动发起视图切换。

视图切换流程

  1. 广播视图切换请求
  • 副本节点向全网广播视图切换消息，包含当前视图编号v、已锁定的提案信息及自身签名。
  • 当节点收到包括自身的至少2f+1个有效的视图切换消息的响应时，触发新视图选举。
  1. 选举新的主节点
  • 新主节点选择：根据预定义规则确定新主节点。新主节点编号通常为v % n（v为视图编号，n为节点总数）。
  • 广播新视图信息：新主节点收集所有视图切换消息，生成新视图消息，新视图消息中包含已验证的提案状态和新视图编号v+1，并广播至全网。
  1. 状态同步与恢复
  • 继承历史状态：新主节点需继承前视图的锁定提案，即已提交但未执行的请求，确保跨视图一致性，避免分叉。
  • 恢复共识流程：新主节点继续处理未完成的提案或发起新提案，系统进入新视图的正常共识阶段。

安全性保障

  1. 消息签名与验证：所有视图切换消息和新视图消息需包含数字签名，防止伪造或篡改。
  2. 阈值约束：
    • 触发视图切换需满足2f+1个节点的确认，确保恶意节点无法操控选举。
    • 新主节点需验证所有视图切换消息的合法性，避免无效状态继承。
  3. 防重复攻击：通过视图编号递增和提案序号管理，防止旧视图的恶意消息干扰新视图。

PBFT容错能力

PBFT采用3f+1节点模型，其中f为可容忍的拜占庭节点数。具体规则如下：

  • 最大容错节点数：系统最多允许f个恶意节点，总节点数需满足n ≥ 3f+1。 例如：
    • 若f = 1，即容忍1个恶意节点，则需至少4个节点；
    • 若f = 2，则需至少7个节点。

PBFT的局限性

  1. 通信开销：节点间通信复杂度为O(n²)，大规模网络性能显著下降。
  2. 中心化风险：主节点轮换依赖算法设计，若轮换机制不公可能引入中心化。
  3. 主节点瓶颈：主节点可能成为性能瓶颈或攻击目标，需依赖视图切换机制。
  4. 同步假设：PBFT假设网络部分同步，消息延迟有上限，需网络强同步性，异步环境下可能失效。

PBFT与BFT的区别

算法复杂度

  • 传统BFT：复杂度为指数级，仅适用于小规模网络。
  • PBFT：复杂度为多项式级（O(n²)），通过状态机复制和三阶段投票降低通信开销。

节点角色与通信模式

  • BFT：节点对称，无明确主节点，依赖多轮广播。
  • PBFT：区分主节点与副本节点，主节点负责提案生成，副本节点通过三阶段投票协作。

四、可用性和一致性（Raft）

Raft是一种分布式一致性算法 ，旨在通过强领导机制和日志复制实现节点间的高效共识。与PoW依赖算力或PBFT的多阶段投票不同，Raft通过**领导者选举、**日志同步和安全性保障简化分布式系统的容错设计，适用于私有链、联盟链及分布式存储系统。

Raft的核心设计目标

  1. 易理解性：通过模块化设计（如分离领导者选举、日志复制、安全性）降低算法复杂度。
  2. 强一致性：确保所有节点的日志副本完全一致，即使网络分区或节点失效。
  3. 容错能力：总节点数需满足2f+1，支持容忍最多f个故障节点。

领导者选举

触发选举的条件

  • 心跳超时机制：跟随者在选举超时时间内未收到来自当前领导者的心跳或日志复制消息，即触发选举流程。
  • 初始状态：所有节点启动时默认为跟随者，等待领导者的消息。

选举流程

  • 转为候选人
    • 自增任期：跟随者将当前任期号加1，进入候选人状态。
    • 投票给自己：候选人立即给自己投一票，并向其他节点广播请求投票消息，携带当前任期和日志信息。
  • 其他节点投票
    • 投票条件：
      • 若节点的当前任期小于候选人的任期，则接受投票请求。
      • 若节点的当前任期等于候选人的任期，需判断候选人的日志是否“更新”，即日志条目更多。
    • 投票响应：节点仅投一票给首个符合条件的候选人，并重置自身的选举超时计时器。
  • 选举结果判定
    • 成功当选：候选人收到超过半数节点的投票后，立即成为新领导者，并开始发送心跳维持权威。
    • 选举失败：若未获得多数票或发现更高任期的领导者，候选人回退为跟随者。

避免选票分裂

  • 随机超时时间：每个节点的选举超时时间在一定范围内随机生成（如150ms~300ms），降低多个跟随者同时触发选举的概率。
  • 任期冲突处理：若多个候选人同时发起选举，任期号更高的候选人优先；若任期相同，则通过日志新旧决定。

安全性保障

  • 单领导者原则：每个任期内只能有一个领导者，通过投票机制和任期递增规则确保。
  • 日志一致性：候选人必须包含最新的日志条目才能当选，避免日志丢失或不一致。

领导者维持与心跳机制

  • 心跳广播：新领导者周期性发送AppendEntries至所有跟随者，维持自身权威并阻止其他选举。
  • 日志同步：领导者通过心跳携带日志条目，确保所有节点的日志副本最终一致。

日志复制

日志结构与基本规则

  • 日志条目：每个条目包含：
    • 索引Index：日志在日志序列中的唯一位置。
    • 任期Term：日志条目生成时的领导者任期号。
    • 命令Command：客户端提交的操作，如交易或状态变更。
  • 持久化要求：所有日志条目需持久化存储，避免节点重启后丢失。

日志复制的核心流程

  • 客户端请求处理
    • 请求接收：客户端将读写请求操作发送至领导者。
    • 日志追加：领导者将操作封装为新的日志条目，追加到本地日志中，并记录当前任期。
  • 日志广播与复制
    • AppendEntries：领导者通过心跳（AppendEntries）将新日志条目并行发送至所有跟随者， 心跳包含以下关键字段：
      • 领导者的当前任期Term。
      • 前一个日志条目的索引和任期，用于一致性检查。
      • 新日志条目内容Command。
      • 领导者的提交索引Commit Index。
  • 一致性检查 ：
    • 跟随者验证本地日志的前一个条目是否与心跳请求中的prevLogIndex和prevLogTerm匹配。
      • 若匹配：接受新日志条目并追加到本地日志。
      • 若不匹配：拒绝请求，触发领导者递减索引并重试。

日志提交与应用

  • 多数节点复制成功：当领导者确认新日志条目已复制到大多数节点，将日志标记为Commit。
  • 提交通知：领导者通过后续的AppendEntries将提交索引（Commit Index）广播至所有跟随者。
  • 应用日志：所有节点将已提交的日志条目按顺序更新到本地状态机，执行客户端请求的操作。

处理不一致日志

Raft通过领导者强制覆盖机制解决节点间日志不一致问题

  • 冲突检测
    • 若跟随者的日志与领导者不一致，如缺少条目或任期冲突，领导者通过递减索引重试AppendEntries请求，找到双方日志一致的最高索引位置。
    • 例如：领导者从自己的最新索引开始尝试，若跟随者拒绝，则回退到前一个索引，直到找到匹配点。
  • 覆盖不一致条目
    • 领导者覆盖跟随者在匹配点之后的所有冲突日志条目，确保最终一致性。

Raft的容错与恢复机制

网络分区处理

  • 双领导者问题：通过任期号Term冲突解决，旧任期的领导者自动降级为跟随者。
  • 日志修复：新领导者通过强制覆盖不一致的日志条目，修复跟随者数据。

成员变更

  • 联合共识：新增或移除节点时，通过两阶段配置（旧配置与新配置并存）确保过渡期一致性

五、委托权益证明（DPoS）

DPoS（Delegated Proof of Stake，委托权益证明）是一种高效、低能耗的共识算法，通过代币持有者投票选举区块生产者实现快速出块与网络治理。与PoW的算力竞争和PoS的质押权重不同，DPoS通过民主化委托机制平衡去中心化与性能，被EOS、BitShares等区块链采用。

DPoS的核心设计目标

  • 高吞吐量：通过固定数量的区块生产者实现秒级出块，支持每秒数千至数万笔交易。
  • 低能耗：无需算力竞争，依赖投票与信誉机制维持网络运行。
  • 去中心化治理：代币持有者通过投票决定网络参数。

DPoS的核心机制

投票与区块生产者选举

  • 候选节点注册
    • 注册条件：节点需质押一定数量的代币，如EOS要求100 EOS，并公开技术方案与服务承诺。
    • 动态参与：候选节点可随时加入或退出，但需持续满足质押门槛。
  • 持币者投票
    • 投票权重：持币者按持币比例分配投票权重，1代币=1票，可将票投给多个候选节点。
    • 投票方式：用户需将代币锁定在投票系统中，投票实时生效且可随时更改。
    • 激励机制：部分系统（如EOS）允许节点向投票者分享出块奖励，提高参与度。
  • 选举结果统计
    • 得票排名：系统实时统计候选节点的得票数，排名前N的节点成为区块生产者，如EOS为21个）。
    • 动态更新：选举结果通常每轮更新（如EOS每2分钟统计一次），确保生产者反映最新民意。

区块生产与验证

  • 生产者轮换出块
    • 固定顺序：当选生产者按随机或预定顺序轮流出块（如EOS每0.5秒一个区块）。
    • 时间窗口：每个生产者在指定时间段内生成多个区块（如EOS每轮12个区块/生产者）。
    • 无效区块处理：若生产者未按时出块或生成无效区块，后续生产者将跳过该区块并报警。
  • 验证与惩罚机制
    • 拜占庭容错：区块需经2/3以上生产者验证才能最终确认，防止双花攻击。
    • 漏块惩罚：未按时出块的生产者按漏块数量扣除质押代币。
    • 作恶惩罚：签署冲突区块的生产者将被没收全部质押代币并永久除名。
  • 治理与更新
    • 参数调整：持币者可通过投票修改网络参数（如区块大小、出块间隔）。
    • 分叉处理：若发生分叉，系统默认选择最长链；恶意分叉可通过投票冻结账户或回滚交易（如EOS的治理争议）。

六、权威证明（PoA）

PoA（Proof of Authority）是一种基于身份认证与信誉机制的共识算法，通过预选可信节点（验证者）快速生成区块，适用于私有链和联盟链场景**。**与PoW的算力竞争不同，PoA依赖节点的 现实身份与声誉维护网络安全性，实现高吞吐量与低能耗。

PoA的核心设计目标

  • 高效率：秒级出块，支持每秒数百至数千笔交易，适用于企业级应用。
  • 低能耗：无需算力竞争，节点仅需验证身份与签署区块。
  • 可控性：仅授权节点可参与共识，防止匿名恶意节点攻击。

PoA的核心机制

验证者身份认证

  • 准入门槛：节点需通过身份审核 （如企业资质、政府认证），成为验证者。
  • 动态管理：验证者列表由网络治理委员会维护，可添加或移除节点。

轮流出块机制

  • 固定顺序：验证者按预定顺序轮流出块（如每5秒一个区块），无需竞争。
  • 签名验证：每个区块需包含验证者的数字签名，确保来源可信。

惩罚与激励

  • 作恶惩罚：若验证者签署无效区块或离线，将被扣除质押代币并移除资格。
  • 奖励机制：验证者按出块数量获得交易手续费或系统代币奖励。

PoA的详细流程

验证者选举

  • 资质审核：候选节点提交身份证明（如企业营业执照、个人KYC资料）。
  • 投票或指定：由现有验证者投票或治理委员会直接指定新节点。
  • 质押保证金：验证者需锁定一定数量的代币作为诚信担保。

区块生成与验证

  • 出块权限分配：验证者按固定时间表（如每5秒）轮流出块，无竞争延迟。
  • 跨节点验证：后续验证者验证前序区块签名与交易合法性，若发现问题则触发惩罚。
  • 最终确认：区块经多数验证者签名后标记为不可逆。

动态调整

  • 节点替换：若验证者频繁漏块或作恶，治理委员会可启动替换流程。
  • 参数优化：出块间隔、质押门槛等参数可通过治理投票调整。

PoA的优缺点

优势

  • 高TPS：固定出块顺序减少通信开销，支持高频交易（如供应链、医疗数据共享）。
  • 低资源消耗：普通服务器即可运行节点，无需矿机或显卡。
  • 抗51%攻击：仅授权节点可参与，攻击者无法通过算力或代币控制网络。

局限性

  • 中心化风险：验证者权力集中，可能违背区块链去中心化理念。
  • 信任依赖：依赖身份审核机制，若治理委员会腐败则系统失效。

七、Casper

Casper的两种主要变种

Casper FFG（Friendly Finality Gadget）

  • 设计者：由Vitalik Buterin提出，是以太坊从PoW过渡到PoS的核心方案。
  • 核心机制：
    • 混合共识：初期与PoW结合，后期完全转向PoS。
    • 检查点（Checkpoint）：每50个区块为一个检查点，验证者通过投票确认检查点的合法性。
    • 两阶段提交：
      1. Prepare阶段：验证者投票支持某个检查点成为“预准备”状态。
      2. Commit阶段：若某检查点获得2/3以上验证者的投票，则被标记为“最终确定”（Finalized）。

Casper CBC（Correct-by-Construction）

  • 设计者：由Vlad Zamfir和Greg Meredith提出，强调协议的形式化验证与安全性 。
  • 核心机制：
    • 渐进式协议构建：通过数学证明逐步完善协议规则，确保每一步的安全性。
    • 预言机集群（Oracle）：验证者通过集群协作达成共识，动态调整协议参数以应对网络变化。
  • 原理：以太坊2.0的PoS实现，结合“最终确定性检查点”机制，验证者需抵押ETH，恶意行为会被罚没。
  • 案例：以太坊2.0（信标链）。

Casper的核心机制

验证者角色与质押

  • 准入条件：节点需质押一定数量的代币（如以太坊要求32 ETH），成为验证者。
  • 投票权重：质押量决定投票影响力，但每个验证者的投票权重上限为1（防止单点控制）。

共识流程（以Casper FFG为例）

  • 区块提议：验证者按质押权重被随机选为“提议者”，生成新区块。
  • 投票与确认：
    • 验证者对检查点进行投票，若某检查点获得2/3以上投票，则触发“最终确定”。
    • 最终确定的区块不可逆，防止分叉。
  • 惩罚机制（Slashing）：恶意行为者将被罚没部分或全部质押代币。
    • 双重投票：同一高度投票给两个不同区块。
    • 环绕投票：投票的源检查点与目标检查点存在逻辑矛盾。

3. 安全性保障

  • 经济绑定：攻击者需掌握超过1/3的质押代币才能破坏共识，成本极高。
  • 长程攻击防御：通过检查点机制与定期状态快照，阻止历史链回滚。

Casper检查点

检查点的定义

  • 周期性标记：检查点是每个Epoch的第一个Slot的区块。例如，以太坊2.0中每个Epoch包含32个Slot（每个Slot约12秒），因此检查点每6.4分钟生成一次。
  • 空块处理：若某Epoch的第一个Slot未生成区块，则该Epoch的检查点为空，但仍作为逻辑标记存在。

检查点的作用

  • 最终性判定：验证者通过投票对检查点进行“确认”，若某检查点获得2/3以上质押权重的支持 ，则被标记为“最终确定”（Finalized），后续无法被分叉。
  • 防分叉机制：一旦检查点被最终确定，任何与该检查点冲突的链（如双花攻击产生的分叉）将被协议直接拒绝。