CN112968901A - Blacklist block chain consensus method and device - Google Patents

Blacklist block chain consensus method and device Download PDF

Info

Publication number
CN112968901A
CN112968901A CN202110220423.4A CN202110220423A CN112968901A CN 112968901 A CN112968901 A CN 112968901A CN 202110220423 A CN202110220423 A CN 202110220423A CN 112968901 A CN112968901 A CN 112968901A
Authority
CN
China
Prior art keywords
consensus
blacklist
proposal
node
voting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110220423.4A
Other languages
Chinese (zh)
Inventor
王瑞
李子轩
魏超
史表师
徐红娟
齐超
尹彦斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Sankuai Online Technology Co Ltd
Original Assignee
Beijing Sankuai Online Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Sankuai Online Technology Co Ltd filed Critical Beijing Sankuai Online Technology Co Ltd
Priority to CN202110220423.4A priority Critical patent/CN112968901A/en
Publication of CN112968901A publication Critical patent/CN112968901A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The specification discloses a blacklist block chain consensus method and device. Any consensus node in the consensus network can initiate a blacklist proposal, the blacklist proposal is stored in a block chain after the consensus passes, each consensus node can vote for the blacklist proposal according to a self-wind control strategy and stores the corresponding relation between the voting result and the blacklist proposal in the block chain after the voting result consensus passes, and each consensus node can flexibly use the blacklist proposal and the voting result stored in the block chain for wind control based on requirements. The method has the advantages that the generalization of the blacklist in the same field is realized, the verifiability of the blacklist is guaranteed, meanwhile, the theoretic conclusion under the blacklist is not determined, the user decides the blacklist, and the flexibility of the blacklist is guaranteed.

Description

Blacklist block chain consensus method and device
Technical Field
The present disclosure relates to the field of information technologies, and in particular, to a block chain consensus method and apparatus for a blacklist.
Background
Typically, different organizations have their own user blacklists or whitelists. Generally, users in the black list are distressed persons or distressed institutions with behaviors of default, law violation and the like, and users in the white list are persons or institutions with better credit. For users on the blacklist, the organization holding the blacklist needs to service them or not provide them with services for risk control.
Currently, some organizations only control the risk of users according to their blacklists, and lack blacklist communication and sharing with other organizations, which results in message blocking among organizations. When these organizations execute services, if a user who is lost in the blacklist of another organization encounters a risk that the user who is lost is not known because the blacklist is not shared between these organizations and the other organization, the loss of the organization may be caused by providing services to the user who is lost. In addition, as no blacklist sharing is performed among organizations, different organizations need to repeatedly establish the blacklist for the same lost-credit user, which causes serious waste of resources and low utilization rate of the blacklist among different organizations. For some organizations which share the blacklist, the authenticity and the reliability of the blacklist mutually provided among the organizations are difficult to guarantee, and whether a false blacklist organization maliciously provided is difficult to verify or not still exists.
Disclosure of Invention
The present disclosure provides a method and an apparatus for identifying a black list block chain, which partially solve the above problems in the prior art.
The technical scheme adopted by the specification is as follows:
the specification provides a blacklist block chain consensus method, a consensus network is composed of a plurality of consensus nodes, and the method comprises the following steps:
a consensus node in the consensus network acquires a blacklist proposal to be consensus, broadcasts the blacklist proposal to other consensus nodes, and performs consensus on the blacklist proposal;
if the blacklist proposal is determined to pass the consensus, the consensus node stores the blacklist proposal into the block chain maintained by the consensus node;
the consensus node votes whether the blacklist proposal is approved or not according to a self wind control strategy, and broadcasts a voting result to other consensus nodes so as to perform consensus on the voting result;
and when the consensus node determines that the voting result consensus passes, storing the voting result and the corresponding relation between the voting result and the blacklist proposal into the block chain maintained by the consensus node, wherein the voting result of the blacklist proposal stored in the block chain is used for determining a wind control strategy when the risk control is performed.
Optionally, the method further comprises:
the consensus node responds to a network access request sent by a node to be accessed to the network and broadcasts the network access request to other consensus nodes in the consensus network;
after determining that the network access request is passed, sending a resource acquisition request to the node to be accessed to enable the node to be accessed to provide network access resources;
and executing a resource sharing service according to the network access resources provided by the nodes to be accessed, the blacklist proposals stored in the self-maintained block chain and the voting results corresponding to the blacklist proposals, and taking the nodes to be accessed as consensus nodes in the consensus network.
Optionally, executing a resource sharing service according to the network access resource provided by the node to be networked, each blacklist proposal stored in the block chain maintained by the node to be networked, and the voting result corresponding to each blacklist proposal, specifically including:
calling a preset intelligent contract stored in the block chain according to the network access resource provided by the node to be accessed;
and executing the intelligent contract to distribute the resources to the consensus nodes initiating the blacklist proposals according to the voting results of the blacklist proposals stored in the block chain.
Optionally, allocating the resource to the consensus node initiating each blacklist proposal according to the voting result obtained by each blacklist proposal stored in the block chain, specifically including:
determining a consensus node initiating each blacklist proposal stored in the block chain as a proposal node;
aiming at each proposal node, determining the number of votes in voting results obtained by each blacklist proposal initiated by the proposal node as a node voting value;
determining the total number of voting results belonging to votes obtained by each blacklist proposal stored in the block chain as a total voting value;
and allocating the resources to the proposal node according to the ratio of the node voting value to the total voting value.
Optionally, the method further comprises:
for each consensus node in the consensus network, after the consensus node agrees with the voting result of the blacklist proposal, the consensus node in the consensus network calls an intelligent contract according to the consensus result;
executing the intelligent contract to allocate resources to the consensus nodes in the consensus network.
Optionally, the method further comprises:
a consensus node in the consensus network judges whether a blacklist proposal initiated aiming at a target user exists in a self-maintained block chain or not according to a user identifier of the target user controlled by a risk;
and if so, determining the voting result of the blacklist proposal corresponding to the target user from the self-maintained block chain according to the proposal identifier of the blacklist proposal corresponding to the target user, and determining the wind control strategy.
Optionally, the method further comprises:
aiming at each consensus node in the consensus network, the consensus node judges whether the voting result of other consensus nodes on the blacklist proposal exists in the self-maintained block chain or not according to the received voting result broadcasted by other consensus nodes, each blacklist proposal stored in the self-maintained block chain and the voting result corresponding to each blacklist proposal;
if not, performing consensus processing on the received voting results broadcasted by other consensus nodes;
and if so, not performing consensus processing on the voting results broadcasted by other consensus nodes.
The present specification provides a block chain consensus device for blacklist, where a consensus network is composed of a plurality of consensus nodes, and the device specifically includes:
the proposal consensus module is used for controlling the consensus nodes in the consensus network to acquire blacklist proposals to be consensus, broadcasting the blacklist proposals to other consensus nodes and performing consensus on the blacklist proposals;
a proposal storage module, configured to control the consensus node to store the blacklist proposal in the block chain maintained by the consensus node if it is determined that the blacklist proposal is agreed;
the voting consensus module is used for controlling the consensus nodes to vote whether the blacklist proposal is approved or not according to own wind control strategies, and broadcasting voting results to other consensus nodes so as to perform consensus on the voting results;
and the voting storage module is used for storing the voting results and the corresponding relation between the voting results and the blacklist proposal into the block chain maintained by the voting storage module when the consensus node determines that the voting results pass the consensus, and determining a wind control strategy when the voting results of the blacklist proposal stored in the block chain are used for risk control.
The present specification provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the above-described method for blockchain consensus of blacklists.
The present specification provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the block chain consensus method of the blacklist is implemented.
The technical scheme adopted by the specification can achieve the following beneficial effects:
in the block chain consensus method for the blacklist provided in this specification, any consensus node in the consensus network can initiate a blacklist proposal, and store the blacklist proposal in the block chain after the consensus passes, and each consensus node can also propose the blacklist, vote the blacklist proposal according to its own wind control policy, and store the corresponding relationship between the voting result and the blacklist proposal in the block chain after the voting result passes, and each consensus node can flexibly use the blacklist proposal and the voting result stored in the block chain for wind control based on the requirement.
The method can be seen in the above way, the method realizes the generalization of the blacklist in the same field, ensures the verifiability of the blacklist, does not make a theoretic conclusion on the blacklist, is determined by a user, and ensures the flexibility of the blacklist.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:
fig. 1 is a schematic flowchart illustrating a blacklist blockchain consensus method according to the present disclosure;
fig. 2 is a schematic diagram of a blacklisted blockchain consensus apparatus provided in the present specification;
fig. 3 is a schematic structural diagram of an electronic device corresponding to fig. 1 provided in this specification.
Detailed Description
In order to make the objects, technical solutions and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort belong to the protection scope of the present specification.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
According to the requirements of China people banks, institutions such as financial institutions and payment platforms need to carry out strict blacklist verification on customers served by the institutions. Typically, the customers in the blacklist are the distressed persons or distressed agencies who have serious distressing behaviors such as default, law violation, etc. The holding authority of the blacklist needs to make service restrictions on the clients in the blacklist or not provide services to the clients in the blacklist. In addition, in some industries, different organizations also collect blacklists and record clients with poor credit or industry-related organizations to limit or not provide services to the clients in the blacklists, and do not cooperate with the businesses in the blacklists to reduce or avoid loss of own parties.
At present, some organizations collect the blacklist by sharing the blacklist, so as to make the blacklist of their own customers more complete. Generally, in order to make the blacklist obtained by sharing the blacklist among the participating mechanisms more reliable and avoid that a part of the mechanisms maliciously provide the false blacklist, the mechanisms participating in the sharing of the blacklist collect and identify the blacklist through a block chain technology, and the blacklist which is more reliable and has more public trust is obtained by using the characteristics of decentralization, non-falsification and the like of the block chain technology.
In the prior art, different nodes in a block chain network have different weights, and the weight of each node is determined by voting results obtained by blacklist proposals initiated historically. For a blacklist proposal, after voting is performed on each consensus node and the voting result of each consensus node is verified, the number of votes approved and votes disapproved in the voting result which is finally obtained by a preset intelligent contract according to the proposal and the weight of the node corresponding to each votes approved and votes disapproved is obtained to obtain the weighted voting result of the blacklist proposal as the final voting result of the blacklist proposal, and whether the blacklist proposal is stored in a block chain is determined according to the weighted voting result. It is obvious that, in the prior art, a blacklist proposal may be stored in a block chain only after voting is performed on each node and a weighted voting result of the blacklist proposal is obtained, and generation of the blacklist proposal in the block chain depends heavily on the voting result of the blacklist proposal, which results in low generation efficiency of the blacklist proposal in the block chain. In addition, because the weights of the nodes are different, the weighted voting result of the node with the high weight on the blacklist proposal is greatly influenced, and the blacklist proposal finally stored in the block chain is easy to be unreliable.
In order to solve the problems that the generation efficiency of the blacklist proposal in the existing block chain is low, and the finally stored blacklist proposal is easy to be unreliable, the application provides a block chain consensus method for the blacklist.
Fig. 1 is a schematic flowchart of a block chain consensus method for blacklists in this specification, where the process of blacklist consensus is divided into two parts, namely proposal consensus and voting consensus. Steps S100 to S102 are the steps of proposing a consensus process, and steps S104 to S106 are the steps of voting the consensus process.
The proposal consensus process is as follows:
s100: and the consensus nodes in the consensus network acquire blacklist proposals to be consensus, broadcast the blacklist proposals to other consensus nodes, and perform consensus on the blacklist proposals.
In this specification, a consensus network is composed of a plurality of consensus nodes, and each consensus node in the consensus network maintains its own blockchain for storing a blacklist proposal list and voting results of each blacklist proposal.
In one or more embodiments of the present disclosure, the consensus nodes in the consensus network may be nodes owned by organizations in different fields, for example, the consensus nodes in the consensus network may be nodes of financial institutions or nodes of e-commerce platforms, and different enterprises in different types of industries may join the consensus network. For example, nodes of different enterprises in the food industry, nodes of different enterprises in the clothing industry, nodes of various service industry enterprises, and the like can all join the consensus network as the consensus nodes in the consensus network. For example, taking an industry corresponding to each common identification node for sharing the black list through the common identification network as an example of a takeout industry, each store participating in the sharing of the black list in the industry may have its own common identification node, and the black list can be shared through the common identification network. Each shop participating in the sharing of the blacklist can initiate the blacklist proposal by itself, and meanwhile, can obtain the blacklist proposal initiated by other consensus nodes, so as to realize the intercommunication of the blacklist.
In one or more embodiments of the present specification, after the consensus node obtains the blacklist proposal to be identified, first, it may be determined whether a blacklist proposal that has passed the consensus, which is the same as the proposal object of the blacklist proposal, exists in a block chain maintained by the consensus node, and if the blacklist proposal that has passed the consensus exists, the blacklist proposal to be identified is not broadcasted, so as to avoid repeated consensus of the existing blacklist proposal by the consensus network, reduce network pressure, and enable each consensus node in the consensus network to use resources in the consensus of the newly added blacklist proposal and voting results. Wherein, as long as the blacklist proposal to be identified is consistent with the proposal object of the blacklist proposal passing the identification, the identification node does not broadcast the blacklist proposal to be identified, but the initiator of the blacklist proposal to be identified and the initiator of the blacklist proposal passing the identification can be the same or different. If not, the consensus node can encrypt the blacklist proposal to be consensus and broadcast the encrypted blacklist proposal to other consensus nodes.
In addition, the consensus nodes in the consensus network are owned by different owners, so that the blacklist proposal to be consensus at least includes the identification of the proposal object corresponding to the proposal, which is used to indicate to which person or organization the blacklist proposal to be consensus is proposed, that is, the blacklist proposal to be consensus needs to include the identification of the person or organization proposed as the blacklist. The identifier is a social universal identifier that can uniquely identify the proposal object, for example, the identifier may be an identity card number of the proposal object, or an organization registration name, or may be other identity identifiers, and may be specifically set as required. Each consensus node in the consensus network can determine the identity of the proposal object according to the identity of the proposal object.
Further, the blacklist proposal may be a proposal of a blacklist, or may be a proposal of a set of several blacklists. The blacklist proposal may be a proposal for an individual or a proposal for a group. The common node may encrypt the blacklist proposal by using an existing encryption method, for example, an elliptic encryption algorithm, or may use another asymmetric encryption algorithm, and specifically which encryption method is used may be set as required, which is not limited herein.
In this specification, the asymmetric encryption algorithm is used for encryption, so that the security of transmission of the blacklist proposal in the consensus network can be increased, and the consensus node receiving the blacklist proposal can perform identity verification on the consensus node sending the blacklist proposal.
In one or more embodiments of the present disclosure, after the common node broadcasts the blacklist proposal to other common nodes, the common node and other common nodes in the common network may perform common identification on the blacklist proposal according to a preset common algorithm, so that the other common nodes verify whether a correct blacklist proposal initiated by the user and not tampered with maliciously is received. And if the number of the common identification nodes in the common identification network exceeds the preset number, verifying that the received blacklist proposal is a correct blacklist proposal which is initiated by the user and is not maliciously tampered, passing the common identification. The preset number can be set according to needs, for example, the preset number can be two thirds, one half, and the like, and the present specification is not limited herein.
The preset consensus algorithm may be a Practical Byzantine Fault Tolerance (PBFT), a RAFT algorithm, or other consensus algorithms, which may be specifically set as required, and the present specification is not limited herein.
In one or more embodiments of the present disclosure, when the predetermined consensus algorithm is based on a main node-initiated consensus algorithm in a consensus network, the blacklist proposal in the consensus network is obtained by the main node in the consensus network and broadcasted to other consensus nodes in the consensus network. For each other consensus node in the consensus network, the voting results of the other consensus nodes can also be broadcast to the other consensus nodes by the master node for consensus.
It should be noted that the embodiments provided in this specification are based on the assumption that most of the consensus nodes participating in the consensus network are normal nodes rather than malicious nodes. The malicious node refers to a consensus node which maliciously issues a false blacklist proposal in the consensus network, a consensus node which performs malicious voting on the blacklist proposal (for example, votes on the blacklist proposal corresponding to a proposal object without illegal and illegal behaviors, votes on the blacklist proposal corresponding to a proposal object with illegal and illegal behaviors), and a consensus node which broadcasts different voting results to different other consensus nodes.
S102: and if the blacklist proposal is determined to pass the consensus, the consensus node stores the blacklist proposal into the block chain maintained by the consensus node.
In one or more embodiments of the present disclosure, for each consensus node in the consensus network, if it is determined that the blacklist proposal is agreed, it is determined that the blacklist proposals received by more than a preset number of consensus nodes in the consensus network are consistent, and the consensus node may store the blacklist proposal in a block chain maintained by the consensus node. And if the consensus of the blacklist proposal is determined not to pass, the consensus node does not store the blacklist proposal into a block chain maintained by the consensus node.
The blacklist proposal consensus is passed, namely, other consensus nodes in the consensus network determine that the blacklist proposals broadcasted by the consensus nodes are consistent, including the agreement between the proposal initiator and the proposal content. And for whether the proposal object in the blacklist proposal should be listed in the blacklist, the consensus nodes do not need to perform consensus.
The voting consensus process is as follows:
s104: and the consensus node votes whether the blacklist proposal is approved or not according to a self wind control strategy, and broadcasts a voting result to other consensus nodes so as to perform consensus on the voting result.
Based on the assumption that most of the consensus nodes in the consensus network are normal consensus nodes, in one or more embodiments of the present description, for a blacklist proposal, the consensus nodes in the consensus network can only perform voting once, so as to avoid performing repeated voting on the same blacklist proposal, and reduce the number of consensus times. For each consensus node in the consensus network, after storing the blacklist proposal in the block chain maintained by the consensus node, before voting the blacklist proposal, the consensus node can judge whether the blacklist proposal has been voted according to each blacklist proposal stored in the block chain maintained by the consensus node and the voting result corresponding to each blacklist proposal, if not, whether the blacklist proposal is voted for, and if so, whether the blacklist proposal is voted for is not voted for.
In addition, if only the consensus node determines whether the consensus node has the repeated voting condition, the malicious node may repeatedly vote for one or some blacklist proposals, and the repeated voting of the malicious node may crowd resources of each consensus node in the consensus network, thereby affecting the operation efficiency of the consensus network. Therefore, in one or more embodiments of the present specification, for each consensus node in the consensus network, when receiving a voting result of another consensus node on a blacklist proposal that has been agreed upon, the consensus node may further determine, according to the received voting result broadcast by the other consensus node, each blacklist proposal stored in the block chain maintained by the consensus node, and a voting result corresponding to each blacklist proposal, whether a voting result of another consensus node on the blacklist proposal exists in the block chain maintained by the consensus node. That is, it is determined whether there is a consensus node that votes for the blacklist proposal and has agreed the voting result among other consensus nodes corresponding to the received voting results. If not, namely no consensus node voting the blacklist proposal exists in the other consensus nodes corresponding to the received voting results, performing consensus processing on the voting results broadcast by the other consensus nodes. If yes, namely the consensus nodes which vote the blacklist proposal and perform consensus on the voting results exist in other consensus nodes corresponding to the received voting results, the voting results of the consensus nodes which vote the blacklist proposal are not subjected to consensus processing.
Therefore, the voting times of the consensus nodes on the blacklist proposal in the consensus network can be reduced, the consensus times of the voting results can be reduced, repeated voting on the same blacklist proposal can be avoided, and the occupation of public resources can be reduced. And can ensure that most blacklist proposals for consensus in the consensus network are newly initiated blacklist proposals. The malicious nodes are prevented from repeatedly voting for obtaining reward resources, and the fairness of the voting results of the blacklist proposals is ensured.
In one or more embodiments of the present specification, when it is determined that the consensus node has not voted for the blacklist proposal, the consensus node may vote whether to approve the blacklist proposal according to its own gating policy, and broadcast whether the voting result is approved or disapproved to other consensus nodes to perform consensus on the voting result. The wind control strategies of the consensus nodes in the consensus network may be the same or different, and the consensus networks vote the blacklist proposal specifically according to what, which is not limited herein.
Therefore, in the blockchain maintained by each common node in the method for identifying a blockchain of a blacklist provided in this specification, it is not recorded which objects should be listed in the blacklist of each organization participating in the sharing of the blacklist, but it is recorded which objects are stored in the blockchain maintained by each common node as proposal objects of a blacklist proposal, and voting results of different common nodes on each blacklist proposal. That is, the block chain maintained by each consensus node does not provide a conclusion whether a certain proposal object (e.g., a user of a certain organization) is a user in the blacklist, but provides a judgment result of each consensus node on each blacklist proposal, that is, a voting result of each consensus node, so that information contained in the blacklist proposal stored in the block chain maintained by each consensus node is richer, and can be applied more flexibly by each consensus node. For example, what the voting result of a certain blacklist proposal by a certain consensus node A and a certain trusted consensus node B is, what the voting results of the consensus nodes C and D that the consensus node a does not trust are, the consensus node a may be wind-controlled based on the voting results of the consensus node B (since the consensus node a trusts the consensus node B and also trusts the voting results of the consensus node B), or based on the voting results of the consensus node C and the consensus node D, e.g., according to the voting results opposite to the consensus node C and the consensus node D, or, when the voting results of the consensus nodes C and D are the same as the voting results of most consensus nodes in the consensus network, the consensus node a can be gated based on the voting results of the consensus nodes C and D (i.e., the voting results of most of the consensus nodes).
In addition, in one or more embodiments of the present specification, before voting on the blacklist proposal according to the own wind control policy, the consensus node may further determine, according to an identity of a proposal object of the blacklist proposal, whether there is or can obtain relevant data of the proposal object, where the relevant data may be data that can reflect the degree of conservation and reliability of the proposal object, such as a conservation record and a complaint record of the proposal object, and is used as a basis for voting on the proposal object. If not, the consensus node cannot judge whether the proposed object has illegal behaviors such as illegal behaviors, default behaviors and the like, and does not vote on the blacklist proposal. If so, the consensus node can vote whether the blacklist proposal is approved or not according to the relevant data of the proposal object and the own wind control strategy, and broadcast whether the voting result is approved or disapproved to other consensus nodes. Or when the consensus node determines that the consensus node does not exist and cannot acquire the relevant data of the proposal object, voting is performed on the blacklist proposal according to the voting result of other trusted consensus nodes in the consensus network.
In one or more embodiments of the present specification, an account corresponding to each common node may also be stored in the blockchain of the common network, so that the blockchain maintained by each common node in the common network stores the account of each common node in the common network. The account of each consensus node is used for recording the condition that each consensus node obtains resources in the consensus network. After the voting result passes the consensus, the consensus node can call a preset intelligent contract according to the consensus result, and execute the intelligent contract to allocate reward resources to each consensus node participating in the voting in the consensus network, store the number of the reward resources allocated by each consensus node participating in the voting in a block chain maintained by the consensus node, and update the condition of the resources stored in the account of each consensus node. The resource is provided by the consensus network, e.g., the resource can be considered as digital currency provided by the consensus network. If the consensus network is assumed to be a consensus system and the consensus nodes are devices that make up the system, the resource may also be considered a resource provided by the system to the consensus nodes.
Or, in one or more embodiments of the present specification, after the voting result passes through consensus, the service execution module in the consensus network may send, according to a preset code, an incentive resource allocation message carrying an identifier of each consensus node participating in the voting to each consensus node in the consensus network, so that each consensus node performs consensus on the incentive resource allocation message, and after the consensus passes, the service execution module allocates an incentive resource to each consensus node participating in the voting in the consensus network. And then, each consensus node in the consensus network can store the number of the rewarded resources allocated by each consensus node participating in voting in a block chain maintained by the consensus node, and update the condition of the resources stored in the account of each consensus node.
In one or more embodiments of the present specification, the consensus node may receive the reward resource as long as the consensus node participates in the voting and the voting result passes the consensus. And the positive voting result of the consensus node is the same as the reward resource obtained by the negative voting result. Therefore, the method can avoid impure voting of each consensus node for acquiring more resources, and ensure the fairness of voting results. For example, if the consensus node votes for more awards than for the votes for a blacklist proposal, there may be situations where the consensus node votes for more awards, causing the voting results of the blacklist proposal to be unfairly positive.
In addition, no matter whether the voting result of the consensus nodes in the consensus network is approved or disapproved, the consensus nodes corresponding to the voting result can obtain the allocated resources as long as the voting result is passed through the consensus. Therefore, the consensus nodes in the consensus network tend to vote for each blacklist proposal, and the effect of promoting the consensus nodes to participate in voting actively can be achieved. Based on the above policy of resource sharing and resource allocation according to the voting result of the consensus nodes and the assumption that most of the consensus nodes in the consensus network are normal nodes, when the blacklist proposal is wrong and unreasonable, most of the consensus nodes in the consensus network cast an objection vote to the blacklist proposal, so that the blacklist proposal stored in the block chain in the specification can actually play a role of a white list. That is, when most of the consensus nodes vote against a blacklist proposal for which the vote result belongs to negative votes, the proposal object of the blacklist proposal can be considered as the object in the white list.
The intelligent contract is a program which is stored in a block chain of the consensus network and can be automatically executed according to preset conditions. In addition to the aforementioned bonus resource provided by the consensus network, the bonus resource may be digital currency, or other resources. For example, assuming that the entities that share blacklists over the consensus network are takeaway or shopping platforms, the reward resource may be a discount coupon or coupon that may attract customers to their platform for consumption through the discount coupon or coupon. Or advertisement preference of the platform to which other consensus nodes belong. Alternatively, the reward resource may be virtual currency or the like that can be circulated among institutions participating in the blacklist sharing, and may be set according to needs.
S106: and when the consensus node determines that the voting result consensus passes, storing the voting result and the corresponding relation between the voting result and the blacklist proposal into the block chain maintained by the consensus node, wherein the voting result of the blacklist proposal stored in the block chain is used for determining a wind control strategy when the risk control is performed.
In one or more embodiments of the present specification, when the voting result is identified together, the consensus node determines that the voting result and the corresponding relationship between the voting result and the blacklist proposal can be stored in the block chain maintained by the consensus node, and determines a wind control policy when the voting result of the blacklist proposal stored in the block chain is used for risk control.
In one or more embodiments of the present description, when a consensus node in the consensus network needs to perform risk control, the consensus node in the consensus network may determine, according to a user identifier of a target user for risk control, whether a blacklist proposal initiated for the target user exists in a block chain maintained by the consensus node, that is, determine whether the target user is a blacklist user. When it is determined that the blacklist proposal initiated for the target user exists in the self-maintained block chain, the consensus node in the consensus network can determine the voting result of the blacklist proposal corresponding to the target user from the self-maintained block chain according to the proposal identifier of the blacklist proposal corresponding to the target user, and determine the wind control strategy. The voting result at least comprises the number of voting results belonging to positive votes, the number of voting results belonging to negative votes, the voting results belonging to positive votes and the voting results belonging to negative votes from which consensus nodes the voting results belong to negative votes. The consensus node in the consensus network can judge whether to use the blacklist proposal for risk control according to the voting result of the blacklist proposal corresponding to the target user. Specifically, for example, the consensus node that needs risk control may trust the blacklist proposal when the voting result belonging to votes approved is greater than the voting result belonging to votes rejected in the voting result of the blacklist proposal corresponding to the target user, perform risk control on the user according to the blacklist proposal, and determine the wind control policy. Or, the consensus node that needs to perform risk control may also select the voting result of the trusted consensus node from the voting results as the basis for determining whether the blacklist proposal is trusted. That is, the voting result of the consensus node trusted by the blacklist proposal is only followed no matter what the voting result ratio of the positive votes and the voting result ratio of the negative votes are obtained by the blacklist proposal.
Based on the block chain consensus method of the blacklist shown in fig. 1, any consensus node in the consensus network can initiate a blacklist proposal, and store the blacklist proposal in the block chain after the consensus passes, and each consensus node can also propose the blacklist, vote the blacklist proposal according to the own wind control strategy, and store the corresponding relationship between the voting result and the blacklist proposal in the block chain after the voting result passes, and each consensus node can flexibly use the blacklist proposal and the voting result stored in the block chain for wind control based on the requirement.
Therefore, the method realizes the generalization of the blacklist in the same field, ensures the verifiability of the blacklist, does not decide the conclusion of theoretic property under the blacklist, is decided by a user, and ensures the flexibility of the blacklist.
In addition, in one or more embodiments provided in the present specification, when a new node (i.e., a node to be networked) wants to join the consensus network to participate in blacklist sharing, a network entry request may be sent to a consensus node in the consensus network. The network access request can be received by the network access request receiving consensus node in the consensus network, and the network access request can be responded to the network access request and broadcasted to other consensus nodes in the consensus network to perform consensus on the network access request. After the network access request consensus passes, that is, after determining that all other consensus nodes in the consensus network have received the network access request, the receiving consensus node may send a resource acquisition request to the node to be accessed, so that the node to be accessed provides network access resources according to the resource acquisition request. After the node to be networked provides the network access resource, the receiving consensus node can determine a resource sharing request according to the network access resource, each blacklist proposal stored in the self-maintained block chain and a voting result corresponding to each blacklist proposal based on a preset resource sharing rule stored in the self-maintained block chain, broadcast the resource sharing request to other consensus nodes in the consensus network, and perform consensus on the resource sharing request. The resource sharing request comprises the identification of the node to be accessed to the network and the resource sharing condition.
In one or more embodiments of the present specification, after the resource sharing request passes the consensus, the receiving consensus node may execute a resource sharing service according to the network access resource, each blacklist proposal stored in the block chain maintained by the receiving consensus node and the voting result corresponding to each blacklist proposal based on the preset resource sharing rule, and store the identifier of the node to be networked into the block chain maintained by the receiving consensus node as the consensus node in the consensus network.
In one or more embodiments of the present specification, after joining the consensus network, the node to be networked may synchronize contents of each blacklist proposal, voting information corresponding to each blacklist proposal, a preset intelligent contract, account information of each consensus node, and the like in the consensus network into a block chain maintained by the node to be networked. After synchronization, the node to be networked can vote for each blacklist proposal in the block chain maintained by the node to be networked, and broadcast the voting result to other consensus nodes for consensus. That is, the voting will not be terminated for each blacklist proposal stored in the block chain maintained by the consensus node of the consensus network itself, and any consensus node in the consensus network that has not voted for each blacklist proposal stored in the block chain can vote at any time. In addition, because the intelligent contract stored in the block chain maintained by the consensus node of the consensus network is preset, the consensus node newly added into the consensus network does not participate in the signing of the intelligent contract, and the intelligent contract obtained by synchronization can be verified after the node to be accessed is added into the consensus network.
In one or more embodiments of the present specification, when the receiving consensus node executes a resource sharing service according to the network access resource, each blacklist proposal stored in the block chain maintained by the receiving consensus node and a voting result corresponding to each blacklist proposal, the receiving consensus node may first determine a consensus node initiating each blacklist proposal stored in the block chain maintained by the receiving consensus node as a proposal node. And then, aiming at each proposal node, determining the number of voting results obtained by each blacklist proposal initiated by the proposal node as a node voting value, and determining the total number of the voting results obtained by each blacklist proposal stored in the block chain as a total voting value. And finally, distributing network access resources to the proposal node according to the ratio of the node voting value to the total voting value. And the total number of voting results which are obtained by each blacklist proposal initiated by the proposal node and belong to positive votes and negative votes is used as a node voting value to encourage each consensus node to initiate the blacklist proposal and vote mutually.
Taking four consensus nodes in the consensus network as an example, including the receiving consensus node a and the other consensus nodes B, C, D, it is assumed that 8 blacklist proposals are stored in the blockchain maintained by the consensus node a itself and not all consensus nodes vote on 8 blacklist proposals. Wherein, the proposal one and the proposal two are initiated by the consensus node A, the proposal one obtains 4 tickets, and the proposal two obtains 3 tickets. The third proposal, the fourth proposal and the fifth proposal are initiated by other consensus node B, the third proposal obtains 4 tickets, the fourth proposal obtains 4 tickets, and the fifth proposal obtains 3 tickets. The proposal six and the proposal seven are initiated by other consensus nodes C, the proposal six obtains 4 tickets, and the proposal seven obtains 2 tickets. Proposal eight is initiated by other consensus nodes D, which obtain 2 tickets. The proposed node A, B, C, D has corresponding node vote values of 4+3, 4+2, i.e., 7, 11, 6, 2, respectively. The total vote value for the 8 blacklist proposals stored in the blockchain is 7+11+6+ 2-26. The proposal node A, B, C, D can obtain the network access resource respectively
Figure BDA0002954592720000161
In one or more embodiments of the present specification, in order to encourage each node in the consensus network to initiate a more reliable blacklist proposal, the node receiving the consensus network may further use, as the node voting value, only the number of votes agreed upon in the voting results obtained by each blacklist proposal initiated by the proposal node when executing a resource sharing service according to each blacklist proposal stored in the network access resource and the block chain maintained by the node receiving the consensus network and the voting result corresponding to each blacklist proposal. And determining the total number of votes in the voting results obtained by all the blacklist proposals stored in the blockchain as the total voting value. And then distributing the network access resource to each proposal node according to the ratio of the node voting value to the total voting value. Following the above example, assume that proposal one gets 3 positive and 0 negative tickets, and proposal two gets 3 positive and 0 negative tickets. Proposal three gets 1 positive and 3 negative, proposal four gets 3 positive and 1 negative, and proposal five gets 2 positive and 2 negative. Proposal six gets 3 positive and 1 negative tickets, and proposal seven gets 1 positive and 1 negative tickets. Proposal eight gets 2 positive tickets and 0 negative tickets. The proposed node A, B, C, D has node vote values of 3+ 2-5, 1+3+ 2-6, 3+ 1-4, and 2, respectively. The total vote value for the 8 blacklist proposals stored in the blockchain is 5+6+4+ 2-17. The proposal node A, B, C, D can obtain the network access resource respectively
Figure BDA0002954592720000171
In one or more embodiments of the present specification, after the node to be networked provides a network access resource, the consensus node in the consensus network may further invoke a preset intelligent contract, and execute the intelligent contract, so as to execute a resource sharing service according to the network access resource, each blacklist proposal stored in the block chain maintained by the consensus node, and a voting result corresponding to each blacklist proposal.
It can be seen that, after the node to be networked joins the consensus network, the resource provided by the node to be networked can allocate the reward resource to the consensus node proposing the blacklist proposal according to the voting result belonging to the vote approval in the blacklist proposal, so that the consensus node in the consensus network tends to provide an accurate (i.e., most other consensus nodes can approve the vote) blacklist proposal, and the quality and accuracy of the blacklist proposal stored in the block chain maintained by each consensus node in the consensus network are improved.
In this specification, the intelligent contract invoked by the consensus node in the consensus network when executing the resource sharing service may be the same as or different from the intelligent contract invoked in step S106, and may be specifically set as needed, which is not limited herein.
In addition, in step S102 in this specification, after receiving the blacklist proposal sent by the consensus node, the other consensus node may store, according to the block chain maintained by the other consensus node, an identifier of each consensus node in the consensus network and the identifier of the consensus node, determine whether the consensus node is a consensus node that joins the consensus network after passing the consensus, if so, perform consensus on the blacklist proposal sent by the consensus node, and if not, not perform consensus on the blacklist proposal sent by the consensus node.
Based on the same idea, the present specification further provides a corresponding blacklist blockchain consensus system, where the consensus system includes a consensus network composed of a plurality of consensus nodes, each consensus node in the consensus network maintains its own blockchain, and the blockchain is used to store a blacklist proposal list and a voting result of the blacklist proposal, where:
the consensus node acquires a blacklist proposal to be consensus and broadcasts the blacklist proposal to other consensus nodes;
the consensus node and other consensus nodes in the consensus network perform consensus on the blacklist proposal, and if the blacklist proposal is determined to pass the consensus, the blacklist proposal is stored in the block chain maintained by the consensus node;
the consensus node votes whether the blacklist proposal is approved or not according to the own wind control strategy, and broadcasts the voting result to other consensus nodes so as to perform consensus on the voting result;
and when the consensus node determines that the voting result consensus passes, storing the voting result and the corresponding relation between the voting result and the blacklist proposal into the block chain maintained by the consensus node, and determining a wind control strategy when the voting result of the blacklist proposal stored in the block chain is used for risk control.
In one or more embodiments of the present specification, any one of the consensus nodes in the consensus network may initiate a blacklist proposal, and store the blacklist proposal in a block chain maintained by itself after the consensus passes. And each consensus node can vote for the blacklist proposal according to the own wind control strategy, and the corresponding relation between the voting result and the blacklist proposal is stored in the block chain after the voting result consensus passes.
The present specification also provides a corresponding blacklisted blockchain consensus apparatus, as shown in fig. 2.
Fig. 2 is a schematic diagram of a blacklisted blockchain consensus apparatus provided in the present specification, the apparatus including: a proposal consensus module, a proposal storage module, a voting consensus module and a voting storage module, wherein:
a proposal consensus module 200, configured to control a consensus node in the consensus network to obtain a blacklist proposal to be consensus, broadcast the blacklist proposal to other consensus nodes, and perform consensus on the blacklist proposal;
a proposal storage module 201, configured to control the consensus node to store the blacklist proposal in the block chain maintained by the consensus node if it is determined that the blacklist proposal is agreed;
the voting consensus module 202 is configured to control the consensus node to vote whether to approve the blacklist proposal according to a wind control policy of the consensus node, and broadcast a voting result to other consensus nodes to perform consensus on the voting result;
and the voting storage module 203 is configured to store the voting results and the corresponding relationship between the voting results and the blacklist proposal into the block chain maintained by the consensus node when the consensus node determines that the voting results pass the consensus, and determine a wind control policy when the voting results of the blacklist proposal stored in the block chain are used for risk control.
Optionally, the consensus node responds to a network access request sent by a node to be accessed, broadcasts the network access request to other consensus nodes in the consensus network, and after it is determined that the network access request passes the consensus, sends a resource acquisition request to the node to be accessed, so that the node to be accessed provides a network access resource, executes a resource sharing service according to the network access resource provided by the node to be accessed, each blacklist proposal stored in a block chain maintained by the node to be accessed, and a voting result corresponding to each blacklist proposal, and takes the node to be accessed as a consensus node in the consensus network.
Optionally, according to the network access resource provided by the node to be networked, calling a preset intelligent contract stored in the block chain, and executing the intelligent contract, so as to allocate the resource to the consensus node initiating each blacklist proposal according to the voting result of each blacklist proposal stored in the block chain.
Optionally, a consensus node initiating each blacklist proposal stored in the block chain is determined as a proposal node, for each proposal node, the number of votes attributed to votes in voting results obtained by each blacklist proposal initiated by the proposal node is determined as a node voting value, the total number of voting results attributed to votes obtained by each blacklist proposal stored in the block chain is determined as a total voting value, and the resource is allocated to the proposal node according to the ratio of the node voting value to the total voting value.
Optionally, for each consensus node in the consensus network, after the consensus node agrees with the voting result of the blacklist proposal, the consensus node in the consensus network invokes an intelligent contract according to the consensus result, and executes the intelligent contract to allocate resources to each consensus node in the consensus network.
Optionally, the consensus node in the consensus network determines, according to a user identifier of a target user controlled by a risk, whether a blacklist proposal initiated for the target user exists in a block chain maintained by the consensus node, and if so, determines, according to a proposal identifier of the blacklist proposal corresponding to the target user, a voting result of the blacklist proposal corresponding to the target user from the block chain maintained by the consensus node, and determines a wind control policy.
Optionally, for each consensus node in the consensus network, the consensus node determines, according to the received voting results broadcast by other consensus nodes, each blacklist proposal stored in the block chain maintained by the consensus node and the voting result corresponding to each blacklist proposal, whether the voting results of the blacklist proposal by other consensus nodes exist in the block chain maintained by the consensus node, if not, performs consensus processing on the received voting results broadcast by other consensus nodes, and if so, does not perform consensus processing on the received voting results broadcast by other consensus nodes.
The blacklisted blockchain consensus device may be disposed in a consensus node of a consensus network, and is configured to implement the consensus process shown in fig. 1.
The present specification also provides a computer-readable storage medium storing a computer program for performing a blacklist consensus operation by a consensus node in the consensus network, where the computer program is operable to perform the above-mentioned block chain consensus method for the blacklist provided in fig. 1.
This specification also provides a schematic block diagram of the electronic device shown in fig. 3. Each consensus node, i.e. each electronic device, in the consensus network. As shown in fig. 3, at the hardware level, the electronic device includes a processor, an internal bus, a memory, and a non-volatile memory, but may also include hardware required for other services. The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to implement the blacklisted blockchain consensus method provided in fig. 1.
Of course, besides the software implementation, the present specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may be hardware or logic devices.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification should be included in the scope of the claims of the present specification.

Claims (10)

1. A blacklisted blockchain consensus method, wherein a consensus network consists of a plurality of consensus nodes, the method comprising:
a consensus node in the consensus network acquires a blacklist proposal to be consensus, broadcasts the blacklist proposal to other consensus nodes, and performs consensus on the blacklist proposal;
if the blacklist proposal is determined to pass the consensus, the consensus node stores the blacklist proposal into the block chain maintained by the consensus node;
the consensus node votes whether the blacklist proposal is approved or not according to a self wind control strategy, and broadcasts a voting result to other consensus nodes so as to perform consensus on the voting result;
and when the consensus node determines that the voting result consensus passes, storing the voting result and the corresponding relation between the voting result and the blacklist proposal into the block chain maintained by the consensus node, wherein the voting result of the blacklist proposal stored in the block chain is used for determining a wind control strategy when the risk control is performed.
2. The method of claim 1, wherein the method further comprises:
the consensus node responds to a network access request sent by a node to be accessed to the network and broadcasts the network access request to other consensus nodes in the consensus network;
after determining that the network access request is passed, sending a resource acquisition request to the node to be accessed to enable the node to be accessed to provide network access resources;
and executing a resource sharing service according to the network access resources provided by the nodes to be accessed, the blacklist proposals stored in the self-maintained block chain and the voting results corresponding to the blacklist proposals, and taking the nodes to be accessed as consensus nodes in the consensus network.
3. The method of claim 2, wherein the performing the resource sharing service according to the access resource provided by the node to be accessed, each blacklist proposal stored in the block chain maintained by the node to be accessed, and the voting result corresponding to each blacklist proposal specifically comprises:
calling a preset intelligent contract stored in the block chain according to the network access resource provided by the node to be accessed;
and executing the intelligent contract to distribute the resources to the consensus nodes initiating the blacklist proposals according to the voting results of the blacklist proposals stored in the block chain.
4. The method of claim 3, wherein allocating the resource to the consensus node initiating each blacklist proposal according to a voting result obtained from each blacklist proposal stored in the blockchain comprises:
determining a consensus node initiating each blacklist proposal stored in the block chain as a proposal node;
aiming at each proposal node, determining the number of votes in voting results obtained by each blacklist proposal initiated by the proposal node as a node voting value;
determining the total number of voting results belonging to votes obtained by each blacklist proposal stored in the block chain as a total voting value;
and allocating the resources to the proposal node according to the ratio of the node voting value to the total voting value.
5. The method of claim 1, wherein the method further comprises:
for each consensus node in the consensus network, after the consensus node agrees with the voting result of the blacklist proposal, the consensus node in the consensus network calls an intelligent contract according to the consensus result;
executing the intelligent contract to allocate resources to the consensus nodes in the consensus network.
6. The method of claim 1, wherein the method further comprises:
a consensus node in the consensus network judges whether a blacklist proposal initiated aiming at a target user exists in a self-maintained block chain or not according to a user identifier of the target user controlled by a risk;
and if so, determining the voting result of the blacklist proposal corresponding to the target user from the self-maintained block chain according to the proposal identifier of the blacklist proposal corresponding to the target user, and determining the wind control strategy.
7. The method of claim 1, wherein the method further comprises:
aiming at each consensus node in the consensus network, the consensus node judges whether the voting result of other consensus nodes on the blacklist proposal exists in the self-maintained block chain or not according to the received voting result broadcasted by other consensus nodes, each blacklist proposal stored in the self-maintained block chain and the voting result corresponding to each blacklist proposal;
if not, performing consensus processing on the received voting results broadcasted by other consensus nodes;
and if so, not performing consensus processing on the voting results broadcasted by other consensus nodes.
8. A blacklisted blockchain consensus device, wherein a consensus network is composed of a plurality of consensus nodes, the device comprising:
the proposal consensus module is used for controlling the consensus nodes in the consensus network to acquire blacklist proposals to be consensus, broadcasting the blacklist proposals to other consensus nodes and performing consensus on the blacklist proposals;
a proposal storage module, configured to control the consensus node to store the blacklist proposal in the block chain maintained by the consensus node if it is determined that the blacklist proposal is agreed;
the voting consensus module is used for controlling the consensus nodes to vote whether the blacklist proposal is approved or not according to own wind control strategies, and broadcasting voting results to other consensus nodes so as to perform consensus on the voting results;
and the voting storage module is used for storing the voting results and the corresponding relation between the voting results and the blacklist proposal into the block chain maintained by the voting storage module when the consensus node determines that the voting results pass the consensus, and determining a wind control strategy when the voting results of the blacklist proposal stored in the block chain are used for risk control.
9. A computer-readable storage medium, characterized in that the storage medium stores a computer program which, when executed by a processor, implements the method of any of the preceding claims 1 to 7.
10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 7 when executing the program.
CN202110220423.4A 2021-02-26 2021-02-26 Blacklist block chain consensus method and device Pending CN112968901A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110220423.4A CN112968901A (en) 2021-02-26 2021-02-26 Blacklist block chain consensus method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110220423.4A CN112968901A (en) 2021-02-26 2021-02-26 Blacklist block chain consensus method and device

Publications (1)

Publication Number Publication Date
CN112968901A true CN112968901A (en) 2021-06-15

Family

ID=76276135

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110220423.4A Pending CN112968901A (en) 2021-02-26 2021-02-26 Blacklist block chain consensus method and device

Country Status (1)

Country Link
CN (1) CN112968901A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023233013A1 (en) * 2022-06-02 2023-12-07 Nchain Licensing Ag Methods and systems for freezing digital assets

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110879826A (en) * 2019-10-12 2020-03-13 深圳壹账通智能科技有限公司 Credit blacklist sharing method and device based on block chain
CN111131218A (en) * 2019-12-19 2020-05-08 平安资产管理有限责任公司 Blacklist management method, device, computer system and readable storage medium

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110879826A (en) * 2019-10-12 2020-03-13 深圳壹账通智能科技有限公司 Credit blacklist sharing method and device based on block chain
CN111131218A (en) * 2019-12-19 2020-05-08 平安资产管理有限责任公司 Blacklist management method, device, computer system and readable storage medium

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023233013A1 (en) * 2022-06-02 2023-12-07 Nchain Licensing Ag Methods and systems for freezing digital assets

Similar Documents

Publication Publication Date Title
US11218327B2 (en) Digital certificate management method and apparatus, and electronic device
Lopez et al. A multi-layered blockchain framework for smart mobility data-markets
US20200183757A1 (en) Blockchain-based resource allocation method and apparatus
US11144618B2 (en) Methods and apparatuses for copyright allocation for blockchain-based work
CN110166442B (en) Data processing method and device based on block chain
CN110020774B (en) Resource sharing method, system, device and electronic equipment
CN111724150A (en) Service request processing method and device
JP2020522927A (en) Blockchain for general calculation
TWI671703B (en) Method and device for rights management and resource control
CN110264351B (en) Copyright distribution method and device based on block chain
CN109388957B (en) Block chain-based information transfer method, device, medium and electronic equipment
CN108848125B (en) Method and apparatus for providing consensus service in block chain and storage medium
CN110930578A (en) Voting method, equipment and medium based on block chain
CN114710329A (en) Method and apparatus for managing access to accounts in a blockchain system
CN112968901A (en) Blacklist block chain consensus method and device
CN115801407A (en) Abnormal node shielding method and device, storage medium and target node
CN111611599A (en) Block chain consensus algorithm implementation method, equipment and medium
CN103051623A (en) Method for limiting calling of open platform
CN116595571A (en) Block chain-based carbon data management method, device and equipment
CN112968772B (en) Cross-chain decoupling method and system for block chain data
TW202008230A (en) Event prediction method and apparatus, and electronic device
CN112801661B (en) Block chain cross-chain rule management method and system
CN115511595A (en) Service execution method and device based on block chain
CN115545683A (en) Block chain-based electronic ticket processing method and device
CN110969476A (en) Marketing activity information promotion method and device, storage medium and processor

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20210615

RJ01 Rejection of invention patent application after publication