请使用支持现代 CSS 与 JavaScript 的浏览器播放课件
DBPA · 18.2

区块链发展阶段、准入模式与技术架构

应用规模与信任环境决定区块链的准入和架构

VER. 2608.3 Built with impress.js
DBPA | CH18 | 18.2

学习目标

完成本节后，你应该能够

交易验证、共识和状态更新决定基础流程；应用规模和信任环境进一步决定准入、治理与系统架构

  1. 01解释区块链三个发展阶段各自增加的能力与边界
  2. 02按准入、读写、记账权和治理比较公有、联盟和私有链
  3. 03将九层功能架构归并为五个责任组，并说明各组的抽象边界
  4. 04用事件—条件—动作解释智能合约，并说明外部输入与执行风险
  5. 05解释去中心化、安全和效率为何形成工程取舍
  6. 06说明吞吐、跨链、账本增长和合约安全的原因与后果
2/14
LEARNING OBJECTIVES
DBPA | CH18 | 18.2 | 18.2

区块链能力可按三个阶段梳理

应用范围扩大后，规则、参与者、治理和架构边界都会变化；三个阶段不是必经升级路线

区块链从分布式记账向智能合约和行业协作平台演进
概念总览图连接区块链的工作机制与能力扩展；不表示历史时间轴、准入差异或固定架构

第一阶段：数字货币记账

以数字货币记账和链式历史为主要能力；边界是吞吐、确认延迟和开放网络协调

第二阶段：智能合约

引入智能合约和可编程金融规则；边界是代码执行、治理和外部输入

第三阶段：行业协作

扩展到社会治理与行业协作；边界是身份准入、跨组织治理和系统集成

Takeaway

三个阶段用于梳理能力扩展；不同项目可以并存或跳过阶段，不代表技术成熟度排名

3/14
THREE STAGES
DBPA | CH18 | 18.2 | 18.2

准入机制与治理权限

公有、联盟、私有链体现不同的信任与治理选择，不能按先进程度排序

模式节点准入读／写权限记账与治理代表性共识例子
公有链开放参与规则通常公开；读写由协议约束参与者竞争或按协议记账PoW 等
联盟链组织授权可按成员与业务划分受控记账，组织协商治理PBFT 类等
私有链单组织控制组织决定读写范围内部记账与治理Raft／Paxos 等

联盟链与私有链合称许可链；共识名称只是代表性例子，具体平台的权限和协议可能不同

4/14
ACCESS MODEL
DBPA | CH18 | 18.2 | 18.2

准入模式的信任与成本

许可链用受控身份和治理边界换取更可预测的协调条件；具体性能仍取决于系统设计

公有链

适合开放参与和弱中心信任；代价是广播、共识和身份治理更难预测

联盟链

适合多机构协作；需要成员准入、权限治理和共同规则，性能取决于具体系统

私有链

适合组织内部协作；控制边界更清晰，但不再解决多个互不信任主体的共同治理

Takeaway

选择模式时，应按参与者、监管、数据边界、工作负载和管理成本评估；开放程度本身不代表先进程度

5/14
TRADEOFF
DBPA | CH18 | 18.2 | 18.2

九层架构的功能责任

资源、节点、状态、业务和治理承担不同功能责任

区块链系统从基础设施、基础组件、账本、共识、智能合约、接口、管理、运维到应用分层组织
九层可归并为五个责任组；箭头表示资源、状态和调用依赖，不表示所有平台的严格流水线
  1. 01资源组（基础设施）提供网络、存储和计算
  2. 02节点基础组（基础组件）提供通信、密码和数据存储
  3. 03可信状态组（账本、共识）负责收集、验证、追加和确定接受顺序
  4. 04业务执行组（智能合约、接口）负责规则执行以及 RPC、SDK 调用
  5. 05治理服务组（系统管理、运维、应用）负责身份、权限、监控、服务和业务入口
Takeaway

九层是功能责任抽象，不等于九套系统、九台服务器或固定部署流水线

6/14
ARCHITECTURE
DBPA | CH18 | 18.2 | 18.2

账本、共识与跨链互操作

规模增长后，归档、多链和跨链会改变查询、证明与追溯边界

账本

收集、打包、验证并追加被接受的历史；它回答“记录了什么”

共识

在协议和故障假设下决定哪些顺序或状态转移被接受；最终性依协议而异

规模与互操作

归档保留历史但改变在线查询；多链分散状态；跨链还要验证身份、证明和一致性边界

Takeaway

账本保存历史，共识决定接受条件，查询索引服务可见数据；系统设计要同时说明历史保存、接受条件和可查询范围

7/14
LEDGER AND CONSENSUS
DBPA | CH18 | 18.2 | 18.2

智能合约的 ECA 规则链

ECA 将事件、条件与动作连成执行规则；代码和外部输入受平台边界约束

Event 事件

货物签收等外部事件进入系统；身份认证和数据真实性依赖可信接口或预言机

Condition 条件

双方签名、权限和业务规则满足；条件由平台按其执行语义判断

Action 动作

确认付款并追加账本记录；执行结果仍需按平台规则验证和达成共识

Takeaway

智能合约在功能上类似存储过程或触发器，把规则与数据操作绑定；多节点执行、代码错误和升级治理使它不等同于数据库对象

8/14
SMART CONTRACT
DBPA | CH18 | 18.2 | 18.2

区块链服务的四层能力

接口层封装底层能力；节点和密钥管理的责任取决于部署边界

层次主要能力对应用的意义
接口层RPC、SDK简化调用和访问
管理层身份、权限、节点控制主体可执行的操作和可访问的数据
运维层日志、监视、管理支持运行和故障处理
应用／BaaS业务服务与封装降低接入门槛；BaaS 是服务形态，不是第十个架构层
9/14
OPERATIONS
DBPA | CH18 | 18.2 | 18.2

不可能三角的工程取舍

去中心化、安全和效率要分别落实为参与、验证、吞吐、延迟和资源开销

去中心化

更多主体参与和共同治理；协调、广播和身份管理成本可能上升

安全

副本、验证和故障容忍提高篡改检测或可用性；存储、确认和隐私成本也会增加

效率

吞吐、延迟和资源开销要求更短路径或更少协调；可能改变开放参与和信任假设

Takeaway

这是工程权衡框架，不是严格数学定理；不存在一次性把三个维度都无限增强的方案

10/14
IMPOSSIBLE TRIANGLE
DBPA | CH18 | 18.2 | 18.2

区块链工程与治理难点

系统规模会放大算法、网络、状态和治理的难点；各问题都有对应的原因、后果和边界

吞吐与确认

广播和共识共同形成确认延迟；高并发会争用网络、节点和排序路径

跨链互操作

不同链的身份、状态证明和最终性不一致；验证与失败处理增加复杂度

账本增长

历史越长，存储、索引和查询压力越大；归档能降在线成本，却改变可查询范围

合约安全

代码错误、权限和升级风险会在多节点执行中放大；开发、审计和治理成为系统边界

Takeaway

工程选择必须同时考虑准入模式、架构责任和业务治理，单个算法的局部性能不足以代表系统性能

11/14
ENGINEERING PAINS
DBPA | CH18 | 18.2

区块链架构取舍连接阶段、准入与工程边界

发展阶段说明能力扩展，准入和架构决定责任边界，工程取舍决定适用条件

历史框架

三个阶段分别扩展数字货币记账、智能合约和社会治理／行业协作；它们是历史框架，不是必经路线

准入取舍

公有、联盟、私有链按参与、读写、记账权和治理选择；开放程度不代表先进程度

九层责任

九层可归并为资源、节点基础、可信状态、业务执行和治理服务五组

工程边界

系统难点包括不可能三角、吞吐、跨链、账本增长和合约安全

Takeaway

区块链方案需要同时评估准入、架构责任、性能成本与业务治理

12/14
RECAP
DBPA | CH18 | 18.2

本节知识地图

13/14
KNOWLEDGE MAP
DBPA | CH18 | 18.2

本节问题

  1. 01为什么三个发展阶段是历史梳理框架，而不是所有项目的必经路线？
  2. 02给定一个多机构业务，如何分别判断节点准入、读写权和记账权？
  3. 03账本、共识和跨链分别如何改变历史保存、接受条件和查询范围？
  4. 04货物签收事件进入智能合约后，ECA 规则中的外部输入和代码执行分别处于什么边界？
  5. 05不可能三角中的三个词分别对应哪些工程指标和成本？
  6. 06吞吐、跨链、账本增长和合约安全各自面临什么困难，会造成什么后果？
14/14
CHECK YOUR UNDERSTANDING