CN111899019A - Method and system for cross validation and sharing of blacklist and multiple parties - Google Patents

Abstract

The invention discloses a system for multi-party cross-validation and sharing of blacklists, including a Bloom Filter blacklist shared library module, which is used to obtain blacklist data for calculation and storage based on Bloom Filter, and to retrieve and query the stored blacklist data. ;The blacklist submission record sharing ledger module is used to record the submitted blacklist data details, and send it to the accounting nodes on the blockchain, so that the accounting nodes can be packaged into blocks and passed to each node; public chain consensus management The module is used to deploy smart contracts on the public chain for node management and consensus mechanism management on the blockchain; the present invention utilizes the advantages of Bloom Filter technology in space efficiency, query efficiency and security, combined with blockchain technology to achieve lossless The private blacklist sharing and efficient retrieval functions break through the storage capacity limitation of the blockchain; and through smart contracts, data sharing and consensus among participating nodes are constrained, and automated execution is implemented to achieve a credible data sharing system.

Description

A method and system for multi-party cross-validation and sharing of blacklists

technical field

The present invention relates to the technical field of blockchain applications, in particular, to a method and system for multi-party cross-validation and sharing of blacklists.

Background technique

Blockchain is an underlying technology brought by Bitcoin, which includes a series of technologies, such as asymmetric encrypted signatures, distributed ledgers, consensus mechanisms, peer-to-peer protocols, smart contracts, etc. Blockchain can realize value transfer, data consensus, automatic contract execution, etc. in a peer-to-peer network environment. The blockchain is divided into a public chain and a consortium chain. The public chain is an open structure, and any unfamiliar node can join it; the consortium chain is a permissioned joining structure, and only permissioned nodes can participate in consensus and bookkeeping.

Achieving blacklist sharing among multiple institutions or within the industry has always been a difficult problem. There are both technical difficulties in sharing data among multiple parties and achieving data consistency, as well as concerns about leaking sensitive data and violating privacy. Blacklist sharing based on blockchain technology also has privacy issues. Even if the hash value is used to upload the chain, there are still retrieval efficiency issues and the capacity limitation of the blockchain itself. These problems make it difficult for the blacklist sharing to be applied in all walks of life despite the urgent needs of the industry.

In view of this, the present invention is proposed.

SUMMARY OF THE INVENTION

In view of the defects in the prior art, the present invention provides a method and system for multi-party cross-validation and sharing of blacklists, aiming to use the Bloom Filter data structure to achieve privacy-free blacklist sharing and efficient retrieval functions, and to use blockchain technology. Realize the consensus and consistency of Bloom Filter data and blacklist submission record data within the alliance. The consensus mechanism and data that constitute the alliance chain between nodes are consistent, and are achieved by relying on a trusted public chain.

To achieve the above object, the technical scheme of the application is as follows:

A system for multi-party cross-validation and sharing of blacklists, characterized by comprising:

The Bloom Filter blacklist shared library module is used to obtain the blacklist data for operation and storage based on Bloom Filter, and to retrieve and query the stored blacklist data;

The blacklist submission record shared ledger module is used to record the detailed information submitted to the Bloom Filter blacklist shared library module, and send it to the accounting node on the blockchain, so that the accounting node can be packaged into a block and transmitted to each node;

The public chain consensus management module is used to deploy smart contracts on the public chain for node management and consensus mechanism management of nodes on the blockchain;

The interface module is used to provide a standardized program interface for the business system to access, so as to submit the blacklist data and query the blacklist data.

Further, in the above-mentioned blacklist multi-party cross-validation and sharing system, the Bloom Filter blacklist shared library module is specifically used for

Perform various hash operations on the obtained blacklist data, and the obtained operation results are mapped to the Bit bits of the BloomFilter data structure of the module to verify whether the blacklist exists and the number of submissions of the blacklist, and return the verification result;

And, each piece of blacklist data that has been verified by the operation is stored to form a blacklist shared library based on the Bloom Filter data structure, and the shared library is updated after the operation verification of each blacklist data for query;

When receiving a blacklist query request, the module returns at least two results, whether the requested query blacklist exists and the number of times the blacklist is submitted.

Further, in the above-mentioned system for multi-party cross-validation and sharing of blacklists, the Bloom Filter is a Bloom Filter with a counter, and the counter records the number of elements added to the Bit bit of the Bloom Filter data structure and the number of blacklist submissions.

Further, in the above blacklist multi-party cross-validation and sharing system, when the blacklist submission record sharing ledger module stores the detailed information, the transaction is constructed according to the following data structure:

The various hash values of the blacklist data, the hash value obtained by concatenating the various hash values and performing the encryption operation, the count value of the blacklist on the Bloom Filter, the timestamp, the public key, and the node private key digital signature.

Further, in the above-mentioned blacklist multi-party cross-validation and sharing system, the blockchain includes the local node main body of the alliance chain and the main body of the smart contract of the alliance chain public chain;

The main body of the local node of the alliance chain includes the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module, and is deployed locally on all nodes together with the interface module;

The main body of the alliance chain public chain smart contract includes a public chain consensus management module, and the public chain consensus management module deploys at least three smart contracts on the public chain in a procedural manner, including an identity authentication smart contract, a consensus management smart contract and a certificate smart contract .

Further, in the above-mentioned blacklist multi-party cross-validation and sharing system, the identity authentication smart contract is used for the identity authentication management of the participating nodes of the alliance chain, and the public key of the alliance chain is stored in the smart contract; the consensus management smart contract is used for randomization. Allocate the accounting rights of the nodes in the alliance chain and maintain the accounting history; the smart contract for depository is used to save the block data of the alliance chain about the blacklist and the digital signature of the voting nodes for the block data.

Further, in the above system for multi-party cross-validation and sharing of blacklists, the blacklist submission record sharing ledger module generates a data block every preset time period, and the node currently responsible for bookkeeping collects data within the preset time period. All transaction information submitted by all nodes is verified, packaged to generate block data, attached with the hash value of the previous block, encrypted to generate the block hash value of this block, and block header information; The block that is sent to the voting nodes and verified and signed by more than half of the nodes enters the confirmed state.

The present invention also provides a method for multi-party cross-validation and sharing of the blacklist, comprising the steps of:

Obtaining blacklist data, calculating and storing it based on Bloom Filter, and retrieving and querying the stored blacklist data to determine whether the blacklist data exists in the shared library;

Record the submission details of the blacklist data, and send it to the accounting node on the blockchain, so that the accounting node can be packaged into a block and transmitted to each node;

Deploy smart contracts to manage nodes and consensus mechanisms on the blockchain.

Further, in the above-mentioned blacklist multi-party cross-validation and sharing method, blacklist data is obtained, calculated and stored based on Bloom Filter, and the stored blacklist data is retrieved and queried to determine whether the shared library exists. Blacklist data, including:

S1. Obtain suspected or confirmed blacklist data, and obtain valid identification data of the blacklist data;

S2. In the local environment, perform 10 hash operations on the acquired valid identification data, including APHash, BKDRHash, BPHash, DJBHash, DEKHash, FNVHash, JSHash, PJWHash, RSHash and SDBMHash, and then obtain 10 hash operations. hash value;

S3. Submit 10 hash values to the blacklist shared library based on the Bloom Filter data structure, wherein:

S31. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 1, then it is judged that other nodes have submitted the blacklist; go to step S4.;

S32. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 0, set the bit to 1; enter step S5.;

S4. Obtain the 10-bit count through the Bloom Filter counter, so as to know that there have been several submissions to the blacklist before; and add 1 to the 10 bits of the counter respectively;

S5. Set the value of the corresponding 10 bits in the Bloom Filter data structure to 1; and add 1 to the 10 bits of the counter respectively.

Further, in the above-mentioned blacklist multi-party cross-validation and sharing method, smart contracts are deployed to manage nodes and consensus mechanisms on the blockchain, including:

Three smart contracts are deployed on the public chain, including identity authentication smart contracts, consensus management smart contracts and certificate storage smart contracts. The identity authentication smart contracts are used for the identity authentication management of the participating nodes in the alliance chain; the consensus management smart contracts are used for random allocation The accounting rights of the nodes in the alliance chain and maintaining the accounting history; the smart contract for depository is used to save the block data of the alliance chain about the blacklist and the digital signature of the voting nodes for the block data;

The alliance chain generates a data block every preset time period, and the node currently responsible for bookkeeping collects all transaction information submitted by all nodes within the preset time period, verifies, packs and generates block data, and attaches the previous block. After the block is sent to the voting node, the block that is verified and signed by more than half of the nodes enters the confirmed state;

The consensus management smart contract randomly selects an address from the public key addresses of all alliance nodes every preset time period, designates this address as the next round of billing nodes, and the node submits the block header information of this round to the storage within the preset time period. The certificate smart contract is used for deposit; otherwise, the consensus management smart contract randomly selects another public key address as the accounting node for this round.

The beneficial effects of the present invention are embodied in:

The system and method of the present invention utilizes the advantages of the Bloom Filter technology in space efficiency, query efficiency and security, and combines the blockchain technology to achieve privacy-free blacklist sharing and efficient retrieval functions, and break through the storage capacity limitation of the blockchain. ; and the present invention adopts blockchain technology to constrain data sharing and consensus among nodes participating in the alliance through smart contracts, and automate execution, thereby realizing a credible and reliable data sharing system.

Description of drawings

In order to illustrate the specific embodiments of the present invention or the technical solutions in the prior art more clearly, the following briefly introduces the accompanying drawings that are required to be used in the description of the specific embodiments or the prior art. Similar elements or parts are generally identified by similar reference numerals throughout the drawings. In the drawings, each element or section is not necessarily drawn to actual scale.

FIG. 1 is an architecture diagram of a blacklist multi-party cross-validation and sharing system in a specific embodiment of the present invention;

Fig. 2 is the flow chart that utilizes Bloom Filter data structure and alliance to carry out blacklist submission and verification in the system shown in Fig. 1;

FIG. 3 is a schematic diagram of the principle of storing, verifying and retrieving blacklist data by a Bloom Filter with a counter in the system shown in FIG. 1 .

Detailed ways

Embodiments of the technical solutions of the present invention will be described in detail below with reference to the accompanying drawings. The following examples are only used to more clearly illustrate the technical solutions of the present invention, and are therefore only used as examples, and cannot be used to limit the protection scope of the present invention.

It should be noted that, unless otherwise specified, the technical or scientific terms used in this application should have the usual meanings understood by those skilled in the art to which the present invention belongs.

Explanation of relevant terms in the present invention:

Bloom Filter: Bloom filter is a data storage and retrieval technology, proposed by Bloom (Burton HowardBloom) in 1970. The data structure of Bloom Filter is composed of a long binary vector, and each binary bit can be set to 0 or 1. Bloom Filter technology uses a series of random mapping functions, such as hash functions, to operate on data elements, and then map them to the corresponding binary bit, setting the bit to 1. If the values of the bits mapped by an element are all 1, it means that the element exists. The space efficiency and computational efficiency of Bloom Filter are higher than general retrieval algorithms.

As shown in Figure 1-2, the present invention is a blacklist multi-party cross-validation and sharing system, including

The Bloom Filter blacklist shared library module is used to obtain the blacklist data for operation and storage based on Bloom Filter, and to retrieve and query the stored blacklist data;

The blacklist submission record shared ledger module is used to record the detailed information submitted to the Bloom Filter blacklist shared library module, and send it to the accounting node on the blockchain, so that the accounting node can be packaged into a block and transmitted to each node;

The public chain consensus management module is used to deploy smart contracts on the public chain to manage nodes on the blockchain and manage the consensus mechanism.

The blacklist multi-party cross-validation and sharing system provided by the present invention uses the Bloom Filter data structure to store, verify and retrieve the blacklist, realizes the cross-validation of the blacklist without revealing privacy, and adopts the form of alliance chain among the multi-party participating in the sharing. Share the data stored on the Bloom Filter blacklist shared library and reach a consensus. The consensus mechanism and management depend on the implementation of smart contracts deployed on public chains such as Ethereum, which cannot be tampered with, ensuring execution and high reliability.

In a specific embodiment provided by the present invention, the system further includes an SDK interface module, which is used to provide an SDK module with a standardized interface for access by the business systems of other organizations to submit the blacklist data and query the blacklist data.

The Bloom Filter blacklist shared library module obtains blacklist data from the above-mentioned SDK module (which can be a universal unique identifier such as an ID card), and performs various hash operations on the obtained data, and the obtained operation result is mapped to the The Bit bit of the Bloom Filter data structure of the module is used to verify whether the blacklist exists and the number of submissions of the blacklist, and returns the verification result; each piece of blacklist data verified by the operation is stored to form a blacklist based on the BloomFilter data structure. Shared library, and update the shared library for query after the operation verification of each blacklist data; and when other business systems initiate a blacklist query request, the module returns whether the blacklist requested for query exists, and the blacklist There are two results for the number of submissions.

Specifically, with reference to FIG. 3 , the Bloom Filter described in the present invention adopts a Bloom Filter with a counter, preferably a dlCBF (d-Left Counting Bloom Filter), which can increase the number of elements by recording the Bit bits of the counter, so that the number of elements can be increased. Implement element deletion, and can calculate the number of times that a blacklist is submitted by multiple parties; then when the blacklist is queried, it can not only return whether the element exists, but also return the number of times the element was submitted. It is important for verification and validation.

In a specific example, the procedure steps of the Bloom Filter blacklist shared library module performing computation and sharing are as follows:

S1. Obtain suspected (or confirmed) blacklist data, and obtain valid identification data of the blacklist data, for example, the valid identification data is ID card data;

S2. In the local environment, perform 10 hash operations on the acquired ID card data, including APHash, BKDRHash, BPHash, DJBHash, DEKHash, FNVHash, JSHash, PJWHash, RSHash and SDBMHash, and then obtain 10 hash operations. hash value;

S3. Submit 10 hash values to the blacklist shared library based on the Bloom Filter data structure, wherein:

S31. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 1, it means that other nodes have submitted the blacklist; then go to step S4.;

S32. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 0, set the bit to 1; enter step S5.;

S4. Obtain the 10-bit count through the Bloom Filter counter, so as to know how many times the blacklist has been submitted before; the more the count, the higher the severity of the blacklist; plus 1;

S5. Set the value of the corresponding 10 bits in the Bloom Filter data structure to 1; and add 1 to the 10 bits of the counter respectively.

In this embodiment, the total number of bits m set by the Bloom Filter is 2 billion, the number of hash operation types k is 10, and if the storage rate of the Bloom Filter does not exceed 50%, the blacklist elements that can be accommodated are 100 million, and the storage capacity is large.

The blacklist submission record shared ledger module records the detailed information of the submitted blacklist data to the Bloom Filter blacklist shared library module, stores it locally, and sends it to the accounting node, so that the accounting node can package it into block data, It is then passed to each node to achieve data consistency between nodes, and form verifiable consistency with the Bloom Filter blacklist shared library; the submission record here can be regarded as a transaction in the blockchain.

Wherein, when the blacklist submission record sharing ledger module stores the submission record details, the transaction is constructed according to the following data structure:

The 10 hash values of the blacklist data, the hash value obtained by concatenating the 10 hash values and doing SHA 256, the count value of the blacklist on the Bloom Filter, the timestamp, the public key, and the private key of the node key digital signature.

The blacklist submission record sharing ledger module sends the data block formed by the above data structure to the accounting node for subsequent verification operations on the blockchain.

In the system of the present invention, the smart contract is deployed on the public chain through the public chain consensus management module to carry out identity authentication, consensus management and/or certificate storage for the transaction and consensus process between nodes.

The blockchain in the present invention includes the local node main body of the alliance chain and the intelligent contract main body of the alliance chain public chain; wherein the local node main body of the alliance chain includes the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module, and is connected with the SDK. The interface modules are jointly deployed locally on all nodes.

The peer-to-peer data sharing is realized between the nodes of the alliance chain through the Gossip protocol. The shared data includes the data on the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module.

In a preferred implementation given in this embodiment, the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module are developed in go language; the Bloom Filter is based on the Bitset data structure and uses MarshalBinary for persistent file storage. The data of the blacklist submission record shared ledger module is stored in Leveldb; data is transmitted between nodes through gRPC.

The main body of the alliance chain public chain smart contract includes a public chain consensus management module, and the public chain consensus management module deploys three smart contracts on public chains such as Ethereum in a programmatic way, including an identity authentication smart contract, a consensus management smart contract and a certificate deposit. Smart contract to realize node management and consensus mechanism management of the local node main body of the alliance chain.

Among them, the identity authentication smart contract is used for the identity authentication management of the participating nodes of the alliance chain, and the public key of the alliance chain is stored in the smart contract; the consensus management smart contract is used to randomly assign the accounting rights of the nodes in the alliance chain and maintain the accounting history ; The smart contract for depository is used to save the block data about the blacklist of the alliance chain and the digital signature of the voting node for the block data.

In a preferred implementation given in this example, the consensus management module is based on the Ethereum public chain, and uses Solidity language to develop three smart contracts;

In another optional embodiment, a centralized consensus management module can also be used, that is, using the go language development program to realize the functions of identity authentication, consensus management and certificate storage, and run on a centralized server.

The blacklist submission record sharing ledger module generates a data block every 20 minutes, that is, the consortium chain (also referred to as the "blacklist consortium chain") generates a block every 20 minutes, which is collected by the node responsible for bookkeeping in this round for 20 minutes All transaction information submitted by all nodes (that is, the detailed information of the blacklist submission record), verify, package and generate block data, attach the hash value of the previous block, and calculate SHA256 to generate the block hash of this block. value, and generate block header information. The block header information includes: the block hash value of the previous block, the hash value of this block, the timestamp, the number of transactions in this block, and the private key signature of the accounting node; The block is sent to other nodes (voting nodes), and the block that is verified and signed by more than half of the nodes enters the confirmed state.

The packaging work of the accounting node includes:

1) Arrange all transaction information in chronological order and put them together;

2) Add the hash value of the previous block;

3) SHA 256 of the two-step data operation to generate the block hash value of this block;

4) Generate block header information. The block header information includes: the block hash value of the previous block, the hash value of the current block, the timestamp, the number of transactions in the block, and the private key signature of the accounting node.

The packaged block is sent by the accounting node to other nodes, and the block that has been verified and signed by more than half of the nodes enters the confirmed state, and its block hash value can be referenced by the next block.

Further, during the consensus verification process of the present invention, the registration information and public key addresses of all alliance nodes are stored in the identity authentication smart contract, and new alliance nodes can be added through the smart contract, and an existing alliance can also be deleted. node.

The consensus management smart contract randomly selects an address from the public key addresses of all alliance nodes every 20 minutes, and designates this address as the next round of billing nodes. Within 20 minutes, the node submits the block header information of this round to the smart contract for depositing the certificate for storage. If the accounting node does not submit the block header information within 20 minutes, the consensus management smart contract randomly selects another public key address as the accounting node for this round to ensure the execution of the contract.

The current round of bookkeeping nodes in the alliance chain should submit the block header information of the current round of blocks to the certification smart contract for certification. The block header information of the current round of blocks includes: the block hash value of the previous block, the current block The hash value of the block, the timestamp, the number of transactions in this block, and the private key signature of the accounting node.

This round of non-bookkeeping nodes (voting nodes) receives the block, verifies the transaction and the block, and after the verification is correct, submits the private key digital signature of the block to the smart contract for verification to be used for audit voting.

The certificate-storing smart contract saves the digital signature of the private key of each block from the non-accounting node, and records the number of audit votes. If more than half of the votes are voted, the block status will be set to the final status (Finalized). Only blocks in the "final state" can have their hash value referenced by the next block.

Among them, the verification of the transaction by the non-accounting node includes: 1) the correctness of the format of the transaction information, 2) the consistency of the 10 hash values in the transaction and the state change of the Bloom Filter data structure, 3) the private key in the transaction information Verification of correctness of digital signatures.

The verification of the block by the non-bookkeeping node includes: 1) the consistency of the transaction order and timestamp in the block, 2) the consistency of all transaction execution in the block and the final state of the Bloom Filter data structure, 3) the block data The correctness of the format, 4) the correctness of the hash value of the block header, and 5) the correctness of the digital signature of the private key of the accounting node.

After the verification is correct, the non-accounting node submits the digital signature of the private key of the block to the smart contract.

The block data after consensus is completed on the chain, and the participating nodes of the alliance chain can obtain credible blacklist data from the chain.

The system of the invention utilizes the advantages of the Bloom Filter technology in space efficiency, query efficiency and security, and combines the blockchain technology to realize the blacklist sharing and efficient retrieval functions without loss of privacy, and breaks through the storage capacity limitation of the blockchain; The invention adopts blockchain technology to constrain data sharing and consensus among nodes participating in the alliance through smart contracts, and automate execution, thereby realizing a credible and reliable data sharing system.

Example 2

The present invention also provides a method for multi-party cross-validation and sharing of blacklists, which is implemented based on the system in Embodiment 1 above, as shown in FIG. 2, and specifically includes the following steps

Obtaining blacklist data, calculating and storing it based on Bloom Filter, and retrieving and querying the stored blacklist data to determine whether the blacklist data exists in the shared library;

Record the submission details of the blacklist data, and send it to the accounting node on the blockchain, so that the accounting node can be packaged into a block and transmitted to each node;

Deploy smart contracts to manage nodes and consensus mechanisms on the blockchain.

The method of the present invention aims to use the Bloom Filter technology to realize the verification and sharing of blacklist data on the blockchain, and its implementation principle can refer to the relevant description in the above-mentioned Embodiment 1.

Specifically, with reference to Figures 1 and 3, in the method of the present invention, the step "obtaining blacklist data, calculating and storing it based on Bloom Filter, and retrieving and querying the stored blacklist data, determines whether the shared library has the Blacklist data" includes:

Obtain the blacklist data submitted by other institutions (it can be a universal unique identifier such as an ID card), and perform various hash operations on the obtained data, and the obtained operation results are mapped to the Bit bits of the Bloom Filter data structure to verify Whether the blacklist exists, and the number of submissions of the blacklist, and return the verification result; store each piece of blacklist data that has been verified by the operation to form a blacklist shared library based on the Bloom Filter data structure, and display the data in each blacklist data. The shared library is updated for query after the operation verification of the query; and when other business systems initiate a blacklist query request, two results are returned, whether the blacklist requested to be queried exists, and the number of times the blacklist has been submitted.

Specifically, the Bloom Filter described in the general method of the present invention adopts a Bloom Filter with a counter, preferably a dlCBF (d-Left Counting Bloom Filter), which can increase the number of elements by recording the Bit bits of the counter, so as to realize the element Delete, and can calculate the number of times that a blacklist is submitted by multiple parties; then when the blacklist is queried, it can not only return whether the element exists, but also return the number of times the element was submitted. For the multi-party verification and Confirmation is important.

In a specific example, the steps of "computing and storing it based on Bloom Filter, and retrieving and querying the stored blacklist data to determine whether the blacklist data exists in the shared library" are as follows:

S1. Obtain suspected (or confirmed) blacklist data, and obtain valid identification data of the blacklist data, for example, the valid identification data is ID card data;

S2. In the local environment, perform 10 hash operations on the acquired ID card data, including APHash, BKDRHash, BPHash, DJBHash, DEKHash, FNVHash, JSHash, PJWHash, RSHash and SDBMHash, and then obtain 10 hash operations. hash value;

S3. Submit 10 hash values to the blacklist shared library based on the Bloom Filter data structure, wherein:

S31. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 1, it means that other nodes have submitted the blacklist; then go to step S4.;

S32. If these 10 hash values are mapped to the corresponding bits in the Bloom Filter data structure are all 0, set the bit to 1; enter step S5.;

S4. Obtain the 10-bit count through the Bloom Filter counter, so as to know how many times the blacklist has been submitted before; the more the count, the higher the severity of the blacklist; plus 1;

S5. Set the value of the corresponding 10 bits in the Bloom Filter data structure to 1; and add 1 to the 10 bits of the counter respectively.

In this embodiment, the total number of bits m set by the Bloom Filter is 2 billion, the number of hash operation types k is 10, and if the storage rate of the Bloom Filter does not exceed 50%, the blacklist elements that can be accommodated are 100 million, and the storage capacity is large.

The step of "recording the submission details of the blacklist data and sending it to the accounting node on the blockchain, so that the accounting node can be packaged into a block and transmitted to each node" includes:

Record and submit the detailed information of the blacklist data to the Bloom Filter blacklist shared library, store it locally, and send it to the accounting node for the accounting node to package it into block data, and then pass it to each node to achieve inter-node communication. The data is consistent, and forms verifiable consistency with the Bloom Filter blacklist shared library; the submission record here can be regarded as a transaction in the blockchain.

Among them, when recording the detailed information of the submitted blacklist data to the Bloom Filter blacklist shared library, construct the transaction according to the following data structure:

The 10 hash values of the blacklist data, the hash value obtained by concatenating the 10 hash values and doing SHA 256, the count value of the blacklist on the Bloom Filter, the timestamp, the public key, and the private key of the node key digital signature.

The data block formed by the above data structure is sent to the accounting node for subsequent verification operations on the blockchain.

The step "Building a smart contract to manage nodes and consensus mechanisms on the blockchain" includes:

Deploy smart contracts on the public chain to perform identity authentication, consensus management, and/or deposit certificates for transactions and consensus processes between nodes.

The blockchain constructed in the present invention includes the main body of the local node of the alliance chain and the main body of the smart contract of the public chain of the alliance chain; wherein the main body of the local node of the alliance chain includes the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module, and is connected with the The SDK interface modules are jointly deployed locally on all nodes.

The peer-to-peer data sharing is realized between the nodes of the alliance chain through the Gossip protocol. The shared data includes the data on the Bloom Filter blacklist shared library module and the blacklist submission record shared ledger module.

The main body of the alliance chain public chain smart contract includes a public chain consensus management module, and the public chain consensus management module deploys three smart contracts on public chains such as Ethereum in a programmatic way, including an identity authentication smart contract, a consensus management smart contract and a certificate deposit. Smart contract to realize node management and consensus mechanism management of the local node main body of the alliance chain.

Among them, the identity authentication smart contract is used for the identity authentication management of the participating nodes of the alliance chain, and the public key of the alliance chain is stored in the smart contract; the consensus management smart contract is used to randomly assign the accounting rights of the nodes in the alliance chain and maintain the accounting history ; The smart contract for depository is used to save the block data about the blacklist of the alliance chain and the digital signature of the voting node for the block data.

In a preferred implementation given in this example, the consensus management module is based on the Ethereum public chain, and uses Solidity language to develop three smart contracts;

In another optional embodiment, a centralized consensus management module can also be used, that is, using the go language development program to realize the functions of identity authentication, consensus management and certificate storage, and run on a centralized server.

The alliance chain (also referred to as the "blacklist alliance chain") generates a block every 20 minutes, and the node responsible for bookkeeping in this round collects all transaction information submitted by all nodes within 20 minutes (that is, the details of the blacklist submission records). ), verify, package and generate block data, attach the hash value of the previous block, calculate SHA256 to generate the block hash value of this block, generate block header information, and the block header information includes: The block hash value, the hash value of this block, the timestamp, the number of transactions in this block, and the private key signature of the accounting node; then the block is sent to other nodes (voting nodes), verified by more than half of the nodes and confirmed. The signed block enters the confirmation state.

The packaging work of the accounting node includes:

1) Arrange all transaction information in chronological order and put them together;

2) Add the hash value of the previous block;

3) SHA 256 of the two-step data operation to generate the block hash value of this block;

4) Generate block header information. The block header information includes: the block hash value of the previous block, the hash value of the current block, the timestamp, the number of transactions in the block, and the private key signature of the accounting node.

The packaged block is sent by the accounting node to other nodes, and the block that has been verified and signed by more than half of the nodes enters the confirmed state, and its block hash value can be referenced by the next block.

Further, during the consensus verification process of the present invention, the registration information and public key addresses of all alliance nodes are stored in the identity authentication smart contract, and new alliance nodes can be added through the smart contract, and an existing alliance can also be deleted. node.

The consensus management smart contract randomly selects an address from the public key addresses of all alliance nodes every 20 minutes, and designates this address as the next round of billing nodes. Within 20 minutes, the node submits the block header information of this round to the smart contract for depositing the certificate for storage. If the accounting node does not submit the block header information within 20 minutes, the consensus management smart contract randomly selects another public key address as the accounting node for this round to ensure the execution of the contract.

The current round of bookkeeping nodes in the alliance chain should submit the block header information of the current round of blocks to the certification smart contract for certification. The block header information of the current round of blocks includes: the block hash value of the previous block, the current block The hash value of the block, the timestamp, the number of transactions in this block, and the private key signature of the accounting node.

This round of non-bookkeeping nodes (voting nodes) receives the block, verifies the transaction and the block, and after the verification is correct, submits the private key digital signature of the block to the smart contract for verification to be used for audit voting.

The certificate-storing smart contract saves the digital signature of the private key of each block from the non-accounting node, and records the number of audit votes. If more than half of the votes are voted, the block status will be set to the final status (Finalized). Only blocks in the "final state" can have their hash value referenced by the next block.

Among them, the verification of the transaction by the non-accounting node includes: 1) the correctness of the format of the transaction information, 2) the consistency of the 10 hash values in the transaction and the state change of the Bloom Filter data structure, 3) the private key in the transaction information Verification of correctness of digital signatures.

The verification of the block by the non-bookkeeping node includes: 1) the consistency of the transaction order and timestamp in the block, 2) the consistency of all transaction execution in the block and the final state of the Bloom Filter data structure, 3) the block data The correctness of the format, 4) the correctness of the hash value of the block header, and 5) the correctness of the digital signature of the private key of the accounting node.

After the verification is correct, the non-accounting node submits the digital signature of the private key of the block to the smart contract.

The block data after consensus is completed on the chain, and the participating nodes of the alliance chain can obtain credible blacklist data from the chain.

It should be noted that the implementation of the present invention and all functional operations provided herein can be implemented by digital electronic circuits, or by computer software, firmware or hardware, including the structures disclosed in this specification and its structural equivalents, or one of them. or a combination of more than one. Implementations of the present disclosure may be implemented as one or more computer program products, ie, one or more modules of computer program instructions encoded on a computer-readable medium for execution by or to control the operation of a data processing apparatus. operate. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition that affects a machine-readable propagated signal, or a combination of one or more thereof. The term "data processing apparatus" encompasses all apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may include code that creates an execution environment for the described computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more thereof.

A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and a computer program may be deployed in any form, including as a stand-alone program or As a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. Programs may be stored in sections of files that hold other programs or data (such as one or more scripts stored in a markup language document), in a single file dedicated to the program being described, or in multiple collaborative files (for example, a file that stores one or more modules, subroutines, or portions of code). A computer program can be deployed to be executed on one computer, or on multiple computers that are located at one site or distributed at multiple sites and interconnected by a communication network.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features thereof can be equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention. The scope of the invention should be included in the scope of the claims and description of the present invention.

Claims (10)

1. A blacklist multiparty cross validation and sharing system is characterized by comprising

The system comprises a Bloom Filter blacklist shared library module, a BloomFilter blacklist database module and a BloomFilter database module, wherein the BloomFilter blacklist shared library module is used for acquiring blacklist data, performing calculation and storage based on the Bloom Filter, and searching and querying the stored blacklist data;

the blacklist submission record shared account book module is used for recording detailed information submitted to the Bloom Filter blacklist shared library module and sending the detailed information to the accounting nodes on the block chain, so that the accounting nodes can be packaged into blocks and transmitted to each node;

the public chain consensus management module is used for deploying an intelligent contract on a public chain so as to carry out node management and consensus mechanism management on the nodes on the blockchain;

and the interface module is used for providing a standardized program interface for a service system to access so as to submit the blacklist data and inquire the blacklist data.

2. The blacklisting multi-party cross validation and sharing system according to claim 1, wherein the BloomFilter blacklisting shared library module is specifically used for

Carrying out various Hash operations on the acquired blacklist data, mapping the obtained operation result to a Bit of the module Bloom Filter data structure to verify whether the blacklist exists and the submission times of the blacklist, and returning the verification result;

storing each blacklist data subjected to operation verification to form a blacklist shared library based on a Bloom Filter data structure, and updating the shared library after the operation verification of each blacklist data for query;

when a blacklist query request is received, the module at least returns two results, namely whether the blacklist requested to be queried exists and the submission times of the blacklist.

3. The system of claim 2, wherein the Bloom Filter is a Bloom Filter with a counter, and the number of Bit increment elements of a data structure of the Bloom Filter and the number of times of submission of the blacklist are recorded by the counter.

4. The system of claim 2, wherein the blacklist multiparty cross validation and sharing system is configured to construct a transaction according to the following data structure when the blacklist submission record shared ledger module stores the detail information:

the node comprises a plurality of hash values of blacklist data, hash values obtained by performing encryption operation after the plurality of hash values are spliced, count values of the blacklist on a Bloom Filter, a timestamp, a public key and a private key digital signature of the node.

5. The blacklisted multi-party cross validation and sharing system of claim 1, wherein the blockchain includes a federation chain local node principal and a federation chain public chain intelligent contract principal;

the local node main body of the alliance chain comprises the Bloom Filter blacklist shared library module and a blacklist submission record shared account book module, and is deployed locally on all nodes together with the interface module;

the alliance chain public chain intelligent contract main body comprises a public chain consensus management module, and the public chain consensus management module deploys at least three intelligent contracts on a public chain in a program mode, wherein the intelligent contracts comprise an identity authentication intelligent contract, a consensus management intelligent contract and a storage intelligent contract.

6. The blacklisted multi-party cross-validation and sharing system according to claim 5, wherein an identity authentication intelligent contract is used for identity authentication management of federation chain participant nodes, the public key of a federation chain being stored in an intelligent contract; the consensus management intelligent contract is used for randomly distributing the accounting right of the nodes in the alliance chain and maintaining the accounting history; the evidence-preserving intelligent contract is used for preserving block data of the alliance chain, wherein the block data are related to the blacklist, and digital signatures of voting nodes aiming at the block data are preserved.

7. The blacklist multiparty cross validation and sharing system according to claim 4, wherein the blacklist submission record sharing book module generates a data block every other preset time period, the node currently responsible for accounting collects all transaction information submitted by all nodes in the preset time period, performs validation and packaging to generate block data, attaches the hash value of the previous block, performs encryption operation to generate the block hash value of the cost block, and generates block header information; and then sending the block to a voting node, and entering a determined state by using more than half of the blocks verified and signed by the nodes.

8. A blacklist multiparty cross validation and sharing method is characterized by comprising the following steps:

acquiring blacklist data, calculating and storing the blacklist data based on Bloom Filter, retrieving and querying the stored blacklist data, and determining whether the blacklist data exists in a shared library;

recording the submission detailed information of the blacklist data, and sending the submission detailed information to the accounting nodes on the block chain, so that the accounting nodes can be packaged into blocks and transmitted to each node;

and deploying an intelligent contract, and managing the nodes on the blockchain and a consensus mechanism.

9. The method for cross-validation and sharing of blacklist and multiple parties as claimed in claim 8, wherein obtaining blacklist data, performing operation and storage based on Bloom Filter, and searching and querying the stored blacklist data to determine whether the blacklist data exists in a shared library, specifically comprises:

s1, obtaining suspected or determined blacklist data, and taking effective identification data of the blacklist data;

s2, in a local environment, performing 10 hash operations including 10 hash operations of APHash, BKDRHAsh, BPHash, DJBHASh, DEKHASh, FNVHASh, JSHHash, PJWHASh, RSHash and SDBMHash on the obtained effective identification data, and then obtaining 10 hash values;

s3, submitting 10 hash values to a blacklist shared library based on the Bloom Filter data structure, wherein:

s31, if the 10 hash values are mapped to corresponding bits of the Bloom Filter data structure to be 1, judging that other nodes submit the blacklist; entering a step S4;

s32, if the 10 hash values are mapped to corresponding bits of the Bloom Filter data structure and are all 0, setting the bits to be 1; entering a step S5;

s4, counting the 10 bits through a Bloom Filter counter, so that the submission of the blacklist for a plurality of times is known;

s5, setting the value of the corresponding 10 bits in the Bloom Filter data structure as 1; and 1 is added to 10 bits of the counter, respectively.

10. The blacklisting multi-party cross validation and sharing method according to claim 8, wherein deploying an intelligent contract to manage nodes and a consensus mechanism on the blockchain specifically comprises:

three intelligent contracts are deployed on the public chain, wherein the three intelligent contracts comprise an identity authentication intelligent contract, a consensus management intelligent contract and a storage intelligent contract, and the identity authentication intelligent contract is used for identity authentication management of the nodes participating in the public chain; the consensus management intelligent contract is used for randomly distributing the accounting right of the nodes in the alliance chain and maintaining the accounting history; the evidence-storing intelligent contract is used for storing block data of the alliance chain, which relates to the blacklist, and a digital signature of the voting node aiming at the block data;

the alliance chain generates a data block every other preset time period, all transaction information submitted by all nodes in the preset time period is collected by the node which is currently responsible for accounting, verification and packaging are carried out to generate block data, the hash value of the previous block is attached, the block hash value of the cost block is generated through encryption operation, and block header information is generated; then, the block is sent to a voting node, and more than half of the blocks verified and signed by the node enter a determined state;

randomly selecting an address from public key addresses of all alliance nodes every a preset time period by the consensus management intelligent contract, designating the address as a next round of accounting node, and submitting the round of block header information to a certificate-storing intelligent contract for certificate storage by the node within the preset time period; otherwise, the consensus management intelligent contract randomly selects another public key address as the accounting node of the current round.

Images