WO2019042176A1

WO2019042176A1 - Blacklist data exchange method and application server

Info

Publication number: WO2019042176A1
Application number: PCT/CN2018/101265
Authority: WO
Inventors: 郭鹏程
Original assignee: 深圳壹账通智能科技有限公司
Priority date: 2017-08-31
Filing date: 2018-08-20
Publication date: 2019-03-07
Also published as: CN107896157A; CN107896157B

Abstract

Disclosed in the present application is a blacklist data exchange method, for use in an application server, the application server being a main node and being in data communication with a plurality of sub-nodes, the method comprising: monitoring a blacklist data exchange request and response between sub-nodes; on the basis of the monitoring results, allocating a corresponding responsibility to each sub-node; notifying the sub-nodes not participating in the data exchange to act as supervisors for checking the exchange conditions of the data exchange parties; and notifying the sub-nodes having passed the exchange condition checking to implement one-to-one data exchange. Also provided in the present application are an application server and a computer readable storage medium. The blacklist data exchange method, the application server, and the computer readable storage medium provided in the present application can use blockchain-based smart contract technology to implement blacklist data exchange and management thereof.

Description

Blacklist data exchange method and application server

This application claims the priority of the Chinese Patent Application filed on August 31, 2017, the Chinese Patent Application No. 201710773975.1, the name of the invention is "blacklist data exchange method and application server", the entire contents of which are incorporated by reference in the application. .

Technical field

The present application relates to the field of data processing technologies, and in particular, to a blacklist data exchange method and an application server.

Background technique

At present, the blacklist exchange sharing in the industry mainly involves the use of various operating methods by data storage center units to attract external organizations to upload blacklist data to central units, and then share them with other external organizations by the central unit. External organizations have no control over the use of uploaded data. The favorable rules for sharing data are not reliable enough because of the central unit operation definition. Therefore, the willingness of external organizations to upload and exchange data is weak, and data islands are difficult to break. In addition, the quality of the data uploaded by external agencies received by the central unit is uneven, and it is difficult for the central unit to regulate and constrain the data, resulting in high cost of data post-processing, and the cost of external sharing and reuse is very high.

Summary of the invention

In view of this, the present application proposes a blacklist data exchange method and an application server to solve the problem of how to standardize the exchange and management of blacklist data.

First, in order to achieve the above object, the present application provides a blacklist data exchange method, which is applied to an application server, where the application server is a main node and performs data communication with multiple sub-nodes, and the method includes the following steps:

Monitoring blacklist data exchange requests and responses between the sub-nodes;

According to the monitoring results, each sub-node is assigned corresponding responsibilities;

Notifying the sub-nodes not participating in the exchange as the supervisor, and verifying the exchange conditions of the exchange parties; and

The sub-nodes that have passed the exchange condition check are notified to exchange data one-to-one.

Optionally, the method further comprises the steps before monitoring:

Perform pre-verification on the blacklist data uploaded by the sub-node;

Performing the verification and classification process on the node according to the pre-verification result.

Optionally, the pre-verification process is performed by the primary node to verify whether the blacklist data meets requirements according to a preset rule, where the preset rule includes: the data format is correct, the user privacy cannot be written, and there is no duplication or deletion. False data.

Optionally, the verification grading process is to set a corresponding exchange level for the corresponding node according to the degree of standardization of the blacklist data, and then authorize and allocate the corresponding transaction currency to the node.

Optionally, the verification grading process further includes:

Setting that when the standardization degree of the blacklist data is high, the node is exchanged with more data in a smaller transaction currency;

And assigning a corresponding quantity of the transaction currency to the node according to the data amount of the blacklist data and a preset ratio.

Optionally, the step of assigning corresponding responsibilities to each sub-node according to the monitoring result specifically includes:

Configuring a sub-node that issues a blacklist data exchange request as a data requester, configuring a sub-node that agrees to the blacklist data exchange request as a data provider, and not issuing a blacklist data exchange request and response or the response The feedback result is that the sub-nodes that do not agree with the blacklist data exchange request or select one or more of them are configured as supervisors.

Optionally, the exchange condition includes whether the blacklist data provided by the data provider meets the preset rule and whether the data requestor has a sufficient amount of transaction currency, and when both parties of the exchange reach the exchange condition, that is, the data provider provides When the blacklist data meets the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, it indicates that the verification is passed.

Optionally, the step of notifying the one-to-one data exchange by the node that exchanges the condition check includes:

Calculating a transaction currency that the data requestor needs to pay according to the exchange level of the data requester and the data amount of the blacklist data;

After the data requester successfully pays, the blacklist data uploaded by the data provider is copied to the data requester.

In addition, to achieve the above object, the present application further provides an application server, including a memory, a processor, and a blacklist data exchange system stored on the memory and operable on the processor, the blacklist data exchange The steps of the blacklist data exchange method as described above are implemented when the system is executed by the processor.

Further, to achieve the above object, the present application further provides a computer readable storage medium storing a blacklist data exchange system, the blacklist data exchange system being executable by at least one processor, The step of causing the at least one processor to perform the blacklist data exchange method as described above.

Compared with the prior art, the blacklist data exchange method, the application server, and the computer readable storage medium proposed by the present application may use one central unit as the primary node of the blockchain, and other cooperative organizations as the sub-nodes, and utilize the based region. The blockchain's smart contract technology performs blacklist data exchange and management. The blacklist data uploaded by the sub-nodes is pre-verified for authenticity classification, and the sub-nodes that do not participate in the exchange are used as supervisors to verify the exchange conditions of the exchange parties, thereby ensuring the true compliance of the exchanged data. Since the exchange process is clear and transparent, the sharing of blacklist data is conducive to the business development of each organization and dispels the concerns of the cooperation agencies to upload data. The central unit can escort the quality of the exchanged data and establish a data ecosystem.

DRAWINGS

1 is a schematic diagram of an optional application environment of each embodiment of the present application;

2 is a schematic diagram of an optional hardware architecture of the application server of FIG. 1;

3 is a schematic diagram of a program module of a first embodiment of a blacklist data exchange system of the present application;

4 is a schematic diagram of a program module of a second embodiment of the blacklist data exchange system of the present application;

5 is a schematic flowchart of a first embodiment of a blacklist data exchange method according to the present application;

FIG. 6 is a schematic flowchart diagram of a second embodiment of a blacklist data exchange method according to the present application.

The implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

It should be noted that the descriptions of "first", "second" and the like in the present application are for the purpose of description only, and are not to be construed as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. . Thus, features defining "first" and "second" may include at least one of the features, either explicitly or implicitly. In addition, the technical solutions between the various embodiments may be combined with each other, but must be based on the realization of those skilled in the art, and when the combination of the technical solutions is contradictory or impossible to implement, it should be considered that the combination of the technical solutions does not exist. Nor is it within the scope of protection required by this application.

Referring to FIG. 1 , it is a schematic diagram of an optional application environment of each embodiment of the present application.

In this embodiment, the present application is applicable to an application environment including, but not limited to, the terminal device 1, the application server 2, and the network 3. The application server 2, the blockchain network 3, and the plurality of terminal devices 1 together form a blockchain network system for performing blacklist data exchange and management.

The application server 2 is a device capable of automatically performing numerical calculation and/or information processing according to an instruction set or stored in advance, for centrally storing and managing blacklist data to be exchanged, that is, the blockchain. The primary node of the network system. The application server 2 may be a computer, a single network server, a server group composed of a plurality of network servers, or a cloud-based cloud composed of a large number of hosts or network servers.

The blockchain network 3 is used for data transmission and interaction in the blockchain network system. The application server 2 performs data communication with a plurality of terminal devices 1 through the blockchain network 3, and the network may be an intranet, an Internet, or a Global System of Mobile communication. GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, etc.

The terminal device 1 is configured to exchange the blacklist data with each other as a sub-node of the blockchain network system. The terminal device 1 may be a mobile phone, a smart phone, a notebook computer, a digital broadcast receiver, a PDA (Personal Digital Assistant), a PAD (Tablet PC), a PMP (Portable Multimedia Player), a navigation device, an in-vehicle device, or the like. Mobile devices, as well as fixed terminals such as digital TVs, desktop computers, notebooks, servers, and the like.

Referring to FIG. 2, it is a schematic diagram of an optional hardware architecture of the application server 2 in FIG. In this embodiment, the application server 2 may include, but is not limited to, the memory 11, the processor 12, and the network interface 13 being communicably connected to each other through a system bus. It is to be noted that FIG. 2 only shows the application server 2 with components 11-13, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.

The memory 11 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (eg, SD or DX memory, etc.), and a random access memory (RAM). , static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), magnetic memory, magnetic disk, optical disk, and the like. In some embodiments, the memory 11 may be an internal storage unit of the application server 2, such as a hard disk or memory of the application server 2. In other embodiments, the memory 11 may also be an external storage device of the application server 2, such as a plug-in hard disk equipped on the application server 2, a smart memory card (SMC), and a secure digital number. (Secure Digital, SD) card, flash card, etc. Of course, the memory 11 can also include both the internal storage unit of the application server 2 and its external storage device. In this embodiment, the memory 11 is generally used to store an operating system installed in the application server 2 and various types of application software, such as program codes of the blacklist data exchange system 200. Further, the memory 11 can also be used to temporarily store various types of data that have been output or are to be output.

The processor 12 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 12 is typically used to control the overall operation of the application server 2, such as performing control and processing related to data interaction or communication with the terminal device 1. In this embodiment, the processor 12 is configured to run program code or process data stored in the memory 11, such as running the blacklist data exchange system 200 and the like.

The network interface 13 may comprise a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the application server 2 and other electronic devices. In this embodiment, the network interface 13 is mainly used to connect the application server 2 to one or more of the terminal devices 1 through the blockchain network 3, and the application server 2 and the one or A data transmission channel and a communication connection are established between the plurality of terminal devices 1.

So far, the application environment of the various embodiments of the present application and the hardware structure and functions of related devices have been described in detail. Hereinafter, various embodiments of the present application will be proposed based on the above-described application environment and related devices.

First, the present application proposes a blacklist data exchange system 200.

Referring to FIG. 3, it is a program module diagram of the first embodiment of the blacklist data exchange system 200 of the present application.

In this embodiment, the blacklist data exchange system 200 includes a series of computer program instructions stored in the memory 11, and when the computer program instructions are executed by the processor 12, the blacklist of the embodiments of the present application can be implemented. Data exchange operation. In the blockchain for blacklist data exchange, one central unit is used as the primary node, and other cooperative organizations are used as the branch nodes. The application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node. The plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes. The blockchain-based intelligent contract technology is used to exchange and manage the blacklist data according to the agreed exchange rules between the nodes to ensure that the entire data exchange process is fair and transparent, and the process of obtaining data by the cooperative organization is standardized.

In some embodiments, the blacklist data exchange system 200 can be divided into one or more modules based on the particular operations implemented by the various portions of the computer program instructions. For example, in FIG. 3, the blacklist data exchange system 200 can be divided into a monitoring module 201, an allocation module 202, and a notification module 203. among them:

The monitoring module 201 is configured to monitor a blacklist data exchange request and response between the node nodes.

Specifically, each of the sub-nodes having the data exchange requirement sequentially sends a blacklist data exchange request to the other sub-nodes through the blockchain network 3. The request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like. The sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request. The response includes an identifier of the response, information of the corresponding blacklist data, an identity of the demanding node, an identity of the response node, a feedback result of the request, and the like. The feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request. The feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange. The monitoring module 201 can monitor requests and responses between the various sub-nodes. The sub-node that receives the blacklist data exchange request responds automatically, tries to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.

The allocating module 202 is configured to allocate corresponding responsibilities to each sub-node according to the monitoring result.

For example, the distribution module 202 configures the sub-node that issues the blacklist data exchange request as the data requester, configures the sub-node that agrees to the blacklist data exchange request as the data provider, and does not issue the blacklist data exchange request and response or The sub-nodes that disagree with the blacklist data exchange request (or select one or more of them) are configured as supervisors.

The notification module 203 is configured to notify the branch node that does not participate in the current exchange as the supervisor, and check the exchange conditions of the exchange parties.

Specifically, before performing the exchange of the blacklist data, each of the node nodes uploads blacklist data to the master node (the application server 2), and the master node allocates a certain number of transaction coins (bits) for each node. Currency) for subsequent exchanges. The supervisor can obtain the blacklist data provided by the data provider (that is, the blacklist data uploaded by the data provider to the master node) from the master node, and perform verification. The exchange condition includes whether the blacklist data provided by the data provider conforms to a preset rule and whether the data requestor has a sufficient amount of transaction currency. In this embodiment, the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like. In addition, according to the data amount of the blacklist data and the preset ratio (the ratio between the amount of data and the number of coins), the data requester needs to pay a corresponding amount of the transaction currency. When both parties of the exchange reach the exchange condition, that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, the verification is passed, this time The exchange can proceed.

The notification module 203 is further configured to notify the sub-nodes that exchange the condition check to perform data exchange one-to-one.

Specifically, after the exchange conditions of both parties of the exchange are verified, the notification module 203 notifies the data requester and the node of the data provider to start data exchange. The data providing direction data requester shares its pre-stored blacklist data (synchronizes the related data to the data requester), and the data requester pays the data provider according to the exchange level corresponding to the node and the data amount of the blacklist data. The corresponding number of trading coins. The notification module 203 needs to calculate the transaction currency that the data requester needs to pay according to the exchange level of the data requester and the data amount of the blacklist data, and upload the data provider after the data requester successfully sends the data. The blacklist data copy is synchronized to the data requester.

Referring to FIG. 4, it is a program module diagram of a second embodiment of the blacklist data exchange system 200 of the present application. In this embodiment, the blacklist data exchange system 200 includes a series of computer program instructions stored in the memory 11, and when the computer program instructions are executed by the processor 12, the blacklist of the embodiments of the present application can be implemented. Data exchange operation. In the blockchain for blacklist data exchange, one central unit is used as the primary node, and other cooperative organizations are used as the branch nodes. The application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node. The plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes.

In this embodiment, the blacklist data exchange system 200 includes a pre-verification module 204 and a classification module 205 in addition to the monitoring module 201, the distribution module 202, and the notification module 203 in the first embodiment.

The pre-verification module 204 is configured to perform pre-verification on the blacklist data uploaded by the sub-node.

Specifically, when a sub-node uploads blacklist data to the master node (the application server 2), pre-verification is performed with the master node. The pre-verification process is that the pre-verification module 204 verifies whether the blacklist data meets the requirements according to a preset rule. In this embodiment, the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.

The grading module 205 is configured to perform a grading process on the node according to the pre-verification result.

Specifically, the grading module 205 performs a grading process on the blacklist data according to the verification result of the blacklist data, and mainly sets a corresponding exchange level according to the standardization degree of the blacklist data for the corresponding node, and then Authorize and assign the corresponding transaction currency to the sub-node. For example, when the degree of standardization of the blacklist data is high, the node can subsequently exchange more data with less transaction currency. After the blacklist data is verified, the master node authorizes the node to perform blacklist data exchange, and allocates a corresponding number of transactions to the node according to the data amount of the blacklist data and a preset ratio. currency.

In addition, the present application also proposes a blacklist data exchange method.

Referring to FIG. 5, it is a schematic flowchart of the first embodiment of the blacklist data exchange method of the present application. In the blockchain for blacklist data exchange, one central unit is used as the primary node, and other cooperative organizations are used as the branch nodes. The application server 2 is a central unit in the blockchain for performing blacklist data exchange, that is, a master node. The plurality of terminal devices 1 are other cooperative mechanisms in the blockchain for performing blacklist data exchange, that is, minute nodes. The blockchain-based intelligent contract technology is used to exchange and manage the blacklist data according to the agreed exchange rules between the nodes to ensure that the entire data exchange process is fair and transparent, and the process of obtaining data by the cooperative organization is standardized.

In this embodiment, the order of execution of the steps in the flowchart shown in FIG. 5 may be changed according to different requirements, and some steps may be omitted. The method includes the following steps:

Step S600, monitoring a blacklist data exchange request and response between the node nodes.

Specifically, each of the sub-nodes having the data exchange requirement sequentially sends a blacklist data exchange request to the other sub-nodes through the blockchain network 3. The request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like. The sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request. The response includes an identifier of the response, information of the corresponding blacklist data, an identity of the demanding node, an identity of the response node, a feedback result of the request, and the like. The feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request. The feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange. The application server 2 as a master node can monitor requests and responses between the various node nodes. The sub-node that receives the blacklist data exchange request automatically responds, attempts to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.

Step S602, assigning respective responsibilities to each of the sub-nodes according to the monitoring result.

For example, the application server 2 configures the sub-node that issues the blacklist data exchange request as the data requester, configures the sub-node that agrees to the blacklist data exchange request as the data provider, and does not issue the blacklist data exchange request and The sub-nodes that answer or disagree with the blacklist data exchange request (or select one or more of them) are configured as supervisors.

Step S604, notifying the sub-nodes that do not participate in the current exchange as the supervisory party, and verifying the exchange conditions of the exchange parties.

Step S606, notifying that the sub-nodes that exchange the condition check perform one-to-one data exchange.

Specifically, after the exchange conditions of both parties of the exchange are verified, the application server 2 notifies the data requester and the node of the data provider to start data exchange. The data providing direction data requester shares its pre-stored blacklist data (synchronizes the related data to the data requester), and the data requester pays the data provider according to the exchange level corresponding to the node and the data amount of the blacklist data. The corresponding number of trading coins. The application server 2 needs to calculate a transaction currency that the data requester needs to pay according to the exchange level of the data requester and the data volume of the blacklist data, and when the data requester successfully pays, the data provider is The uploaded blacklist data is copied to the data requester.

After the transaction currency is used up, the sub-node can acquire the transaction currency again by uploading new blacklist data.

As shown in FIG. 6, it is a schematic flowchart of a second embodiment of the blacklist data exchange method of the present application. In this embodiment, the steps S704-S710 of the blacklist data exchange method are similar to the steps S600-S606 of the first embodiment, except that the method further includes steps S700-S702.

The method includes the following steps:

Step S700: Perform pre-verification on the blacklist data uploaded by the sub-node.

Specifically, when a sub-node uploads blacklist data to the master node (the application server 2), pre-verification is performed with the master node. The pre-verification process is performed by the main node according to a preset rule to verify whether the blacklist data meets the requirements. In this embodiment, the preset rule may include: the data format is correct, the user privacy cannot be written, and there is no duplicate, missing, false data, or the like.

Step S702, performing a truth-grading process on the node according to the pre-verification result.

Specifically, the master node performs the authentication and classification process according to the verification result of the blacklist data, and mainly sets a corresponding exchange level for the corresponding node according to the standardization degree of the blacklist data. The sub-node is then authorized and assigned the corresponding transaction currency. For example, when the degree of standardization of the blacklist data is high, the node can subsequently exchange more data with less transaction currency. After the blacklist data is verified, the master node authorizes the node to perform blacklist data exchange, and allocates a corresponding number of transactions to the node according to the data amount of the blacklist data and a preset ratio. currency.

Step S704, monitoring a blacklist data exchange request and a response between the node nodes.

Specifically, each of the sub-nodes having data exchange requirements sequentially sends blacklist data exchange requests to other sub-nodes through the blockchain network 3. The request includes an identifier of the request, information of the requested blacklist data, an identity of the demanding node, and the like. The sub-node receiving the blacklist data exchange request determines whether to agree to perform the current blacklist data exchange according to its own needs and the number of remaining transaction coins, and then responds to the blacklist data exchange request. The response includes an identifier of the response, information of the corresponding blacklist data, an identity identifier of the demanding node, an identity of the response node, a feedback result of the request, and the like. The feedback result includes agreeing to the blacklist data exchange request and disagreeing with the blacklist data exchange request. The feedback result is that the sub-node that does not agree with the blacklist data exchange request or does not issue the response does not participate in the current data exchange. The application server 2 as a master node can monitor requests and responses between the various node nodes. The sub-node that receives the blacklist data exchange request automatically responds, attempts to start data exchange with the data provider, and publicly broadcasts the exchange behavior to other sub-nodes.

Step S706, assigning respective responsibilities to each of the sub-nodes according to the monitoring result.

Step S708, notifying the sub-nodes that do not participate in the current exchange as the supervisor, and verifying the exchange conditions of the exchange parties.

Specifically, the supervisor may obtain blacklist data (that is, blacklist data uploaded by the data provider to the master node) provided by the data provider from the master node, and perform verification. The exchange condition includes whether the blacklist data provided by the data provider conforms to the preset rule and whether the data requestor has a sufficient amount of transaction currency. When both parties of the exchange reach the exchange condition, that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, the verification is passed, this time The exchange can proceed.

Step S710, notifying that the sub-nodes that exchange the condition check perform one-to-one data exchange.

In addition, according to the pre-verification condition of the blacklist data uploaded by the sub-node and the performance in the data exchange process, the exchange level corresponding to the sub-node can be adjusted.

The serial numbers of the embodiments of the present application are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better. Implementation. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.

The above is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent application, and the equivalent structure or equivalent process transformations made by the specification and the drawings of the present application, or directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of this application.

Claims

A blacklist data exchange method is applied to an application server, where the application server is a main node and performs data communication with a plurality of sub-nodes, and the method includes the following steps:

Monitoring blacklist data exchange requests and responses between the sub-nodes;

According to the monitoring results, each sub-node is assigned corresponding responsibilities;

Notifying the sub-nodes not participating in the exchange as the supervisor, and verifying the exchange conditions of the exchange parties; and

The sub-nodes that have passed the exchange condition check are notified to exchange data one-to-one.
The blacklist data exchange method according to claim 1, wherein the method further comprises the steps of: before performing monitoring:

Perform pre-verification on the blacklist data uploaded by the sub-node;

Performing the verification and classification process on the node according to the pre-verification result.
The blacklist data exchange method according to claim 2, wherein the pre-verification process is performed by the main node to verify whether the blacklist data meets requirements according to a preset rule, and the preset rule includes: the data format is correct. , can not write user privacy, can not have duplicates, missing, false data.
The blacklist data exchange method according to claim 2, wherein the verification leveling process is to set a corresponding exchange level according to the degree of standardization of the blacklist data for the corresponding node, and then to the The sub-nodes authorize and assign the corresponding transaction currency.
The blacklist data exchange method according to claim 4, wherein the verification level processing further comprises:

Setting that when the standardization degree of the blacklist data is high, the node is exchanged with more data in a smaller transaction currency;

And assigning a corresponding quantity of the transaction currency to the node according to the data amount of the blacklist data and a preset ratio.
The blacklist data exchange method according to claim 2, wherein the step of assigning corresponding responsibilities to each of the sub-nodes according to the monitoring result comprises:

Configuring a sub-node that issues a blacklist data exchange request as a data requester, configuring a sub-node that agrees to the blacklist data exchange request as a data provider, and not issuing a blacklist data exchange request and response or the response The feedback result is that the sub-nodes that do not agree with the blacklist data exchange request or select one or more of them are configured as supervisors.
The blacklist data exchange method according to claim 3, wherein the exchange condition comprises whether the blacklist data provided by the data provider meets the preset rule and whether the data requestor has a sufficient amount of transaction currency. When both parties of the exchange reach the exchange condition, that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, it indicates that the verification passes.
The blacklist data exchange method according to claim 2, wherein the step of notifying the one-to-one data exchange by the sub-nodes that exchange the condition check includes:

Calculating a transaction currency that the data requestor needs to pay according to the exchange level of the data requester and the data amount of the blacklist data;

After the data requester successfully pays, the blacklist data uploaded by the data provider is copied to the data requester.
An application server, wherein the application server is a main node, and performs data communication with a plurality of sub-nodes, where the application server includes a memory, a processor, and is stored on the memory and can be on the processor. The running blacklist data exchange system, when the blacklist data exchange system is executed by the processor, implements the following steps:

Monitoring blacklist data exchange requests and responses between the sub-nodes;

According to the monitoring results, each sub-node is assigned corresponding responsibilities;

Notifying the sub-nodes not participating in the exchange as the supervisor, and verifying the exchange conditions of the exchange parties; and

The sub-nodes that have passed the exchange condition check are notified to exchange data one-to-one.
The application server according to claim 9, wherein when the blacklist data exchange system is executed by the processor, the method further comprises the steps of:

Perform pre-verification on the blacklist data uploaded by the sub-node;

Performing the verification and classification process on the node according to the pre-verification result.
The application server according to claim 10, wherein the pre-verification process is performed by the main node to verify whether the blacklist data meets requirements according to a preset rule, and the preset rule includes: the data format is correct and cannot be written. Into user privacy, there can be no duplicates, missing, or false data.
The application server according to claim 10, wherein the authentication leveling process is to set a corresponding switching level according to the degree of standardization of the blacklist data for the corresponding node, and then perform the switching level to the node. Authorize and assign the corresponding transaction currency.
The application server according to claim 12, wherein the verification grading process further comprises:

Setting that when the standardization degree of the blacklist data is high, the node is exchanged with more data in a smaller transaction currency;

The corresponding number of transaction coins are allocated to the sub-node according to the data amount of the blacklist data and a preset ratio.
The application server according to claim 10, wherein the step of assigning respective responsibilities to each of the sub-nodes according to the monitoring result comprises:

Configuring a sub-node that issues a blacklist data exchange request as a data requester, configuring a sub-node that agrees to the blacklist data exchange request as a data provider, and not issuing a blacklist data exchange request and response or the response The feedback result is that the sub-nodes that do not agree with the blacklist data exchange request or select one or more of them are configured as supervisors.
The application server according to claim 11, wherein the exchange condition comprises whether the blacklist data provided by the data provider meets the preset rule and whether the data requestor has a sufficient amount of transaction currency, when both parties exchange When the exchange condition is reached, that is, the blacklist data provided by the data provider conforms to the preset rule and the data requester has a sufficient amount of transaction currency corresponding to the blacklist data, the verification is passed.
The application server according to claim 10, wherein the step of notifying the one-to-one data exchange by the sub-nodes that exchange the condition check includes:

Calculating a transaction currency that the data requestor needs to pay according to the exchange level of the data requester and the data amount of the blacklist data;

After the data requester successfully pays, the blacklist data uploaded by the data provider is copied to the data requester.
A computer readable storage medium storing a blacklist data exchange system, the blacklist data exchange system being executable by at least one processor to cause the at least one processor to perform the following steps:

Monitoring blacklist data exchange requests and responses between sub-nodes;

According to the monitoring results, each sub-node is assigned corresponding responsibilities;

Notifying the sub-nodes not participating in the exchange as the supervisor, and verifying the exchange conditions of the exchange parties; and

The sub-nodes that have passed the exchange condition check are notified to exchange data one-to-one.
The computer readable storage medium of claim 17, wherein when the blacklist data exchange system is executed by the processor, the method further comprises the steps of:

Perform pre-verification on the blacklist data uploaded by the sub-node;

Performing the verification and classification process on the node according to the pre-verification result.
The computer readable storage medium according to claim 18, wherein the verification leveling process is to set a corresponding exchange level for the corresponding node according to the degree of standardization of the blacklist data, and then to the The sub-nodes authorize and assign the corresponding transaction currency.
The computer readable storage medium of claim 19, wherein the verification grading process further comprises:

Setting that when the standardization degree of the blacklist data is high, the node is exchanged with more data in a smaller transaction currency;

And assigning a corresponding quantity of the transaction currency to the node according to the data amount of the blacklist data and a preset ratio.