CN111695136A - 业务数据区块链的实现方法及其系统 - Google Patents

业务数据区块链的实现方法及其系统 Download PDF

Info

Publication number
CN111695136A
CN111695136A CN202010270331.2A CN202010270331A CN111695136A CN 111695136 A CN111695136 A CN 111695136A CN 202010270331 A CN202010270331 A CN 202010270331A CN 111695136 A CN111695136 A CN 111695136A
Authority
CN
China
Prior art keywords
information
data
user
chain
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010270331.2A
Other languages
English (en)
Inventor
吉建勋
杨慧
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Ruice Technology Co Ltd
Original Assignee
Beijing Ruice Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Ruice Technology Co Ltd filed Critical Beijing Ruice Technology Co Ltd
Priority to CN202010270331.2A priority Critical patent/CN111695136A/zh
Publication of CN111695136A publication Critical patent/CN111695136A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Abstract

本申请公开了一种业务数据区块链的实现方法及其系统，所述实现方法应用于业务数据区块链系统中，所述业务数据区块链系统包括多个区块链节点；所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述用户操作状态为用户操作后的全局状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。本申请采用区块存储和链上状态存储相结合的方式，实现业务数据区块链；解决了业务数据上链的问题。

Description

业务数据区块链的实现方法及其系统
技术领域
本发明涉及互联网大数据技术领域，公开一种业务数据区块链的实现方法及其系统。
背景技术
目前，区块链技术是运用加密算法、共识机制等技术的分布式存储账本。随着区块链技术的运用，越来越多的互联网数据会存储在区块链上。
现有的区块链中，只能存储交易数据，交易数据包括转账方地址、接收方地址以及转账金额；针对各种业务数据(例如：存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、OTO数据(也称为线上到线下数据)、社交数据、点赞数据、评价数据、网约车数据等互联网相关数据)而言，不仅需要在区块链上表达出数据本身，还需要在区块链上表达出数据之间的关联关系。
因此，如何实现在区块链上存储业务数据，换句话说，如何实现业务数据区块链，成为亟待解决的问题。
以上描述仅仅为了方便理解，并不应限定为本申请的现有技术。
发明内容
基于上述问题，本申请提供一种业务数据区块链的实现方法，该方法采用区块存储和链上状态存储相结合的方式，实现业务数据区块链；解决了业务数据上链的问题。
本申请第一方面公开了一种业务数据区块链的实现方法，所述实现方法应用于业务数据区块链系统中，所述业务数据区块链系统包括多个区块链节点；
所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；
所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述用户操作状态为用户操作后的全局状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
在一种可能的实现方式中，所述用户操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户操作数据的签名以及用户操作数据的哈希值中的一种或多种；其中，所述操作类型包括用户对实体的操作和对积分的操作，所述被操作地址包括对实体的操作地址和其他操作用户的地址。
在一种可能的实现方式中，所述链上状态数据库存储的状态数据包括用户信息和实体信息状态中一种或两种。
在一种可能的实现方式中，所述链上状态数据库存储的状态数据包括积分数据，所述积分数据的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括实体信息和用户信息的关联关系；其中，一个实体信息对应一个或多个用户信息。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括实体信息和积分信息的关联关系；其中，一个实体信息对应一个或多个积分信息。
在一种可能的实施方式中，所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息以数据表的形式存储在所述支持属性查询的数据库中，以便于用户根据所述数据表中的属性字段进行查询；其中，一种信息对应一种数据表，任意一种数据表中的任意一行对应一条信息，一种信息包括多行信息；所述支持属性查询的数据库包括关系数据库和内存数据库；或
所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息采用KV数据库存储，以键值对的方式进行存储。
在一种可能的实现方式中，所述链上数据库采用支持属性查询的数据库或KV数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。
在一种可能的实现方式中，所述用户信息和/或所述实体信息的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一种可能的实现方式中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，所述MPT状态树是融合了前缀树Trie的树形结构的默克尔树Merkle变种，所述默克尔树Merkle为Merkle Patricia Tree状态树。
在一种可能的实现方式中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，任意一棵MPT状态树的树根存储在区块头中。
在一种可能的实施方式中，关系树中叶子节点的value以哈希表或数组的方式存储用户信息-积分信息、实体信息-积分信息以及实体信息-用户信息中的一种或多种。
在一种可能的实施方式中，关系树的叶子节点的value用于存储关系子树的树根，所述关系子树存储用户信息-积分信息、实体信息-积分信息以及实体信息-用户信息中的一种或多种，所述关系子树为默克尔树或MPT树。
本申请第二方面公开了一种业务数据区块链的实现系统，所述业务数据区块链系统包括多个区块链节点，
所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；
所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
在一种可能的实现方式中，所述用户操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户操作数据的签名以及用户操作数据的哈希值中的一种或多种；其中，所述操作类型包括用户对实体的操作和对积分的操作，所述被操作地址包括对实体的操作地址和其他操作用户的地址。
在一种可能的实现方式中，所述链上状态数据库存储的状态数据包括用户信息和实体信息状态中一种或两种。
在一种可能的实现方式中，所述用户操作数据为用户在互联网上的操作数据，所述用户操作数据包括存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、线上到线下数据、社交数据、点赞数据、评价数据以及网约车数据中的一种或多种。
在一种可能的实现方式中，所述链上状态数据库存储的状态数据包括积分数据，所述积分数据的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括实体信息和用户信息的关联关系；其中，一个实体信息对应一个或多个用户信息。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。
在一种可能的实现方式中，所述链上关系数据库存储的关联关系包括实体信息和积分信息的关联关系；其中，一个实体信息对应一个或多个积分信息。
在一种可能的实现方式中，所述链上数据库采用支持属性查询的数据库或KV数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。
在一种可能的实现方式中，所述用户信息和/或所述实体信息的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一种可能的实现方式中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，所述MPT状态树是融合了前缀树Trie的树形结构的默克尔树Merkle变种，所述默克尔树Merkle为Merkle Patricia Tree状态树。
在一种可能的实现方式中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，任意一棵MPT状态树的树根存储在区块头中。
在一种可能的实现方式中，所述用户操作数据为用户在互联网上的操作数据，所述用户操作数据包括存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、线上到线下数据、社交数据、点赞数据、评价数据以及网约车数据中的一种或多种。
本申请第三方面提供一种计算机可读存储介质，该存储介质存储有计算机指令，该计算机指令被处理器执行时，实现如上所述任意一项技术方案。
本申请第四方面提供一种电子设备，该电子设备包括处理器，所述处理器用于执行如上所述任意一项技术方案。
本申请通过区块存储用户操作数据，链上状态数据库存储状态数据和状态关联数据，能够将业务数据的各种属性存储在区块链上，从而解决业务数据上链的问题；此外，链上状态数据库存储的状态数据和状态关联数据，也方便用户进行访问。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请公开了一种业务数据区块链的实现方法流程示意图；
图2为本申请公开了一种业务数据区块链的实现系统结构示意图；
图3为本申请公开了一种业务数据区块链的实现设备结构示意图；
图4为现有的一种将区块链的账户状态数据组织成MPT状态树的示意图；
图5为现有的一种MPT状态树上的节点node复用的示意图；
图6为本申请公开了一种业务数据区块链的区块头结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本申请中的“第一”“第二”仅仅是便于理解，给技术词做区分，并不理解为先后，或作为限制性的理解。
为便于对本发明实施例的理解，下面将结合附图以具体实施例作进一步的解释说明，实施例并不构成对本发明实施例的限定。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(PrivateBlockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。
而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。
基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。
对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备进行共识，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。
在区块链领域，有一个重要的概念就是账户(Account)；以以太坊为例，以太坊通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。
当然，对于一些基于以太坊的架构而衍生出的区块链项目，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。
对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。
以以太坊为例，账户的结构体通常包括Balance，Nonce，Code和storage等字段。其中：
Balance字段，用于维护账户目前的账户余额；
Nonce字段，用于该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击。
code字段，用于维护该账户的合约代码；在实际应用中，code字段中通常仅维护合约代码的hash值；因而，code字段通常也称之为codehash字段。对于外部账户而言，该字段为空值。
storage字段，用于维护该账户的存储(默认为空)。在实际应用中，storage字段仅维护基于账户的存储内容构建的MPT(Merkle Patricia Trie)树的根节点；因此，storage字段通常也称之为storageRoot字段。
其中，对于外部账户而言，以上示出的code字段和storage字段为空值。
而大多数区块链项目，通常都会使用Merkle树；或者，基于Merkle树的数据结构，来存储和维护数据。以以太坊为例，以太坊使用了MPT树(一种Merkle树变种)，作为数据组织形式，用来组织和管理账户状态、交易信息等重要数据。
以太坊针对区块链中需要存储和维护的数据，设计了三颗MPT树，分别是MPT状态树、MPT交易树和MPT收据树。
MPT状态树，是区块链中所有账户的账户状态数据(state)，组织成的MPT树；MPT交易树是区块中的交易数据(transaction)，组织成的MPT树；MPT收据树，是区块中的交易执行完毕后生成的与每笔交易对应的交易收据(receipt)，组织成的MPT树。以上示出的MPT状态树、MPT交易树和MPT收据树的根节点的hash值，都会被添加至区块头中。
其中，MPT交易树和MPT收据树，与区块相对应，每一个区块都有自己的MPT交易树和MPT收据树。而MPT状态树是一个全局的MPT树，并不与某一个特定的区块相对应，而是涵盖了区块链中所有账户的账户状态数据。
对于组织成的MPT交易树、MPT收据树和MPT状态树，最终都会在采用多级数据存储结构的Key-Value型数据库(比如，LevelDB)中进行存储。
而采用多级存储结构的上述数据库，通常可以被划分为n级数据存储；例如，各级数据存储可以依次设为L0，L1，L2，L3....L(n-1)；对于上述数据库中的各级数据存储而言，等级编号越小通常级别越高；例如，L0存储的是最新的若干区块的数据，L1存储的是次新的若干区块数据，依次类推。
其中，各级数据存储对应的存储介质的读写性能，通常也可以存在性能差异；级别高(即等级编号较小的)的数据存储对应的存储介质的读写性能，可以高于级别低的数据存储对应的存储介质的读写性能。
例如，在实际应用中，级别高的数据存储，可以使用读写性能较高的存储介质；而级别低的数据存储，可以使用单位成本低，且容量较大的存储介质。
在实际应用中，随着区块高度的增长，在数据库中存储的数据，会包含很多历史数据；而且，区块号越小的区块中的数据越久远，越不重要。因此，为了降低整体的存储成本，通常需要对不同区块高度的数据进行“区别对待”；
例如，可以将区块号较小的区块中的数据，存储至成本较低的存储介质上；而将区块号较大的区块中的数据，存储在成本较高的存储介质上。
在针对数据库中存储的MPT交易树、MPT收据树和MPT状态树等数据进行分级存储时，由于MPT交易树和MPT收据树，与各个区块相对应,实际上是“区块间无关”的数据；因此，对于MPT交易树和MPT收据树，很容易进行分级存储；例如，直接按照MPT交易树和MPT收据树上的node所属的区块号进行数据迁移即可完成分级存储。
基于此，本说明书将不再具体阐述MPT交易树和MPT收据树的分级存储，而重点阐述MPT状态树的分级存储。
请参见图4，图4为本说明书示出的一种将区块链的账户状态数据组织成MPT状态树的示意图。
MPT树，是一种经过改良的，融合了Merkle树和Trie字典树(也称之为前缀树)两种树形结构的优点的Merkle树变种。
在MPT树中通常包括三种数据节点，分别为叶子节点(leafnode)，扩展节点(extension node)和分支节点(branch node)。
叶子节点，表示为[key，value]的一个键值对，其中key是种特殊十六进制编码。
扩展节点，也是[key，value]的一个键值对，但是这里的value是其他节点的hash值(hash指针)。也就是说通过hash指针链接到其他节点。
分支节点，因为MPT树中的key被编码成一种特殊的16进制的表示，再加上最后的value，所以分支节点是一个长度为17的list，前16个元素对应着key中的16个可能的十六进制字符(一个字符对应一个半字节nibble)。如果有一个[key，value]对在这个分支节点终止，最后一个元素代表一个value值，即分支节点既可以是搜索路径的终止也可以是路径的中间节点。
假设需要组织成MPT状态树的账户状态数据如下表1所示:
Figure BDA0002442925260000111
表1
在表1中，账户地址是由若干16进制的字符构成的字符串。账户状态state，是由上述Balance，Nonce，Code和storage等字段构成的结构体。
最终按照表1中的账户状态数据组织成的MPT状态树，参见图4所示；如图4所示，按照表1中的账户状态数据组织成的MPT状态树，是由4个叶子节点，2个分支节点，和2个扩展节点构成。
在图4中，prefix字段为扩展节点和叶子节点共同具有的前缀字段。该prefix字段的取值，在实际应用中可以用于表示节点类型。
prefix字段的取值为0，表示包含偶数个nibbles的扩展节点；如前所述，nibble表示半字节，由4位二进制组成，一个nibble可以对应一个组成账户地址的字符。
prefix字段的取值为1，表示包含奇数个nibble(s)的扩展节点；
prefix字段的取值为2，表示包含偶数个nibbles的叶子节点；
prefix字段的取值为3，表示包含奇数个nibble(s)的叶子节点。
而分支节点，由于其是并列单nibble的前缀节点，因此分支节点不具有上述prefix字段。
扩展节点中的Shared nibble字段，对应该扩展节点所包含的键值对的key值，表示账户地址之间的共同字符前缀；比如，上表中的所有账户地址均具有共同的字符前缀a7。NextNode字段中填充下一个节点的hash值(hash指针)。
分支节点中的16进制字符0～f字段，对应该分支节点所包含的键值对的key值；如果该分支节点为账户地址在MPT树上的搜索路径上的中间节点，则该分支节点的Value字段可以为空值。0～f字段中用于填充下一个节点的hash值。
叶子节点中的Key-end，对应该叶子节点所包含的键值对的key值，表示账户地址的最后几个字符。从根节点搜索到叶子节点的搜索路径上的各个节点的key值，构成了一个完整的账户地址。该叶子节点的Value字段填充账户地址对应的账户状态数据；例如，可以对上述Balance，Nonce，Code和storage等字段构成的结构体进行编号后，填充至叶子节点的Value字段。
进一步的，如图4所示的MPT状态树上的node，最终也是以Key-Value键值对的形式存储在数据库中；
其中，当MPT状态树上的node在数据库中进行存储时，MPT状态树上的node的键值对中的key，为node所包含的数据内容的hash值；MPT状态树上的node的键值对中的Value，为node所包含的数据内容。
也即，在将MPT状态树上的node存储至数据库时，可以计算该node所包含的数据内容的hash值(即对node整体进行hash计算)，并将计算出的hash值作为key，将该node所包含的数据内容作为value，生成Key-Value键值对；然后，将生成的Key-Value键值对存储至数据库中。
由于MPT状态树上的node，是以node所包含的数据内容的hash值为Key，node所包含的数据内容为value进行存储；因此，在需要查询MPT状态树上的node时，通常可以基于node所包含的数据内容的hash值作为key来进行内容寻址。而采用“内容寻址”，对于一些“内容重复”的node，则通常可以进行“复用”，以节约数据存储的存储空间。
如图5所示，图5为本说明书示出的一种MPT状态树上的node复用的示意图。
在实际应用中，区块链每产生一个最新区块，则在该最新区块中的交易被执行之后，区块链中与这些被执行的交易相关账户的账户状态，通常也会随之发生变化；
例如，当区块中的一笔“转账交易”执行完毕后，与该“转账交易”相关的转出方账户和转入方账户的余额(即这些账户的Balance字段的取值)，通常也会随之发生变化。
而节点设备在区块链产生的最新区块中的交易执行完毕后，由于当前区块链中的账户状态发生了变化，因此节点设备需要根据区块链中所有账户当前的账户状态数据，来构建MPT树，用于维护区块链中所有账户的最新状态。
也即，每当区块链中产生一个最新区块，并且该最新区块中的交易执行完毕后，导致区块链中的账户状态发生变化，节点设备都需要基于区块链中所有账户最新的账户状态数据，重新构建一颗MPT树。
换句话说，区块链中每一个区块，都有一个与之对应的MPT状态树；该MPT状态树，维护了在该区块中的交易在执行完毕后，区块链中所有账户最新的账户状态。
而需要说明的是，一个最新区块中的交易执行完毕后，可能仅仅会导致部分账户的账户状态发生变化；因此，在更新MPT状态树时，并不需要基于区块链中所有的账户当前的状态数据，重新构建一颗完整的MPT状态树，而只需要在该最新区块之前的区块对应的MPT状态树的基础上，对部分账户状态发生变化的账户对应的node进行更新即可。而对于MPT状态树上与账户状态未发生变化的账户对应的node而言，由于这些node为发生数据更新，可以直接复用该最新区块之前的区块对应的MPT状态树上相应的node即可。
如图5所示，假设表1中的账户状态数据，为BlockN中的交易执行完毕后，区块链上所有账户的最新账户状态；基于表1中的账户状态数据组织成的MPT状态树，仍如图4所示。
假设当Block N+1中的交易执行完毕后，导致上述表1中的账户地址为“a7f9365”的账户状态，由“state3”更新为“state5”；此时，在Block N+1更新MPT状态树时，并不需要基于BlockN+1中的交易执行完毕后，区块链中所有的账户当前的状态数据，重新构建一颗MPT状态树。
请参见图5，在这种情况下，可以仅将BlockN对应的MPT树上(即图4示出的MPT状态树)，“key-end”为“9365”的叶子节点中的Value，由“state3”更新为“state5”，并继续更新从root节点到该叶子节点的路径上的所有节点的hash指针；也即，当MPT状态树上的叶子节点发生更新，由于该叶子节点整体的hash值发生更新，那么从根节点到该叶子节点的路径上的所有的节点的hash指针也会随之发生更新。例如，请继续参见图5，除了需要更新“key-end”为“9365”的叶子节点中的Value值以外，还需要更新该叶子节点的上一个分支节点(BranchNode)的f字段中填充的，指向该叶子节点的哈希指针；进一步的，还可以继续向根节点追溯，继续更新该分支节点的上一个根节点(Root ExtensionNode)的“NextNode”字段中填充的，指向该分支节点的hash指针。
而除了以上发生更新的节点以外，其它未发生更新的节点，都可以直接复用BlockN的MPT状态树上对应的节点即可；
其中，由于BlockN对应的MPT树，最终需要作为历史数据进行保留；因此，在BlockN+1更新MPT状态树时，对于这些发生更新的node，并不是对BlockN对应的MPT状态树上原来的node的基础上，直接进行修改更新，而是在BlockN+1对应的MPT树上重新创建这些发生更新的node。
也即，对于与BlockN+1对应的MPT状态树上，实际上只需要重新创建少量发生更新的node，对于其它未发生更新的node，可以通过直接复用Block N对应的MPT状态树上对应的节点。
例如，如图5所示，对于BlockN+1对应的MPT状态树上，实际上只需要重新创建少量发生更新的node；比如，图5中仅需要重新创建一个作为根节点的扩展节点、一个分支节点和一个叶子节点；对于未发生更新的node，可以通过在该MPT状态树上这些重新创建的node中，添加指向BlockN对应的MPT状态树上的相应node的hash指针来完成node的复用。而BlockN对应的MPT状态树上那些更新前的node，将作为历史账户状态数据进行保存；比如，图5示出的“key-end”为“9365”，且Value为“state3”的叶子节点，将作为历史数据进行保留。在以上例子中，以BlockN+1的MPT状态树上的少量node发生内容更新，可以“复用”上一个区块BlockN的大多数node为例进行了说明。而在实际应用中，BlockN+1的MPT状态树上也可能会较上一个区块BlockN新增node。
在这种情况下，该新增的node虽然无法直接从上一个区块Block N的MPT树中进行复用，但有可能从更早之前的区块的MPT状态树上进行“复用”；
例如，BlockN+1的MPT状态树上新增的node，虽然在BlockN的MPT状态树上出现过，但出现在更早的Block的MPT状态树上；比如，出现在Block N-1的MPT状态树上；因此，BlockN+1的MPT状态树上新增的node，可以直接复用BlockN-1的MPT状态树上对应的node即可。
以上是现有的区块链中的存储结构说明，下面对本申请中的业务数据区块链的存储结构进行说明。
本说明书公开了业务数据区块链的实现方法，如图1所示，所述实现方法应用于业务数据区块链系统中，所述业务数据区块链系统包括多个区块链节点；该方法包括S101-S102。
本说明书中的实体信息是指对客观事物的抽象，也指具体的客观事物，实体信息包括关联属性和非关联属性，关联属性是指属性值能够增减；用户信息是指用户的描述信息，用户信息包括用户地址；积分信息指用户发行的积分，是除了区块链上原生积分以外的积分信息，积分信息包括积分的名称、总量。
S101、所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据。
在一个示例中，所述用户操作数据为用户在互联网上的操作数据，所述用户操作数据包括存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、线上到线下数据、社交数据、点赞数据、评价数据以及网约车数据中的一种或多种。
在一个示例中，所述用户操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户操作数据的签名以及用户操作数据的哈希值中的一种或多种；其中，所述操作类型包括用户对实体的操作和对积分的操作，所述被操作地址包括对实体的操作地址和其他用户的地址。
举例来说，实体是互联网电子商务平台的商品，用户可以发起购买该商品的操作，就是针对该商品实体对应积分的积分转移操作(即积分从操作用户的地址，转入被操作用户的地址)；用户也可以发起针对该商品的评论或点赞操作，就是针对该商品实体的用户操作。
在一个示例中，所述链上状态数据库存储的状态数据包括用户信息和实体信息状态中一种或两种。
在一个示例中，所述链上状态数据库存储的状态数据包括积分，所述积分数据的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
此时，该积分是用户发行的积分，例如：用户可以通过公证后，将房子证券化后，在区块链上发行一个积分，这个积分在区块链上唯一表示该房产；也可以是，将房子证券化，发行预定数量的积分，拥有该积分即拥有该房子的所有权，享有该房子租赁或者变卖的对等所有权。除此之外，区块链上拥有原生积分，该原生积分可以用于约束用户在区块链上的操作，避免用户无限制的使用区块链系统的资源；例如：区块链上的用户注册后，在区块链上进行操作，需要抵押原生积分，才能将用户操作数据上链。
S102、所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述用户操作状态为用户操作后的全局状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
在一个示例中，所述链上关系数据库存储的关联关系包括实体信息和用户信息的关联关系；其中，一个实体信息对应一个或多个用户信息。
例如：在互联网的电子商务平台(如：淘宝、天猫、京东商城)上，一件商品，有多位不同用户购买；在互联网上的自媒体平台(如：微信、微博)上，一条自媒体数据，多位用户进行了点赞或评论；这类实体与用户之间的一对多关系，可以采用上述实体信息-用户信息的关联关系表达出来。不仅方便了业务数据上链，也方便了用户对业务数据进行查询。
在一个示例中，所述链上关系数据库存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。
此时，一位用户有可能拥有多种积分；例如：一位用户既拥有区块链上的原生积分，还拥有其他类型的积分。上述关联关系能够描述该用户与积分之间的一对多关系，同时也方便该用户查询。需要说明的是，在区块链系统中的用户，至少会拥有该区块链系统的原生积分；有可能拥有其他用户发行或者自己发行的积分。
在一个示例中，所述链上关系数据库存储的关联关系包括实体信息和积分信息的关联关系；其中，一个实体信息对应一个或多个积分信息。
此时，相当于在区块链上，实现了实体的证券化；例如：一件商品的所有权，对应一个积分，积分的转账对应该商品所有权的转移；一套房子的所有权，对应预定数量的积分，拥有积分的数量对应该房子的所有权比例，即拥有该房子出售或者租赁同比例的价款。
如上所述，用户信息(如：Account字段)、积分信息(如：Asset字段)、实体信息(如：Object字段)、实体信息-用户信息(如：Object-Account字段)、用户信息-积分信息(如：Account-Asset字段)、实体信息-积分信息(如：Object-Asset字段)中任意一种状态信息都可以采用MPT状态树来实现，各种MPT状态树的树根存储在区块头中。如图6所示，区块存储的用户操作(如：Action字段)，和链上数据库存储的收据信息(如：Receipt字段)的MPT状态树的树根也存储在区块头中。
需要说明的是，区块链系统中的区块包括区块头和区块体，区块头存储的是摘要信息，区块体存储的是转账信息(也称交易信息)。本说明书中用户操作是存储在区块的区块体中，用户操作的摘要值(也称哈希值)存储在区块头中；本说明书中的链上状态数据库也是区块链系统存储的一部分，每个区块链节点都有链上状态数据库和区块，来存储本说明书中的业务数据。
在一个示例中，所述链上数据库采用支持属性查询的数据库或KV数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。
在一个示例中，所述用户信息和/或所述实体信息的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，所述MPT状态树是融合了前缀树Trie的树形结构的默克尔树Merkle变种，所述默克尔树Merkle为Merkle Patricia Tree状态树。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息以数据表的形式存储在所述支持属性查询的数据库中，以便于用户根据所述数据表中的属性字段进行查询；其中，一种信息对应一种数据表，任意一种数据表中的任意一行对应一条信息，一种信息包括多行信息；所述支持属性查询的数据库包括关系数据库和内存数据库。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息采用KV数据库存储，以键值对的方式进行存储。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，任意一棵MPT状态树的树根存储在区块头中。
在一个示例中，关系树中叶子节点的value以哈希表或数组的方式存储用户信息-积分信息、实体信息-积分信息以及实体信息-用户信息中的一种或多种。
在一个示例中，关系树的叶子节点的value用于存储关系子树的树根，所述关系子树存储用户信息-积分信息、实体信息-积分信息以及实体信息-用户信息中的一种或多种，所述关系子树为默克尔树或MPT树。
上述中，采用MPT状态树的方式存储这些信息，用户可以通过地址信息进行查询；针对用户信息、积分信息和实体信息，直接采用用户地址、积分地址以及实体地址信进行信息查询；针对实体信息-用户信息、用户信息-积分信息以及实体信息-积分信息，分别采用实体地址、用户地址以及实体地址进行信息查询。
此外，用户地址可以根据用户公钥进行多次哈希运算得到；积分地址或实体地址，可以由创建积分或实体的用户操作来得到，例如：对该用户操作进行多次哈希运算，从得到的哈希值中选取预设位数的字符作为积分地址或实体地址。
在一个示例中，所述链上数据库采用支持属性查询的数据库，其中，所述链上数据库包括关系数据库和内存数据库。也就是，将用户信息、积分信息、实体信息、实体信息-用户信息、用户信息-积分信息、实体信息-积分信息中任意一种状态信息采用支持属性查询的数据库进行存储，关系数据库可以采用MySql，内存数据库可以采用MongoDB。
此时，采用支持属性查询的数据库，用户信息、积分信息、实体信息、实体信息-用户信息、用户信息-积分信息以及实体信息-积分信息，都可以采用对应的属性进行查询，相比于在区块链上用地址查询来说，属性查询的查询效率更高。同时，上述信息的MPT状态树根存储在区块头中，如图6所示。在实际的使用中，若上述任意一棵MPT状态树未使用，可以置为空。
本说明书中，用户信息、积分信息、实体信息、实体信息-用户信息、用户信息-积分信息以及实体信息-积分信息中任意一种信息被组织成MPT状态树的数据结构，也就是数据逻辑结构；采用的存储结构可以是KV数据库，例如：LevalDB数据库，也可以采用支持属性查询的MySql和MongoDB数据库，这些数据库是物理的存储结构。
本说明书能够让业务数据上链，让业务数据的各种关联关系也能够上链；业务数据上链的好处包括但不限于真实可信、可溯源、数据权属归属于个人等。
本申请通过区块存储用户操作数据，链上状态数据库存储状态数据和状态关联数据，能够将业务数据的各种属性存储在区块链上，从而解决业务数据上链的问题；此外，链上状态数据库存储的状态数据和状态关联数据，也方便用户进行访问。
此外，需要说明的是，本说明书公开了业务数据上链，采用区块存储的用户操作数据，链上存储的用户信息和实体信息；用户操作数据、用户信息以及实体信息也可以被称为三维数据模型，区别于现有技术中的用户地址和转账余额的二维数据。上述的用户信息、实体信息、积分信息以及它们之间的关联信息，也成为多状态信息；多状态信息的存储上链，也就意味着业务数据的上链。
本说明书还公开了一种业务数据区块链的实现系统，所述业务数据区块链系统包括多个区块链节点，如图2所示。图2中仅仅示出了4个区块链节点，区块链节点的数量不以此为限。
所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；
所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
在一个示例中，所述用户操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户操作数据的签名以及用户操作数据的哈希值中的一种或多种；其中，所述操作类型包括用户对实体的操作和对积分的操作，所述被操作地址包括对实体的操作地址和其他操作用户的地址。
在一个示例中，所述链上状态数据库存储的状态数据包括用户信息和实体信息状态中一种或两种。
在一个示例中，所述用户操作数据为用户在互联网上的操作数据，所述用户操作数据包括存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、线上到线下数据、社交数据、点赞数据、评价数据以及网约车数据中的一种或多种。
在一个示例中，所述链上状态数据库存储的状态数据包括积分数据，所述积分数据的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一个示例中，所述链上关系数据库存储的关联关系包括实体信息和用户信息的关联关系；其中，一个实体信息对应一个或多个用户信息。
在一个示例中，所述链上关系数据库存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。
在一个示例中，所述链上关系数据库存储的关联关系包括实体信息和积分信息的关联关系；其中，一个实体信息对应一个或多个积分信息。
在一个示例中，所述链上数据库采用支持属性查询的数据库或KV数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。
在一个示例中，所述用户信息和/或所述实体信息的属性类型包括关联属性和非关联属性；其中，所述关联属性的属性值根据所述用户操作数据自动增减。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，所述MPT状态树是融合了前缀树Trie的树形结构的默克尔树Merkle变种，所述默克尔树Merkle为Merkle Patricia Tree状态树。
在一个示例中，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织成MPT状态树；其中，任意一棵MPT状态树的树根存储在区块头中。
在一个示例中，所述用户操作数据为用户在互联网上的操作数据，所述用户操作数据包括存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、线上到线下数据、社交数据、点赞数据、评价数据以及网约车数据中的一种或多种。
本申请通过区块存储用户操作数据，链上状态数据库存储状态数据和状态关联数据，能够将业务数据的各种属性存储在区块链上，从而解决业务数据上链的问题；此外，链上状态数据库存储的状态数据和状态关联数据，也方便用户进行访问。
上述装置实施例中与上述方法实施例中相同或相近之处可相互参见，在此不再赘述。
本说明书还公开了一种计算机可读存储介质，该存储介质存储有计算机指令，该计算机指令被处理器执行时，实现如上所述任意一项技术方案。
本说明书还公开了一种电子设备，该电子设备包括处理器，所述处理器用于执行如上所述任意一项技术方案。
与此同时，本申请还提供一种实体装置的实施例。
图3示出了一种计算机设备结构示意图，该计算机设备可以包括：处理器310、存储器320、输入/输出接口330、通信接口340和总线350。其中处理器340、存储器320、输入/输出接口330和通信接口340通过总线350实现彼此之间在设备内部的通信连接。
处理器310可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器320可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器320可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器320中，并由处理器310来调用执行。
输入/输出接口330用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口340用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线350包括一通路，在设备的各个组件(例如处理器310、存储器320、输入/输出接口330和通信接口340)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器310、存储器320、输入/输出接口330、通信接口340以及总线350，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的范围之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.业务数据区块链的实现方法，其特征在于，所述实现方法应用于业务数据区块链系统中，所述业务数据区块链系统包括多个区块链节点；
所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；
所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述用户操作状态为用户操作后的全局状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
2.根据权利要求1所述的实现方法，其特征在于，所述用户操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户操作数据的签名以及用户操作数据的哈希值中的一种或多种；其中，所述操作类型包括用户对实体的操作和对积分的操作，所述被操作地址包括对实体的操作地址和其他操作用户的地址。
3.根据权利要求1所述的实现方法，其特征在于，所述链上状态数据库存储的状态数据包括用户信息和实体信息状态中一种或两种。
4.根据权利要求1或3所述的实现方法，其特征在于，所述链上关系数据库存储的关联关系包括实体信息和用户信息的关联关系；其中，一个实体信息对应一个或多个用户信息。
5.根据权利要求1或3所述的实现方法，其特征在于，所述链上关系数据库存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。
6.根据权利要求1或3所述的实现方法，其特征在于，所述链上关系数据库存储的关联关系包括实体信息和积分信息的关联关系；其中，一个实体信息对应一个或多个积分信息。
7.根据权利要求6所述的实现方法，其特征在于，所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息以数据表的形式存储在所述支持属性查询的数据库中，以便于用户根据所述数据表中的属性字段进行查询；其中，一种信息对应一种数据表，任意一种数据表中的任意一行对应一条信息，一种信息包括多行信息；所述支持属性查询的数据库包括关系数据库和内存数据库；或
所述用户信息、所述实体信息、所述积分信息、所述用户信息-所述积分信息、所述实体信息-所述积分信息以及所述实体信息-所述用户信息中的任意一种信息采用KV数据库存储，以键值对的方式进行存储。
8.根据权利要求1所述的实现方法，其特征在于，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织到MPT树或默克尔树；其中，所述MPT树是融合了前缀树Trie的树形结构的默克尔树变种，所述默克尔树为Merkle Patricia Tree树。
9.根据权利要求8所述的实现方法，其特征在于，所述用户信息、所述实体信息、所述积分信息、所述实体信息-用户信息、所述用户信息-积分信息以及所述实体信息-积分信息中的任意一种信息被组织到MPT树或默克尔树；其中，任意一棵树的树根存储在区块头中。
10.业务数据区块链的实现系统，其特征在于，所述业务数据区块链系统包括多个区块链节点，
所述区块链节点采用区块存储和链上数据库存储的方式存储业务数据；其中，所述区块存储用于存储用户操作数据，所述链上数据库存储用于存储用户操作的状态数据；
所述链上数据库存储包括链上状态数据库和链上关系数据库；其中，所述链上状态数据库用于存储用户操作状态，所述链上关系数据库用于存储用户操作后全局状态之间的关联关系。
CN202010270331.2A 2020-04-08 2020-04-08 业务数据区块链的实现方法及其系统 Pending CN111695136A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010270331.2A CN111695136A (zh) 2020-04-08 2020-04-08 业务数据区块链的实现方法及其系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010270331.2A CN111695136A (zh) 2020-04-08 2020-04-08 业务数据区块链的实现方法及其系统

Publications (1)

Publication Number Publication Date
CN111695136A true CN111695136A (zh) 2020-09-22

Family

ID=72476353

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010270331.2A Pending CN111695136A (zh) 2020-04-08 2020-04-08 业务数据区块链的实现方法及其系统

Country Status (1)

Country Link
CN (1) CN111695136A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112988911A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN113420325A (zh) * 2021-06-07 2021-09-21 北京许继电气有限公司 一种基于区块链技术的物联网数据管理系统和方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112988911A (zh) * 2021-05-07 2021-06-18 支付宝(杭州)信息技术有限公司 区块链数据存储方法及装置、电子设备
CN113420325A (zh) * 2021-06-07 2021-09-21 北京许继电气有限公司 一种基于区块链技术的物联网数据管理系统和方法

Similar Documents

Publication Publication Date Title
CN111488396B (zh) 业务数据区块链的数据同步方法及装置
CN111488614A (zh) 基于业务数据区块链的数字身份存储方法及装置
CN111737726A (zh) 基于业务数据区块链的关系数据查询方法及装置
CN111488608A (zh) 业务数据区块链的数据验证方法及装置
CN111694837A (zh) 基于业务数据区块链的共享数据存储方法及装置
CN111695136A (zh) 业务数据区块链的实现方法及其系统
CN111488610A (zh) 基于业务数据区块链的状态数据查询方法及装置
CN111488611B (zh) 业务数据区块链的关系数据存储方法及装置
CN111488607A (zh) 业务数据区块链的数据处理方法及其装置
CN111523137A (zh) 基于业务数据区块链的数据推荐方法及装置
CN111695137A (zh) 基于业务数据区块链的旅游数据存储方法及系统
CN111695139A (zh) 基于业务数据区块链的知识问答数据存储方法及系统
CN111737728A (zh) 基于业务数据区块链的自媒体数据存储方法及系统
CN111488606B (zh) 基于业务数据区块链的数据共享方法及装置
CN111488356A (zh) 业务数据区块链的数据存储方法及其装置
CN111695132A (zh) 基于业务数据区块链的投票数据存储方法及系统
CN111488345A (zh) 业务数据区块链的存储优化方法及装置
CN111488352A (zh) 基于业务数据区块链的积分兑换方法及装置
CN111737733A (zh) 业务数据区块链的实现方法及其系统
CN111488605A (zh) 业务数据区块链的数据上链方法及装置
CN111737732A (zh) 基于业务数据区块链的合约数据存储方法及装置
CN111488612A (zh) 基于业务数据区块链的状态数据查询方法及装置
CN111695135A (zh) 基于业务数据区块链的关系数据查询方法及装置
CN111695134A (zh) 基于业务数据区块链的搜索数据存储方法及系统
CN111738719A (zh) 基于业务数据区块链的跨境支付数据存储方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20200922