English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC021
区块链共识主张，不应只告诉读者系统使用工作量证明、权益证明还是投票委员会。至少需要区分四个问题：哪些区块有效，参与者怎样取得权重，节点目前选择哪段有效历史，以及有什么证据支持在协议下把部分历史视为稳定。
这些问题相互影响，答案却不能互换。大量工作量不能把无效交易变有效；选定链头不自动等于最终确定检查点；持续出块也不一定保证每个用户及时获得交易收录。
本篇介绍一种阅读方法：把共识说明转成假设卡，标记已经规定的内容，把没有支持的结论保留为待确认。两份虚构说明用于练习，特意不完整，不能当作能够运行的共识协议。
选择适合你的阅读路线
本篇目录
- 一、一个词里面藏着四个问题
- 二、比较合格历史之前，先检查有效性
- 三、权重必须有单位，也要有准入规则
- 四、分叉选择针对节点当前视图
- 五、最终性需要定义和假设
- 六、时序与故障限定不同承诺
- 七、虚构说明 A：开放的工作量计权链
- 八、虚构说明 B：经过认证的投票链
- 九、比较假设卡，不凭空选冠军
- 十、检验共识主张的六个问题
- 十一、制作持续有用的假设卡
- 常见问题
- 来源与下一步阅读
阅读协议介绍时，可以从四个问题和假设卡开始。比较主张时，可以使用两份虚构说明和压力问题。如果需要复制日志与法定集合交集的数学基础，请先看已有的分布式共识、法定人数与容错指南（英文）。
本篇不重复其中的 Raft 演算，而是对区块链说明执行另一项任务：识别有效性、参与权重、历史选择、最终性和时序假设之间的边界。
一、一个词里面藏着四个问题
“共识”常被用作整个系统的简称。这样说很方便，直到需要核对某项主张。可以先问：
- 有效性：按照规则，什么让区块及其提出的状态转换可以被接受？
- 参与和权重：谁可以提议或影响一致结果，有效权重由什么决定？
- 历史选择：在节点已知的有效候选中，它选择哪个分支或链头？
- 稳定或最终性：什么额外条件支持协议特定的稳定性主张？
再加第五问：在什么条件下，系统应该实现所承诺的进展？进展可能指出块、最终确定检查点，或收录某一类交易。这些结果不同。
即使实现把几项规则紧密组合，阅读时也要分别记录。目的不是强迫每条链采用同一架构，而是避免一个标签悄悄回答了其定义没有覆盖的问题。
如果协议说明只填了参与方式，它作为共识解释仍不完整。“任何人都能加入”，没有说明加入者能让系统接受什么。
二、比较合格历史之前，先检查有效性
设想一笔虚构目录交易缺少授权签名，却被某提议区块当作成功状态更新纳入。如果这违反系统验证规则，受欢迎程度或投票权重不能修复缺陷。诚实验证节点应执行适用规则，而不是只计算任意字节获得多少支持。
具体边界取决于协议。有些系统会拒绝包含无效交易的区块；有些系统记录排序后的交易，再把其中无效交易标记出来，不让它们改变应用状态。读者必须弄清具名系统采用哪一种模型。
Hyperledger Fabric 排序服务文档区分交易排序与节点验证。它说明，无效交易可以留在区块中，但被标记无效，不更新账本状态。因此，“纳入已排序区块”不等于“成功改变应用状态”。
对任何链，都应问每项检查由哪个组件执行，以及接受状态是什么意思。区块头检查、交易签名检查和完整状态转换验证，提供的证据不同。不要让界面上单一的“已接受”抹掉这些区别。
三、权重必须有单位，也要有准入规则
说明可能声称，多数支持某段历史。究竟是哪一种多数？网络连接、登记身份、计算工作量、权益权重，还是配置的组织集合？不同单位带来不同假设。
创建许多节点身份，不自动等于控制同样数量的独立决策者。协议需要说明参与怎样准入或计权，以及对对手影响作出什么假设。本模块后文会详细讨论女巫攻击。
现在先写清分母。如果使用投票权重，要确定对应哪个集合、哪个权重快照。如果使用累计工作量，要问怎样计算、哪些区块合格。如果使用认证成员资格，要问成员资格及其变化怎样建立。
不要把一个协议的百分比直接搬到另一个协议。没有单位、故障模型和目标属性的百分比，不是可用安全说明。例如，“容忍三分之一故障”，需要区分不可用参与者与任意对抗行为，并解释针对的是安全性、进展，还是两者。
四、分叉选择针对节点当前视图
节点可能得知多个有效分支。分叉选择规则依据节点可用信息和协议规则，帮助它选择链头或历史。不同时间收到资料的节点，可能暂时具有不同视图。
比特币开发者指南说明，节点在有效分支之间依据累计工作量选择。相关度量不只是区块数量。“有效”这个前提十分重要：更多工作量，不赋予违反节点共识规则的权限。
阅读时，可以分开三句话：节点收到了区块；按照已执行检查，节点认为区块有效；节点选择了包含它的分支。不能悄悄用前一句替代后一句。
选定链头也对应某个时间点的视图。后来的消息可能改变节点掌握的资料。这是否影响、怎样影响已稳定历史，要另行阅读最终性或稳定模型。
一个节点的链头截图，是有用观察证据，但本身不是所有诚实节点已经看到或选中完全相同链头的普遍声明。
五、最终性需要定义和假设
有些系统按照模型下替换历史的难度或概率，描述稳定信心；另一些系统有明确协议条件，把检查点或区块标记为最终确定。两类承诺不能互换。
以太坊 Gasper 文档提供了一个具体例子：把 LMD-GHOST 分叉选择组件，与 Casper-FFG 最终性区分开。这些名称识别该设计中的职责，不是每条权益证明链都必须使用的通用组件。
阅读最终性主张时，要问检查什么证据、哪些参与者或权重重要，以及哪些假设失效才可能出现互不相容的最终结果。如果主张基于概率，就应问哪种模型和参数支持信心程度。没有这些背景，确认次数不是通用保证。
还要区分协议最终性、法律结算、应用完成和实物交付。协议可能建立记录历史的某项属性，但文档运输、法律转让或外部服务仍未完成。
本篇只识别需要问的问题。后续文章会追踪确认与最终性时间线，并检查具体设计采用的证书或规则。
六、时序与故障限定不同承诺
网络假设可能规定消息延迟上界，假设通信最终恢复良好，或采用另一种精确模型。故障假设则可能限制崩溃参与者、对抗投票权重、被攻破密钥或其他行为。
读者应把每项假设连接到它支持的属性。系统可能希望在延迟期间保留某项安全性，同时需要通信改善才能取得进展。这不表示每次延迟都证明攻击，也不表示每个停顿系统都违反一致性。
超时是“某项资料没有在期限前到达”的观察。本身不能识别原因是崩溃、分区、过载、审查还是调度延迟。协议如何回应这个观察，也是规范的一部分。
实现假设同样重要。诚实软件必须按兼容规则解释同样输入，保留必要状态，并正确验证认证信息。抽象的对抗参与者比例限制，不自动覆盖影响所有人的共同软件缺陷。
关于主张的不变量与实现之间的区别，可参考已有的软件运行前正确性证明指南（英文）。本篇的实际任务，是标记区块链主张究竟写明了哪些假设。
七、虚构说明 A：开放的工作量计权链
虚构“River Chain”宣传册写道：“任何人都能通过提供所需工作量提议区块。节点选择累计工作量最大的有效分支。后续被接受区块会增加对早期历史的信心。区块出现很快。”
说明提供了一些信息，但仍有重要缺口。参与机制基于工作量，历史选择明确限定有效分支，稳定主张基于信心而不是已说明的最终性证书。不过，宣传册没有给出精确验证规则、工作量公式、对手资源假设、网络模型或信心计算。
“区块出现很快”尤其不完整。它指平均生成间隔、实测传播延迟、目标参数，还是用户看到的收录估计？观察了什么分布和负载？网络中断时是否仍适用？
正确阅读结论既不是“安全”，也不是仅凭这些就判定“不安全”，而是一张部分填好的假设卡。评估相关保证之前，审查者需要缺少的规范和测量。
River Chain 是虚构名称，不是换个名字的比特币规范。简短说明用于练习识别一项主张提供了什么、没有提供什么。
八、虚构说明 B：经过认证的投票链
另一份“Cedar Ledger”宣传册写道：“配置的验证者集合提议并投票。规定的证书规则让区块最终确定。在有界对手模型下，不应出现冲突的最终历史。进展需要足够诚实投票权重和合适通信。”
它区分了提议与最终性，也提到对手和通信假设，但仍省略实际证书规则、权重快照、轮次转换条件、签署限制、成员变化机制和应用验证规则。
读者不能借用另一协议熟悉的门槛来补空白。证书人数或权重运算本身，不是完整安全证明。参与者跨轮次、面对冲突提议时的行为重要，签名和状态保持可靠所依赖的假设也重要。
进展主张还需要定义进展：是出现下一份区块提议、一个最终确定区块，还是任何有效提交交易最终都能收录？哪些额外准入或调度政策控制个别请求？
Cedar Ledger 与 River Chain 一样，是诊断用说明，不是可运行算法。词汇更正式，也不能据此假定实现满足提出的保证。
九、比较假设卡，不凭空选冠军
两份说明强调不同证据与权衡。River 的选择规则依赖有效分支累计工作量；Cedar 的最终性主张依赖规定证书和参与者模型。按目前写法，两张卡都不足以对总体安全或性能排名。
公平比较应先对齐任务。如果应用需要特定稳定历史证据，就比较各设计假设下的同一属性。如果需要分区期间服务，就说明是什么服务、分区哪一侧。如果需要低延迟，就定义测量起点和终点。
不要拿 River 的平均出块间隔，与 Cedar 的最终确定应用响应延迟比较，再把小数字称为更快。它们衡量不同事件。同样，提交请求吞吐量，不一定等于有效、稳定应用更新的吞吐量。
资源成本与治理也不同。参与准入、运行、恢复、升级和验证，可能依赖不同主体。这些都是合理比较维度，但应由证据支持，不能从“无许可”或“许可制”标签自行推断。
有用成果是一组已对齐问题和缺少证据，而不是把不兼容宣传数字混成一个分数。
十、检验共识主张的六个问题
问题 A。某分支宣称权重更大，但完整验证发现违反规则，节点是否必须接受？
答案。不必须。选择规则作用于协议合格历史，权重不会自动覆盖有效性要求。
问题 B。两个节点显示不同的近期链头，是否单凭这一点就证明安全性违反？
答案。不是。应检查协议允许的暂时分歧和稳定规则。不同本地链头，不自动等于冲突的最终结果。
问题 C。中断期间 Cedar 没收到最终性证书，是否证明它最终确定了矛盾区块？
答案。不是。没有进展与作出冲突决定，是不同观察。应调查承诺属性及其假设是否成立。
问题 D。River 在测试中一直出块，但某个提交请求始终未出现，是否建立了每位用户都能收录的保证？
答案。没有。链进展本身，不证明每个请求满足收录条件或得到公平调度。
问题 E。提案说“三分之二同意”，却不定义参与者集合或权重，能充分评估安全主张吗？
答案。不能。分母、认证、故障模型、投票规则和目标属性都未明确。
问题 F。Fabric 把交易纳入排序区块，但节点标记无效，预定状态更新是否一定发生？
答案。不一定。在这个流程里，排序包含与成功状态更新不同。应读取有效性结果，不能从区块成员关系推断成功。
十一、制作持续有用的假设卡
对某个具名协议及版本，记录八项内容：
- 精确有效性检查，以及负责组件。
- 参与准入，以及影响力或投票权重单位。
- 历史选择规则，以及节点执行它所需资料。
- 最终性或稳定主张及其证据。
- 故障模型、限制，以及相应参与者或资源分母。
- 各种进展主张的时序与通信假设。
- 影响上述规则的成员、升级与恢复假设。
- 主张实际支持的应用可见事件。
为每个已填字段附上来源，缺少字段保持可见的待确认状态。留空比从另一条链继承假设更诚实。还要记录协议版本，因为规则变化可能改变旧摘要的含义。
然后写一句校准后的结论，例如：“说明已规定有效分支选择，但尚未提供评估其稳定信心主张所需的网络与对手假设。”这句话推动审查，却没有装作知道超出证据的事情。
假设卡不是形式证明，也不是生产审计。它是有纪律的阅读工具，告诉你还需要什么证据，以及哪些主张不能混为一谈。
常见问题
权益证明是完整共识规范吗？
不是。系统仍需要精确有效性、参与、投票、历史选择和稳定规则，以及相应假设。
投票能把无效数据变有效吗？
如果协议要求那条已违反的有效性规则，就不能。对字节达成一致，与满足应用规则应分开理解。
没有分叉，是否代表每笔交易成功？
不是。不分叉和交易有效性的含义取决于系统。已排序记录与已应用状态更新可以具有不同状态。
共识协议能保证每位用户立即收录吗？
不能从一般进展主张推断。准入、网络条件、容量、调度和审查假设，都需单独检查。
来源与下一步阅读
来源核对日期为新加坡时间 2026 年 10 月 12 日。River Chain 与 Cedar Ledger 是原创、刻意不完整的诊断例子，不规定可部署协议，也不声称已经证明安全。
- 比特币开发者指南：Block Chain：有效分支与累计工作量背景。
- 以太坊：Gasper：分叉选择与最终性组件区别。
- Hyperledger Fabric：The Ordering Service：特别参阅排序与节点交易验证的分离。
- 分布式共识、法定人数与容错：已有复制日志数学基础。
- 软件运行前的正确性证明：已有形式推理基础。
下一篇会跟随两个节点经历消息延迟与网络分区，记录各自知道什么、选择哪个链头，以及通信恢复后什么可能改变。