Chương 8 — Sổ cái phân tán: Trạng thái chung được hình thành như thế nào

第八章　分布式账本：共同状态如何形成

一项请求具有有效签名，还不足以成为各方可以共同采用的结果。同一主体可以签署相互冲突的请求，不同参与者也可能先后收到不同消息。如果每个人都仅依据自己最先看到的内容继续行动，共同资源就可能被重复使用，已经调整的权限也可能在另一处继续生效。

分布式账本需要处理的，是这些分别到达、可能冲突的请求如何进入一组相容的状态。它既要判断什么变化可以发生，也要确定相互依赖的变化按什么顺序发生，并使遵守规则的参与者能够在明确条件下据此协作。记录分布在多个地方，只是这一过程的组织形式；共同状态的形成，还需要有效性规则、确认机制和可核验的历史依据。

对于利益相关者资本治理，共同状态可以涉及资源是否可用、承诺是否已经履行、权限是否仍然有效，以及某项制度程序进行到哪一步。它为行动提供共同参照，但其含义取决于事先明确的制度。本章沿着交易、验证、顺序和故障处理展开，说明这种共同参照如何建立，以及它在什么条件下值得依赖。

一、交易、账本与状态转换

区块链中的“交易”，通常指按照协议表达、请求改变系统状态的操作。它可以涉及资产转移，也可以涉及权限调整、程序调用和其他被系统支持的变化。这个术语并不表示每次操作都对应现实中的买卖，也不能单凭它被称为交易，就推定有关法律关系已经成立。

“状态”则是在某一确定位置上，系统根据有效规则和已采用记录所维护的结果。账户余额、尚未使用的资产输出、有效权限和已经登记的承诺，都可以成为状态的一部分。状态回答的是：在当前认可的依据下，系统接下来允许什么、拒绝什么，以及能够向参与者呈现什么。

交易和状态由转换规则联系起来。对通常的交易处理，可以概括为：既定状态，加上满足条件的交易，按照确定规则，得到后续状态。这里的规则既包括权限检查，也包括资源约束和具体计算。若还使用区块高度、协议时间等环境信息，这些输入也需要按照协议取得共同可采用的值。

这种表达的关键在于可重复核验。参与者从相同的有效起点出发，依据相同规则处理相同顺序的输入，应当得到相同结果。若程序运行时随意读取本地时钟、各自访问的外部网页或未经共同确定的随机结果，即使交易相同，也可能算出不同状态。外部信息需要通过相应机制成为明确输入，才能进入共同计算。

账本保存的是已采用的交易及其相应历史关系；当前状态则是根据这些记录和规则形成的结果。二者密切联系，但不需要以完全相同的形式保存。系统可以使用便于查询的状态数据，也可以通过检查点或其他机制支持同步。采用这些方式时，需要说明它们如何与已确认的历史对应，以及核验者另外接受了哪些信任条件。

因此，账本中的一项历史记录不等于当前仍然有效的权限。一项授权已经被后续记录撤销，其原始记录仍然可以存在；一项资源已经被使用，过去的取得记录也不会因此消失。共同状态通过解释历史中的变更，区分曾经成立与现在可用。保留历史，服务于追溯；更新状态，服务于当前行动。

不同系统可以采用不同的状态表达。未花费交易输出模型，把可支配价值表达为尚未被使用的输出及其支出条件。账户模型则维护账户余额、序号和其他状态。以太坊的交易文档说明，交易包含发送方、接收方、数额及账户序号等内容，用于发起状态更新。Ethereum开发文档：交易〔1〕

这些表达方式改变了核验过程，但共同要求仍然清楚：识别正在使用什么，检查请求者是否满足条件，并在采用结果后更新剩余的行动空间。利益相关者资本治理可以借鉴这种表达纪律，把承诺、确认、权益和履行的变化分别记录，避免用一个持续增加的总分替代全部关系。

区块链还把若干交易组织为区块，并通过协议规定的关联方式形成历史。在一条采用顺序执行语义的链上，区块之间与区块内部的交易顺序，共同影响状态演进。并行计算可以提高执行效率，但参与者仍需取得与协议要求一致的结果；计算可以分工，结果不能由各节点自行解释。

共同状态也不要求所有参与者在每一瞬间都拥有完全相同的数据。消息传递需要时间，节点承担的角色也可能不同。某些节点保存并检查较完整的数据，另一些使用证明或服务接口取得结果。判断一种查询结果是否可靠，需要知道它依据哪条链、哪个区块或检查点，以及查询者实际完成了哪些验证。

这使“共同”具有一个重要含义：各方具备识别相容依据和核验结果的路径，而不是所有屏幕必须同时刷新。对于尚未达到共同确认条件的变化，系统可以显示观察结果，但应当保留它的暂时性。只有这样，参与者才不会把传播速度上的差异误认为不同的有效权利。

在资本治理中，状态设计还需要保持语义上的分工。贡献已经申报、事实已经核实、权益已经批准与义务已经履行，是不同状态。它们可能依次发生，也可能需要补充材料或进入争议处理。状态转换规则应当表达这些条件，而不能只因前一步完成，就自动赋予后一步的全部后果。

本书主张，共同账本应当保留从当前结果返回其依据的路径。参与者看到一项权益状态时，应当能够在适当权限内查明它来自哪次决定、采用哪个规则版本、依赖哪些确认，以及后来是否发生调整。这种可追溯关系，使共同状态成为可以解释的制度结果。

二、交易有效性与重复支出的拒绝

共同状态的建立，需要先确定什么交易可以被采用。有效性判断是相对于特定规则和状态作出的。签名通过验证，只满足其中一类要求；请求还可能因为引用的资源不存在、权限已经失效或使用条件尚未达到而被拒绝。

有效性检查通常涉及数据是否符合格式、授权是否满足要求、引用对象是否存在、资源是否足够，以及状态转换是否遵守相关约束。这些检查应当在实际执行所依据的状态上完成。一个请求在准备时看起来可以执行，到了处理时，其前置状态可能已经被其他交易改变。

这一区别有助于理解交易池的作用。节点可以暂存准备传播或等待纳入的请求，并根据自身策略进行筛选。进入某个节点的交易池，不等于整个网络已经接受，也不等于请求最终会被纳入账本。节点的转发和暂存策略，与决定区块能否被接受的共同规则，不宜混为一谈。

重复支出涉及同一资源被相互冲突的请求再次使用。分布式网络允许消息复制和多次传播，因此拒绝重复支出的关键，是在共同采用的状态中，使已经消耗的支出条件不能再被当作未消耗条件。原交易数据可以继续存在，原有使用机会则需要发生明确变化。

在未花费交易输出模型中，一笔普通支出引用已有的未花费输出；被采用后，这些输出退出当前可支出集合，并形成新的输出。同一输出不能在同一条有效历史中被成功消耗两次。比特币开发文档据此说明，支出必须使用尚未花费的输出，重复引用已经被消耗的输出不能构成有效付款。Bitcoin开发文档：区块链与交易输出〔2〕

在账户模型中，余额约束与序号等机制共同限制请求。账户序号使某个位置上的一次交易被采用后，另一条试图使用同一序号的冲突请求不能继续按原条件执行；余额和其他业务规则则约束可用资源。序号不会判断现实中的两次申报是否描述同一件事，也不能替代资产和权限的具体检查。

重复传播与重复支出应当分别处理。网络再次收到完全相同的交易，可以识别为已经见过或处理过的请求，不需要因此再次改变状态。另一个签名、格式均正确的请求，如果竞争使用同一份资源，则需要依据共同状态拒绝其中不能继续成立的部分。后者具有实质性的冲突，不能仅用消息去重解决。

还需要区分技术重复与业务重复。两条不同交易可以具有不同序号和标识，却指向同一项现实贡献或同一笔应付义务。只要协议没有表达这种业务关联，二者可能都通过技术验证。要防止重复确认或重复支付，组织还需要建立适当的事项标识、责任关联和审核规则。

这一点对利益相关者资本治理尤其重要。同一项投入可能被不同渠道收集，也可能由多个协作者分别描述。共同账本可以约束一个确定标识下的重复处理，但哪个标识代表同一事项、多人贡献如何分别认定，仍需要事实与制度工作。拒绝重复支出不能被扩张为系统已经自动识别全部重复价值申报。

有效性判断也不是“获得足够支持即可通过”。在既定协议下，遵守规则的验证者需要独立拒绝无效交易和区块。即使某个提议者拥有较强的排序能力，也不能仅凭这种能力，使缺少必要授权或违反资源约束的交易成为这些验证者认可的有效交易。参与者改用另一套规则，则属于规则和网络边界发生变化的问题。

多个交易分别通过初步检查，也不意味着它们可以无条件组合。执行前项后，后项需要面对更新后的状态。竞争同一资源的请求，其有效性可能随顺序改变；相互独立的请求则可能允许并行处理。系统需要保存这种依赖关系，使批量处理不会绕过逐步更新后的约束。

交易被有效纳入与预期业务执行成功，也需要区别。某些支持程序调用的系统，允许一笔符合纳入条件的交易在运行时产生失败结果：预期的合约状态修改被撤销，但费用、序号等仍按协议处理。因此，账本可以可靠记录一次失败的调用。核验者还应当检查执行结果，不能只查到交易存在就认定支付、登记或分配已经成功。Ethereum开发文档：Gas与执行费用〔3〕

对参与者而言，拒绝应当尽可能形成可以理解的反馈。授权不足、资源已用、请求到期、程序执行失败与暂时未被纳入，具有不同含义，也对应不同后续动作。准确呈现原因，有助于区分需要重新提交、等待同步、补充批准，还是进入事实争议处理。

有效性规则由此限定了共同状态可以怎样变化。它使已经表达的排他条件能够持续约束后续行动，却还没有决定多个有效候选历史之间如何选择。只有把有效性检查与共同采用的顺序结合起来，拒绝重复支出才能超出单个节点的局部观察，成为多方可以依赖的结果。

三、历史顺序、分叉选择与最终性

分布式网络不存在一个所有参与者天然共享的消息到达顺序。某个节点先收到甲请求，另一个节点可能先收到乙请求；两个提议者也可能几乎同时提出不同的后续记录。这些差异可以在没有任何恶意的情况下出现，因此协议需要预先规定如何处理竞争的历史。

顺序之所以重要，是因为交易之间可能相互依赖。先使用资源再撤销权限，与先撤销权限再提出使用请求，可能产生不同结果。共同账本需要使参与者采用相容的执行顺序，才能使同一套规则产生相容的状态。顺序是有效执行的条件，同时也可能影响不同主体的实际利益。

账本顺序不必等于现实事件发生的精确顺序。请求进入网络之前可能已经等待，传播路径可能不同，提议者也可能按协议允许的方式选择交易。区块时间和提交时间各有具体含义，不能直接推出谁在现实中最早作出贡献或首先取得某种资格。若制度赋予时间顺序以权益后果，需要明确采用哪种时间证据。

由此，排序机制需要接受制度审查。在技术上符合规则的顺序，仍可能使某些请求长期落后，或者让具有入口和排序能力的主体获得优势。共同账本可以让已经采用的顺序更容易检查，但排序是否公平、有效请求能否获得合理处理，仍需结合机制和实际运行评价。

分叉表示历史出现不同延续。短暂分叉可以发生于使用相同规则的参与者之间，其原因是信息尚未充分传播。另一些分叉则来自不同参与者采用了不兼容的有效性规则。前者通常由既定的分叉选择机制处理；后者可能形成持续的网络分离，不能仅靠继续交换消息就恢复共同判断。

分叉选择需要在协议认可的有效候选历史中进行。比特币采用累计工作量作为选择有效链的重要依据，不能简单理解为“区块个数最多的一条一定获胜”。如果候选历史包含违反本地有效规则的区块，更大的工作量也不会使遵守这些规则的完整验证节点接受它。Bitcoin开发文档：区块高度与分叉〔2〕

其他系统可以采用不同的权重和确认结构。以太坊的Gasper说明将分叉选择与最终性机制区分：前者帮助确定当前继续构建的历史，后者使符合相应条件的检查点取得更强的确认地位。这说明，选择当前链头与确定哪些历史已达到最终性，是相关但不同的任务。Ethereum开发文档：Gasper〔4〕

当节点依据分叉选择改变当前采用的历史时，可能发生链重组。原先在本地链上的某些交易不再位于新的采用历史中，相应状态需要重新计算。相关交易可能随后重新被纳入，也可能因冲突或条件变化不再有效。查询结果曾经出现过，不能据此保证它会始终保持相同的确认地位。

最终性所回答的，是某项已经形成的结果在什么条件下可以被稳定采用。它并不只有一种表达方式。在概率性确认机制中，随着后续历史继续建立，在给定攻击能力和网络条件的模型下，结果被替换的风险通常可以降低。确认次数是一项观察指标，其含义仍取决于具体协议和安全假设，不能解释为达到固定次数后风险绝对归零。

在采用明确最终性规则的机制中，确认需要满足规定的证明和程序。在相应故障上限、验证者行为及其他安全条件成立时，遵守规则的参与者不应确认相互冲突的最终结果。这里的确定性属于模型内的安全保证；若关键假设遭到破坏，系统仍可能发生严重故障，并需要协议规定或额外治理程序处理。

经济约束可以支持这些保证。使矛盾确认带来处罚或高额成本，有助于约束参与者行为，但不能把处罚机制当作逻辑上的绝对禁止。也不能认为发生处罚后，受到影响的参与者就必然得到足额补偿。确认安全、违规责任和损失分担，是需要分别说明的关系。

对使用者而言，有必要把交易经历的阶段清楚表达。

表中的最后阶段并不适用于所有协议；没有明确最终性证明的系统，需要准确说明采用的风险判断方式。界面不应把不同机制统一压缩为一个没有解释的“已完成”。组织也需要预先确定何种业务可以在哪一阶段继续，而不能在看到结果后再临时改变确认标准。

业务对结果稳定性的需求可能不同。可以撤回的内部准备动作，与会引起难以恢复的外部交付，不宜无条件依赖同一确认阶段。本书主张，把技术确认程度与后续承诺相联系：何时允许继续准备，何时允许对外履行，出现重组后怎样暂停、纠正和分担影响，都应当形成明确安排。

技术上的最终性也不意味着制度不能纠错。账本可以保留原有历史，再通过有权的新交易调整当前状态；现实中的争议处理，也可能形成新的履行义务。这与直接改写已确认历史属于不同路径。稳定保存历史和允许有依据地纠正后果，可以在同一制度中同时存在。

对于利益相关者资本治理，还需要识别最终性的范围。某条链确认了一项凭证变更，不代表另一套系统中的相关状态同时完成，也不保证现实资产已经交付。发生持久分叉时，两个网络还可能各自保留相似凭证；这不会仅凭记录复制就在现实中创造两份相同资源或两项当然有效的请求权。凭证所指权利如何延续，需要原有制度与相应处置程序说明。

共同状态由此取得可供后续行动使用的稳定程度。它的价值在于使参与者能够依据明确条件安排承诺，同时知道哪些变化仍可能发生、哪些边界没有被技术覆盖。最终性将确认转化为行动预期，其制度意义也体现在这种预期的准确表达上。

四、网络故障、账本分歧与一致性条件

分布式系统必须在参与者只能看到部分信息的条件下运行。网络延迟、消息丢失、设备停机和软件差异，都可能影响各方的判断。节点没有收到某条消息时，往往不能立即分辨对方是暂时缓慢、已经离线，还是有意不响应。确认机制需要在这种不确定性中形成可解释的处理方式。

需要先区分不同故障。节点停止工作，主要减少可参与处理的资源；节点提供错误结果或向不同对象发送相互矛盾的信息，则可能主动干扰确认。后一类通常纳入拜占庭故障的讨论。只考虑停机的复制机制，不能自动被视为能够承受参与者任意偏离协议的行为。

消息传递条件也需要明确。有的模型假定延迟存在已知上限，有的允许消息延迟不可预测；部分同步模型则在相应形式下假定网络最终进入具有延迟约束的阶段。不同假设支持不同保证。不能把正常运行时的速度表现，直接当作任意故障下仍能持续确认的证明。

分布式一致性中，安全性与活性是两个基本维度。在本章语境下，安全性主要要求遵守规则的参与者不确认相互冲突的最终结果；活性关注在规定条件下系统能否继续形成结果。等待更多信息可能有助于避免冲突，却会影响进展；提前继续则需要解释依据何在，以及承担何种暂时不确定性。

Fischer、Lynch与Paterson的研究说明，在完全异步的消息传递模型中，即使只允许一个进程停止工作，也不存在能够在所有允许执行中保证终止的确定性共识协议。这个结论针对明确的模型和保证，并不表示现实系统不能形成共识，而是要求准确说明保证成立所依赖的条件。Fischer、Lynch与Paterson，1985：单进程故障下分布式共识的不可能性〔5〕

实际协议可以引入不同的时间假设、随机化方法或其他机制，以取得相应范围内的进展保证。超时可以帮助触发更换提议者或进入下一轮，但超时本身不能证明未响应者必然恶意。将网络慢与违规行为混同，可能使故障处理变成不当处罚，也可能损害恢复后的继续协作。

网络分区是理解这种边界的重要情形。不同部分暂时无法通信时，一些协议可能允许各自延续尚未最终确认的候选历史，恢复通信后再按规则处理；另一些机制在无法取得必要确认时，会暂停新增最终结果。具体后果取决于协议、分区持续时间和参与力量分布，不能统一表述为“断网也能保持所有功能”。

如果不同分区都无条件把针对同一资源的冲突行动作为不可撤销结果对外履行，那么恢复连接时，现实后果未必还能合并。共同资源的排他性要求，决定了网络分区期间不能仅凭各自局部可用就推定全局可以完成。系统应当区分暂存请求、提供历史查询和确认新增状态等不同服务能力。

许多确认机制通过具有适当交集的确认集合支持安全性。其基本思路是，使两个可能决定冲突结果的集合，必须共享足够的守规参与力量；这些参与者按照协议的锁定和轮次规则，不会为相互冲突的最终结果同时提供所需支持。单有一个多数比例仍然不够，参与身份、权重、消息认证与跨轮次规则都必须配合。

因而，所谓容错门槛必须结合具体协议解释。按节点数量、计算能力或质押权重衡量的门槛，分别涉及不同控制条件。许多节点由同一主体支配，或共同依赖一个可能失效的服务入口，会形成相关风险。实际独立性和故障是否可能同时发生，需要与名义上的分散数量一并检查。

账本分歧还可能源于软件和规则，而非通信。相同历史在不同执行实现中产生不同结果，可能表明实现存在错误；参与者有意采用不兼容规则，则可能形成制度与网络分离。前者需要定位、修复和核验，后者还需要处理版本采用及合作范围。不能把所有分歧都当作等待同步即可消失的现象。

恢复工作需要一个可以说明的起点。重新接入的节点应当检查必要的历史、状态和确认依据，使用检查点或快照时，还应当了解其来源与验证方式。某些协议对长期离线后的重新加入具有额外要求。下载速度快，不能代替对所采用状态的核验。

数据可得性同样影响共同验证。一个摘要可以帮助核对数据，但仅有摘要未必足以重建状态或判断执行是否正确。系统需要确保相应验证方式所必需的数据、证明和历史依据能够取得，并说明保存责任。若全部查询依赖一个可能停止服务的入口，账本的分布式结构就未必转化为参与者实际可用的核验能力。

组织还需要把故障状态翻译为行动规则。查询停留在旧位置时，应当说明其依据；不能继续确认时，应当明确哪些履行需要等待；恢复后，应当核对重复提交和未完成承诺。技术上的停顿可以被准确表达为暂缓，不能自动变成拒绝责任或消除既有义务的理由。

本书提出“可说明的共同状态”这一设计要求：重要结果应当同时提供状态内容、依据位置、适用规则和确认程度，使参与者能够判断它现在可以支持什么行动。它不要求每个人掌握全部协议细节，而是要求系统把影响承诺的关键条件转化为可理解、可检查的信息。

这一要求也适用于未来的多账本协作。不同网络即使分别形成一致状态，相互连接仍需处理证据传递、确认时间和故障责任。可以研究让每一项跨系统承诺附带清楚的状态依据及接受条件，但这些机制能否保持责任连续、避免重复履行，需要具体检验。局部的一致性不会自动扩大为跨系统的共同确定性。

分布式账本的制度贡献，正在于让多方在明确条件下，持续维护一组可以共同采用的行动依据。它通过交易表达变化，通过有效性规则限制变化，通过排序和最终性稳定结果，并通过故障处理说明保障的边界。下一章将进一步讨论承担这些工作的确认制度：谁可以参与、谁提出记录、谁负责验证，以及其权力、成本与责任如何安排。

定稿补强：最终性的四层表达与网络分区

为了避免把不同含义压缩成一个“已完成”，本书在定稿中采用四层表达。概率稳定性表示结果在给定攻击与网络假设下，随确认积累而降低被重组的可能；经济最终性表示逆转需要承担显著成本或处罚；协议确定性表示在明确故障上限和协议条件内，不应产生相互冲突的最终结果；业务采用则是组织基于技术状态、外部条件和损失承受能力决定是否继续履行。法律上的终局、不可撤销或对世效力不由这四层中的任何一层自动产生。

网络分区时还要把安全性和活性分开。系统可能为了避免冲突而暂时停止确认，也可能继续处理而增加分歧风险。界面和运行规则应说明当前状态是等待、降级、暂停还是可继续，并预先确定恢复后的重放、对账和补偿程序。继续出块不等于全部安全条件仍然成立，暂时停顿也不必然表示制度失败。

本章注释

1. [SRC-041] Ethereum.org：Ethereum开发文档：交易。原文或官方页面

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

2. [SRC-011] Bitcoin Project：Bitcoin开发文档：工作量证明与分叉选择。原文或官方页面

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

3. [SRC-036] Ethereum.org：Ethereum开发文档：Gas与执行费用。原文或官方页面

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

4. [SRC-032] Ethereum.org：Ethereum开发文档：Gasper。原文或官方页面

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

5. [SRC-048] Michael J. Fischer、Nancy A. Lynch、Michael S. Paterson：Impossibility of Distributed Consensus with One Faulty Process。原文或官方页面

   • 本章引证：Fischer、Lynch与Paterson，1985：单进程故障下分布式共识的不可能性。
   • 支持范围：用于支持所引理论、模型、算法或经验研究的原始论证，本书引用主题包括：Fischer、Lynch与Paterson，1985：单进程故障下分布式共识的不可能性。
   • 使用边界：原始研究支持其设定范围内的结论，不直接证明本书提出的治理制度已获得普遍实证验证。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。