CN117521157A - Multi-party data sharing cooperation method and system based on license chain - Google Patents

Abstract

The invention relates to the technical field of blockchains and discloses a multi-party data sharing cooperation method and system based on a license chain. The full-node replication mode is beneficial to ensuring the integrity, the decentralization and the attack resistance of the data, and can improve the safety of the data and the usability of the system in the collaboration and sharing process.

Description

Multi-party data sharing cooperation method and system based on license chain

Technical Field

The invention relates to the technical field of blockchains, in particular to a multi-party data sharing cooperation method and system based on a license chain.

Background

With the advent of smart contracts, blockchain platforms are being applied to many other scenarios beyond cryptocurrency, and include government, medical health, and internet of things scenarios. These scenarios all have in common that blockchains are used to provide shared data access for parties that are not trusted with each other. However, blockchains are not used as shared databases for two different reasons: first, one major obstacle is their limited scalability and performance. Second, blockchains lack an easy-to-use programming interface, such as a simple query interface, and other guarantees, such as good consistency in design.

As the scale of web applications grows larger, the data sets grow larger and more data types. To address this challenge, the distributed database, data and computation are distributed across multiple nodes to achieve high availability and scalability. Distributed databases typically have rich and easy-to-use connection, storage, query, update, and other operational interfaces. However, the distributed database has some drawbacks, such as inconvenient data sharing, to-be-reinforced data security and integrity check, data tracing, weaker data consistency guarantee, and the like.

Thus, the characteristics of the blockchain and the distributed database form a complementary advantage to a large extent. Recently, research work on fusion design of blockchains and databases has begun to appear and is becoming a trend. The fusion of the two may bring some benefits: (1) Providing verifiable data storage and access services using the security features of the blockchain; (2) The performance and usability advantages of the distributed database are utilized, and more efficient and convenient data service is provided; (3) Thanks to the disclosure and traceability of the blockchain, data sharing and collaboration can be performed in an untrusted multi-party environment. The method of implementing the two-way fusion design may be to start with a blockchain (or a blockchain-like system) and build database properties on top of it. However, the data of the fusion system in the prior art is poor in security in the process of collaboration and sharing, and when a blockchain is used as a database, the usability of the system is poor due to the lack of a simple and easy-to-use operation interface.

Disclosure of Invention

The invention provides a multi-party data sharing cooperation method and system based on a permission chain, which are used for solving the problems of poor safety and poor usability of a system in the cooperation and sharing process of data of a fusion system in the prior art.

In order to achieve the above object, the present invention is realized by the following technical scheme:

in a first aspect, the present invention provides a license chain-based multi-party data sharing collaboration method, including:

the service provider node receives a data request sent by a client through a connection pool of a database layer;

if the type of the data request is a query request, searching in a cache pool, a collaboration table related chain and a data chain until the data corresponding to the data request is found and returned to the client;

if the type of the data request is an update request, the following steps are executed:

s1: carrying out transaction pool processing;

s2: each service provider node continuously acquires the transaction from the transaction pool and puts the transaction into a new block, and when the number of the transaction in the block reaches the set upper limit, the service provider node selected as a member of the block verification committee agrees with the block proposed by the block proposer;

s3: the block proposer distributes the block to all other nodes in the group, the other nodes perform integrity verification again on the block, the block is added into the ledger after passing, and meanwhile, the transaction pool is updated.

In a second aspect, the present application provides a license chain-based multi-party data sharing collaboration system, including a storage layer and a database layer built on the storage layer;

the storage layer comprises a transaction pool, and the database layer comprises a cache pool, a history queue, an index table and a connection pool; the storage layer is communicated with the database layer through the transaction pool, and the database layer is communicated with the client through the connection pool.

The beneficial effects are that:

according to the multi-party data sharing cooperation method based on the license chain, a storage layer is designed based on the blockchain technology, and data participating in cooperation and sharing can be copied to all the peer points in the storage layer so as to ensure the consistency of data states. The full-node replication mode is beneficial to ensuring the integrity, the decentralization and the attack resistance of the data, and can improve the safety of the data and the usability of the system in the collaboration and sharing process.

In a further scheme, a secure consensus mechanism based on a secret random leader election scheme using a verifiable random function VRF is provided for a storage layer, so that efficient consensus can be guaranteed under the condition that malicious nodes are less than 1/3, and a selected leader cannot be revealed until the agreement is agreed, so that a targeted attack cannot be initiated on a consensus block before the agreement is agreed, and the security of a system can be further guaranteed.

In a further technical scheme, a three-level query mechanism of cache pool query, history queue query and index table query is provided, so that query efficiency can be improved.

Drawings

FIG. 1 is a schematic diagram of a typical application scenario of a preferred embodiment of the present invention;

FIG. 2 is a flowchart of a multi-party data sharing collaboration method based on a license chain in accordance with a preferred embodiment of the present invention;

FIG. 3 is a diagram of throughput and delay versus the number of different clients in accordance with a preferred embodiment of the present invention;

FIG. 4 is a diagram showing throughput and delay versus the number of different servers in accordance with a preferred embodiment of the present invention;

FIG. 5 is a diagram showing throughput and delay versus size for different blocks in accordance with a preferred embodiment of the present invention;

FIG. 6 is a graph showing throughput versus key size for a preferred embodiment of the present invention;

FIG. 7 is a graph showing throughput versus different transaction delays in accordance with a preferred embodiment of the present invention;

FIG. 8 is a block diagram of a multi-party data sharing collaboration system based on a license chain in accordance with a preferred embodiment of the present invention.

Detailed Description

The following description of the present invention will be made clearly and fully, and it is apparent that the embodiments described are only some, but not all, of the embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Unless defined otherwise, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this invention belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. Likewise, the terms "a" or "an" and the like do not denote a limitation of quantity, but rather denote the presence of at least one. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", etc. are used merely to indicate a relative positional relationship, which changes accordingly when the absolute position of the object to be described changes.

It is understood that the multiparty data sharing collaboration method based on the license chain can be oriented to safe and efficient data sharing and collaboration scenes among different service providers. For example, order data between e-commerce and logistics commerce cooperate, patient medical record data sharing between different hospitals, data exchange between different internet of things devices, and the like. The system adds database characteristics on the blockchain to form a novel safe collaboration database facing the granularity of the data table. But unlike existing similar schemes, the present application does not build new databases on existing blockchain platforms, but instead implements the blockchain storage layer, database layer, and application-oriented client programs from bottom to top.

It should be noted that, as shown in fig. 1, a typical application scenario of the system is composed of two types of entities: a group of data storage servers belonging to different service providers, and a corresponding group of clients that can query and update data without storing the data itself. Different service providers represent different interested entities and lack trust with each other. However, data collaboration and sharing is often required between these untrusted providers, such as when a user submits a new order through the e-commerce platform, which adds a new entry to the order form. The product supplier then processes the order, checks the product inventory in the order, and changes the status of the order to a ready state. Once the order is ready, the logistics business begins its operations, tracks the logistics process of the product in real time, and updates the status of the order. In such a scenario, three untrusted parties, e-commerce, product vendor and logistics, share access to the same database. Based on this, the present application needs to solve the problem of how to construct a hybrid blockchain database to enable a group of multiple untrusted servers related to a client user to effectively perform data sharing and collaboration, so as to break the data barrier and provide an efficient, convenient, safe and reliable integrated data service mode for the user.

Referring to fig. 2, the license chain-based multi-party data sharing collaboration method provided by the present application is applied to a license chain-based multi-party data sharing collaboration system, where the system includes a storage layer and a database layer connected with the storage layer, and the storage layer is a blockchain-based storage layer, and the method is characterized in that:

the service provider node receives a data request sent by a client through a connection pool of a database layer;

if the type of the data request is a query request, searching in a cache pool, a collaboration table related chain and a data chain until the data corresponding to the data request is found and returned to the client;

if the type of the data request is an update request, the following steps are executed:

s1: carrying out transaction pool processing;

s2: each service provider node continuously acquires the transaction from the transaction pool and puts the transaction into a new block, and when the number of the transaction in the block reaches the set upper limit, the service provider node selected as a member of the block verification committee agrees with the block proposed by the block proposer;

s3: the block proposer distributes the block to all other nodes in the group, the other nodes perform integrity verification again on the block, the block is added into the ledger after passing, and meanwhile, the transaction pool is updated.

It should be noted that, the block proposer is a node that proposes a block, and some of the nodes in the server node will be selected as the block proposer in one round.

According to the multiparty data sharing cooperation method based on the license chain, the storage layer is designed based on the blockchain technology, and data participating in cooperation and sharing can be copied to all the peer points in the storage layer so as to ensure the consistency of the data state. The full-node replication mode is beneficial to ensuring the integrity, the decentralization and the attack resistance of the data, and can improve the safety of the data and the usability of the system in the collaboration and sharing process.

Specifically, the service provider node receives and processes data update and query requests sent by the affiliated clients through the connection pool. If the data is the query request, sequentially searching in the cache pool, the relevant chain of the collaboration table and the data chain until the data is found, and returning the query result to the client. If none of the three are found, an error is returned to the client. If the update request is received, the following processing flow is entered:

(1) And (5) processing a transaction pool. And putting the data corresponding to the update request into a transaction pool of the affiliated service provider node, broadcasting the data to the transaction pools of other service provider nodes in the group, and synchronizing the data to keep consistency. It should be noted in particular that rights checking and transaction verification are also required before the transaction enters the transaction pool. The entitlement check is implemented by an entitlement chain, which is a blockchain that stores the user's access entitlements to the collaboration table, but to ensure the efficiency of the consensus, a non-Bayesian fault tolerance (CFT) consensus algorithm, lift, is used here. The purpose of the transaction verification is to verify the validity of the transaction source and the integrity of the transaction data by utilizing a Hash algorithm and an asymmetric encryption method.

In this embodiment, the transaction pool is a container that temporarily stores the transaction to be validated. In the system, each data update request from a client contains data that is treated as a transaction. The composition and description of the transaction is shown in table 1. Including the ID of the transaction, the ID of the data, the key-value pair, the transaction producer, the timestamp of the transaction, the public key of the transaction producer, and the signature. Wherein the key and the value form data of the transaction, the transaction data ID is a hash value of the data, and the uniqueness of the key in the same table is ensured. Table is a collaboration Table for data storage. Signature is the data Signature generated by the transaction generator after hashing the data using its own private key. Each server node maintains a pool of transactions to process transaction requests sent by the affiliated clients.

Table 1 field description of transactions

Field name	Description of the invention
		TxID	The ID of the transaction is a hash of the transaction, i.e., a digest.
DataID	ID of transaction data, which is hash of data
		Table	A table in which data is to be stored.
Key	And (3) key of the data.
		Value	Value of the data.
Producer	The producer of the transaction.
		TimeStamp	A timestamp of the transaction is generated.
PublicKey	A public key of the transaction producer.
		Signature	Signature of transaction producer.

When implemented, the transaction pool has the following processing flow:

firstly, when a client sends a data update request, a server node to which the client belongs analyzes the content in the request, invokes a permission checking function, judges whether the user has permission to update data of a collaboration table, if not, writes the data into the local of the server node to which the client belongs, and returns a processing result. If yes, the data carried in the request is packaged into a transaction and initialized, and the original text of the transaction is obtained.

Then, the hash function is used for carrying out hash processing on the transaction to generate a digest, an elliptic curve encryption algorithm is used for generating a pair of public key and private key for a transaction producer, and the private key is used for carrying out digital signature on the digest to obtain a signature. The transaction generator encapsulates the signature and public key together into a transaction, which is broadcast to other server nodes for verification.

Then, after receiving the transaction, the other service provider nodes firstly decrypt the signature by using the public key to check the validity of the source of the transaction, and after the decryption is successful, a digest is obtained and recorded as R.dig. Then, the same hash function as the transaction producer is utilized to carry out hash processing on the analyzed Tx, and a new digest N.dig is obtained. Next, n.dig and r.dig are compared, and if they are the same, it is explained that the transaction data is complete, and each server node adds the transaction to its own transaction pool and sorts it by the transaction generation time stamp.

Finally, if a new block is generated, the transactions contained in the block are deleted from all the transaction pools, keeping their states synchronized.

(2) A consensus is reached. Each service provider node continuously acquires the transaction from the transaction pool and puts the transaction into own new block, and when the number of the transaction in the block reaches the set upper limit, all the service provider nodes reach consensus on the nodes of the proposed block. The CoralDB designs a BFT consensus mechanism based on PPoS, can ensure that a result can be agreed under the condition that malicious nodes do not exceed 1/3, and ensures the safety. The selected block producer (Leader) submits the block generated by itself to a node in a voting committee for verification and voting, and finally the block which can be stably agreed and the proposer thereof are elected.

In this embodiment, the consensus algorithm is an important component of the blockchain-based system. In CoralDB, the contents of the transaction need to be verified by a consensus algorithm. There are two types of common consensus algorithms, one is the Nakamoto consensus, such as PoW and PoS, and the other is the BFT (bayer fault tolerance) protocol, such as PBFT and HotStuff.

The Nakamoto consensus algorithm may result in higher computational overhead and longer transaction times. Most BFT protocols are designed based on a random leader election scheme, meaning that the leader's choice is visible or predictable and vulnerable to targeted attacks. To address these challenges, and in combination with considering the application features of the CoralDB, the CoralDB adopts SRL-BFT (Secret Random Leader based Byzantine Fault Tolerant), which is a novel consensus scheme, which can ensure system security and has good scalability.

The SRL-BFT main idea is to realize decentralization consensus through VRF (Verifiable Random Function), and any node with certain rights has equal opportunity to become a proposer and a committee member, so that all consensus participants are ensured to be selected randomly and fairly. The specific flow of SRL-BFT is described as follows:

step 1: selecting the blockchain proposal. Each service provider node simultaneously checks the number of transactions in the transaction pool, and when the number is larger than the set block packing transaction number packNum, a selection operation (sort) is performed to select a block proposer, and a set function is operated to obtain a VRF value (a string of hash values) and a corresponding proof proposer_p. Specifically, the function is set as an evaluation (sk, x) function, which is a function that generates vrf values and corresponding certificates from the private key and the random value x.

Then calculateWhere hashlen is the length of the hash value, if b falls within interval b ^j And if so, indicating that j sub-users of the service provider node are selected. Solving b by introducing a rights proving mechanism ^j The process is as follows:

each server node is set to have the same number of tokens m, each unit of tokens (inseparable) is regarded as a child user, and the number of tokens owned by the server node cluster is w. If the number of block propozers to be selected in the round is t, the probability that all the sub-users of the nodes in the round are extracted is:

for each server node, the probability that its k child users are selected will obey a binomial distribution, expressed as:

where B (k; m, p) represents the probability that exactly k sub-users are selected among the m sub-users,coefficients representing binomials, p ^k Representing the probability that k sub-users are selected.

Dividing the interval [0,1 ] into m+1 consecutive intervals, b ^j Represents any one of these m+1 intervals, defined as follows:

if j >0, the resolution operation returns to the proposer_p, and when the proposer_p is not null, the service node indicates that the service node is a block proposer, and further broadcasts the proposal information of the block and the block together, wherein the block msg comprises the hash, the current round, the VRF value and the proposer_p of the block, and the smaller the value of the VRF is, the higher the priority is.

Step 2: committee member selection and voting. Similar to block presenter selection, each server node selects committee members by performing a resolution operation. The committee member can receive the proposed block RB and the proposal information RBMsg within a set time window Tre and verify the legitimacy of the proposal according to the RBMsg. After passing the verification, the RB is saved in the block_map. Next, the committee members acquire the block VB with the highest priority in the block_map, and then they vote on VB and sign-confirm using the initvolt function. This voting stage can ensure that each committee member expresses support for VB. The final committee member broadcasts their voting information to let other nodes know their decisions.

Step 3: and counting voting information. The committee members may receive the voting information of the other committee members within the set time window Tvi and verify the signature of the vote and VRF proof. After the verification is passed, the voting information is stored in the vot_map. When Tvi ends, the committee members count the voting information through the function, assign the hash value of the proposed block with the vote number exceeding 2/3 to the tentative block hash (Tentative Block Hash, TBH) to form a preliminary consensus result. It should be noted that, if the number of votes obtained for any proposed block exceeds 2/3, a hash of an empty block is obtained.

Step4: achieving consensus and uplink. The committee member further confirms the primary consensus result, and the application introduces 'BBA' and an improved binary Bayesian protocol (so-called binary, namely only 0 or 1 consensus can be achieved) to achieve the final consensus. The 'BBA ∈' can quickly reach consensus under the condition that honest nodes exceed 2/3. And finally marking the obtained block obtained through the consensus as the FB, broadcasting the FB to all nodes, receiving the block by each node, and adding the block into an account book of the node to form a new account book.

(3) Commit and execute. The block proposer distributes the block to all other nodes in the group, the other nodes perform integrity verification again on the block, and the block is added into the ledger after passing through the block proposer. And updating the own transaction pool, namely eliminating the uplink transaction in the transaction pool.

It should be noted that the collaboration table is a data structure, and is also a logical data table, and resides in the memory. It maintains an up-to-date state of a set of cooperating peer nodes and is managed and maintained by those nodes together. The schema of the collaboration table is designed using a key/value data model and encapsulates simple and easy-to-use read/write interfaces for the user that the collaboration participants can use to access the tuples in the collaboration table according to their primary keys. Meanwhile, the collaboration table can control the access rights of the parties in collaboration.

Any node participating in data collaboration can initiate a request for creating a collaboration table and invite other nodes to join the collaboration table, and after agreement, the other nodes can join the collaboration table and be assigned a default operation authority for the collaboration table. The basic information of the collaboration table is shown in table 2, and includes a name, authority of the participating node, creator information, and creation time, wherein the Permission field is a one-dimensional array for storing the address of the user and the authority of the user to the sharing table, and the definition form is as follows: permission= [ "address 1: rights level 1", "address 2: rights level 2",.]. The basic information of the collaboration table is stored in the authority chain, a blockchain that is similar in structure to the data chain. All nodes can write the basic information of the collaboration table into the permission chain after the basic information is commonly known. The logical structure of the collaboration table is shown in Table 3, including four fields, key, value, timestamp, and data submitter.

Table 2 basic information of the synergistic table

Field name	Description of the invention
		Name	Table name of shared table
Permission	Rights of users to shared tables
		Possessor	Creator of shared table
TimeStamp	Time of shared table creation

TABLE 3 collaborative table logic structure

Key	Value	TimeStamp	Submitter
				Tom	35years old	1688618979	User1
Bob	20years old	1688619050	User2
				Ailith	15years old	1688618830	User1

The specific workflow of the collaboration table is described as follows:

step 1: a collaboration table is created. And a certain node participating in data collaboration is responsible for creating a collaboration table, inviting other nodes to join, and initializing basic information of the collaboration table. The creator packages the collaboration table base information into a transaction, signs it, and then broadcasts the transaction to other nodes. The other nodes verify their authenticity to ensure the legitimacy of the transaction, and the transaction that passed the verification will be placed in the collaborative table transaction pool.

Step 2: a leader is selected. All nodes execute the Raft algorithm, hope to become a leader candidate, and send requests containing own information (including hash values of transactions) to other nodes, and after receiving the requests, the other nodes check the information of the candidate and vote on the candidate when certain conditions are met. These conditions include: the node does not vote on other candidates, and the hash value of the transaction matches the hash value in the collaborative table transaction pool.

Step 3: and packing the basic information of the collaboration table. When a node is selected as a leader, it is responsible for packaging the collaboration table transaction into chunks and adding the chunks to the permission chain. And then, the non-leader node synchronizes the authority chains and updates the collaboration table transaction pool and the collaboration table according to the latest block.

Step4: access control of the cooperation table. After the authority chain synchronization is completed, the nodes participating in the data collaboration and sharing can use a read/write interface to perform data read/write operation on the collaboration table. When the node performs data writing operation on the cooperation table, the cooperation table judges whether the node has corresponding authority, and if the node has no authority, the data cannot be written into the cooperation table.

In this application, in order to increase the speed of querying data, we have implemented three query methods, respectively: cache pool queries, history queue queries, and index table queries. Wherein the cache pool query and the history queue query are designed based on an LRU-K cache elimination algorithm. The index table is a hash of the block where all the data in the cooperation table is located, and is a highly ordered list of the blocks, and is updated whenever a new block is generated. When the data to be queried is not in the cache pool or the history queue, the data can be sequentially searched according to the block hash in the index table without performing full traversal search on the blocks on the data chain, so that the searching times are reduced.

Under the flow of data query, mainly include:

step one: the node analyzes the query request of the user to obtain the name of the cooperation table to be queried, the address of the data to be queried and the address of the user, judges whether the user has the query authority of the cooperation table, and returns directly if the user has no authority.

Step two: and inquiring the data in the node cooperation table cache pool, and assigning an inquiry result to the value.

Step three: judging whether the value is empty, if so, inquiring the data in the history queue, and assigning the inquiring result to the value.

Step four: judging whether the value is empty, if so, acquiring an index table, and searching a block where the data are located in the index table.

Step five: judging whether the value is empty, if so, indicating that the data does not exist, and if not, returning the data, and updating the cache pool and the history queue.

To sum up, to guarantee data sharing collaboration among multiple untrusted providers, we use blockchains as an integrity-protected storage layer. Within the same group, each service provider has duplicate journals and metadata and uses the Bayer Fault Tolerance (BFT) consensus mechanism to agree. Any state data updates committed to the present system are unalterable. All updates are verifiable and there are no unauthorized updates. The log and metadata are publicly transparent to all service providers and traceable.

Because of the need to agree on and synchronize state data on all nodes for each transaction, the scalability of the blockchain system is greatly limited, becoming a performance bottleneck. The system has high transaction processing performance, supports high throughput and low delay on database transactions, and can keep good throughput along with the increase of the number of client and server nodes.

When a blockchain is used as a database, its ease of use is affected by its lack of a simple and easy-to-use operating interface. The system provides a simple and easy-to-use abstraction for clients by introducing a database transaction layer over the blockchain and storing data in a blockchain-dependent storage layer. The updating, inserting and deleting of data is transparent to all persons. Finally, the organization complexity of data sharing by using the system is reduced, and the usability of the system is improved.

A centralized database server determines the results of all updates and queries performed. In such a design, the server can conceal any possible damage or error without the user having a way to authenticate them. The system is independent of any center and is an decentralized autonomous organization.

The effectiveness of the method is verified by a specific implementation, and specifically, a multiparty data sharing and collaboration database system (CoralDB) based on a license chain is compared with the existing blockchain platform Quorum, tendermint and database platforms Etcd, mongoDB. To evaluate the performance of the system under test, we send 1000 transactions to each system. The number of clients is represented by setting concurrency parameters, and the clients send a plurality of transactions to one system in parallel. The transactions are evenly distributed across the different nodes in the system. We use Yahoo-! Cloud Serving Benchmark (YCSB) data set is widely used for benchmark testing of databases and blockchains.

The throughput and delay for different client numbers are compared as follows:

referring to fig. 3, fig. 3 (a) and 3 (b) show the effect of increasing the number of clients on throughput and delay, respectively, it can be observed that the throughput and delay of CoralDB is intermediate between the blockchain platform and the database under test. For all tested systems, the throughput and delay of the system increases as the number of clients increases. The throughput rates of Quorum, tendermint, mongoDB, and CoralDB are progressively slower. Whereas Etcd increases with the number of client nodes, the throughput rate increases gradually. When the number of clients is greater than 32, the delay of all systems becomes significantly large. The delay growth rate of CoralDB is close to the database platform but significantly slower than the two blockchain platforms tested.

The throughput and delay for different numbers of servers are compared as follows:

as shown in fig. 4, for the blockchain platform and CoralDB, as the number of service nodes increases, the throughput of the system decreases. CoralDB drops from 806TPS at 4 nodes to 316TPS at 25 nodes, tendermine and Quorum drops from 390TPS at 4 nodes, 335TPS to 100TPS at 25 nodes and 83TPS, respectively, by a greater magnitude than CoralDB. This may be due to the fact that the consensus time, communication frequency, message complexity between nodes of tendermine and Quorum are more affected by the number of nodes. The TPS of the Etcd in the database platform drops significantly with the increase in the number of servers, since the Etcd node cluster needs to elect different leader nodes in different tenns, and the leader nodes need to wait for their replies when broadcasting data to other nodes, resulting in a significant drop in TPS of the system. In contrast, the TPS of MongoDB fluctuates less when the number of service nodes is increased. Both the blockchain platform and the CoralDB increase in terms of delay as the number of server nodes increases, but the growth rate of quum and tendril is faster than CoralDB. This is because communication between CoralDB nodes is faster and consensus is more stable. And the delay of the database platform does not fluctuate greatly along with the increase of the number of the service ends, and basically keeps stable.

The throughput and delay at the different block sizes are compared as follows:

referring to fig. 5, as the size of the block increases, the throughput and delay of the CoralDB increase. From 4TPS for 10 transactions per tile to 623TPS for 2000 transactions per tile, the processing delay increases from 3s to 3.5s. This is because the size of the block increases, and the frequency of communication between nodes and the size of the message may cause an increase in processing delay. In increasing the block size, the user needs to trade-off between throughput and delay. This trade-off depends on the application scenario.

The throughput at different key sizes is compared as follows:

as shown in fig. 6, the throughput of all tested systems decreases as the size of the key increases. For key sizes greater than 8KB, the drop in throughput is more pronounced. This is mainly due to the larger key size that can lead to greater network overhead. When the key size is equal to or larger than 32KB, tendril stops working due to the upper limit of the block size being reached. When the key size is 128KB or more, the CoralDB also stops working because its limit with the largest message is 4MB. For database platforms, as the key size increases, the network transmission and system processing times increase accordingly, resulting in a rapid decrease in throughput. As expected, throughput may be significantly reduced when transactions require longer time to process. But for tendril and CoralDB this effect is not as pronounced as in other systems.

The throughput at different transaction delays is compared as follows:

as shown in fig. 7, when the transaction processing delay increases from 0ms to 1s, the throughput of tendermine decreases from approximately 140TPS to 100TPS, and the throughput of coraldb decreases from 311TPS to 269TPS, with a decrease of only 42TPS. Whereas the throughput of Etcd, mongoDB and Quorum is reduced directly to 4TPS. This can be explained by the fact that the average delay of tendermine and CoralDB has exceeded 1 second due to consensus. Adding more execution time delay does not affect the consensus that overlaps with the transaction processing portion.

In summary, the present system designs a storage layer based on a blockchain technique. In the storage layer, data participating in collaboration and sharing is copied to all peers to ensure consistency of data states. This full-node replication mode, while having higher requirements for storage space and bandwidth, is more advantageous to ensure data integrity, decentralization, and resistance to attacks. We construct the basic structure of the block, implementing a transaction pool for receiving, ordering, verifying and managing transactions to be validated. A secure consensus mechanism based on a secret random leader election scheme using a Verifiable Random Function (VRF) is also provided for the storage layer, so that efficient consensus can be guaranteed in the case that malicious nodes are less than 1/3, and a selected leader cannot be revealed until the agreement is reached, so that a targeted attack cannot be initiated on a consensus block until the agreement is reached.

The system proposes and implements a database layer on a storage layer. And rich data operation interfaces are provided for users, and the efficiency and convenience of adding, updating and querying of the collaboration data are improved. For this purpose, we have designed a connection pool for the database layer, responsible for managing and maintaining database connections. A collaboration table is constructed, which is a logic structure for abstracting the collaboration and sharing state data of all parties, integrates a simple and easy-to-use data operation interface, and also has a permission control mechanism. In addition, we propose the three-level query mechanism of buffer pool query, history queue query and index table query, which can improve the query efficiency.

The application also provides a multi-party data sharing collaboration system based on the license chain, which comprises a storage layer and a database layer constructed on the storage layer;

the storage layer comprises a transaction pool, and the database layer comprises a cache pool, a history queue, an index table and a connection pool; the storage layer is communicated with the database layer through the transaction pool, and the database layer is communicated with the client through the connection pool.

The system of the present system is constructed as shown in fig. 8, and its main idea is to construct a decentralised, safe and efficient storage layer by using the blockchain technique. And then a transaction layer which can provide a simple and easy NoSql database operation interface is constructed on the storage layer so as to improve the usability of the system and the storage experience of a user.

Unlike prior art solutions, the present system uses an autonomously developed blockchain as the storage layer of the system, rather than an existing blockchain platform. And a database layer is introduced at the top of the data collaboration platform, and the usability and efficiency of data collaboration and sharing are improved by constructing a connection pool, a collaboration table and a block chain of a query interface expansion storage layer.

The multi-party data sharing collaboration system based on the license chain can realize the embodiments of the multi-party data sharing collaboration method based on the license chain, and can achieve the same beneficial effects, and the details are not repeated here.

The foregoing describes in detail preferred embodiments of the present invention. It should be understood that numerous modifications and variations can be made in accordance with the concepts of the invention by one of ordinary skill in the art without undue burden. Therefore, all technical solutions which can be obtained by logic analysis, reasoning or limited experiments based on the prior art by the person skilled in the art according to the inventive concept shall be within the scope of protection defined by the claims.

Claims (9)

1. A license chain-based multi-party data sharing collaboration method, which is applied to a license chain-based multi-party data sharing collaboration system, wherein the system comprises a storage layer and a database layer connected with the storage layer, and the storage layer is a block chain-based storage layer, and the method is characterized by comprising the following steps:

the service provider node receives a data request sent by a client through a connection pool of a database layer;

if the type of the data request is a query request, searching in a cache pool, a collaboration table related chain and a data chain until the data corresponding to the data request is found and returned to the client;

if the type of the data request is an update request, the following steps are executed:

s1: carrying out transaction pool processing;

s2: each service provider node continuously acquires the transaction from the transaction pool and puts the transaction into a new block, and when the number of the transaction in the block reaches the set upper limit, the service provider node selected as a member of the block verification committee agrees with the block proposed by the block proposer;

s3: the block proposer distributes the block to all other nodes in the group, the other nodes perform integrity verification again on the block, the block is added into the ledger after passing, and meanwhile, the transaction pool is updated.

2. The license chain-based multiparty data sharing collaboration method according to claim 1, wherein prior to the transaction pool processing, the method further comprises:

and realizing authority checking through an authority chain, and verifying the validity of a transaction source and the integrity of transaction data by utilizing a Hash algorithm and an asymmetric encryption method.

3. The license chain-based multiparty data sharing collaboration method according to claim 1, wherein the S1 comprises:

the service provider node puts the data corresponding to the update request into the transaction pools of the service provider node to which the update request belongs, and simultaneously broadcasts the data to the transaction pools of other service provider nodes in the group, and synchronizes the data to maintain consistency.

4. The multi-party data sharing collaboration method based on the permission chain according to claim 3, wherein the server node puts the data corresponding to the update request into a transaction pool of the server node to which the server node belongs, specifically comprising;

the server node analyzes the update request, invokes a permission checking function, judges whether the user has permission to update data of the cooperation table, if not, writes the data carried by the update request into the local of the affiliated server node, returns a processing result, and if so, packages the data carried by the update request into a transaction and obtains an original document of the transaction by initial trial;

the transaction is subjected to hash processing by using a hash function to generate a digest, a pair of public keys and private keys are generated for a transaction producer by using an elliptic curve encryption algorithm, the digest is digitally signed by using the private keys to obtain a signature, and the signature and the public keys are packaged into the transaction by the transaction producer and broadcast to other service provider nodes for verification;

after receiving the transaction, other service provider nodes firstly decrypt the signature by using a public key, check the validity of the source of the transaction, obtain a summary after successful decryption, record as R.dig, hash the parsed result by using the same hash function as the transaction producer to obtain a new summary N.dig, compare the N.dig with the R.dig, if the N.dig and the R.dig are the same, indicate that the transaction data is complete, and each service provider node adds the transaction into its own transaction pool and sorts the transaction according to the transaction production time stamp;

if a new block is generated, deleting the transactions contained in the block from all transaction pools, and keeping the state synchronous.

5. The license chain-based multiparty data sharing collaboration method according to claim 1, wherein the S2 comprises:

s21: each service provider node checks the number of transactions in the transaction pool at the same time, when the number of transactions is larger than the set block packing number, performs a selection operation to select a block proposer, runs a setting function to obtain a VRF value and a corresponding proof proposer_p, and then calculatesWhere hashlen is the length of the hash value, if b falls within interval b ^j In, the service provider node is describedJ sub-users are selected;

s22: each service provider node selects a committee member by executing a selection operation, the committee member receives a proposed block RB and proposal information RBMsg in a set time window Tre, verifies the legitimacy of the proposal according to the proposal information RBMsg, stores the RB into a block_map after verification, acquires a block VB with the highest priority in the block_map, votes and signs and confirms the VB by using an InitVote function, and finally broadcasts voting information of the committee member to enable other nodes to acquire decisions;

s23: the committee member receives voting information of other committee members in a set time window Tvi, verifies the signature and VRF certification of the votes, saves the voting information into a vot_map after the verification is passed, and after Tvi is over, the committee member counts the voting information through a function, and assigns the hash value of a proposed block with the number of votes exceeding 2/3 to a tentative block hash to form a preliminary consensus result;

s24: the committee member further confirms the preliminary consensus result, marks the block obtained by the consensus as FB, broadcasts the FB to all nodes, and each node receives the block and adds the block into the account book of the committee member to form a new account book.

6. The license chain-based multiparty data sharing collaboration method according to claim 5, wherein in S21, b ^j The calculation process of (2) is as follows:

setting that each service provider node has the same number of tokens m, wherein each unit of tokens is regarded as a sub-user, the number of the tokens owned by the service provider node cluster is w, and if the number of the block proposer to be selected in the round is t, the probability that the sub-users of all the nodes are extracted in the round is:

for each server node, the probability that its k child users are selected obeys a binomial distribution, expressed as:

where B (k; m, p) represents the probability that exactly k sub-users are selected among the m sub-users,coefficients representing binomials, p ^k Representing the probability that k sub-users are selected;

dividing the interval [0,1 ] into m+1 consecutive intervals, b ^j Represents any one of these m+1 intervals, defined as follows:

if j >0, the selection operation returns to the proposer_p, and when the proposer_p is not null, the service node is indicated to be the block proposer, and further the block and the proposal information block msg of the block are broadcasted together, wherein the block msg comprises the hash, the current round, the VRF value and the proposer_p of the block, and the smaller the value of the VRF is, the higher the priority is.

7. The license chain-based multiparty data sharing collaboration method according to claim 1, wherein prior to S1, the method further comprises:

creating a cooperation table;

selecting a leader;

the leader packs the basic information of the collaboration table, and the non-leader node synchronizes the authority chains and updates the collaboration table transaction pool and the collaboration table according to the latest area block;

after the authority chain synchronization is completed, the nodes participating in the data collaboration and sharing use a read/write interface to perform data read/write operation on the collaboration table, when the nodes perform data write operation on the collaboration table, the collaboration table judges whether the nodes have corresponding authorities, and if the nodes do not have the authorities, the nodes cannot write data into the collaboration table.

8. The license chain-based multiparty data sharing collaboration method according to claim 7, wherein,

when the type of the data request is a query request, the query mode comprises cache pool query, history queue query and index table query;

the index table is a list which stores the hashes of all the blocks where the data in the cooperation table are located and is ordered according to the heights of the blocks, the index table is updated every time a new block is generated, and the index table is sequentially searched according to the block hashes in the index table when the data to be searched is not in a cache pool or a history queue.

9. The multi-party data sharing collaboration system based on the license chain is characterized by comprising a storage layer and a database layer constructed on the storage layer;

the storage layer comprises a transaction pool, and the database layer comprises a cache pool, a history queue, an index table and a connection pool; the storage layer is communicated with the database layer through the transaction pool, and the database layer is communicated with the client through the connection pool.