基于业务数据区块链的社区数据存储方法及系统与流程

本发明涉及互联网大数据技术领域，公开一种基于业务数据区块链的社区数据存储方法及系统。

背景技术：

目前，区块链技术是运用加密算法、共识机制等技术的分布式存储账本。随着区块链技术的运用，越来越多的互联网数据会存储在区块链上。

现有的区块链中，只能存储交易数据，交易数据包括转账方地址、接收方地址以及转账金额；针对各种业务数据(例如：存证数据、溯源数据、金融数据、旅游数据、搜索数据、自媒体数据、调研数据、广告数据、电商数据、社区数据、知识问答数据、知识付费数据、共享单车数据、招聘数据、生活服务数据、租房数据、投票数据、oto数据(也称为线上到线下数据)、社交数据、点赞数据、评价数据、网约车数据等互联网相关数据)而言，不仅需要在区块链上表达出数据本身，还需要在区块链上表达出数据之间的关联关系。

因此，如何实现在区块链上存储社区数据，成为亟待解决的问题。

以上描述仅仅为了方便理解，并不应限定为本申请的现有技术。

技术实现要素：

基于上述问题，本申请提供一种基于业务数据区块链的社区数据存储方法及其系统，该方法通过在业务区块链上存储用户社区操作数据，实现用户社区操作数据的上链。

本申请第一方面公开了一种基于业务数据区块链的社区数据存储方法，所述方法应用于业务数据区块链的社区数据存储系统中，所述业务数据区块链的社区数据存储系统包括多个社区区块链节点；包括：

社区区块链节点接收社区客户端发送用户社区操作数据上链请求；

通过链式结构和树形结构存储用户社区数据；其中，所述用户社区数据包括用户社区操作数据和用户社区操作后的状态数据，所述链式结构用于存储用户社区操作数据，所述树形结构用于存储用户社区操作后的状态数据；所述树形结构包括状态树和关系树，所述状态树用于存储用户社区操作数据的全局状态，所述全局状态为用户社区操作后的全局状态，所述关系树用于存储用户社区操作后全局状态之间的关联关系；所述链式结构为区块的链式存储结构；

发送用户所述操作数据上链响应给所述社区客户端。

在一种可能的实施方式中，所述用户社区操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户社区操作数据的签名以及用户社区操作数据的哈希值中的一种或多种；其中，

所述社区数据操作类型包括用户对社区数据的操作和对积分的操作，所述被操作地址包括对社区数据的操作地址和其他社区数据操作用户的地址。

在一种可能的实施方式中，所述状态树存储的用户社区操作数据全局状态包括用户信息、社区数据以及积分数据中的一种或多种。

在一种可能的实施方式中，所述关系树存储的关联关系包括用户社区操作数据和用户信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个用户信息；和/或

所述关系树存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息；和/或

所述关系树存储的关联关系包括用户社区操作数据信息和积分信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个积分信息。

在一种可能的实施方式中，所述树形结构采用支持属性查询的数据库或kv数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。

在一种可能的实施方式中，所述用户信息、所述用户社区操作数据、所述积分信息、所述用户社区操作数据-用户信息、所述用户信息-积分信息以及所述用户社区操作数据-积分信息中的任意一种信息被组织到mpt树或默克尔树；其中，

任意一棵树的树根存储在区块头中，所述mpt树是融合了前缀树的树形结构的默克尔树变种，所述默克尔树为merklepatriciatree树。

在一个示例中，所述关系树中叶子节点存储关系子树的树根，所述关系子树叶子节点的value存储用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中一种或多种；或

所述关系树中叶子节点的value以数组或哈希表的方式存储用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中一种或多种。

在一个示例中，所述用户信息、所述实体信息、所述积分信息、用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中任意一种信息以数据表的形式存储在支持属性查询的数据库中，以便于用户根据所述数据表中的属性字段进行查询；其中，一种信息对应一种数据表，任意一种数据表中的任意一行对应一条信息，一种信息包括多行信息。

本申请第二方面公开了一种基于业务数据区块链的社区数据存储系统，所述业务数据区块链的社区数据存储系统包括多个社区区块链节点；所述社区区块链节点包括接收单元、处理单元以及发送单元；其中，

所述接收单元，接收社区客户端发送用户社区操作数据上链请求；

所述处理单元，通过链式结构和树形结构存储用户社区数据；其中，所述用户社区数据包括用户社区操作数据和用户社区操作后的状态数据，所述链式结构用于存储用户社区操作数据，所述树形结构用于存储用户社区操作后的状态数据；所述树形结构包括状态树和关系树，所述状态树用于存储用户社区操作数据的全局状态，所述全局状态为用户社区操作后的全局状态，所述关系树用于存储用户社区操作后全局状态之间的关联关系；所述链式结构为区块的链式存储结构；

所述发送单元，发送用户所述操作数据上链响应给所述社区客户端。

在一种可能的实施方式中，所述用户社区操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户社区操作数据的签名以及用户社区操作数据的哈希值中的一种或多种；其中，

所述社区数据操作类型包括用户对社区数据的操作和对积分的操作，所述被操作地址包括对社区数据的操作地址和其他社区数据操作用户的地址。

在一种可能的实施方式中，所述状态树存储的用户社区操作数据全局状态包括用户信息、社区数据以及积分数据中的一种或多种。

在一种可能的实施方式中，所述关系树存储的关联关系包括用户社区操作数据和用户信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个用户信息；和/或

所述关系树存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息；和/或

所述关系树存储的关联关系包括用户社区操作数据信息和积分信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个积分信息。

在一种可能的实施方式中，所述树形结构采用支持属性查询的数据库或kv数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。

在一种可能的实施方式中，所述用户信息、所述用户社区操作数据、所述积分信息、所述用户社区操作数据-用户信息、所述用户信息-积分信息以及所述用户社区操作数据-积分信息中的任意一种信息被组织到mpt树或默克尔树；其中，

任意一棵树的树根存储在区块头中，所述mpt树是融合了前缀树的树形结构的默克尔树变种，所述默克尔树为merklepatriciatree树。

本申请第三方面提供一种计算机可读存储介质，该存储介质存储有计算机指令，该计算机指令被处理器执行时，实现如上所述任意一项技术方案。

本申请第四方面提供一种电子设备，该电子设备包括处理器，所述处理器用于执行如上所述任意一项技术方案。

本申请通过在业务数据区块链上存储用户社区操作数据，实现用户社区操作数据的上链；同时，业务数据区块链中采用链式存储和树形存储的方式，方便了用户社区操作数据的查询，提升了查询效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请公开了一种基于业务数据区块链的社区数据存储方法流程示意图；

图2为本申请公开了一种业务数据区块链系统的结构示意图；

图3为本申请公开了一种基于业务数据区块链的社区数据存储结构示意图；

图4为现有的一种将区块链的账户状态数据组织成mpt状态树的示意图；

图5为现有的一种mpt状态树上的节点node复用的示意图；

图6为本申请公开了一种业务数据区块链系统中区块头结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请中的“第一”“第二”仅仅是便于理解，给技术词做区分，并不理解为先后，或作为限制性的理解。

为便于对本发明实施例的理解，下面将结合附图以具体实施例作进一步的解释说明，实施例并不构成对本发明实施例的限定。

区块链一般被划分为三种类型：公有链(publicblockchain)，私有链(privateblockchain)和联盟链(consortiumblockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。

而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。

基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。

对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备进行共识，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。

在区块链领域，有一个重要的概念就是账户(account)；以以太坊为例，以太坊通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。

当然，对于一些基于以太坊的架构而衍生出的区块链项目，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。

对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。

以以太坊为例，账户的结构体通常包括balance，nonce，code和storage等字段。其中：

balance字段，用于维护账户目前的账户余额；

nonce字段，用于该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击。

code字段，用于维护该账户的合约代码；在实际应用中，code字段中通常仅维护合约代码的hash值；因而，code字段通常也称之为codehash字段。对于外部账户而言，该字段为空值。

storage字段，用于维护该账户的存储(默认为空)。在实际应用中，storage字段仅维护基于账户的存储内容构建的mpt(merklepatriciatrie)树的根节点；因此，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)，扩展节点(extensionnode)和分支节点(branchnode)。

叶子节点，表示为[key，value]的一个键值对，其中key是种特殊十六进制编码。

扩展节点，也是[key，value]的一个键值对，但是这里的value是其他节点的hash值(hash指针)。也就是说通过hash指针链接到其他节点。

分支节点，因为mpt树中的key被编码成一种特殊的16进制的表示，再加上最后的value，所以分支节点是一个长度为17的list，前16个元素对应着key中的16个可能的十六进制字符(一个字符对应一个半字节nibble)。如果有一个[key，value]对在这个分支节点终止，最后一个元素代表一个value值，即分支节点既可以是社区路径的终止也可以是路径的中间节点。

假设需要组织成mpt状态树的账户状态数据如下表1所示:

表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字段。

扩展节点中的sharednibble字段，对应该扩展节点所包含的键值对的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所示。

假设当blockn+1中的交易执行完毕后，导致上述表1中的账户地址为“a7f9365”的账户状态，由“state3”更新为“state5”；此时，在blockn+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字段中填充的，指向该叶子节点的哈希指针；进一步的，还可以继续向根节点追溯，继续更新该分支节点的上一个根节点(rootextensionnode)的“nextnode”字段中填充的，指向该分支节点的hash指针。

而除了以上发生更新的节点以外，其它未发生更新的节点，都可以直接复用blockn的mpt状态树上对应的节点即可；

其中，由于blockn对应的mpt树，最终需要作为历史数据进行保留；因此，在blockn+1更新mpt状态树时，对于这些发生更新的node，并不是对blockn对应的mpt状态树上原来的node的基础上，直接进行修改更新，而是在blockn+1对应的mpt树上重新创建这些发生更新的node。

也即，对于与blockn+1对应的mpt状态树上，实际上只需要重新创建少量发生更新的node，对于其它未发生更新的node，可以通过直接复用blockn对应的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虽然无法直接从上一个区块blockn的mpt树中进行复用，但有可能从更早之前的区块的mpt状态树上进行“复用”；

例如，blockn+1的mpt状态树上新增的node，虽然在blockn的mpt状态树上出现过，但出现在更早的block的mpt状态树上；比如，出现在blockn-1的mpt状态树上；因此，blockn+1的mpt状态树上新增的node，可以直接复用blockn-1的mpt状态树上对应的node即可。

以上是现有的区块链中的存储结构说明，下面对本申请中的业务数据区块链的存储结构进行说明。

本说明书公开了基于业务数据区块链的社区数据存储方法，如图1所示，所述方法应用于业务数据区块链的社区数据存储系统中，所述业务数据区块链的社区数据存储系统包括多个社区区块链节点；该方法包括s101-s102。

本说明书中的用户信息、用户社区数据以及积分数据均包括关联属性和非关联属性，关联属性是指属性值能够增减；用户信息是指用户的描述信息，用户信息包括用户地址；积分信息指用户发行的积分，是除了区块链上原生积分以外的积分信息，积分信息包括积分的名称、总量。

此外，本说明书中的业务数据区块链是指包括链式存储结构和树形存储结构，且用于存储业务数据的区块链。

并且，本说明书中，对于用户社区操作数据的打包成区块，完成共识验证等流程没有做出说明，可以采用常用的数据上链方式。

s101、社区区块链节点接收社区客户端发送用户社区操作数据上链请求。

在一个示例中，所述用户社区操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户社区操作数据的签名以及用户社区操作数据的哈希值中的一种或多种；其中，所述社区数据操作类型包括用户对社区数据的操作和对积分的操作，所述被操作地址包括对社区数据的操作地址和其他社区数据操作用户的地址。

需要说明的是，本说明书中，客户端可以是服务器，也可以是用户设备。

s102、通过链式结构和树形结构存储用户社区数据；其中，所述用户社区数据包括用户社区操作数据和用户社区操作后的状态数据，所述链式结构用于存储用户社区操作数据，所述树形结构用于存储用户社区操作后的状态数据；所述树形结构包括状态树和关系树，所述状态树用于存储用户社区操作数据的全局状态，所述全局状态为用户社区操作后的全局状态，所述关系树用于存储用户社区操作后全局状态之间的关联关系；所述链式结构为区块的链式存储结构。

s103、发送用户所述操作数据上链响应给所述社区客户端。

在一个示例中，所述状态树存储的用户社区操作数据全局状态包括用户信息、社区数据以及积分数据中的一种或多种。

在一个示例中，所述关系树存储的关联关系包括用户社区操作数据信息和用户信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个用户信息。

举例来说，用户社区操作数据包括对社区贴子的浏览、收藏、点击、评论等。拿评论来说，针对同一个社区贴子，不同的用户进行评论；该贴子对应着不同用户，这类对应关系存储在区块链上，不能被篡改，保证了社区数据的真实性，现对于现有的中心化数据库更加可信。

在一个示例中，所述关系树存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息。

在社区中，用户可以设置贴子的查看权限，只有拥有一定数量积分的用户，才能够查看该贴子。这里的积分对应于该贴子的查看权限，不同种类的贴子对应不同种类的积分，也可以都对应相同的积分类型。故一位用户可以拥有多种积分，这种对应关系状态的存储，便于用户自身查询。

在一个示例中，所述关系树存储的关联关系包括用户社区操作数据信息和积分信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个积分信息。

用户社区操作数据可以是自己发布的贴子的查看权限，对应一个或多个积分。当其他用户想看该贴子内容时，就需要拥有该积分；整个操作过程全部存储在区块链上，不能篡改，保证真实。该积分可以是其他用户参加该发行贴子用户的活动来获得。

此外，积分的获得可以通过抵押原生积分来获得。原生积分是使用区块链系统所需的积分，只有抵押原生积分，用户才能够使用区块链系统的网络和存储资源；原生积分也能够避免用户无限制的使用区块链系统的网络资源，造成区块链系统资源的浪费。此时，用户转移积分，就相当于转移发社区操作的权限。

在一个示例中，所述树形结构采用支持属性查询的数据库或kv数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。

该关系数据库可以是mysql数据库，内存数据库可以是mongodb数据库；采用支持属性查询的数据库存储用户操作社区数据时，方便用户通过属性字段查询，提升用户查询的效率。

当采用kv数据库时，例如采用key-value数据库，查询时需要通过地址查询；例如：用户信息根据用户地址进行查询，用户社区操作数据根据用户社区操作地址查询，用户积分数据根据积分地址查询；用户信息-积分信息需要根据用户地址进行查询，用户社区操作数据信息-积分信息需要根据用户社区操作数据地址进行查询，用户社区操作数据信息-用户信息需要根据用户社区操作数据地址进行查询。

需要指出的是，用户信息的地址可以根据用户公钥进行多次哈希运算后得到；用户社区操作数据地址或积分地址，均可以根据用户创建积分操作或者发起用户社区操作进行哈希运算后，取运算结果的预定前几位字符得到。

在一个示例中，所述用户信息、所述用户社区操作数据信息、所述积分信息、所述用户社区操作数据信息-用户信息、所述用户信息-积分信息以及所述用户社区操作数据信息-积分信息中的任意一种信息被组织成mpt状态树；其中，任意一棵mpt状态树的树根存储在区块头中(如图6所示)，所述mpt状态树是融合了前缀树trie的树形结构的默克尔树merkle变种，所述默克尔树merkle为merklepatriciatree状态树。

在一个示例中，所述关系树中叶子节点存储关系子树的树根，所述关系子树叶子节点的value存储用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中一种或多种；或

所述关系树中叶子节点的value以数组或哈希表的方式存储用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中一种或多种。

在一个示例中，所述用户信息、所述实体信息、所述积分信息、用户信息-积分信息、实体信息-用户信息以及实体信息-积分信息中任意一种信息以数据表的形式存储在支持属性查询的数据库中，以便于用户根据所述数据表中的属性字段进行查询；其中，一种信息对应一种数据表，任意一种数据表中的任意一行对应一条信息，一种信息包括多行信息。

图6中action表示用户社区操作，account表示用户信息，asset表示积分，object表示用户社区操作数据，object-asset表示用户社区操作数据-用户信息的关联关系，account-asset表示用户信息-积分信息的关联关系，object-asset表示用户社区操作数据-积分信息的关联关系。root表示树根。简要来说，区块包括区块头和区块体，图6中所示的mpt状态树的树根是存储在区块头中。

本申请通过在业务数据区块链上存储用户社区操作数据，实现用户社区操作数据的上链；同时，业务数据区块链中采用链式存储和树形存储的方式，方便了用户社区操作数据的查询，提升了查询效率。

本说明书还公开了基于业务数据区块链的社区数据存储系统，如图2所示。实际中，区块链节点的数量并不以此为限。所述业务数据区块链的社区数据存储系统包括多个社区区块链节点；所述社区区块链节点包括接收单元、处理单元以及发送单元。

所述接收单元，接收社区客户端发送用户社区操作数据上链请求。

所述处理单元，通过链式结构和树形结构存储用户社区数据；其中，所述用户社区数据包括用户社区操作数据和用户社区操作后的状态数据，所述链式结构用于存储用户社区操作数据，所述树形结构用于存储用户社区操作后的状态数据；所述树形结构包括状态树和关系树，所述状态树用于存储用户社区操作数据的全局状态，所述全局状态为用户社区操作后的全局状态，所述关系树用于存储用户社区操作后全局状态之间的关联关系；所述链式结构为区块的链式存储结构。

所述发送单元，发送用户所述操作数据上链响应给所述社区客户端。

在一个示例中，所述用户社区操作数据包括时间戳、操作用户地址、被操作地址、操作类型、操作的值、积分地址、用户对用户社区操作数据的签名以及用户社区操作数据的哈希值中的一种或多种；其中，

所述社区数据操作类型包括用户对社区数据的操作和对积分的操作，所述被操作地址包括对社区数据的操作地址和其他社区数据操作用户的地址。

在一个示例中，所述状态树存储的用户社区操作数据全局状态包括用户信息、社区数据以及积分数据中的一种或多种。

在一个示例中，所述关系树存储的关联关系包括用户社区操作数据和用户信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个用户信息；和/或

所述关系树存储的关联关系包括用户信息和积分信息的关联关系；其中，一个用户信息对应一个或多个积分信息；和/或

所述关系树存储的关联关系包括用户社区操作数据信息和积分信息的关联关系；其中，一个用户社区操作数据信息对应一个或多个积分信息。

在一个示例中，所述树形结构采用支持属性查询的数据库或kv数据库，其中，所述支持属性查询的数据库包括关系数据库和内存数据库。

在一个示例中，所述用户信息、所述用户社区操作数据、所述积分信息、所述用户社区操作数据-用户信息、所述用户信息-积分信息以及所述用户社区操作数据-积分信息中的任意一种信息被组织到mpt树或默克尔树；其中，

任意一棵树的树根存储在区块头中，所述mpt树是融合了前缀树的树形结构的默克尔树变种，所述默克尔树为merklepatriciatree树。

本申请通过在业务数据区块链上存储用户社区操作数据，实现用户社区操作数据的上链；同时，业务数据区块链中采用链式存储和树形存储的方式，方便了用户社区操作数据的查询，提升了查询效率。

上述装置实施例中与上述方法实施例中相同或相近之处可相互参见，在此不再赘述。

本说明书还公开了一种计算机可读存储介质，该存储介质存储有计算机指令，该计算机指令被处理器执行时，实现如上所述任意一项技术方案。

本说明书还公开了一种电子设备，该电子设备包括处理器，所述处理器用于执行如上所述任意一项技术方案。

与此同时，本申请还提供一种实体装置的实施例。

图3示出了一种计算机设备结构示意图，该计算机设备可以包括：处理器310、存储器320、输入/输出接口330、通信接口340和总线350。其中处理器340、存储器320、输入/输出接口330和通信接口340通过总线350实现彼此之间在设备内部的通信连接。

处理器310可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器320可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器320可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器320中，并由处理器310来调用执行。

输入/输出接口330用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口340用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线350包括一通路，在设备的各个组件(例如处理器310、存储器320、输入/输出接口330和通信接口340)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器310、存储器320、输入/输出接口330、通信接口340以及总线350，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的范围之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。