VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

最终性、确认数与链重组:接收者的交易状态时间线

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

English version · 区块链学习导航 · 上一篇

区块链学习 · 文章 BC028

三名学生在教室桌旁一起阅读书本,身边放有课本和文具。
学习场景配图;不代表照片中的学生正在学习区块链。

交易标识不是包含证明。交易被某个区块包含,也不保证该区块一直留在所选历史中。不断增长的确认数,与协议定义的最终性,还是不同类型的证据。接收应用需要保留这些区别,而不是把每次成功回复都显示成“已完成”。

本篇跟踪一次虚构档案更新,经历提交、包含、增加深度、链重组、重新包含,以及单独提供的最终性观察。任务是解释接收者的状态记录,并判断应用可以诚实地显示什么。它不是支付、投资或法律结算建议。

选择适合你的阅读路线

本篇目录

先阅读状态词汇及完整时间线。构建或审查应用的读者,可接着关注过时回执、能够撤回的显示,以及状态标签背后的证据。最后练习检验:根据高度算出的数字,与某段具体历史支持的主张,有什么区别?

本例不教授 Merkle 证明算法,也不规定共识协议。它假定题目所给区块与祖先观察已经检查,因此可以集中研究:所选历史改变时,接收者的状态如何变化。

返回目录 · 下一节

1. 先明确接收者真正需要回答的问题

虚构档案馆收到请求 T,希望更新一条目录记录。应用想知道能否把更新显示为待处理、暂时已包含,或已被网络最终性条件覆盖。它也另外需要知道:执行是否产生了预期目录变化?

这些不是同一个问题。请求可以只在本地创建,尚未到达节点;节点可以确认收到,却没有区块包含它;区块可以包含它,但应用操作失败;接收者也可能观察到一次包含,后来却不再属于所选链。

选择状态标签之前,先把主张写成完整句子。“某服务返回 T 的标识”,不同于“T 位于当前所选分支的 A100 中”;后者又不同于“题设最终性证据覆盖该区块”。

有用状态记录包括网络、交易标识、已观察到的包含区块哈希(若有)、所选链头引用、观察时间、证据来源、执行结果(若已知),以及相关最终性引用(若已提供)。缺失信息应保持缺失,不应悄悄推断出来。

返回目录 · 下一节

2. 定义确认数的计数约定

本课堂练习约定:如果 T 位于所选链高度 i 的区块中,而所选链头高度为 h,确认数就是 h 减 i 加一。因此,当 T 恰好包含在链头中时,算一次确认,不是零次。

该约定计算包含区块及其所选链后继,不是计算独立审计者、签名或经过了多少分钟。如果每块工作量不同,它也不能直接衡量累计工作量。

如果 T 不在所选历史中,这个公式就不适用。工作表写“未包含”,而不是继续拿旧分支高度做减法。某些接口可能用零或其他状态表示特定情况,但含义必须依据接口文档。

比特币开发者文档的确认数说明介绍了包含及后继区块形成的确认观察。本篇只采用这个狭窄概念。该页面还含历史操作指导,本课不沿用其中过时的时间例子,也不采用统一接受次数。

返回目录 · 下一节

3. 档案更新的六阶段时间线

在 s0,T 已提交给一个服务,观察到的所选链头高度为 99。工作表没有提供包含区块。接收者可以记录提交回执,却不能宣称已经包含。

在 s1,T 被包含于 A100,所选链头就是 A100。确认数为 100−100+1=1。记录需要识别 A100,而不只是数字 100。

在 s2,所选链沿 A100 的有效后继推进到 A102。T 仍在 A100 中,所以确认数变成 102−100+1=3。题设分支深度增加了,但尚未提供 A100 的最终性证据。

在 s3,所选历史切换到另一条分支,链头为 B103。题目明确说明 A100 不属于该历史,而且 T 在其中缺席。旧的“三次确认”不再是 T 当前所选链包含状态。

在 s4,题目明确给定 T 有资格再次被包含,并且已进入 B104。所选链头为 B106,因此新的确认数为 106−104+1=3。重新包含是本案例提供的事实,不代表所有被移出所选历史的交易都会自动回来。

在 s5,所选链头为 B107;另有单独提供的有效最终性证据,指定检查点 B105,而 B105 是 B104 的后继。T 在本计数约定下有四次确认,同时被该最终性检查点覆盖。这是两项分别记录的事实,不是同一计算的两个名字。

这是具有单独给定最终性机制的合成网络时间线,并不宣称比特币存在这种检查点最终性过程。我们没有规定虚构机制如何工作,只规定练习在 s5 提供了什么证据。

返回目录 · 下一节

4. 重组改变了什么

在 s3,接收者应更新当前包含视图。原包含区块 A100 仍属于观察记录的历史,但已经不在新选分支中。应用不应把 A100 的旧确认数显示成描述 B103 的当前状态。

这种变化不证明 T 的字节从所有地方被删除,也不证明请求从未存在,更不会自动识别恶意行为。它只是在题设条件下,确立观察者当前跟随的历史改变了。

它也不构成最终确定历史被推翻的证据,因为工作表从未说 A100 已最终确定。把每次普通分支变化都称为“最终性失败”,会添加证据不支持的主张。

在档案界面中,由 A100 派生的临时目录更新,可能需要撤回或标记为不再包含。具体应用反应属于其预先定义的政策。技术重点是:当前派生数据不应悄悄混合来自不兼容所选历史的记录。

返回目录 · 下一节

5. 重新包含带来新的包含区块观察

在 s4,T 出现在 B104。交易标识可以相同,包含区块却不同。因此,只存 T 的标识和一个永久“已确认”标记,会丢失有用背景。

新确认数是三,因为 B104、B105、B106 构成题设所选链段。它不是六,不能把被放弃 A 分支上的旧三次相加。确认深度依赖特定当前包含位置及所选历史,不是在不兼容分支之间积累的积分。

重新包含也不会自动保留此前执行结果。周围状态或顺序可能不同。除非某案例明确给出执行结果,否则工作表没有这项信息,应用不能仅因再次看见 T,就推断目录变更成功。

即使不用金融例子,这个区别也很实用。目录字段更新可能依赖较早版本号或授权状态。如果先前历史改变,请求处理时的效果也可能改变。因此,结果需要自己的证据。

返回目录 · 下一节

6. 基于深度的信心与明确最终性不同

在工作量证明语境下,更多有效工作延伸某段历史,可以在相关假设下使替换它更困难。确认数是方便的深度观察,却不是统一概率,也不是绝对保证。解释它需要协议、工作量、攻击者及网络背景。

比特币区块链指南说明了有效竞争分支与基于工作量的选择。接收者不应把熟悉的区块次数变成无条件安全承诺,也不应把一个网络的规则直接移植到另一个网络。

具有明确最终性的协议,则依据自己的机制与假设提供另一种状态。以太坊 Gasper 概述区分分叉选择与检查点最终性机制。这是具体系统中该区别的例子,不是本篇虚构时间线的规范。

两类证据都不能消除其他一切风险。观察来源错误、软件缺陷、模型假设被突破或应用解释错误,仍可能重要。有用问题是证据支持什么主张,而不是界面是否用了令人安心的“最终”二字。

返回目录 · 下一节

7. 不要把回执等同于最新链视图

保存的回执可以指出:观察该回执时,交易被包含在哪里。它不会自动证明同一区块后来仍被选择。应用需要把回执的区块引用,与当前链观察关联起来。

以太坊 JSON-RPC 文档区分 latest、safe、finalized 等区块选择标签,也说明交易回执中的区块引用与执行信息。这些字段支持不同问题。查询最新状态,不自动等于查询最终确定状态。

如果应用先取得回执,随后在另一时间查询不同提供商的链头,就需要处理不匹配。两份回复可能并不描述同一个一致快照。匹配区块哈希及祖先关系,比只比较高度更有信息量。

本篇是证据阅读课程,不是命令执行流程。真实客户端版本与提供商各不相同,应用依赖字段之前,必须核对准确接口语义与信任模型。

返回目录 · 下一节

8. 设计能够诚实变化的状态标签

对课堂档案馆,有用标签可以是“已观察到提交”“包含于 A100”“在观察分支上有三次确认”“不再包含于所选历史”,以及“包含于 B104,并被题设最终性检查点 B105 覆盖”。

这些比一个绿勾冗长,但界面可以显示短标签,同时保留可查看的支持细节。核心要求是底层记录保留观察到了什么,以及何时观察。

临时显示应能反映后续变化。如果标签说“临时”,派生数据却完全不能修正,那么即使区块链按规范运行,应用自身也存在不一致。

本题不为所有接收者规定同一接受政策。可撤回的目录预览,与不可逆外部行动,后果不同。技术状态证据可以支持政策,却不会替用户选择后果,也不会自动授权外部行动。

返回目录 · 下一节

9. 分开协议最终性与机构层面的完成

在 s5,工作表提供了覆盖 B104 的最终性证据。这支持关于协议在其假设下如何对待相关历史的陈述,却不能证明档案审阅者已经批准措辞、实物已经到达,或所有外部系统都更新完毕。

机构可以定义额外完成条件,例如执行成功、必要人工审核,或与另一记录核对一致。这些条件应单独说明,不应隐藏在区块链状态背后。

同样,在技术文件里使用“最终性”,并不会自动确立法律结算或有法律约束力的权利。本课不作具体法域的法律结论。这类问题需要适用法律框架与事实。

这个区别可以防止读者和设计者过度主张。“网络报告该检查点已最终确定”,是有来源与范围的技术陈述;“所有义务从此不可逆地履行完毕”,则宽泛得多,单一技术字段不能支持。

返回目录 · 下一节

10. 接收者的证据检查表

第一,识别精确请求与网络。不同网络或应用环境中外观相似的标识,不应混用。记录哪个来源在何时提供观察。

第二,如果声称包含,应识别包含区块,并确立它与当前使用的所选历史之间的关系。关于某区块的历史证明或回执,不自动构成当前分支成员关系声明。

第三,按已说明约定计算或解释深度。高度、区块哈希、适用时的累计工作量,以及最终性状态,应分别记录。不能把经过时间换算成保证出现的区块数量。

第四,单独检查执行结果与应用含义。成功处理的交易仍可能需要应用解释;执行失败,也不会因等待更多后继区块就变成成功。

第五,如果政策依赖最终性,应识别实际最终性证据或受信任观察,并确认其是否覆盖包含区块。然后记录尚未完成的机构条件。这是一张推理检查表,不是转移资产或触发不可逆外部行动的授权。

返回目录 · 下一节

11. 六道练习与答案

  1. 在 s0,服务返回 T 的标识,接收者能声称什么?只能说明该服务确认了提交,不能声称包含或最终性。
  2. T 在 A100 中,所选链头是该分支的 A102。按本篇约定有几次确认?三次,即 102−100+1。
  3. 在 s3,选择 B103,而 T 不在该历史中。应用能否仍把三次作为 T 当前确认数?不能。可以保留历史观察,但当前包含主张已经改变。
  4. 在 s4,T 位于 B104,链头为 B106,新确认数是三还是六?三。不能把不兼容 A 分支上的旧深度加进来。
  5. 在 s5,题设 B105 有效地获得最终性,且是 B104 的后继。它是否覆盖 T 的包含区块?在给定祖先关系与最终性假设下,覆盖。这与链头 B107 时算出四次确认,是不同事实。
  6. T 被最终性证据覆盖,但执行结果显示失败,是否说明预期目录变更成功?不能得出该结论。包含的最终性不会推翻已报告的执行结果。

扩展练习:把 s5 的最终确定检查点改成 B103,T 仍位于 B104。这样,检查点不再覆盖 T 的包含区块。历史中某处存在最终确定检查点还不够;它与相关包含位置的祖先关系很重要。

返回目录 · 下一节

12. 常见报告错误

“三次确认意味着三个验证者批准”,混淆了深度与参与者。“曾经包含,所以当前状态不能改变”,忽略了所选历史关系。“计时器到期,所以已最终确定”,则用界面事件替代协议证据。

“有回执,所以执行成功”,合并了包含与结果。“网络最终确定了某些内容,所以 T 也最终确定了”,漏掉检查点是否覆盖 T 的区块。“新分支更长,所以全部旧交易都复制过去了”,则发明了证据没有说明的合并。

修正这些错误的方法,是把标签连接到具体对象、历史、来源和时间。清楚的状态语言不只是外观问题,它能避免应用根据比数据更强的主张作决定。

返回目录 · 下一节

13. 常见问题

多少次确认永远足够?

本课没有提供通用数字。答案取决于系统、假设及接收者定义的后果。熟悉的次数不是普遍保证。

重组是否总会移除该交易?

不一定。包含历史可能以不同方式改变。本例明确给出 T 在 s3 缺席;另一段过程可能在两条分支上都包含同一交易。

最终性是否意味着数据属实?

不是。它关注协议如何对待历史。输入真实性与应用解释,需要其他检查。

分支变化后,应用是否应该删除旧观察?

课堂做法保留观察历史,同时更新当前视图。真实保存与隐私政策需要独立要求,本课不指示你删除或保留任何特定生产记录。

返回目录 · 下一节

资料来源与下一步学习

主要资料于新加坡时间 2026 年 10 月 12 日核对:比特币开发者文档中狭窄的确认概念、其区块链指南、以太坊 Gasper 概述及 JSON-RPC 参考。本篇不沿用历史支付建议与时间主张。档案时间线和标签练习均为原创合成材料。

下一步可从接收者视角转到节点决策过程:应用读取答案之前,分叉选择、检查点及启动信任假设,如何决定节点跟随哪段历史?

返回目录