English version · 区块链学习导航 · 上一篇：区块链与传统数据库
区块链学习 · 文章 BC003
分布式系统由位于不同机器上的组件组成，组件通过通信共同完成任务。区块链则是一类特定的分布式记录系统：它需要规定怎样验证更新、怎样形成被接受的历史，以及怎样用密码学方法连接记录。两者有关联，但不能互换使用。
这个区别很重要，因为增加计算机只能解决部分问题。副本可能提高可用性，却不能单靠数量决定冲突更新中哪一个有效。一个网络可以把工作分散到许多机器，同时仍由一家机构掌握全部重要权力。
本文通过虚构的博物馆目录和纸笔练习，解释区块链需要回答哪些额外的协作问题。理解原理不需要部署软件，也不需要使用金融资产。
选择适合你的阅读路线
本篇目录
- 1. 三份目录副本，并不会自动变成区块链
- 2. “分布式”可能描述不同性质
- 3. 为什么通信会带来协作难题？
- 4. 有效性与排序，回答不同问题
- 5. 区块链需要补充哪些规则？
- 6. 机器停止，与机器发送矛盾消息，是两种故障
- 7. 安全性与活性，有时需要不同取舍
- 8. 更多副本，不一定意味着更多独立保障
- 9. 确定性执行，关注能否重复得到同样结果
- 10. 纸笔练习：三名登记员与两个请求
- 11. 这个练习说明了什么？
- 12. 怎样更认真地读架构图？
- 常见误区
- 检查你的理解
- 资料来源与下一步
- 弄清区别：先读目录案例，以及“分布式”的三种含义。
- 跟随技术问题：阅读消息延迟、冲突更新，以及有效性与排序的区别。
- 理解故障：重点看崩溃故障、拜占庭行为、安全性与活性。
- 用于教学或复习：使用三名登记员的纸笔练习、误区说明和参考答案。
1. 三份目录副本，并不会自动变成区块链
设想一份博物馆目录保存在三个馆舍的服务器上。中央服务接受修改，再复制到其他服务器。某个馆舍的连接故障时，访客仍然可以浏览其他副本。
这是分布式运行：多台机器共同提供服务。设计可能很合理，但它不自动等于区块链，也不能证明有三个独立主体共同控制目录。
如果一名管理员可以替换所有服务器的软件、重写源数据库，并控制全部访问，物理副本就没有形成独立决策权。它们可能防护某些设备故障，却仍然保留同一个管理依赖。
现在设想，三家独立博物馆共同维护借展目录。每家都希望核验经过授权的顺序，不愿让另一家悄悄改写历史。协作要求由此发生变化。区块链可能成为候选方案，但前提是实际规则与运行安排确实提供所需的独立性。
关键是区分：计算在哪里发生，与谁决定什么记录算数。
2. “分布式”可能描述不同性质
存储分布在多处
数据保存在不同地方。副本可能完整或不完整，可能是最新状态，也可能存在延迟。这可以改善访问或韧性，却不能单独说明谁控制修改。
计算由多台机器完成
多台机器可以分担任务，也可以重复计算以进行检查。一家公司完全可以在单一管理结构下，运营规模很大的分布式计算服务。
权力由不同主体共同掌握
不同参与者具有实际决策权。某些重要动作不能由一方独自完成，例如接纳新成员或改变已经接受的规则。这是治理与协议属性，不是机器数量增加后自然产生的结果。
同一系统在不同维度上的分散程度可能差别很大。例如，数千名用户持有副本，但升级由少数人控制；也可能由多方共同治理，却只使用数量不多、身份明确的运营者。
与其只问“是否去中心化”，不如问：哪种操作分散了，由谁承担，又受到什么限制？精确答案比简单的是或否更有信息量。
3. 为什么通信会带来协作难题？
在一台机器上，程序可以按选定顺序处理两条指令。但在网络中，不同机器可能以不同顺序收到相同指令。
假设一家博物馆提交“批准借展A”，另一家提交“批准借展B”，两者涉及同一件藏品和重叠日期。北方服务器先看到A，南方服务器先看到B。两个请求都可能具有正确签名，但规则只允许该时段存在一项确认借展。
任何一台服务器的接收顺序，都不会自动成为全网权威时钟。先创建的请求，可能因连接较慢而更晚到达；本地时钟也可能有差异。系统需要一种共同接受的方法，确定影响共享结果的顺序。
这并不是区块链独有的问题。分布式数据库、复制服务和其他协作系统，也需要处理并发与故障。区块链采用特定的历史结构、验证、参与和共识规则组合，但不是分布式协作的发明者。
实际结论是：把同一条消息发给多台计算机，不等于形成了一个被共同接受的结果。
4. 有效性与排序，回答不同问题
有效性问的是：请求是否符合适用规则？签名能否接受？发送者有没有权限？所请求的状态变化是否允许？
排序问的是：一个动作相对于其他动作处于什么位置？两个各自符合申请条件的请求竞争同一资源时，顺序可能决定谁成功。
回到借展案例。两家博物馆都可能有资格申请藏品，却不代表两个重叠借展都能确认。一旦其中一个确认改变了共享状态，另一个请求就必须根据新状态重新判断。
提出顺序的参与者，不应因此获得绕过验证的权力。同样，有效签名也不保证发送者拥有优先排序权。理解这些边界，才能避免把“网络收到了”误认为“网络必须接受”。
比特币开发者指南介绍了其账本中的独立验证与区块链接结构。它是一种具体设计，不是所有分布式系统的定义。比特币开发者指南：区块链。
5. 区块链需要补充哪些规则？
可以用五个高层问题检查设计。
记录怎样连接？密码学承诺使记录之间的关系可以检查，有助于发现修改，但不能单独迫使其他人接受或拒绝某段历史。
谁能承担哪些角色？网络需要规定谁能提交、提出区块、验证或投票。许可型系统可以采用成员管理；开放系统则需要避免某人仅通过大量创建身份，就获得无限影响力。
哪些变化有效？参与者需要对授权和状态变化采用兼容规则。即使所有运营者都认为自己正确，软件对规则的不同解释也可能破坏一致性。
怎样选择被接受的历史？协议应说明提案竞争、消息到达顺序不同时如何处理，也应明确确认或最终性在实际使用中的含义。
出问题后怎样继续？新加入或重新上线的参与者，需要取得并核验合适状态的方法。运营者需要在治理框架内处理故障、升级与事件。
并非所有区块链都以同样方式回答这些问题。清单描述的是职责，而不是通用协议配方。2018年10月发布的NIST IR 8202，提供了相关基础术语。
6. 机器停止，与机器发送矛盾消息，是两种故障
崩溃故障指组件停止履行角色，例如服务器断电或进程终止。系统可以针对一定数量的这类故障进行设计。
拜占庭行为的范围更广：组件可能任意偏离协议，包括向不同节点发送互相冲突的说法。原因可能是被入侵、软件错误或其他故障，并不限于某个恶意人员有意识地撒谎。
在博物馆案例里，崩溃的登记员不发送确认；表现出拜占庭行为的登记员，则可能告诉A馆“你的借展已批准”，同时告诉B馆“与你冲突的那笔借展也已批准”。第二种问题不能只靠假定登记员最终会重新上线来处理。
因此，系统声称“容错”时，必须说明容忍哪种故障。能够应对服务器停止，并不自动意味着能够防护任意矛盾消息。
Hyperledger Fabric的排序服务文档讨论了不同排序安排及其故障模型。实际选择的实现与配置很重要，仅有平台名称不够。Fabric排序服务。
7. 安全性与活性，有时需要不同取舍
在这里，安全性指避免协议所禁止的冲突结果；活性指在规定条件下持续取得进展。这里的“安全性”是共识语境中的专门含义，不等于所有网络安全问题。
对于借展，安全性可以要求：两个按协议行动的参与者，不会把互相冲突的已确认借展都视为最终结果。活性则可以要求：必要参与者与网络条件满足时，有效请求最终能够得到处理结果。
网络分区时，部分参与者无法与其他人通信。系统可能暂缓确认，以免形成互相矛盾的最终决定。用户感受到延迟，但这可能是有意保护安全性的选择，不一定表示数据已经损坏。
反过来也一样：一个总能很快回复的服务，不一定提供应用所假定的那种一致性保证。讨论速度时，必须同时说明它承诺的结果是什么。
Castro与Liskov于1999年发表的实用拜占庭容错论文，是一个明确规定复制服务故障与时间假设的基础例子。常见的故障数量界限属于该模型，不能当作所有区块链的通用规则。PBFT服务性质。
8. 更多副本，不一定意味着更多独立保障
假设一场演示展示十二台服务器。在把它们视为十二重独立保障之前，应先问谁控制它们。
如果服务器共用相同管理凭证、同一托管账户和同一软件发布流程，一处管理权限失陷可能同时影响全部机器。物理分散仍然可能有用，但不能消除相关的管理风险。
反过来，真正独立的机构也可能共用存在缺陷的软件依赖。运营者不同，不保证实现故障不同。独立性至少涉及管理、基础设施、软件、访问渠道和激励等维度。
这不表示每个系统都必须在每个维度追求最大多样性。增加差异也带来协作和维护成本。应当先明确要应对什么故障，再为这个目标选择有意义的独立性。
对于博物馆联盟，各方独立保留签名记录，可能保护管理员争议中的证据；独立网络路径则可能帮助应对断网。它们是不同的保护，架构应分别说明。
9. 确定性执行，关注能否重复得到同样结果
参与者核验同一组已接受输入时，需要用兼容规则计算结果。如果计算不可预测地依赖每台机器的本地时钟，或不断变化的网站内容，不同机器就可能得到不同答案。
设想一条规则：“如果今天的保险状态有效，就批准借展。”但每个参与者都在不同时刻，从网站拿到不同响应。此时，系统还没有确定一个共同输入。即使规则文字完全相同，也不保证执行结果相同。
应用可以改为采用一项明确定义、经过授权的保险状态声明。这使状态转换可以重复计算，却引入了对声明提供者的依赖。计算可重复，不等于外部事实为真。
这就是预言机边界：链外信息进入链上执行，需要一条明确路径。以太坊预言机文档解释了这一差别。它不只适用于金融应用。
10. 纸笔练习：三名登记员与两个请求
准备三张纸，分别写“北”“南”“西”，代表虚构共享目录中的三个参与者。这是展示问题的练习，不是一套安全共识算法。
再准备两张请求卡：A申请周一使用17号藏品；B申请在同一时间使用同一件藏品。规则只允许一个确认预约。
第一轮：先向北展示A再展示B，向南则先展示B再展示A。要求各自确认最先收到的请求。结果出现分歧，说明本地到达顺序本身不能产生共同决定。
第二轮：指定西为唯一协调者，由西选择顺序并发给另外两方。如果各方接受西的权力，而且西正确执行职责，就比较容易达成一致。你改变了信任安排，而不是消除了信任。
第三轮：让西向北发送一个顺序，向南发送相反顺序。现在讨论：需要哪些证据和通信规则，才能发现或阻止互相冲突的接受结果？不要假定“投票表决”就自动解决所有消息组合。
练习的作用是把设计问题展示出来。真实协议需要精确规则、身份验证、故障假设，以及对保证的论证。练习刻意停在这里，不假装已经提供完整方案。
11. 这个练习说明了什么？
第一，复制不等于共识。北和南都可以准确保留自己收到的消息，却仍然对被接受的顺序有分歧。
第二，授权不等于排序。两个请求都可能来自合格发送者，但按照规则，稀缺资源只能分配给其中一个。
第三，协调者并非天然不好。如果其权力被接受，并受到合适控制，这可能就是正确方案。避免单方控制的要求，应当来自真实应用。
第四，不一致或不诚实行为改变了问题。只为静默停止设计的协议，不应被默认能够处理“向不同接收者发送矛盾说法”的行为。
最后，看得见的记录链只是系统的一部分。关键是通过什么程序，让正确参与者在规定故障下仍然接受合适的历史。
12. 怎样更认真地读架构图？
看到节点、箭头和链条图标时，可以要求对方带着一条具体请求走完整个过程。
谁先收到请求？谁能拒绝？哪个组件决定顺序？谁核验结果？用户拿到什么证据？这份证据具体证明什么？
然后划掉一个组件，问哪些承诺仍然成立。不要只划掉验证者，也试着划掉访问网站：用户还有没有其他路径进入网络？再把“停止工作的组件”换成“发送矛盾消息的组件”，看保护结论是否变化。
最后，找出普通图中经常没有画出的管理路径。谁能改变配置、替换软件、增加参与者或启动恢复？这些路径往往揭示了分布式部署与分散决策权的差别。
这是本文提供的检查方法，不能替代协议安全分析，但能帮助读者提出有用问题，而不把一张图当成证明。
常见误区
“所有分布式系统都是区块链。”
不是。分布式存储、计算和服务早于区块链系统，也属于更广泛的类别。办公室之间同步的共享文件夹，不会因为有多台计算机保存副本就变成区块链。
“共识就是每台计算机对每个请求投票。”
不是。角色、参与范围和决策规则各不相同。共识描述的是在假设条件下解决一致性问题的方法，不是一套通用投票流程。
“多数参与者可以让任何交易变得有效。”
不能这样理解验证模型。正确进行验证的参与者仍然执行自己的规则。影响共识，与伪造授权或重新定义有效执行，是不同问题。
“系统暂停，说明数据一定错了。”
不一定。无法满足推进条件时，暂停可能是在保护某项安全性质。运营者仍然需要调查原因，并说明用户可以安全依赖哪些结果。
检查你的理解
问题一：一家公司在多个城市运行二十个副本，却通过一个管理账户控制它们。什么明确分散了？什么可能仍然集中？
答案：存储或计算可能分散了；管理权仍可能集中。在声称存在独立控制前，需要更多信息。
问题二：两个正确授权的请求竞争同一借展时段，还缺少什么处理？
答案：系统需要形成被接受的顺序或冲突解决结果，并对相应状态应用规则。有效签名本身不决定谁获胜。
问题三：一个参与者向不同节点发送不同批准消息，这只是服务器停止故障吗？
答案：不是。这属于更广泛的拜占庭故障类别中的不一致行为。如果声称能够防护，协议的故障假设必须覆盖它。
问题四：通信故障时，参与者拒绝最终确认更新。在直接判断系统失效前，应先问什么？
答案：它在保护什么安全性质？哪些推进假设没有满足？恢复程序需要什么？延迟与接受错误结果，是不同的故障。
资料来源与下一步
技术参考资料的研究日期为2026年10月12日，时区为新加坡。以下保留原始发表日期。纸笔练习与读图方法属于教学分析，不是生产环境协议设计。
- NIST IR 8202：区块链技术综述，2018年10月：基础架构与术语。
- 比特币开发者指南：区块链，持续更新文档：一种链式账本与验证设计；历史细节需要核对版本。
- Castro与Liskov：PBFT服务性质，1999年2月：复制服务的安全性、活性和故障假设。
- Hyperledger Fabric：排序服务，持续更新文档：排序职责和具体实现的故障模型。
- 以太坊：预言机，持续更新文档：外部信息与可重复执行。
下一步，可以为一个系统画出信任模型：列明参与者、权限，以及设计假定能够应对的故障。这样，“很多计算机”与“共同掌握权力”的区别，就变成了可以具体检查的内容。
下一篇：共享记录为什么需要信任模型