DBPA · 18.1

区块链概念、区块结构与工作机制

区块链把链式记录、共识和状态数据库组合为分布式数据系统

VER. 2608.3 Built with impress.js

学习目标

完成本节后，你应该能够

01区分链式数据结构、分布式账本、共识和节点状态数据库
02解释区块头与区块体的作用
03说明父哈希和 Merkle 根如何让改动可检测，并提高历史重写成本
04描述节点验证到状态更新的流程
05比较工作量证明与 PBFT
06区分区块链技术组合与比特币业务系统，并判断应用边界

2/15

LEARNING OBJECTIVES

区块链组合了四类不同对象

链式结构、分布式账本、共识和状态数据库承担不同职责

区块链由数据块、链式记录、共识和智能合约共同形成系统能力 — 概念总览图展示记录、Merkle 汇总、链和节点副本的关系；不对应具体协议或固定分层架构

链式结构

父哈希连接区块历史，使已接受记录的改动留下可检测证据

分布式账本

多个节点保存并验证共同接受的历史副本

共识

节点按协议决定接受哪一段历史及其状态结果

状态数据库

节点执行账本记录后维护本地可查询的派生状态

3/15

DEFINITION

区块的元信息与交易记录

区块头保存链接和协议证据，区块体保存交易；节点按协议验证区块

比特币式区块的区块头保存父哈希和 Merkle 根，区块体保存交易，当前区块哈希供后继区块作为父哈希 — 比特币式示例；其他区块链的字段和验证流程可能不同

01区块头包含 Version、父区块哈希和 Merkle 根等元信息
02父哈希把当前区块接入前一区块；当前区块哈希可供后继区块引用
03Merkle 根承诺区块体交易集合，不负责判断交易是否合法
04区块体保存交易；交易计数是编码中的计数项，不是区块头字段

4/15

BLOCK STRUCTURE

区块头保存链条证据

字段职责随协议而变；比特币式区块的核心字段包括 Version、父哈希、Merkle 根、Timestamp、Bits 和 Nonce

父哈希

父哈希把本区块接到上一区块

Merkle 根

承诺区块体中的交易集合；交易变化会传导到根

Version / Timestamp

Version 标记规则版本；Timestamp 是协议约束下的时间信息

Bits / Nonce

Bits 与 Nonce 服务比特币式工作量证明；不是所有区块链的通用字段

区块头字段依协议而定；节点按协议验证交易合法性

5/15

BLOCK HEADER

Merkle 根如何承诺交易集合

Merkle 根变化会传导到区块哈希

交易哈希→两两合并→Merkle 树根→区块头哈希

Merkle 根承诺的是本区块的交易集合；它不负责验证交易合法性，不等于共识、最终性或绝对不可篡改

6/15

MERKLE ROOT

改写旧区块会留下可检测的链式证据

后续区块的父哈希和已同步节点的副本可能暴露不一致

01交易变化使 Merkle 根不再匹配
02区块头哈希随之改变
03子孙区块保存的父哈希出现断链
04已同步节点的副本可能与被改写链不一致

Takeaway

这提供改动可检测性并提高重写成本，不保证历史绝对不能改写；最终性和重组边界依协议而异

7/15

TAMPER EVIDENCE

P2P 传播与节点证据

传播、副本和状态数据库承担不同职责；比特币式系统可见三类典型角色

P2P 传播

节点发现邻居并传播交易或区块；网络传输本身不决定哪条历史被接受

全节点

全节点通常保存并验证较完整的账本数据，也维护本地状态

轻节点

轻节点通常只保存区块头或依赖证明查询，具体能力依系统而异

8/15

P2P NETWORK

交易从验证到状态更新

典型流程包括验证、排序、执行和提交；具体顺序依协议而异

典型流程：交易验证、区块提议与打包、区块验证和共识接受，最后更新本地账本与状态数据库 — 状态数据库是节点本地可查询的派生结果，可能存在同步延迟；图示顺序不代表所有协议

01节点收到交易并按协议验证格式、签名和业务状态
02某节点提议、排序并打包新区块
03节点验证区块，由共识协议决定是否接受
04接受后执行状态转移，更新本地账本和状态数据库

9/15

WORKFLOW

PoW 与 PBFT 的参与和最终性边界

两者都协调节点接受同一历史，但参与条件、代价和最终性不同

方式	参与条件	达成接受的机制	主要代价与边界
工作量证明（PoW）	开放节点；无需预先许可	竞争满足难度的计算结果，按协议选择历史	计算与能源开销；确认通常具有概率最终性
PBFT 类投票	已知身份的许可节点	按协议达到法定多数后接受；可容忍部分拜占庭故障	通信与投票开销；故障假设和节点规模受限

10/15

CONSENSUS

区块链组合与比特币系统

区块链机制可以适配其他业务，比特币只是一个具体系统

区块链技术组合

链式记录、密码学链接、分布式网络、共识和可编程规则可以按业务重新组合

比特币业务系统

以数字货币为业务目标的具体系统；其区块字段、激励和共识安排是一个实例

区块链的准入模式和架构应按业务适配；比特币参数不能直接作为通用答案

11/15

SYSTEM BOUNDARY

区块链的适用边界

是否适合区块链，取决于治理、数据真实性、延迟、删除修改和共识成本

场景特征	适合程度	原因
多方共同记账且缺少共同中心	可能适合	满足治理、接入和数据真实性条件时，可能减少重复对账
需要历史追溯	可能适合	链式证据支持追溯，但不自动保证现实输入真实
单一可信中心且只要求低延迟	未必适合	普通数据库可能更简单直接
极高频低延迟写入	谨慎	共识和广播有额外开销
需要删除或修改历史记录	谨慎	已接受的历史记录受删除、修改和隐私控制约束

预言机提供现实输入，但区块链只能保护已经写入并达成共识的记录的可追溯性，不能自动证明输入真实

12/15

USE CASE

区块链把结构、共识与状态更新连接起来

链式结构记录历史，P2P 传播信息，共识决定接受哪条历史，状态数据库提供可查询状态

定义

四个对象承担不同职责，区块链是它们的技术组合

结构证据

父哈希连接历史，Merkle 根承诺交易集合；改动可检测不等于绝对不可改写

网络流程

P2P 传播 → 验证与提议 → 共识接受 → 本地账本和状态更新

应用边界

治理、真实性、延迟、删除修改和协议成本共同决定是否适合

Takeaway

区块链技术组合必须与业务治理、真实性、延迟和协议成本一起评估

13/15

RECAP

本节知识地图

14/15

KNOWLEDGE MAP

本节问题

01区块链、分布式账本、共识和节点状态数据库分别解决什么问题？
02Merkle 根能承诺什么，不能负责什么？
03父区块哈希与 Merkle 根如何让旧区块改动留下链式证据？
04交易从 P2P 广播到本地账本与状态更新经过哪些典型阶段？
05PoW 与 PBFT 类的参与条件、故障假设和最终性有何不同？
06为什么不能直接用比特币的业务逻辑判断区块链是否适合某个应用？

15/15

CHECK YOUR UNDERSTANDING