区块缓存设置

ICS35.
020A30DB深圳市地方标准DBXX/XXXXX—XXXX金融行业区块链平台技术规范FinancialBlockchainPlatform----TechnicalSpecifications点击此处添加与国际标准一致性程度的标识(征求意见稿)XXXX-XX-XX发布XXXX-XX-XX实施深圳市市场监督管理局发布DBXX/XXXXX—XXXXI目次前言II引言III1范围12规范性引用文件13术语和定义14缩略语25基本原则26区块链平台功能组件及技术规范3附录A(资料性附录)常见的共识机制类别与适用性参考9参考文献10DBXX/XXXXX—XXXXII前言本部分按照GB/T1.
1-2009给出的规则起草.
本部分由深圳市人民政府金融发展服务办公室归口.
本部分起草单位:深圳证券交易所、深圳前海微众银行股份有限公司、深圳证券通信有限公司、深圳市互联网金融协会、深圳市标准技术研究院、深圳前海联易融金融服务有限公司.
本部分主要起草人:宿旭升、李斌、张敖、李凯、钟松然、计胜侠、萧建昌、卢丽珊、汤霞,谭宇,朱玉含、李如先、李绅、姚辉亚、罗振伟、范瑞彬、张开翔、苏小康、徐磊.
DBXX/XXXXX—XXXXIII引言在分布式商业需求逐渐扩大的背景下,分布式技术以其较好的弹性、较高的经济效用、对等网络和容错机制渐渐被应用普及,区块链技术就是其中的典型代表.
这是一种由分布式架构、分布式存储、块链式数据结构、点对点网络、共识算法、隐私保护算法、智能合约等多种信息技术共同组成的整体解决方案,可带来信息技术的全新变革.
在实际应用中,"区块链"和"分布式账本技术"这两个概念经常被互相替代使用.
严格意义上,区块链技术是一种在对等网络环境下,通过透明和可信规则,构建不可伪造、不可篡改和可追溯的块链式数据结构,实现和管理可信数据的产生、存取和使用等的模式.
其块链式数据结构的基本特征是将一段时间内发生的事务处理以区块为单位进行存储,并以密码学算法将区块按时间顺序连接成链条的一种数据结构,该"链"在区块链网络参与节点间复制和共享,同时链上内容依据不同的共识机制由参与节点组成的网络集体维护.
而分布式账本技术的概念更为广泛,强调的是事务处理通过复制和共享的账本来实现,参与者可以在多个站点、不同地理位置或者多个机构组成的网络里实现共同治理及分享资产数据库,分布式账本技术并不指定具体的数据结构特征,某种程度上也可以将区块链看作是分布式账本技术的一种.
尤其是在不同的利益、关注点和需求的驱使下,两者的应用实践逐渐体现了一种相互融合的趋势,主要代表了符合两者共同点的技术统称.
因此,在描述具体的系统时,本文件将简化采用"区块链"一词代表"区块链和分布式账本技术".
金融行业应用场景中,金融机构注重多层次的对等合作,且业务往往涉及大量的资金流动,有强监管、严合规、高安全的行业特殊要求,无论是仅由单个实体控制的私有链,抑或是任意节点均可接入的公有链,都难以满足金融行业的特性.
因此金融业界往往将通用的分布式技术与金融信息技术中的身份认证、权限管理、隐私保护、反洗钱反欺诈支持、监管审计支持等模块相结合,并通过组建联盟的形式探索联盟链的技术路线.
由于金融行业各机构发展区块链技术的进程、深度、路线等千差万别,区块链平台技术规范的标准化有助于统一认识,规范和指导各机构对区块链技术的应用.
DBXX/XXXXX—XXXX1金融行业区块链平台技术规范1范围本标准规定了金融行业区块链技术平台的功能组件、分层框架及技术规范.
本标准所使用的体系化方法,重点关注金融区块链服务的功能架构和技术规范.
本标准适用于深圳市企业参考功能视图以建设金融区块链和分布式账本系统、参考技术规范开展金融区块链和分布式账本服务,并不适用于直接构建金融区块链服务的具体解决方案、技术实现与部署等.
2规范性引用文件下列文件对于本文件的应用是必不可少的.
凡是注日期的引用文件,仅所注日期的版本适用于本文件.
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件.
GB/T11457-2006信息技术软件工程术语GB/T25069-2010信息安全技术术语GB/T32399:2015信息技术云计算参考架构ISO/IEC9804:1998信息技术开放系统互连、托付、并发和恢复服务元素的服务定义(Informationtechnology—Opensystemsinterconnection—Servicedefinitionforthecommitment,concurrencyandrecoveryserviceelement)3术语和定义下列术语和定义适用于本规范.
3.
1区块链blockchain一种在对等网络环境下,通过透明和可信规则,构建不可伪造、不可篡改和可追溯的块链式数据结构,实现和管理事务处理的模式.
注:事务处理包括但不限于可信数据的产生、存取和使用等.
3.
2块链式数据结构chained-blockdatastructure一段时间内发生的事务处理以区块为单位进行存储,并以密码学算法将区块按时间顺序连接成链条的一种数据结构.
3.
3共识算法consensusalgorithm区块链系统中各分布的节点对事务或状态的验证、记录、修改等行为达成一致确认的方法.
3.
4DBXX/XXXXX—XXXX2智能合约smartcontract以数字形式定义的能够自动执行条款的合约.
3.
5公有链publicblockchain任意节点均可接入,所有接入节点均可参与共识和读写数据的一类金融区块链部署模型.
3.
6联盟链consortiumblockchain由一组利益相关的参与者使用,仅有授权节点可接入,接入节点可按规则参与共识和读写数据的一类金融区块链部署模型.
一般而言,金融行业注重多方合作,涉及大量的信息与资金流动,又因金融行业的强监管及高等级安全要求,金融业内往往是通过组建联盟(如:金链盟)以探索联盟链的技术路线.
3.
7私有链privateblockchain仅由单个实体使用,仅有授权的该使用方节点可接入,接入节点可按规则参与共识和读写数据的一类金融区块链部署模型.
4缩略语下列缩略语适用于本规范.
API:应用程序接口(ApplicationProgrammingInterface)BaaS:区块链即服务(BlockchainasaService)CA:认证授权(CertificationAuthority)DLT:分布式账本技术(DistributedLedgerTechnology)ECC:椭圆曲线加密(EllipticCurveCryptography)KYC:了解你的客户(KnowYourCustomer)PBFT:实用拜占庭容错共识机制(PracticalByzantineFaultTolerance)POS:权益证明共识机制(ProofofStake)POW:工作量证明共识机制(ProofofWork)5基本原则5.
1合法合规原则应遵守国家相关法律法规和金融监管要求,应为监管审计需求提供技术支持.
5.
2可追溯原则业务与活动都应有记录,可追溯,可审计.
5.
3数据一致性原则链上链下存取的数据应保证数据库的一致性,区块链各个节点之间的数据也应保持一致性.
5.
4安全原则应采取各种必要的安全手段,保障链上资产和交易等信息的安全,防范攻击.
DBXX/XXXXX—XXXX35.
5隐私保护原则应保障链上的用户隐私安全,防止泄露用户隐私.
5.
6业务导向原则以需求推动技术,设计与开发时应优先考虑适用的业务场景.
6区块链平台功能组件及技术规范6.
1功能组件分层框架6.
1.
1金融行业区块链平台架构以分层框架来描述各功能组件,在分层框架中,特定类型的功能被分组到各层中,相邻层次的模块和组件之间通过接口交互.
6.
1.
2金融行业区块链平台功能组件的规范应满足金融行业的强监管与高安全要求.
金融行业区块链平台功能组件根据具体业务或需满足以下要求:权限管理、准入机制、信息披露、市场退出等制度在功能组件中的体现;体现监管协调、监管职责、风险处置责任的区分;体现资本市场风险监测、识别和预警功能;支持监管机构应急管理、现场与非现场检查、定期与不定期考核要求.
6.
1.
3区块链平台各功能组件的分层框架如图1所示,包括五层:用户层、接入层、核心层、基础层,以及一个跨越各层的跨层功能集合.
具体如下:图1金融区块链平台分层框架a)用户层:是面向用户的入口.
金融区块链服务的使用方通过该入口和服务进行交互,执行相关管理功能,使用和维护金融区块链服务.
用户层也可将服务输出到其他层,提供跨层服务支持;b)接入层:为用户层或终端应用提供高效、可靠、通用的访问,包括:通过封装核心层功能组件,使用高效缓存、负载均衡等技术,提供高效、可靠的接入管理、节点管理和智能合约管理等服务;支持标准通用的接入协议,为用户在多样化业务场景下提供通用的协议管理;c)核心层:是金融区块链系统的核心功能层.
包括:节点间的共识机制,以及在此共识机制之上的数据与账本记录;隐私保护、加密、摘要与数字签名等模块,保证系统的安全合规与防篡改;此外,根据应用场景的不同,可以有选择地添加能自动执行预设逻辑的智能合约,以及统一全金融区块链系统时间的服务功能;d)基础层:该层可视作全系统的基础支撑,提供金融区块链系统正常运行所需要的运行环境和基础组件,如数据存储、运行容器、通信网络等;e)跨层功能:提供跨越多个功能层次能力的功能组件.
6.
2功能组件及规范要求图2从功能组件通用集的角度描述金融行业区块链平台上各功能组件在具体的参考架构实现中有相应的实现构件,例如:软件组件、子系统或应用.
用户层接入层核心层跨层功能基础层DBXX/XXXXX—XXXX4图2金融区块链功能组件通用集6.
2.
1用户层功能组件及规范要求用户层功能组件应包括:用户功能、业务功能、管理功能.
6.
2.
1.
1用户功能用户功能组件支持金融区块链服务的使用方访问和使用金融区块链服务,在大部分的使用场景下,提供基础资源的管理,链的创建、维护、管理,链上智能合约的部署、使用等功能.
用户功能组件应满足以下技术规范:a)用户交互界面:可以是命令行界面或图形用户接口以及应用程序接口等形式;b)事务:将金融区块链服务的使用方的特定事务请求(查询、更新)提交到金融区块链网络的功能;c)事件:帮助金融区块链服务的使用方在金融区块链网络上监听并采取行动的一组应用事件.
6.
2.
1.
2业务功能业务功能组件支持金融区块链服务的使用方的活动,宜提供服务选择和订购,使用账务和财务管理功能.
6.
2.
1.
3管理功能管理功能组件支持金融区块链服务的使用方的活动,应实现成员管理服务、对服务活动的监控管理、事件处理和问题报告、安全管理服务等.
6.
2.
2接入层功能组件及规范要求接入层功能组件应包括:接入管理、协议管理、链上节点管理.
6.
2.
2.
1接入管理用户层接入层核心层跨层功能基础层用户功能业务功能管理功能接入管理链上节点管理智能合约时序服务共识账本记录存储计算对等网络开发开发环境管理测试管理构建管理运营服务目录及交付管理运营策略监控及日志管理跨链服务管理安全摘要隐私保护监管审计监管支持审计功能加密数字签名身份认证管理权限管理在功能架构之上的金融应用场景实现系统安全策略反洗钱和反欺诈DBXX/XXXXX—XXXX56.
2.
2.
1.
1接入管理功能组件提供跨进程调用功能,为终端应用及用户层提供核心层接入服务.
6.
2.
2.
1.
2提供的接口应至少覆盖以下功能:金融区块链服务的使用方账户信息的基本信息、金融区块链区块、事务详情等账本信息的查询服务、金融区块链服务的使用方特定事务操作请求提交到金融区块链网络的服务.
6.
2.
2.
1.
3接入管理功能组建宜实现的技术规范:接口服务能力管理,如支持接口调用频度设置和事务操作及账本查询缓存设置;接口访问权限管理,如针对不同的用户配置不同的访问权限,接口的通讯安全,如对通讯报文进行加密.
6.
2.
2.
2协议管理协议是连入网络的设备都要遵循的一定的技术规范,应包含关于硬件、软件、端口等的技术规范.
6.
2.
2.
3链上节点管理6.
2.
2.
3.
1节点是区块链的载体,由安装了特定区块链软件、可连接互联网、具有可访问的IP地址、且能对外提供服务的物理服务器或虚拟服务器组成.
6.
2.
2.
3.
2链上节点管理功能组件支持对金融区块链节点的信息查询和管理控制,应至少满足以下技术规范:a)节点服务器的状态信息查询;b)节点服务启动关闭控制;c)节点服务能力配置;c)节点网络状态监控;e)节点授权配置管理.
6.
2.
3核心层功能组件及规范要求核心层功能组件应包括:共识机制、账本记录、隐私保护、加密、摘要、数字签名.
宜包括:时序服务、智能合约.
6.
2.
3.
1共识机制根据不同的业务需求,可选择适用的共识算法来实现共识机制.
常见的共识算法类型有POW、POS、PBFT等.
共识机制功能组件应具备以下技术规范及功能:支持多个节点参与共识和确认,支持独立节点对金融区块链网络提交的相关信息进行有效性验证,防止任何独立的共识节点未经其他共识节点确认而在金融区块链系统中进行信息记录或修改,应具备一定的容错性,包括节点物理或网络故障的非恶意错误、节点遭受非法控制的恶意错误,以及节点产生不确定行为的不可控错误.
6.
2.
3.
2账本记录6.
2.
3.
2.
1账本泛指区块链中分布式数据的存储机制,通过不同节点对账本的共同记录与维护,形成区块链系统中数据的公共管理、防篡改、可信任的机制.
6.
2.
3.
2.
2账本记录功能组件应具备以下功能:a)支持持久化存储账本记录;b)支持多节点拥有完整的数据记录;c)支持向获得授权者提供真实的数据记录;d)确保有相同账本记录的各节点的数据一致性.
6.
2.
3.
3隐私保护DBXX/XXXXX—XXXX6隐私保护目的是保护区块链应用中用户身份和事务处理等敏感信息不被泄露或非法获取,这些信息只有通过充分授权才能被访问.
金融区块链隐私保护功能通常通过数据加密和访问控制手段来实现,隐私保护功能组件宜支持但不限于以下四类隐私保护策略:a)由认证机构代理用户在金融区块链上进行交易,用户资料和个人行为不进入区块链网络;b)不采用全网广播方式,而是将数据的传输限制在正在相关的授权节点之间;c)对用户数据的访问采用权限控制,持有密钥的访问者才能解密和访问数据;d)采用例如零知识证明、环签名和同态加密等隐私保护算法,规避隐私暴露.
6.
2.
3.
4加密加密功能组件应支持加密和解密两个操作.
金融区块链加密功能组件所使用的密码算法应符合国家密码管理局密码管理要求.
6.
2.
3.
5摘要摘要功能组件又称数字摘要功能组件,指将任意长度的消息输入变成固定长度的短消息输出,一般通过摘要函数(或称Hash函数)来实现,摘要功能的输出值被称为摘要值或者Hash值.
摘要功能组件应具备以下功能:对数据的完整性提供保护、对于给定的数据明文和摘要值可验证该数据明文是否被篡改.
6.
2.
3.
6数字签名6.
2.
3.
6.
1数字签名功能组件被用以确认数据单元的完整性以及不可伪造性,是非对称加密技术与数字摘要技术的结合,一般包括数字签名和签名验签两个具体操作.
数字签名操作指对签名内容的摘要用私钥加密生成数字签名值;签名验签操作指用公钥解密签名值并与摘要值进行比对.
一般可根据签名功能依托的非对称加密算法的不同进行分类,典型的算法包括RSA、ECC和我国商密算法SM2.
6.
2.
3.
6.
2数字签名功能组件应具备以下功能:支持对相关信息进行数字签名和签名验证,确保信息的机密性、完整性及不可抵赖性.
宜支持集成权威公正的第三方CA机构签发的数字证书.
6.
2.
3.
6.
3对于签名的私钥需要有安全的保管机制:如客户使用硬件等方式自行保管、或通过中立可靠的第三方来托管.
6.
2.
3.
7时序服务对于金融区块链系统中的行为或数据需记录一致性的时序,可以选择特定的时序机制或工具.
金融区块链系统可有选择性地提供时序服务功能.
时序服务功能组件应具备以下功能:支持账本记录统一时序、具备时序容错性.
宜具备支持集成可信第三方时序服务(如国家授时中心的可信时间戳服务)功能.
6.
2.
3.
8智能合约6.
2.
3.
8.
1智能合约是一套以计算机代码形式定义的承诺,以及合约参与方可执行承诺的协议,即:用计算机代码形式编写合约参与方达成的条件型协议,当条件被触发时区块链系统自动执行该协议.
根据应用场景的不同需求,金融区块链系统可有选择性地提供智能合约功能.
6.
2.
3.
8.
2智能合约功能组件应具备以下技术规范:提供编程语言支持及配套开发环境,支持合约内容静态和动态检查,支持运行载体如虚拟机,支持向账本中写入合约内容,防止对合约内容进行篡改,支持多方共识下的合约内容升级等.
对于与金融区块链系统外部数据进行交互的智能合约,外部数据源的影响范围应仅限于智能合约范围内,不应影响系统的整体运行.
6.
2.
4基础层功能组件及规范要求基础层功能组件如:存储、计算、对等网络.
DBXX/XXXXX—XXXX76.
2.
4.
1存储6.
2.
4.
1.
1存储组件提供区块链运行过程中产生的各种类型数据,如账本、交易信息等的写入及查询功能,相关选型包括但不限于关系型数据库、键值对数据库、文件数据库等.
6.
2.
4.
1.
2存储组件应满足以下需求:点对点网络中,能够被每个节点部署并使用;能够高效、安全、稳定地提供数据写入及查询服务;对于采取分库分表的数据存储方案,存储组件还应包括数据的分片及路由处理能力.
6.
2.
4.
2计算6.
2.
4.
2.
1计算组件提供区块链系统运行中的计算能力支持,包括但不限于容器技术、虚拟机技术、云计算技术等.
6.
2.
4.
2.
2一般应满足以下需求:对区块链系统提供运行环境支持;点对点网络中,能够被每个节点采用.
6.
2.
4.
3对等网络6.
2.
4.
3.
1区块链系统运行的底层拓扑结构是分布式对等网络,采用对等网络协议组织区块链中的各个网络节点.
6.
2.
4.
3.
2各个节点间通常使用点对点通信协议完成信息交换以支撑上层功能.
6.
2.
4.
3.
3网络传输组件通常应满足以下需求:能够进行点对点之间的高效安全通信;能够提供点对点通信基础上的多播能力;应支持对节点的动态添加、减少的识别.
6.
2.
5跨层功能及规范要求6.
2.
5.
1开发功能组件开发功能组件宜由以下组件构成:开发环境管理、构建管理、测试管理.
6.
2.
5.
1.
1开发环境管理功能组件宜包括:支持开发服务相关的配置元数据的生成;支持服务配置脚本和组件的编写或生成.
6.
2.
5.
1.
2构建管理功能组件宜包括:支持自动化构建软件包功能;提供自动化编译功能及出错信息提示;实现构建过程的审核流程;多语言支持;多平台支持.
6.
2.
5.
1.
3测试管理功能组件宜包括:支持测试计划、方案、报告、用例等内容的管理;支持自动生成测试报告;测试环境与生产环境集成的情况下进行测试不应影响生产环境;测试过程自动化;提供测试用例库、测试数据库管理功能.
6.
2.
5.
2运营功能组件运营功能组件宜包括:服务目录及交付管理、运营策略、监控及日志管理、跨链服务管理.
6.
2.
5.
2.
1服务目录及交付管理组件宜包括:所有部署、提供和运行金融区块链服务有关的技术信息,相应的工作流信息.
6.
2.
5.
2.
2运营策略组件宜包括业务、技术、安全、隐私和认证等策略.
6.
2.
5.
2.
3监控及日志管理组件宜包括:监控区块链网络中节点进程的运行状态、网络通信状态、共识达成效率的能力,针对区块链节点在运行过程中所产生日志的存储、分析的能力,节点运行报告.
6.
2.
5.
2.
4跨链服务管理组件宜连接相关FBSP的运营系统、业务系统与管理系统.
6.
2.
5.
3安全功能组件DBXX/XXXXX—XXXX86.
2.
5.
3.
1该组件宜考虑多种层次的安全威胁,包括但不限于身份管理类安全威胁、业务与应用类安全威胁、网络与信息安全威胁、终端类安全威胁、基础类安全威胁、管理类安全威胁等.
安全功能组件应至少包括:身份认证管理、权限管理、系统安全策略、反洗钱与反欺诈、其他金融安全功能体系.
6.
2.
5.
3.
2安全功能组件应具备:支持通过各种有效的身份认证材料进行用户身份认证,支持多种认证方式的组合使用,提供对用户在第三方权威认证机构认证过的证书进行备案、签名、验签的功能;支持设置授权和安全规则授权用户访问和使用资源权限的功能;提供节点间通信加密和节点数据加密存储、节点主机安全加固、智能合约安全验证等安全策略;支持反洗钱与反欺诈功能,具备客户身份识别、可疑交易识别与报告功能,支持对接风险控制系统;宜提供:信息资产安全、人员安全、物理与环境安全、运维安全、办公安全、系统开发与维护安全、业务连续性安全、合规安全等方面的管理组件.
6.
2.
5.
4监管审计功能组件监管和审计功能组件目标是使金融区块链服务符合可监管与可审计的特性,避免金融区块链网络游离于法律法规以及行业规则之外,成为洗钱、非法融资或犯罪交易的载体.
应至少包括以下功能:监管支持、审计功能.
6.
2.
5.
4.
1监管支持功能组件应具备以下特性:支持通过事前准入控制、事中权限控制、事后追溯等技术手段实现监管目标,保证记录不可篡改、可追溯与可稽核;设置明确的监管治理规则;保存与服务、资源、性能相关的数据和证据.
宜具备:允许监管机构加入金融区块链网络作为其中一个节点进行即时监管.
6.
2.
5.
4.
2审计功能功能组件应具备以下特性:保存与审计活动相关的数据和证据.
宜具备:审计方加入区块链网络作为其中一个节点进行实时审计,或允许审计方作为金融区块链网络之外的第三方机构,按需或定时获得区块链网络中的数据与证据;允许实时核查审计被审计对象的全部记录并作为审计证据;实现金融区块链网络与其他相关系统的对接与数据提取.
DBXX/XXXXX—XXXX9AA附录A(资料性附录)常见的共识机制类别与适用性参考表A-1常见共识机制类别和比较注:表中适用性内容仅为一般性参考,可结合具体业务需求选择不同共识机制.
比较内容工作量证明共识机制(POW)基于相关权益的共识机制(POS)传统分布式系统的一致性算法基于拜占庭容错模型(BFT)的共识机制基本机制通过特定计算运算获取特定规则匹配值来取得记账权,对系统事务消息进行记录.
节点通过特定的权益分配获得成为记账节点的不同概率,一般情况下两者成正比,但也会通过特定的规则获取记账权.
通过选举领导者进行共识事务的组织发起,其余参与者跟随验证或确认的方式.
常见的算法有PAXOS、RAFT等.
采用领导者选举机制,在领导者和共识参与者之间通过多轮交互达成共识,以达成拜占庭容错(恶意错误和不可控错误),常见的算法有PBFT.
特点1、网络节点都可参与,具备最广泛的参与性;2、一般情况下,与其他共识算法相比计算资源消耗相对较高,性能速度较低;3、有超过51%恶意节点攻击的风险,特定情况下会产生数据分叉.
1、相比POW,一定程度减少了计算的资源消耗,仍有一定程度的获取记账权的计算消耗;2、在特定权益分配机制下,容易形成记账权的公平性问题,产生中心化控制风险.
1、实现共识的过程类似现实社会中的选举,领导者(节点)需要获得大多数选民(节点)的投票,一旦选定后就跟随其操作,领导者有任期或期限,期限结束后将重新选举领导节点.
PAXOS和RAFT的区别在于选举的具体过程不同,主要目的都是让每一个参与节点按少数服从多数的原则逐步达成一致意见;2、此类算法没有追求取得记账权的计算消耗,整体性能较高.
1、具备更好的容错机制,可以覆盖严格的错误类型(非恶意、恶意、不可控错误);2、共识过程交互相对较多,记账人群体一般事先指定,在部分场景下有选择公平性问题.
容错性容许全网50%的节点容错(恶意、非恶意、不可控).
根据不同的机制设计有所不同,但一般与POW类似.
选举过程可以容忍N/2-1个节点出错,大多不考虑拜占庭容错,即假设所有节点只发生宕机、非人为问题,并不考虑恶意节点篡改数据的问题,但亦有改进后实现拜占庭容错的ByzantinePaxos.
一般可以容忍1/3的拜占庭错误节点,在特定的假设条件下,容错范围可以进一步扩大.
适用性一般适用于对公平性、开放性要求高的场景,如公有链.
不适用于对性能以及即时一致性要求高的场景.
适用于对开放性较高,具备特定权益机制的场景.
适用于成员或节点可控程度较高的私有链及部分联盟链场景.
适用于大部分联盟链场景与特定的公有链场景,可以保证不产生分叉,保持数据的一致性.
DBXX/XXXXX—XXXX10参考文献[1]《COBIT5:ABusinessFrameworkfortheGovernanceandManagementofEnterpriseIT》,ISACA[2]《区块链参考架构》中国区块链技术和产业发展论坛,CBD-Forum-001-2017