分布式账本技术：区块链的底层密码

分布式账本技术让多个网络节点各自保存并更新账本副本，再用规则协调记录顺序与状态。区块链属于分布式账本，但分布式账本不一定把数据组织成区块链。

这里的底层密码不是某段秘密代码。它指的是复制、验证、排序和共识共同解决了一个问题：没有单一数据库管理员时，参与者怎样对同一份历史形成可检查的一致视图。

分布式账本如何运作？

参与者先向网络提交交易或状态更新。节点检查交易是否符合身份、签名和业务规则，排序服务或共识协议再确定处理顺序。有效结果被提交到各节点的本地副本，使多个副本在正常运行下收敛到一致状态。

这里的一致不代表每个节点在每一毫秒都完全相同。网络传播需要时间，节点也可能暂时离线。分布式系统关注的是：在允许的故障和延迟范围内，怎样识别有效更新、解决冲突并最终取得一致结果。

分布式账本与中心化数据库有什么区别？

比较项	中心化数据库	分布式账本
写入控制	通常由一个组织或管理员决定	按成员权限和共识规则决定
数据副本	可做主从复制，但由中心统一管理	多个参与节点维护可验证副本
冲突处理	由数据库和管理策略处理	由协议、排序与共识机制处理
审计方式	依赖权限、日志和组织流程	可结合签名、哈希与共享历史核验
主要成本	中心运维与容灾	重复验证、通信、共识和治理

普通分布式数据库也能跨多台机器复制数据，速度往往更快。分布式账本更关心不同组织的节点能否按照共同规则核验更新，服务器数量本身不是判断标准。

分布式、去中心化和无许可是同一回事吗？

不是。分布式描述组件位于多个节点；去中心化描述控制权没有集中在单一主体；无许可则表示参与不需要预先获得某个管理方批准。

一个联盟账本可以分布在多家机构，却只允许获批成员写入。一个公有链允许任何人提交交易，但验证权仍可能集中在少数实体。分析系统时，应分别看节点部署、身份准入、验证权和升级权。

区块链为什么是分布式账本的一种？

区块链把交易分批装入区块，再用前序区块哈希按顺序连接。节点根据共识规则接受新区块，并保存或验证这段链式历史。这种数据结构便于发现历史改动，也能为交易顺序提供清晰依据。

其他分布式账本可能使用有向无环图、事件日志或不同的状态复制结构，不一定存在传统区块。因此，DLT 和区块链不能在所有语境中互换。区块链的完整组件可见区块链是什么。

共识机制在账本中解决什么问题？

共识主要解决哪些更新有效、以什么顺序提交，以及节点出现不同候选历史时选择哪一个。工作量证明、权益证明和拜占庭容错类协议的参与条件与故障假设不同，不能简单概括成投票。

共识也不能保证输入数据真实。假如某个经授权的参与者把错误的现实数据提交上链，网络可以一致记录这个错误。数据来源、预言机和成员治理仍需单独控制。

企业使用分布式账本要检查什么？

• 参与方是否确实需要共同写入或独立验证。
• 谁能加入网络、读取数据、提交交易和部署规则。
• 节点故障、成员退出或网络分区时怎样恢复。
• 隐私数据是上链、加密保存，还是只上链哈希。
• 协议升级、争议处理和错误纠正由谁批准。
• 与传统数据库相比，额外共识成本是否值得。

若所有写入都由同一机构决定，而且其他参与者无需独立验证，中心化数据库加审计日志可能更合适。分布式账本不是数据库的默认升级版，而是一种针对多方协调问题的架构选择。

要继续理解账本怎样接收一笔交易，可阅读区块链如何工作。

常见问题

每个节点都必须保存完整账本吗？

不一定。完整节点、轻节点和归档节点保存的数据范围不同，许可链也可按频道或权限拆分账本。节点能否独立验证，取决于它持有的数据和使用的验证方式。

分布式账本能避免所有单点故障吗？

不能。多副本可以提高可用性，但客户端入口、排序服务、云供应商、密钥管理或治理委员会仍可能形成单点。需要按系统实际拓扑逐项分析。

账本副本不一致时会立即停止吗？

视协议而定。有些系统会暂时停止最终提交，有些允许短暂出现不同候选历史，再按分叉选择规则收敛。应用层应了解一致性与可用性的取舍。

分布式账本可以修改错误记录吗？

通常不会直接覆盖已经提交的历史，而会追加一笔更正或反向交易。许可网络也可能设计管理操作，但这属于具体治理规则，不能只凭分布式账本这个名称推断。