Chương 9 — Cơ chế đồng thuận: Quy tắc xác nhận sổ cái chung

第九章　共识机制：共同账本的确认制度

共同账本能够持续存在，需要有人提出新的记录，有人检查这些记录是否符合规则，也需要一套程序处理竞争的结果。第八章已经说明，共同状态依赖交易有效性、历史顺序和最终性。本章进一步追问：谁有资格承担这些工作，确认权怎样分配，参与者为什么持续履行职责，以及不履行或滥用权限时怎样受到约束。

这些问题构成共识机制的制度内容。共识机制规定了共同账本的参与关系、确认程序和相应保障，使一部分原本需要持续协调的事项进入可以重复执行的规则。以太坊开发文档也将共识机制描述为支持分布式节点对账本状态形成一致的协议、激励和相关安排的整体，而不只是某一种资源证明方式。Ethereum开发文档：共识机制〔1〕

在这个意义上，共识机制可以理解为共同账本的确认制度。它承载的是各方已经采用的确认规则，并以技术约束执行这些规则。它并不自动完成共同目标的形成，也不直接决定企业所有利益应当怎样分配。理解它的制度价值，需要同时看见确认能力的形成过程与确认权力的适用边界。

一、参与资格、提议权限与验证职责

参与区块链网络，可以指向不同活动。读取记录、提交交易、独立验证、提出区块、参与最终确认和修改协议，具有不同作用。一个主体获得某项能力，不意味着同时获得其他全部权限。共识机制首先需要把这些角色分别表达，使参与者知道自己的行为对共同账本产生什么影响。

读取与验证尤其需要区分。读取可以依赖某个查询入口，独立验证则需要取得必要数据并执行相应检查。一个节点可以核验它所采用的记录，而不承担区块提议或确认投票；一个普通使用者也可以借助证明检查特定结果，而不进入维护者集合。因此，网络中的节点数量不能直接等同于拥有确认权的主体数量。

交易提交权也不等于区块提议权。提交者表达希望发生的状态变化，提议者则依据规则组织候选记录。提议者能够影响什么请求进入候选、采用怎样的顺序以及何时提出，但候选结果仍需要接受其他参与者或验证机制的检查。提议能力如果缺少对应约束，可能成为延迟、筛选或排斥请求的实际权力。

参与资格需要回答谁可以进入相应角色，以及进入以后能影响多少确认力量。开放网络通常需要防止一个主体仅靠批量创建身份就无限扩大影响。计算投入、质押资源或其他机制可以为这种影响设置条件。许可型网络则可以通过身份识别与准入程序确定参与者，但仍需解释准入由谁管理、怎样避免任意排除，以及退出后如何处理既有责任。

这些资格依据解决的是特定的系统问题。某种资源能够支持抗虚假身份或承担安全责任，不表示它天然代表共同事业中的全部贡献。较多计算能力或质押权重，可以依协议形成较多确认影响，却不能据此推定劳动者、客户、协作组织和其他利益相关者的合理诉求已经得到充分表达。

验证职责则需要落到可检查的对象。参与者应当知道要核验的是交易授权、资源约束、执行结果、区块结构，还是其他确认者的证据。职责不清，容易使所有人都以为某个关键条件已经由他人检查。职责明确，也有助于识别某项错误究竟发生于提出、执行、排序还是确认环节。

不同架构可以作出不同分工。Hyperledger Fabric的文档将交易提议与背书、排序、最终验证与提交区分为不同阶段；排序节点与执行和验证交易的节点并不承担完全相同的工作。这个技术结构表明，共同账本的维护职责可以分开安排，不能预设每个参与确认的节点都会完成全部业务检查。Hyperledger Fabric文档：排序服务与交易流程〔2〕

本书从制度分析出发，将这些权限和职责概括如下。

同一主体可以承担多个角色，但应当保留角色之间的区别。运营一个验证服务，与代表某个组织接受新的治理安排，可能需要不同授权；受托代为操作质押资源，也不意味着受托者可以自行决定这些资源的其他用途。技术委托关系应当与现实中的责任关系对应。

还需要检查名义参与与实际控制。多个验证身份可能由同一个运营团队管理，也可能依赖相同的密钥服务、软件或基础设施。反过来，一个组织的控制能力也可以通过内部共同批准受到限制。评价分散程度，应当追踪实际决策和故障关联，不能只计算地址、设备或机构名称。

资格与职责还具有时间边界。成员加入、退出、被替换或改变权重时，系统需要确定何时开始适用新的参与集合。否则，旧集合和新集合可能分别声称自己有权确认同一个位置。成员变更因而既是管理事项，也是共识安全的一部分，需要进入可核验的过渡程序。

对于利益相关者资本治理，确认制度应当给参与者提供适当的核验和异议渠道。没有运行节点的能力，不应在制度设计上被直接解释为没有提出问题的资格；受到一项记录影响的主体，也可能需要通过代表、审计或其他安排检查其依据。确认权可以专业分工，相关权利仍需获得可行的实现路径。

共识机制由此形成一项有边界的权力委托：部分主体承担持续维护共同记录的职责，并在规则内取得相应操作权限。它的质量取决于资格是否清楚、职责能否核验，以及这些技术权限是否始终受其用途和责任约束。

二、确认程序、冲突处理与容错假设

确定参与者以后，还需要规定他们怎样共同完成确认。确认程序应当说明候选记录如何提出，验证依据怎样取得，支持以何种方式表达，达到什么条件才允许采用结果，以及不能取得结果时如何继续。只有把这些阶段连接起来，参与者才能对同一条消息的程序地位作出相容理解。

程序首先需要一个共同可识别的对象。确认者针对哪个区块、哪个高度、哪一轮次或哪个检查点表达意见，应当能够核对。如果支持消息缺少明确范围，过去的表态就可能被重复计入新的确认，或被误用在另一个网络和规则版本中。第七章讨论的签名内容与使用环境，在这里成为确认程序的基础。

对候选结果的检查，也应当先于具有相应后果的支持。收到提议，只能证明提议已经到达；完成验证，才可能形成符合职责要求的确认行为。若某种角色只检查其中一部分条件，程序应当说明其余条件由谁负责，以及最终采用如何依赖这些检查。

不同机制可以采用不同形式积累支持。有的通过对候选历史持续投入工作形成选择依据，有的通过带权确认消息形成证明，也有的把当前分叉选择与最终性确认分别安排。不能把所有共识机制简化为同一种“多数投票”。每种机制中的支持单位、有效范围和确认后果，都需要单独理解。

确认门槛的意义，也取决于它为何足以约束冲突。在一类经典拜占庭容错模型中，若总参与权重表示为3f＋1，最多f的权重可能任意偏离协议，两个各含至少2f＋1权重的集合就必然具有超过f的交集。这个交集包含守规力量，但它还需要与消息认证、轮次和锁定规则结合，才能支持不产生冲突决定的保证。Tendermint的形式化说明体现了这种联系。Buchman、Kwon与Milosevic：The latest gossip on BFT consensus〔3〕

这一门槛表达针对具体模型，不能被推广为所有网络的统一安全公式。按人数计量与按权重计量不同，固定参与集合与动态变化的集合不同，能够核验参与身份与任意创建身份也不同。若不说明分母及其来源，一个“达到三分之二”的数字本身无法说明系统获得了什么保障。

轮次与锁定规则处理的是支持如何跨时间延续。参与者在某个阶段形成承诺以后，不能仅因为下一轮出现新的提议，就随意对冲突结果再次提供足以导致确认的支持。与此同时，系统需要为没有形成决定的情况保留继续推进的路径。何时可以改变候选、需要携带哪些证据，是安全与进展能够兼容的关键。

提议者更换也应当继承必要证据。原提议者失联时，新提议者不能假定此前一切都没有发生。已经形成的确认、锁定或检查点，需要按照协议进入后续判断。程序由此使参与者的暂时离开不至于自动清空先前约束。

冲突处理还需要识别冲突所在的层次。两个尚未确认的候选结果相互竞争，可以进入既定的选择程序；一个候选包含无效交易，应当按有效性规则处理；两个结果都声称已经取得最终确认，则需要核验证据并检查安全条件是否遭到破坏。不能用处理普通候选竞争的办法，掩盖最终性冲突所揭示的问题。

容错假设限定了这些程序能够承受什么。哪些参与者可能离线，哪些可能发送矛盾消息，消息传递需要满足什么条件，以及密码学和数据可得性是否可靠，都会影响结论。第八章已经区分安全性与活性；确认制度还需要把这种区分落实为运行安排，使停顿、降级和恢复具有明确含义。

当可用的确认力量不足时，暂停新增最终结果可能是维持安全要求的一部分。暂停并不自动表示协议已经产生错误结果，也不能被表述为系统仍在正常完成全部业务。组织需要说明可以继续提供哪些查询、暂存哪些请求，以及哪些外部行动必须等待。

相反，如果关键假设已经不成立，继续沿用日常确认标签可能制造错误预期。相关参与者需要保全证据、识别受影响范围，并依据预定权限决定恢复或过渡措施。具有停止接口的人，不因此获得任意改写权；有权组织恢复的人，也需要说明恢复所采用的状态依据。

程序还应当规定规则变化如何进入系统。版本升级、参与权重调整和验证者集合更换，可能改变后续确认的条件。变更需要与当前有效规则衔接，使使用者能够判断哪个版本从何时适用。若不同群体持续采用不兼容安排，可能形成新的网络边界，相应社会关系需要另行处理。

确认制度因此同时包含正常路径和异常路径。正常路径使有效请求能够形成共同结果，异常路径使参与者知道在信息不足或假设失效时怎样限制后续行动。可持续的共同账本，需要两条路径都能被理解、执行和审查。

三、成本承担、奖励安排与违规约束

确认制度需要持续投入。设备、网络、存储、软件维护和人员工作构成直接成本；被锁定的资源、等待期间失去的其他使用机会以及必要的风险承担，也影响参与条件。共识机制即使能够自动运行，其所依赖的服务仍然需要有人长期提供。

成本首先需要找到承担者。在不同安排中，交易使用者可以通过费用承担一部分，网络可以依规则发行奖励，组织也可以从预算中支付维护报酬。没有单独发行代币，并不妨碍建立维护激励；发行了代币，也不表示成本已经获得稳定覆盖。需要检查支付资源从何而来，以及它能否支持实际需要的投入。

奖励应当说明奖励的行为。提出有效区块、及时提供确认、保持必要服务和提交可验证的违规证据，可以分别对应不同工作。若一种报酬只与名义在线时间或持有某项资格联系，就需要进一步判断它能否支持实际职责。指标容易观察，不代表它足以反映需要维护的能力。

协议只能直接评价它能够识别的事项。签名是否矛盾、确认是否在规定窗口内到达，通常比参与者是否认真维护设备、是否具有独立判断更容易进入自动检查。因此，激励设计既要利用可验证信号，也要识别信号覆盖不到的部分。组织安排、审计和专业维护可以补充这些缺口，但不应被包装成协议已经自动保证的结果。

奖励来源也影响利益分布。交易费由使用者支付，其水平可能影响参与门槛；新增单位的发行改变供给及持有结构，但其经济后果还取决于其他条件；组织预算则需要在维护账本与其他用途之间分配。共同账本的运行费用，应当成为利益相关者可以理解的支出，而非隐藏在技术标签之后。

在资本治理中，维护奖励应当与共同创造的其他回报分开表达。验证者承担确认工作，可以依据协议取得相应奖励；劳动投入、知识贡献、客户协作和组织建设，可能需要另外的评价与权益制度。确认服务的重要性，不能推出全部价值都由维护者创造，也不能使协议奖励自动成为企业利润分配权。

同样，奖励记录、可支配资产和实际经济收益具有不同含义。系统记入一定数量的奖励，只说明按相应规则形成了记账结果；参与者为履职付出的成本、资源限制及后续使用条件仍然存在。不能仅依据名义奖励数额，判断维护安排可持续或所有参与者已经获得净收益。

激励还可能改变确认权的分布。规模较大的运营者如果具有成本优势，参与力量可能逐渐集中；较高的进入成本，也可能使较小主体转而依赖受托服务。这些结果需要通过运行数据判断。本书主张，评价奖励制度时同时观察服务质量、进入退出和实际控制分布，避免只检查支付是否准确。

违规约束首先需要明确什么构成违反协议。不同请求形成竞争，未必表示谁在作恶；暂时离线，也不同于对相互矛盾的结果作出被禁止的签署。以太坊的奖励与处罚文档区分了未完成特定职责的惩罚，以及针对双重提议、双重投票或特定矛盾投票等行为的罚没。两类处理具有不同的触发条件。Ethereum开发文档：权益证明奖励与处罚〔4〕

自动处罚依赖可验证的触发证据，其判断对象可能是已经发生的协议行为，而非行为者的主观动机。密钥被盗用、操作失误和有意攻击，可能形成相同类型的违规消息。协议如何处理这些消息，与相关当事人之间如何分担责任，需要分别说明。不能把一次罚没直接解释为完整的事实调查或道德判断。

对于证据难以自动核验的行为，也不应轻率设计确定处罚。某个请求没有被纳入，可能涉及传播、费用、容量或主动排斥；如果缺少足够的可观察条件，系统未必能够区分原因。要约束这种行为，需要先明确接收凭据、处理义务和判断程序，再决定哪些部分适合自动执行。

约束还需要具有执行基础。罚没要求存在可以依规则处置的资源，取消资格要求存在有效的资格控制程序，其他责任追索则依赖相应组织或外部制度。协议没有掌握的资源，不能仅通过一条处罚声明变成可以执行的保障。

有成本的攻击也不等于不会发生攻击。参与者可能追求协议外部的收益，或者愿意承担账内损失来破坏合作。关于“守规更有利”的判断，需要说明它考虑了哪些收益、成本和行为动机。经济激励可以支持对守规参与的预期，却不能替代协议对故障力量的明确容忍条件。

处罚与受害者补偿同样不同。销毁被罚没资源、将其转给特定接收者或停止后续奖励，产生不同分配后果。即使处罚按规则发生，损失也可能没有全部恢复。因此，需要分别说明违规者承担什么，以及受到影响的参与者可以依据什么寻求处理。

退出安排也是激励制度的一部分。尚待核验的行为、可能发生的处罚和未完成的维护责任，可能要求资源在一定期间内继续受到约束；过重或不明确的退出限制，又会影响参与者加入的意愿。退出条件应当与需要覆盖的责任相联系，使责任持续与合理退出之间具有可解释的边界。

协议已经确定并能自动执行的处罚，不能由应用界面随意承诺暂停或撤销。如果某项制度希望提供复核、补偿或例外处理，应当在它实际拥有的权限和资源内设计相应路径，并说明这与底层协议处理的关系。一个组织可以审查自身责任，但未必有能力改变外部网络已经执行的罚没。

成本、奖励与约束由此构成确认制度的持续运行条件。评价它们，需要同时回答服务是否得到支持、参与是否保持可行、权力是否过度集中以及责任是否能够落实。准确执行奖励公式只是其中一步，长期维护共同账本还依赖这些条件之间的协调。

四、协议共识为何不能替代事实判断与制度正当性

共识机制能够使参与者对共同账本形成可采用的结果，但其确认对象需要保持明确。验证者检查的是某项记录和状态变更是否符合规定条件；现实事实是否成立，规则为何有权约束相关主体，则可能需要不同的证据和判断程序。

这种边界首先来自信息来源。系统可以检查一项现实事项已经由具备登记权限的主体签署确认，却不能仅凭该签署推定事项确实发生。多个验证者重复检查同一个输入，只增加了对输入符合协议条件的共同核验，并没有自动增加对现实事件的独立观察。

第六章已经区分记录一致、事实真实与制度正当，第十二章将进一步建立现实信息输入的责任链。本章据此只确认一项边界：协议可以在错误输入之上保持一致，验证者数量或确认权重不能替代链下事实核验。

当一种安排同时让某些参与者承担外部事实审查时，也应当区分其两种职责。其作为事实审核者，需要取得材料、调查来源和回应异议；其作为账本确认者，则需要依协议处理已经表达的结果。两项职责可以由同一主体承担，却不会因此具有相同的判断标准。

在利益相关者资本治理中，贡献评价进一步包含因果和价值判断。某项行动发生过，未必能够精确说明它为共同成果增加了多少价值；某项结果得到认可，也未必意味着可以把它全部归于单一主体。贡献口径、共同作用和已有回报，需要在评价制度中说明。共识机制可以记录采用了哪一种评价，却不能用确认权重代替这些论证。

制度正当性则涉及规则来源与约束理由。谁有权确定贡献标准，谁应当参与分配原则的讨论，哪些基本利益需要受到保护，以及受影响者如何提出异议，都超出账本状态确认本身。一个规则可以被精确执行，同时仍然存在权限不足、参与不充分或负担分配失衡的问题。

共识机制中的权重尤其不能被自动扩大解释。用于抗虚假身份、提供安全资源或分担维护成本的权重，解决的是特定技术问题；企业治理中的表达资格，还可能涉及投入、依赖、风险和受到影响的程度。将前一种权重直接用作后一种权利的全部依据，需要额外论证，不能仅以系统已经支持为理由。

这种区分也关系到规则修改。协议确认了一笔修改参数的交易，可以说明它满足系统当前设定的修改条件；这组条件是否得到适当授权，修改是否越过组织权限，仍然需要相应依据。技术上能够修改，与制度上有权修改之间的距离，不会因为修改获得较多验证支持而自然消失。

不同争议因此需要进入不同的处理路径。

这种分工并不要求不同层次彼此隔绝。事实复核可以导致原有认定调整，新的有效决定可以触发后续状态变更，技术异常也可以成为启动治理审查的原因。关键在于每一次转换都有可以追踪的依据，不能把一个层次的结论直接改名为另一个层次已经完成。

面对错误输入，应当追查输入与审核责任，不能只因验证者采用了符合协议条件的记录，就推定它们全部失职。面对违反协议的确认，也不能仅以基础业务已经获得认可为理由，忽略技术程序的缺陷。责任归属需要对应具体职责和行为，否则共同确认人数越多，反而越难找到真正需要改进的环节。

制度需要为这些联系保留清楚的状态表达。记录已经被确认，但事实仍有争议；事实已获核实，但权益尚未批准；权益已经成立，但现实履行尚未完成，都可以是准确且有用的状态。把它们全部压缩为“共识已达成”，会使参与者无法知道自己究竟可以主张什么。

本书据此提出，应用共识机制时，应当同时建立确认依据、事实责任和制度依据之间的对应关系。一项重要结果需要能够说明：协议确认了什么，哪些外部材料支持其内容，以及哪个有权程序决定其后果。需要保密的材料可以按权限披露，但责任主体、核验路径和争议入口应当明确。

这种对应关系也有助于理解本书关于制度技术的基本判断。共同认可可以通过有权程序形成明确规则，规则中的一部分再被表达为技术可检查的条件，共识机制据此维护共同状态。这是一条需要逐步完成的制度化路径。代码执行的是已经表达的条件，社会共识中尚未澄清的内容不会因此自动获得答案。

面向未来，自动代理可以承担更大量的提议、核验与运行维护，但多个代理给出相同结果，仍需检查它们是否依赖相同信息来源、同一模型或同一控制者。扩大自动参与数量，不必然增加独立证据或代表范围。组织需要继续识别实际控制、委托边界和错误责任。

本书提出一个有待检验的方向：随着确认工作的自动化程度提高，制度设计可以更加重视“技术确认权的受托性质”。承担者应当能够证明自己按明确职责处理了记录，其报酬与责任对应，权限也能够依有效程序交接。这个方向是否改善核验能力、减少权力集中并支持长期合作，需要在不同组织条件下检验。

共识机制的制度价值，最终体现为共同账本的确认过程更可预期、更可核验，并使维护者的权限与责任得到明确表达。它为共同创造提供了一层持续运行的技术基础，同时依赖事实核验、组织治理和有效授权来确定自己的对象与边界。下一章将比较工作量证明、权益证明和许可型网络中的具体安排，进一步观察不同选择如何改变参与门槛、权力分布、最终性与退出条件。

定稿补强：把共识拆成可比较的制度维度

“共识机制”不是一个不可再分的功能。网络首先需要回答参与者如何被识别或限制虚假身份，谁可以提出候选记录，谁负责验证有效性，冲突记录如何排序，执行结果如何取得一致，何时达到相应最终性，以及成本、奖励、处罚和规则变更由谁承担。工作量证明、权益证明和许可型拜占庭容错分别覆盖其中若干维度，并可能与其他机制组合。

因此，机制选择不应只比较吞吐量或一个笼统的“去中心化程度”。同一网络可以使用权益抵抗女巫、以委员会进行提议与证明、用执行层处理状态转换，再由链外治理决定软件升级。每一层都可能产生集中、串谋或责任空缺。比较时要逐层识别参与门槛、故障假设、权力集中点、证据和退出条件。

这也要求把安全性与活性分别说明：安全性关注系统是否避免确认相互冲突的结果，活性关注有效请求能否在条件允许时继续得到处理。制度可以在故障时选择保护安全而牺牲即时活性，也可以设置受限降级，但不能用“系统仍在运行”替代对冲突风险的判断。

本章注释

1. [SRC-030] Ethereum.org：Ethereum开发文档：共识机制。原文或官方页面

   • 本章引证：Ethereum开发文档：共识机制。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Ethereum开发文档：共识机制。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

2. [SRC-049] Hyperledger Fabric：Hyperledger Fabric文档：排序服务及容错类型。原文或官方页面

   • 本章引证：Hyperledger Fabric文档：排序服务与交易流程。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Hyperledger Fabric文档：排序服务与交易流程、Hyperledger Fabric文档：排序服务及容错类型。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。

3. [SRC-002] Ethan Buchman、Jae Kwon、Zarko Milosevic：The latest gossip on BFT consensus。原文或官方页面

   • 本章引证：Buchman、Kwon与Milosevic：The latest gossip on BFT consensus。
   • 支持范围：用于支持所引理论、模型、算法或经验研究的原始论证，本书引用主题包括：Buchman、Kwon与Milosevic：The latest gossip on BFT consensus。
   • 使用边界：原始研究支持其设定范围内的结论，不直接证明本书提出的治理制度已获得普遍实证验证。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

4. [SRC-033] Ethereum.org：Ethereum开发文档：权益证明奖励与处罚。原文或官方页面

   • 本章引证：Ethereum开发文档：权益证明奖励与处罚。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Ethereum开发文档：权益证明奖励与处罚。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。