法律状态公告日
法律状态信息
法律状态
2020-08-14
授权
授权
2020-07-21
实质审查的生效 IPC(主分类):G06F16/21 申请日:20200522
实质审查的生效
2020-06-26
公开
公开
技术领域
本发明涉及区块链技术领域,具体涉及一种联盟链账本平台的数据结构构建方法及系统。
背景技术
联盟链的账本平台与现有技术中的传统系统软件不同,它涵盖账本这一领域概念。
联盟链账本平台和应用有纵向一体化打包的趋势,只有这样才能从技术上保证减少外部“非责任体”介入,提高软件的技术信用。
为有效支撑上层应用,联盟链势必需要在平台层确定账本数据结构,以形成保留结构。
与区块链平台及联盟链平台数据结构相关的现有技术存在以下几个技术问题:
一、对以比特币为代表的区块链相关数据结构进行模仿,此类链平台的主要目的是创新价值载体,而非对链平台进行解构推广,因此对基于链平台的应用拓展不具备太多支撑价值;
二、在数据结构的设计上沿用传统数据库等系统软件的思想,没有对账本这一偏上层技术领域的数据结构进行定义和配置,而是提供了一种过于灵活的自定义方式,使得应用有效性、工程效率均难以得到保障,因此现有技术的传统数据库等系统易发散、且账本数据结构容易被忽略。
发明内容
本发明实施例提供一种联盟链账本平台的数据结构构建方法及系统,该方法及系统创建了以账本“应用对象”为主的数据结构,并对数据结构的语义进行约定,从而解决了以系统软件思想为依据的联盟链数据结构模型存在的易发散、账本数据结构被忽略的技术问题。
第一方面,本发明实施例提供一种联盟链账本平台的数据结构构建方法,该构建方法包括以下步骤:
S100:将原始数据导入联盟链账本平台的数据结构模型;
S200:识别所述原始数据的信息元素,将所述信息元素与所述数据结构模型的各个字段进行语义对照和语义约束以生成信息元素映射表;
S300:对所述原始数据的交易及区块组成结构进行分析,以确定该原始数据的元素、子对象和复合对象;
S400:对所述信息元素映射表进行标记和覆盖度检查以生成第一信息元素集;
S500:对所述第一信息元素集进行实例化处理以生成第二信息元素集;
S600:基于所述第二信息元素集构建联盟链账本平台的数据结构。
进一步的,所述构建方法还包括以下步骤,S700:当所述联盟链账本平台产生新增数据时,基于所述新增数据生成第一信息元素集、第二信息元素集并更新所述联盟链账本平台的数据结构。
进一步的,所述数据结构模型是通过如下子步骤获得的:
S110:基于词根表对联盟链业务涉及的信息元素进行命名,对所述联盟链业务涉及信息元素进行区分以获得区分结果,所述区分结果包括主体、维度、标量或属性;
S120:基于所述区分结果,根据所述联盟链业务涉及的信息元素归属于纵向账本数据结构、横向数据结构或元数据结构的范围界定规则,建立联盟链的纵向账本数据结构、横向数据结构和元数据结构;
S130:分别对所述纵向账本数据结构、横向数据结构和元数据结构的字段进行定义、语义约束和数据类型约束,以获得所述数据结构模型。
进一步的,所述元数据结构用于约束纵向账本数据和横向数据中的字段的取值、存储联盟链内各结点的数据、设置分布的参数和底层通用参数。
进一步的,所述纵向账本数据结构包括交易组成数据结构和区块组成数据结构。
进一步的,所述横向数据结构包括参与者数据结构、管理者数据结构、智能合约数据结构和网络节点数据结构。
进一步的,所述元数据结构包括从交易类型、激励类型、结点关系图、区块记录数、传输类型、超时约定、汇率和账本ID中选取的多个。
进一步的,所述S400包括以下子步骤:
S410:基于所述信息元素映射表、原始数据的元素、子对象和复合对象,对所述信息元素进行横向或纵向归属标记;
S420:对标记后的信息元素进行覆盖度检查,以生成所述第一信息元素集。
进一步的,所述S500包括以下子步骤:
S510:对所述第一信息元素集中的数据的维度进行调整,以及对所述原始数据的子表进行扩充,获得调整后的信息元素集;
S520:基于所述调整后的信息元素集并依据所述数据结构模型的自定义标注,对自定义项进行语义匹配和实例化处理,以生成所述第二信息元素集。
第二方面,本发明实施例提供一种联盟链账本平台的数据结构构建系统,该构建系统包括导入模块、识别模块、分析模块、第一生成模块、第二生成模块和构建模块;其中,
所述导入模块用于将原始数据导入联盟链账本平台的数据结构模型;
所述识别模块用于识别所述原始数据的信息元素,将所述信息元素与所述数据结构模型的各个字段进行语义对照和语义约束以生成信息元素映射表;
所述分析模块用于对所述原始数据的交易及区块组成结构进行分析,以确定该原始数据的元素、子对象和复合对象;
所述第一生成模块用于对所述信息元素映射表进行标记和覆盖度检查以生成第一信息元素集;
所述第二生成模块用于对所述第一信息元素集进行实例化处理以生成第二信息元素集;
所述构建模块基于所述第二信息元素集构建联盟链账本平台的数据结构。
本发明依据创建的联盟链账本平台的数据结构模型,能够有效地支撑基于联盟链平台的上层应用进行拓展,并支撑应用遵照账本数据结构及定义来构建联盟链账本平台,促进联盟链应用中系统软件层和应用软件层的融合,解决联盟链平台大规模解构推广问题,提升了应用该数据结构模型的联盟链平台其扩展应用效果及工程效率。
本发明的联盟链账本平台的数据结构模型在侧重逻辑数据结构的同时,对应用账本语义进行了标准化定义,从而可以支撑基于链平台的相关应用以进行有效的物理实现。
本发明还将联盟链账本平台的数据结构模型划分为纵向账本数据结构、横向数据结构和元数据结构,并对这几个数据结构进行了结构设计、字段命名和定义、语义约束、数据类型约束,从而对账本平台数据结构模型的内容进行了明确,基于该数据结构模型形成的联盟链平台所支撑的上层应用,能够有效地对责任内容进行划分,可以更高效地明确组装交易和应用实施过程中的“责任者”体系;
此外,上层应用在开发设计时能够基于本实施例创建的数据结构模型,简单易行地进行语义映射,提升了应用软件工程化效率。
本发明提出的联盟链账本平台的数据结构模型,还能解决包括对系统干预、短期撤回、系统测试及试用、数据转储等工程类问题。
附图说明
图1为本发明实施例提供的一种联盟链账本平台的数据结构构建方法的流程示意图;
图2为本发明实施例提供的一种联盟链账本平台的结构示意图;
图3为本发明实施例提供的一种联盟链账本平台的数据结构模型的组成示意图;
图 4为本发明又一实施例提供的一种联盟链账本平台的数据结构模型的明细组成示意图;
图 5为本发明实施例提供的交易组成数据结构上位概念与5WH对应示意图;
图6为联盟链账本平台的结点关系示意图;
图7为本发明实施例提供的一种联盟链账本平台的数据结构构建系统的结构示意图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明,但应当说明的是,这些实施方式并非对本发明的限制,本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代,均属于本发明的保护范围之内。
下面对本实施例的联盟链和区块链的区别和联系进行简要说明。
联盟链的各个节点通常有与之对应的实体机构组织,通过授权后才能加入与退出网络。各机构组织组成利益相关的联盟,共同维护区块链的健康运转。
联盟链与区块链的核心区别,在于访问权限的开放程度,或者叫去中心化程度。
实施例一
参见图1,图1为本发明实施例提供的一种联盟链账本平台的数据结构构建方法的流程示意图,该方法包括以下步骤:
S100:将原始数据导入联盟链账本平台的数据结构模型中;其中,所述原始数据来源于具体应用领域的原始数据表单和/或原始数据库结构;
S200:识别所述原始数据的信息元素,将所述信息元素与所述联盟链账本平台的数据结构模型的各个字段进行语义对照和语义约束以生成信息元素映射表;其中,所述原始数据的信息元素需经过辨别和区分,区分结果包括主体、维度、属性、标量;这里原始数据的信息元素指原始数据的所有字段;
S300:对所述原始数据的交易及区块组成结构进行分析,以确定所述信息元素的子元素、子对象和复合对象;其中,所述交易及区块组成结构为最多元素复合的、有特征标量的纵向记录事实型结构;所述子对象包括有多个子元素;所述复合对象包括子对象和子元素;
S400:对所述信息元素映射表进行标记和覆盖度检查以生成第一信息元素集;
具体的,所述S400包括以下子步骤:
S410:基于所述信息元素映射表、子元素、子对象和复合对象,对所述信息元素进行横向或纵向归属标记;
S420:对标记后的信息元素进行覆盖度检查,以生成所述第一信息元素集;优选的参见图5,可使用5wh对标记后的信息元素进行覆盖度检查。
S500:对所述第一信息元素集进行实例化处理以生成第二信息元素集;
具体的,上述S500包括S510和S520;其中,
S510:对所述第一信息元素集中的数据的维度进行调整,以及对所述原始数据的子表进行扩充,获得调整后的信息元素集;
S520:基于所述调整后的信息元素集并依据所述数据结构模型的自定义标注,对可自定义项进行语义匹配和实例化处理,以生成所述第二信息元素集;其中,所述自定义项不能超出所述数据结构模型约束的语义空间。
S600:基于所述第二信息元素集构建联盟链账本平台的数据结构;其中,所述联盟链账本平台的数据结构包括横向数据结构、纵向账本数据结构和元数据结构;所述横向数据结构与元数据结构中的部分字段,可冗余存储在所述纵向账本数据结构中,例如横向数据结构中的交易参与者信息、管理者信息等可冗余存储在所述纵向账本数据结构中。
优选的,所述联盟链账本平台的数据结构预留开放空间,以支持该账本平台的应用升级和扩展。
进一步的,所述构建方法还包括以下步骤,S700:基于所述新增数据生成第一信息元素集、第二信息元素集并更新所述联盟链账本平台的数据结构。
参见图2,联盟链平台包括环境层(包含系统层软件,比如操作系统)、组件层和联盟链账本平台;其中账本平台嵌入在系统层中,被打包形成一体化。
其中,账本平台的数据结构模型是联盟链账本平台的核心要素之一,联盟链账本平台数据结构涉及到账本这类应用概念,它是一组关联的数据结构集合,这组关联的数据结构又分为纵向和横向数据结构以及相关的环境支持,参见图3,该联盟链账本平台数据结构模型包括:纵向账本数据结构、横向数据结构和元数据结构。
下面将具体说明本实施例的步骤S100中的联盟链账本平台的数据结构模型的创建过程,包括以下子步骤:
S110:基于词根表对联盟链业务涉及的信息元素进行命名,对所述联盟链业务涉及的信息元素进行区分以获得区分结果,所述区分结果包括主体、维度、标量或属性;
其中,主体是指区别其他结构的符号(如交易组成结构里的“交易标识”);
维度代表一类元素的组合(如参与者维、网络节点维等);
属性可以是维度属性(如参与者维里的“参与者证书”、“背书条件”等),也可以是结构属性(如交易组成结构里的“交易格式版本”、“交易描述”等);
标量指代有数量信息的字段(如“交易金额”)。
S120:基于所述分类结果,根据所述联盟链业务涉及的信息元素归属于纵向账本数据结构、横向数据结构或元数据结构的范围界定规则,建立联盟链的纵向账本数据结构、横向数据结构和元数据结构;
所述范围界定规则如下:涵盖最多元素复合的、有特征标量的结构为纵向账本数据结构。一般而言,纵向账本数据结构属于复合数据结构,纵向账本数据结构选择的信息元素覆盖面广,可兼顾不同行业领域的需求;
横向数据结构属于单数据结构,对应纵向账本数据结构中可跨领域通用的维度,横向数据结构中大部分信息元素需要先于纵向账本数据结构进行确定,在建立联盟链账本平台的数据结构模型时需要独立存在,在实现时可以冗余记录在纵向账本数据结构中;
元数据结构用于约束纵向账本数据结构和横向数据结构中相关元素的取值,并对纵向账本数据结构和横向数据结构的字段进行解释说明,同时支撑对联盟链内各结点存储及分布的参数设置、底层通用参数设置等。
S130:分别对所述纵向账本数据结构、横向数据结构和元数据结构的字段进行定义、语义约束和数据类型约束,以获得所述数据结构模型。
进一步的,对所述纵向账本数据结构、横向数据结构和元数据结构中的可自定义的字段进行标注;
在建立所述纵向账本数据结构、横向数据结构和元数据结构以及对纵向账本数据结构、横向数据结构和元数据结构的各个字段的取值进行约定时,该数据结构模型可预留出一定的开放空间,以支持该数据结构模型的可扩展性,从而在接口对外关联时再对开放空间做出相应约束,这里约束是指在实例化时不应超出数据结构模型中给出的上位概念语义范围。
进一步的,参见图4,所述纵向账本数据结构包括交易组成数据结构和区块组成数据结构;其中,所述交易组成数据结构用于约束纵向交易包含的字段、命名、语义、数据类型;所述区块组成数据结构用于约束纵向区块包含的字段、命名、语义、数据类型。
该交易组成数据结构是整个数据结构模型的关键,它的元素要覆盖面广、可兼顾不同需求,参见图5,交易组成数据结构的内容分类与5WH对应,这便于联盟链账本平台数据结构模型与其他传统应用软件数据结构对应和衔接。
“交易”本身的概念要有更大的外延,即“交易”可以看成对“状态变化”形成确切“时点”的记录。典型的例子是各种审批结点,在这种情况下,交易可看为达成一致观点(含时点)的记录,参与者是“报/审”的双方。类似的,在做跨行业交易时,需要对交易过程进行追踪,需要一个“发起方”和一个“响应方”,也需要有参与者记录。实际上,还有一个隐含的参与者是“监管方/管理方/平台方”。
参见下表1,所述交易组成数据结构包括交易类型、交易初始化、交易内容分类、交易描述、交易状态、共识信息、交易金额、结点关系图指针、交易背书条件、专项、资产类别/币别、账套ID和权限标识位等;
表1
下面将对上表1中的相关字段的相关语义约束及操作进行说明:
1.交易类型(元数据结构中也可体现):典型交易类型有如下几种:
(1)事实记录(发起和接收已被加密钥的方式确定,即已经形成“交易对”,只是记录问题);
(2)过程记录(发起和接收是过程,已发起但等待接收,需要过程记录);
(3)规则自动匹配(两参与者都发起,由交易规则自动撮合,完全由程序自动完成,可细分为“市场平台”和“做市交易”,常见撮合原则包括价格优先、时间优先、客户优先、做市优先、经纪优先等,最终形成“交易对”记录交易)。此外,在工程应用中,本实例例也可将交易类型定义为:(1)发起发起;(2)发起接收;(3)资产转移。具体分类的依据可根据具体应用领域自行选择。
2.交易初始化:对交易数据结构中的各元素进行初始设置,包括注册/登记。
3.交易内容分类:交易内容分类标准与分类表需根据不同应用场景与应用领域进行自定义。该内容分类主要用于创始区块对区块分类账的初始额统计。
4. 交易描述:又称交易备注,指针对交易行为的描述,通常用于存储与交易相关的备注信息。此外,工程应用中,分类备注优先于通用备注,分类备注又可针对不同类型数据分为参与者备注、标量备注、交易备注、管理者备注、节点备注等。备注也可自定义为指针备注,指代交易指针,指针指向附录文件。
5.交易状态:交易状态在具体应用中体现为枚举型,可根据不同应用场景进行枚举值的自定义,自定义的依据规则包括但不限于:(1)因业务流程引发的交易组成元素数据更新,其造成的状态变化;(2)因管理流程引发的交易检查、撤销等操作,其造成的状态变化。
6.共识信息:用于验证交易有效性以及选择记账权的归属,主要包含以下内容:共识类型;共识结果;共识裁决。
(1)共识类型:共识类型是指在共识裁决过程中采纳应用的多种共识算法,通过指针指向由共识分类而形成的横向代码表,表中包含所有共识类型。
(2)共识结果:共识结果是指共识过程中各个结点投票表决的结果,又包含冲突共识结果,并将冲突共识结果存储成记录。整个结果用副本图表示(结点关系图)即可,不仅能够详细的展现出所有结点的投票情况,还能够发现冲突共识并予以记录。
(3)共识裁决:是指根据产生的共识结果进行最终裁决,决定主链是否有新区块上链,每次更新链,各个结点在下载副本的时候须将对应区块的撤销记录一并进行下载。联盟链采取自动表决机制,需将不一致的结果替换成一致,然后将被替换的交易反向记录下来。
7.交易金额:交易中涉及到的账户资产的变更数量、交易额,是最主要的交易标量信息。此外,针对该标量信息的描述字段:汇率(该字段也体现在元数据中),则作为标量备注存储在交易描述当中。
8.结点关系图指针:指向结点关系图的指针,结点关系图(元数据结构中体现)决定了交易数据的复制路径与复制策略,并能够计算出所有副本数,并显示共识表决结果。
9.交易背书条件:认证交易有效性所需要的交易证明或担保条件。
10.专项:根据应用进行自定义。
11.资产类别/币别:链中流转的不同资产价值载体。
12.账套ID:交易记录所在账套的ID,可根据应用自定义。
13.权限标识位:权限标识位可用来匹配、对应操作者的记录访问权限,记录访问权限的划分通过权限表的形式体现,表中针对权限的不同分级分类可根据具体应用进行自定义规划。
工程应用中,标识位既能归集(多位)使用,也可逐一使用。
参见下表2,所述区块组成数据结构包括区块内容分类、区块状态、区块打包规则和区块序号等,在物理实现时,区块组成数据结构可冗余地记录在交易中。
表2
下面将对上述表2的区块组成数据结构的字段的相关语义约束及操作进行说明:
1.区块内容分类:根据应用自定义。
2.区块状态:根据应用自定义。
3.区块打包规则:通常指交易自动打包进区块的规则,通常由管理者或管理结点制定,内容自定义。
4.区块序号:区块序号是当前区块的标识之一,能够通过该序号查询到相应区块,或便于调用该区块。
本实施例中的区块组成数据结构还包括创始区块和撤销交易信息表;其中,创始区块并不具有交易的记账、检验、打包功能,而仅仅是将上一区块链的交易依据上位信息表形成的“账本核算方向”进行科目分类和初始额归集;撤销交易信息表需要按交易进行顺序存储,每条撤销交易冗余记录所在原区块组成信息。
由于比特币及大部分公有链有一个缺点是不能记录“转储”,而从工程可用性角度处理,交易记录应该可以转储,即必须给交易记录的膨胀设计一个“出口”。必须在账本数据结构中加入适应转储的能力,通过设计相关字段(如交易内容分类),形成转储汇总时的核算方向依据。
进一步的,所述联盟链横向数据结构多个横向字段,所述横向字段为所述纵向字段的组成元素;横向字段既可以冗余地记录在纵向数据结构中,也可独立存在;在物理实现时,部分横向数据结构可冗余地记录在纵向账本数据结构中。
参见图4,所述多个横向字段包括参与者数据结构、管理者数据结构、智能合约数据结构和网络节点数据结构;其中,所述参与者数据结构用于约束横向参与者包含的字段、命名、语义、数据类型;所述管理者数据结构用于约束横向管理者包含的字段、命名、语义、数据类型;所述智能合约数据结构用于约束智能合约包含的字段、命名、语义、数据类型;所述网络节点数据结构用于约束网络节点包含的字段、命名、语义、数据类型。
参见表3,所述参与者数据结构包括参与者标识、背书条件和记录访问权限等;
表3
下面将对上表3中的参与者数据结构的字段的相关语义约束及操作进行说明:
1.参与者标识:是参与者身份唯一ID标识码,按区段发布,确保一致性。
2.背书条件:认证交易有效性所需要的交易证明或担保条件,需要特别指出的是,管理者负责对交易标量信息进行来源审计,审计规则可形成背书策略表达式,具体表达式的构成根据应用进行自定义;此外,管理者背书条件还包括交易认定有效性的约束条件(如链码索引、链码名称、链码路径、管理者签名、管理结点数字签名等)。
3.记录访问权限:参与者/管理者针对交易记录的不同访问权限。
参见表4,所述管理者数据结构包括管理者激励类型等;
表4
下面将对上表4中的管理者数据结构的字段的相关语义约束及操作进行说明:
1.管理者激励类型(元数据结构中也可体现该字段):包括发行激励、管理激励、其他激励。
参见表5,所述智能合约数据结构包括以下字段:合约标识、合约名称、合约版本、生效时间和合约编码等,各字段的数据类型如表5所示。
表5
参见表6,所述网络节点数据结构如下:
表6
需要注意的是,“网络节点数据结构”中的“节点”是物理概念;而下面元数据结构中的“结点关系图指针”中的“结点”是逻辑概念。
进一步的,所述元数据结构从交易类型、激励类型、结点关系图、区块记录数、传输类型、超时约定、汇率和账本ID中选取的多个,下面将具体来描述元数据结构的各个字段。
1.交易类型(Transaction Type;TxType),所述交易类型用于描述交易操作的各种类型。
由于形成交易一般有两个参与者和一个管理者或潜在管理者,这在纵向账本数据结构中已经体现,典型的交易类型包括以下几种:
(1)事实记录:已被加密钥的方式确定发起和接收,即已经形成“交易对”,只是记录问题。
(2)过程记录:发起和接收是过程,已发起但等待接收,需要过程记录。
(3)规则自动匹配:两个参与者都发起,由交易规则自动撮合,完全由程序自动完成。可细分为“市场平台”和“做市交易”(常见撮合原则包括价格优先,时间优先,客户优先,做市优先,经纪优先等),最终形成“交易对”记录交易。
此外,在工程应用中,也可以将交易类型定义为:发起发起;发起接收;资产转移。具体分类的依据可根据具体应用领域自行选择。
2.激励类型(Incentive Type;InctType)
所述激励类型用于控制节点维护账本的数据;在区块链中,激励机制受到的关注远远少于共识机制。相比于共识机制绝对的核心位置,激励机制是建立在共识机制之上的另一个次核心。激励机制是通过经济平衡的手段,鼓励节点参与到维护系统安全运行中来,防止对总帐本进行篡改、是长期维持网络运行的动力。
本实施例示出以下三种激励类型:
(1)发行激励:每个常规区块的第一笔交易,就是为了让成功生成新区块的人获得一定数量的价值资产奖励,这同时也是联盟链价值载体的发行过程。
(2)管理激励:是指行使管理职能所获得的激励,如交易费、管理费等。
(3)其他激励:针对不同应用场景或不同业务领域,可自定义其他激励机制。
3.结点关系图(Peer Subscription Diagram;PrSubDgrm)
参见图6,结点关系图是一个实时变化的图结构,不仅能够描述数据在主/辅结点之间的复制路径,还能通过主结点与辅结点数目确定该结点关系图的副本总数;同时,为数据复制策略的制定提供组织结构依据。通常来讲,一个联盟链平台内的所有结点采用的复制策略具有一致性。
所述结点关系图包括主结点和辅结点,其中,一个主结点对应一个或多个辅结点;根据主结点和辅结点来获得复制路径并基于主结点与辅结点的数目确定该结点关系图的副本总数。在一个实施例中,所述交易类型包括事实记录、过程记录和规则自动匹配。
进一步的,所述结点关系图的图结构为动态配置,根据实际情况添加结点数。
需要说明的是,交易记录中存储的“结点关系图指针”是指向变化的图结构的“指针”,提供了查询图结构的索引。图结构是动态配置,可以根据实际情况添加结点数。此外,根据访问用户的角色、职能以及结点优先级的不同,应设置差异化的“记录访问权限”。
下面将对结合图6,对结点关系图的图结构中结点类型、副本总数、复制路径说明、复制策略说明、缺省策略说明、记录访问权限予以阐述:
(1)结点类型:
主结点:主结点是指联盟链内可进行交易验证、生成、检查/资产转移、全网订阅分发、核查、共识/表决、重发等,区块发起、验证、打包、检查/封包、全网订阅分发、核查、共识/表决、重发等操作的结点,有明显的资源配置优势。主结点是记账的主体,负责形成可被全网复制的账本数据副本,其中:记账的主结点可以为某个拿到令牌的主结点(其他主结点对它形成的账本数据进行复制),也可以为多个具备记账职能的主结点(由记账的主结点之间对数据进行相互检查,达成共识),具体如何设计可按照不同的应用场景进行选择。
辅结点:辅结点是指联盟链内仅能进行交易发起、接收、查询,区块接收、查询等操作的结点,其中一些操作须依托主结点进行。辅结点不具备记账权限,仅能通过主结点进行账本数据副本的复制,为保障数据传输及存储的完整性和一致性,本发明设计辅结点可通过1个以上的主结点进行副本的复制。
(2)副本总数:副本总数=主结点副本数(m)+辅结点副本数(n)
(3)复制路径说明:在结点关系图的基础上说明结点主从关系及数据复制路径。
(4)复制策略说明:
a.若辅结点的个数为1,则联盟链平台仅需制定复制策略,如下:首先复制至主结点;主结点向下复制至辅结点。
b.若辅结点的个数为2个及2个以上,则联盟链平台需制定复制策略+检查策略,如下:首先复制至主结点;主结点向下复制至辅结点;检查下载副本的一致性,若出现数据下载不一致的情况,则先覆盖为统一版本,再将不一致数据记录保存下来。
(5)缺省策略说明:缺省策略为复制策略中的一种特殊情况,指“辅结点可以从多个主结点上复制、下载数据”的复制策略,为了应对主结点脱机情况下的数据复制传输情况。
(6)记录访问权限:记录访问权限是针对每条交易记录的内容,基于参与者的角色、职能、结点的不同优先级而设置的信息查询权限。
4.区块记录数(Block Transactions Count;BlkTxCt)
区块记录数为整数型,通过块记录数的设定,可协助给出区块自动打包的规则。
5.传输类型(Transmission Type;TransType)
传输类型通常指基于不同传输协议的传输类型,可根据应用实际情况进行自定义。
6.超时约定(Time out;Tmeot)
数值型数据,指一旦响应或操作超时则判定该交易无效,继续处理下一笔交易。
7.汇率(Exchange Rate;ExRate)
用于将交易执行过程中转移的不同类别的资产(如不同币别),通过汇率转换成一致的币别(如人民币)完成记账工作,保持记账结果币别的一致性。
8.账本ID(Account Book ID;AcctBookID)
账本ID的组成为如下格式:账本名字(自定义)+时间(时间精确到秒)。
涉及纵向应用概念的数据结构是一个极易语义发散的内容,传统的系统软件和目前大部分的联盟链数据结构很少涉及相关内容。
本实施例创建的联盟链账本数据结构则相对固定,只有在账本基本要素、元数据结构、横向数据结构和纵向账本数据结构以及各数据结构和取值的扩展特性等方面相对稳定时,才能有利于构建出联盟链账本平台,如果数据结构模型是动态自定义的数据结构,那么联盟链平台就会退化成为一个分布式数据库引擎,这也是目前流行的联盟链平台存在的主要问题。
实施例二
图7为本发明实施例提供的一种联盟链账本平台的数据结构构建系统的结构示意图,参见图7,该系统包括导入模块、识别模块、分析模块、第一生成模块、第二生成模块和构建模块;其中,
所述导入模块用于将原始数据导入联盟链账本平台的数据结构模型;
所述识别模块用于识别所述原始数据的信息元素,将所述信息元素与所述数据结构模型的各个字段进行语义对照和语义约束以生成信息元素映射表;
所述分析模块用于对所述原始数据的交易及区块组成结构进行分析,以确定该原始数据的元素、子对象和复合对象;
所述第一生成模块用于对所述信息元素映射表进行标记和覆盖度检查以生成第一信息元素集;
所述第二生成模块用于对所述第一信息元素集进行实例化处理以生成第二信息元素集;
所述构建模块基于所述第二信息元素集联盟链账本平台的数据结构。
上述各个模块的具体实施方式与实施例一的构建方法的的具体实施方式一致,在此不再赘述。
本发明具有以下优点:
本发明依据创建的联盟链账本平台的数据结构模型,能够有效地支撑基于联盟链平台的上层应用进行拓展,并支撑应用遵照账本数据结构及定义来构建联盟链账本平台,促进联盟链应用中系统软件层和应用软件层的融合,解决联盟链平台大规模解构推广问题,提升了应用该数据结构模型的联盟链平台其扩展应用效果及工程效率。
本发明的联盟链账本平台的数据结构模型在侧重逻辑数据结构的同时,对应用账本语义进行了标准化定义,从而可以支撑基于链平台的相关应用以进行有效的物理实现。
本发明还将联盟链账本平台的数据结构模型划分为纵向账本数据结构、横向数据结构和元数据结构,并对这几个数据结构进行了结构设计、字段命名和定义、语义约束、数据类型约束,从而对账本平台数据结构模型的内容进行了明确,基于该数据结构模型形成的联盟链平台所支撑的上层应用,能够有效地对责任内容进行划分,可以更高效地明确组装交易和应用实施过程中的“责任者”体系;
此外,上层应用在开发设计时能够基于本实施例创建的数据结构模型,简单易行地进行语义映射,提升了应用软件工程化效率。
本发明提出的数据结构模型,还能解决包括对系统干预、短期撤回、系统测试及试用、数据转储等工程类问题。
本领域普通技术人员可以意识到,结合本发明实施例中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本申请所提供的实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。
机译: 一种通过音乐的快速(实时)自动构建和搜索具有多个级别的数据结构的电子设备自动控制的方法和实现该方法的系统。
机译: 在分布式分布式账本上存储合同数据结构的系统和方法
机译: 在分布式分布式账本上存储合同数据结构的系统和方法