CN111201751B

CN111201751B - Method and system for arbitrating data authenticity in blockchain

Info

Publication number: CN111201751B
Application number: CN201880002222.3A
Authority: CN
Inventors: 梁川; 杨孟珂; 刘忖生
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-09-26
Filing date: 2018-09-26
Publication date: 2021-03-09
Anticipated expiration: 2038-09-26
Also published as: CN111201751A; WO2020061822A1

Abstract

Embodiments of the present application provide a method and network node for arbitrating data authenticity in a blockchain. The method may include: receiving, by an arbitrating network node, a request to arbitrate data authenticity, wherein the arbitrating network node is one of a plurality of network nodes in a blockchain; generating, by the arbitrating network node, an arbitration event based on the request, wherein the arbitration event comprises information related to the authenticity of the data; prioritizing, by the arbitrating network node, arbitration events to be processed before a next transaction by the arbitrating network node; and processing, by the arbitrating network node, the arbitration event based on information contained in the arbitration event, generating an arbitration result for the arbitrating network node, and providing the arbitration result to the blockchain.

Description

Method and system for arbitrating data authenticity in blockchain

Technical Field

The present application relates generally to computer technology and, more particularly, to a method and system for arbitrating data in a blockchain.

Background

Due to the nature of the shared ledger system, blockchains can be used to store and share information. The system may store information, such as financial data associated with transactions in the blockchain. And the system can prevent stored financial data from being tampered. The financial data may include transaction time, transaction amount, collateral information, and the like.

Although the blockchain may prevent the storage information from being tampered with, the blockchain may not be able to determine whether the storage information is genuine. Manual evaluation of stored information may also be difficult because blockchains may store large amounts of information.

To address the above-mentioned problems, embodiments of the present application provide a method and system for arbitrating data authenticity in a blockchain.

Disclosure of Invention

Embodiments of the present application provide a computer-implemented method for arbitrating data authenticity in a blockchain. The method may include: receiving, by an arbitrating network node, a request to arbitrate data authenticity, wherein the arbitrating network node is one of a plurality of network nodes in a blockchain; generating, by the arbitrating network node, an arbitration event based on the request, wherein the arbitration event comprises information related to the authenticity of the data; prioritizing, by the arbitration network node, the arbitration events so that the arbitration events are processed prior to a next transaction by the arbitration network node; and processing, by the arbitrating network node, the arbitration event based on information contained in the arbitration event, generating an arbitration result for the arbitrating network node, and providing the arbitration result to the blockchain.

The embodiment of the invention also provides an arbitration network node which is used for arbitrating the authenticity of the data in the block chain. The arbitrating network node may comprise: a communication interface configured to receive a request for arbitrating authenticity of data, wherein the arbitrating network node is one of a plurality of network nodes in a blockchain; a memory; and at least one processor coupled to the communication interface and the memory. The at least one processor may be configured to: generating an arbitration event based on the request, wherein the arbitration event comprises information related to authenticity of the data; prioritizing arbitration events to be processed before a next transaction of the arbitrated network node; and processing the arbitration event based on information contained in the arbitration event, generating an arbitration result for the arbitration network node, and providing the arbitration result to a blockchain.

Embodiments of the present invention also provide a non-transitory computer-readable medium storing a set of instructions that, when executed by at least one processor of an arbitrating network node, cause the arbitrating network node to perform a method for arbitrating the authenticity of data in a blockchain. The method may include: receiving a request for arbitrating authenticity of data, wherein the arbitrating network node is one of a plurality of network nodes in a blockchain; generating an arbitration event based on the request, wherein the arbitration event comprises information related to authenticity of data; prioritizing to handle the arbitration event prior to arbitrating a next transaction of the network node; and processing the arbitration event based on information contained in the arbitration event, generating an arbitration result of the arbitration network node, and providing the arbitration result to a blockchain.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

Drawings

Fig. 1 is a schematic diagram of a blockchain shown in accordance with an exemplary embodiment of the present application.

Fig. 2 is a schematic diagram of a network node in a blockchain shown in accordance with an exemplary embodiment of the present application.

Fig. 3 is a schematic diagram of a plurality of network nodes using intelligent contracts, shown in accordance with an exemplary embodiment of the present application.

Fig. 4 is a flow chart illustrating a method for arbitrating authenticity of data in a blockchain in accordance with an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Fig. 1 is a schematic diagram of a blockchain 100 shown in accordance with an exemplary embodiment of the present application. A blockchain may typically be managed by a decentralized peer-to-peer network, comprising a plurality of network nodes. As shown in fig. 1, blockchain 100 may include blockchain 120 and network node 102 connected to

blockchain

120 and 110. For example, each of block chains 120 may be a data block, and each of

network nodes

102 and 110 may be a computer system that includes a processor and a memory.

Network nodes

102 and 110 may collectively manage block chain 120. Block chain 120 may include

blocks

122, 124, 126, and so on. Each block may include a cryptographic hash of the previous block, a timestamp, and stored data. Hashing is a function known in the art to convert an input, such as letters and numbers, to an encrypted output, such as a fixed length. The block chain 120 may be used as a distributed ledger, recording data (e.g., transaction data) for the

network nodes

102 and 110. In other words, each of

network nodes

102 and 110 may have a copy of the ledger that records data. To record new data, blockchain 100 generates an additional block to add to blockchain 120 that includes a cryptographic hash of the previous block in blockchain 120. Therefore, the integrity of the recorded data is associated with the previous blocks, and the recorded data cannot be tampered with unless all of the previous blocks are changed.

In an exemplary embodiment, the blockchain 100 may include a public blockchain, a private blockchain, or a federated blockchain. A common blockchain (e.g., used in bitcoin, etherhouse, etc.) allows any network node to join the blockchain. The private blockchain is controlled by a single administrator and sends invitations to its selected network nodes only to participants with limited access rights. The federated blockchain may be operated by a group of administrators (e.g., a group of financial institutions) rather than being controlled by a single administrator.

In an exemplary embodiment, blockchain 100 may run software corresponding to intelligent contracts, which may be executed in whole or in part without human interaction. For example, multiple parties using respective computer systems may program agreed-upon terms into an intelligent contract, and the intelligent contract may execute automatically when the terms are satisfied. It will be appreciated that since each network node (computer system) in the blockchain owns a copy of the blockchain, a copy of the intelligent contract is also distributed across all network nodes.

In an exemplary embodiment, the contribution to the blockchain 100 may be awarded in a number of tokens, such as bitcoins, ethercoins, and the like. For example, the network nodes 102 may share desired information and receive token rewards in the blockchain 100. What information is desired depends on the nature of the blockchain 100, and different blockchains have different desired information. For example, when blockchain 100 is designed as a financial federation blockchain, the desired information may include financial transaction data, such as parties involved in the transaction, transaction amounts, transaction times, and the like. As another example, when blockchain 100 is a medical association blockchain, the desired information may be physician data, medical records, and the like. On the other hand, the action of the network node may be consuming the token. For example, the network node 102 may spend the token in a transaction with another node, create an intelligent contract, and the like.

Fig. 2 is a schematic diagram of a network node, such as network node 102 (fig. 1), in a blockchain shown in accordance with an exemplary embodiment of the present application. Network node 102 may include a communication interface 202, a memory 204, and a processor 206.

Referring to fig. 2, communication interface 202 may be in communication with block chain 120 (fig. 1) and configured to receive a request from block chain 120 to arbitrate authenticity of data. For example, communication interface 202 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection. As another example, communication interface 202 may be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN. The wireless link may also be implemented by the communication interface 202. In such implementations, communication interface 202 may send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network. The network may generally include a cellular communication network, a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), and the like.

In an exemplary embodiment, the memory 204 may be configured to store a set of instructions. When the processor 206 executes the instructions, the processor 206 may perform the following method for arbitrating the authenticity of data in a blockchain. The memory device 204 may be implemented as any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or a magnetic or optical disk.

In an example embodiment, the network node 102 may perform a method of arbitrating the authenticity of data submitted to a blockchain by another network node (e.g., a first network node). The data may include any data that may be exchanged with other network nodes. For example, the data may include financial data for a transaction, physical data for an anonymous user, device data associated with a condition of a device, and so forth. In some embodiments, the financial data may be purchased by another network node, for example, to determine the trustworthiness of the parties involved in the transaction. In some embodiments, the physical data may be collected and used by a research institution. In some embodiments, the device data may be used to assess the value of the device.

In some embodiments, each network node in the blockchain may be configured with a trustworthiness value associated with a transaction permit in the blockchain. The blockchain may prohibit the network node from conducting a transaction if the trustworthiness value of the network node is below a transaction threshold. In other words, the network node may not use the blockchain when the trustworthiness value of the network node is below the transaction threshold.

In an exemplary embodiment, the network node may obtain a token reward after submitting data to the blockchain. The token may be a cryptocurrency and used to purchase information stored in blockchain 120. In some embodiments, the network node may spend the token to create or join the intelligent contract. The smart contract may be used to trigger a predetermined action when a preset condition is satisfied, and the condition may be set together with the smart contract, as described below.

In an exemplary embodiment, the request to arbitrate authenticity of the data may be submitted through a second network node of the blockchain. Since submitting data may be rewarded for tokens, a network node (e.g., a first network node) may submit spurious data in exchange for tokens. In the exemplary embodiment, any other network node may submit a request for authenticity arbitration of data submitted by the first network node.

Still referring to fig. 2, to perform a method of arbitrating the authenticity of data, e.g., data submitted by a first network node, processor 206 may also include a plurality of functional modules, such as an event generation unit 2062, a prioritization unit 2064, and an arbitration unit 2066. These modules (and any corresponding sub-modules or sub-units) may be functional hardware units (e.g., part of an integrated circuit) of the processor 206 designed for use with other components or parts of a program (stored on a computer-readable medium) that, when executed by the processor 206, performs one or more functions. Although FIG. 2 shows all of the units 2062-2066 within the processor 206, it is contemplated that the units may be distributed among multiple processors that are located near or remote from each other.

In an exemplary embodiment, the event generating unit 2062 is configured to arbitrate requests for authenticity of the data, e.g. submitted by the second network node, generating arbitration events. The arbitration event may be generated for use by an intelligent contract. As described above, the software corresponding to the smart contract performs an action when a preset condition is satisfied. In some embodiments, the action may include decreasing or increasing a trustworthiness value of a network node associated with the smart contract. The preset condition may be whether the network node wins arbitration. For example, software corresponding to a smart contract may need to arbitrate network nodes for voting and determine whether a first network node or a second network node wins. The trustworthiness value of the network node that wins in the arbitration event may be increased and the trustworthiness value of the network node that fails in the arbitration time may be decreased. In some embodiments, to ensure that each vote made by an arbitrating network node may be evaluated, event generation unit 2062 may also determine whether the arbitrating network node has a confidence value above an arbitration threshold. For example, a network node having a confidence value above an arbitration threshold may be invited as an arbitrated network node. In some embodiments, the event generating unit 2062 may further select, among the network nodes having a trustworthiness value above the arbitration threshold, a network node related to the parties involved in the arbitration event. The relevant network node may comprise any network node that ever interacted with the first or second network node. For example, if a network node has previously reviewed data submitted by a first network node, the network node may be invited to arbitrate the event as an arbitrating network node.

In an exemplary embodiment, the event generating unit 2062 may collect information relating to the authenticity of the data as evidence, for example, from the first or second network node. For example, a first network node may submit evidence to prove the integrity of the submitted data, and a second network node may submit evidence to support the direction of the submitted data and the first network node. It should be appreciated that in some embodiments, software corresponding to the intelligent contract may require the second network node to submit evidence before an arbitration event can be generated.

FIG. 3 is a schematic diagram of network node 102 and 110 (FIG. 1) using intelligent contracts 300 shown in accordance with an exemplary embodiment of the present application. For example, software corresponding to the intelligent contract 300 may be run on each

network node

102 and 110 in the blockchain. For purposes of illustration only, it is assumed that in

network node

102 and 110, first network node 104 and second network node 106 are parties involved in arbitration, and that network nodes 102,108, and 110 are arbitration network nodes. In an exemplary embodiment, first network node 104 and second network node 106 submit information regarding the authenticity of the data as evidence to software corresponding to smart contract 300. And as the software corresponding to the smart contract 300 is updated on each of the arbitrating network nodes 102,108, and 110, the arbitrating network nodes 102,108, and 110 may each generate an arbitration event and perform arbitration based on the submitted information.

Referring back to fig. 2, in an exemplary embodiment, the prioritization unit 2064 is configured to prioritize arbitration events to be processed before the next transaction for the arbitrated network node. For example, the arbitrating network node places an arbitration event in the task queue before the next transaction. In other words, the arbitrating network node may be forced to prioritize arbitration events. It will be appreciated that not all of the arbitrating network nodes may perform transactions within a short time after the arbitration event is issued. For example, an arbitrating network node may attempt to execute a transaction several days after an arbitration event occurs. Thus, the time for an arbitrating network node to process an arbitration event and return a result may vary.

In an exemplary embodiment, the arbitration unit 2066 is configured to process the arbitration event based on the submitted information to generate an arbitration result for the network node 102 (the arbitrated network node). The arbitration result may comprise a vote for the first network node or the second network node. The voting of the first network node may indicate that the arbitrating network node determined that the data submitted by the first network node is authentic. The voting of the second network node may indicate that the arbitrating network node determined that the data submitted by the first network node was not authentic.

In some embodiments, software corresponding to the smart contract may collect arbitration results for each arbitration network node in the blockchain and generate a final result based on the collected arbitration results. For example, software corresponding to the intelligent contract may determine which of the first and second network nodes wins the majority. Thus, the final result may indicate that one of the first and second network nodes eventually wins arbitration. Data associated with arbitration events can be tagged with the true end result so that the network node requesting the data can see the history of arbitration. As described above, the software corresponding to the smart contract may not be able to receive votes for all of the arbitrating network nodes simultaneously. Thus, it should be appreciated that software corresponding to a smart contract may retrieve votes that were cast in a given time period.

It should be understood that the winning rules may differ from the majority of rules. For example, software corresponding to a smart contract may require that the second network node win whenever the second network node wins two-thirds of the votes. In this way it can prevent network nodes in the blockchain from generating too many arbitration events, which may waste blockchain resources.

As described above, the trustworthiness value of a network node that fails in an arbitration event may be reduced. If the trustworthiness value of the network node is below the transaction threshold, the network node's transaction permission in the blockchain may be revoked.

Fig. 4 is a flow diagram illustrating a method 400 for arbitrating authenticity of data in a blockchain in accordance with an exemplary embodiment of the present application. For example, method 400 may be implemented by a network node, such as network node 102 (fig. 1), and may include steps S402-S408 as described below.

At step S402, the network node 102 may receive a request for arbitrating the authenticity of the data. For example, the data may be submitted by a first network node (e.g., network node 104 (fig. 1)) and the request may be submitted by a second network node (e.g., network node 106 (fig. 1)).

At step S404, the network node 102 may generate an arbitration event based on the request. The arbitration event may be generated based on a smart contract. As described above, the software corresponding to the smart contract performs an action when a preset condition is satisfied. In some embodiments, the action may include decreasing or increasing a trustworthiness value of a network node associated with the smart contract, and the predetermined condition may be whether the network node wins arbitration. For example, software corresponding to a smart contract may need to arbitrate network nodes for voting and determine whether a first network node or a second network node wins. The trustworthiness value of the network node that wins in the arbitration event may be increased and the trustworthiness value of the network node that fails in the arbitration time may be decreased. In some embodiments, to ensure that each vote made by an arbitrating network node may be evaluated, it may be determined whether the arbitrating network node has a confidence value above an arbitration threshold. For example, a network node having a confidence value above an arbitration threshold may be invited to act as an arbitrating network node. In some embodiments, among the network nodes having a confidence value above the arbitration threshold, network nodes associated with parties involved in the arbitration may be further selected. The relevant network node may comprise any network node that ever interacted with the first or second network node. In addition, information about the authenticity of the data may be collected from the first and second network nodes.

In step S406, the network node 102 may prioritize the arbitration event to be processed before the next transaction for the arbitrated network node. For example, the network node 102 may place an arbitration event in the task queue before the next transaction of the network node, such that the arbitrating network node needs to process the arbitration event before the next transaction. In other words, the arbitrating network node is forced to prioritize arbitration events.

At step S408, the network node 102 may process the arbitration event based on the submitted information, generating an arbitration result for arbitrating network nodes. The arbitration result may comprise a vote for the first network node or the second network node. The voting of the first network node may indicate that the arbitrating network node determines that the data submitted by the first network node is authentic. The voting of the second network node may indicate that the arbitrating network node determines that the data submitted by the first network node is not authentic.

In some embodiments, software corresponding to the smart contract may collect arbitration results for each arbitration network node in the blockchain and generate a final result based on the collected arbitration results. The end result may indicate that one of the first and second network nodes wins arbitration. Data associated with arbitration may be tagged with the end result so that any network node requesting the data may see the history of arbitration.

As described above, the trustworthiness value of the network node with failed arbitration may be reduced. If the trustworthiness value of the network node is below the transaction threshold, the network node's transaction permission in the blockchain may be revoked.

Embodiments of the present application may also provide a non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the above-described method. The computer-readable medium includes volatile or nonvolatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage device. For example, the computer-readable medium of the present application may be a storage device or a storage module having stored thereon computer instructions. In some embodiments, the computer readable medium may be a disk or flash drive having computer instructions stored thereon.

It will be apparent that various modifications and variations can be made in the system and related methods of the present application by those of ordinary skill in the art. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the system and associated method of the present application.

It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.

Claims

1. A computer-implemented method for arbitrating authenticity of data in a blockchain, comprising:

receiving, by an arbitrating network node, data submitted by a first network node of a plurality of network nodes and a request submitted by a second network node of the plurality of network nodes for arbitrating data authenticity, the second network node being different from the first network node, wherein the arbitrating network node is a network node related to parties involved in an arbitration event and having a trustworthiness value above an arbitration threshold, the related network node being any network node that ever interacted with the first or second network node;

generating, by the arbitrating network node, an arbitration event based on the request, wherein the arbitration event comprises information related to the authenticity of the data;

prioritizing, by the arbitrating network node, arbitration events to be processed before a next transaction by the arbitrating network node;

processing, by the arbitrating network node, the arbitration event based on information contained in the arbitration event, generating an arbitration result for the arbitrating network node, and providing the arbitration result to the blockchain, wherein generating the arbitration result comprises determining a vote for the first network node or the second network node;

a final result is generated based on the collected arbitration results.

2. The method of claim 1, wherein generating the arbitration event further comprises:

determining that a trustworthiness value of the arbitrated network node is above a first threshold; and

receiving information relating to authenticity of the data from at least one of the first network node or the second network node.

3. The method of claim 1, wherein prioritizing the arbitration events comprises:

placing the arbitration event in a task queue prior to a next transaction of the arbitrating network node.

4. The method of claim 1, wherein the method further comprises:

configuring a trustworthiness value for each of the plurality of network nodes, the trustworthiness value being associated with a transaction permit in the blockchain.

5. The method of claim 4, wherein:

the trustworthiness value of the first network node submitting the data is increased when the data is determined to be trustworthy, and the trustworthiness value of the first network node submitting the data is decreased when the data is determined to be untrustworthy.

6. The method of claim 4, wherein data submitted by the first network node is marked as a true end result.

7. The method of claim 1, in which the blockchain is a joint blockchain.

8. The method of claim 5, wherein the first network node's permission to transact in the blockchain is revoked in response to the first network node's trustworthiness value being below a second threshold.

9. An arbitrating network node for arbitrating the authenticity of data in a blockchain, comprising:

a communication interface configured to receive data submitted by a first network node of a plurality of network nodes and a request submitted by a second network node of the plurality of network nodes for arbitrating data authenticity, the second network node being different from the first network node, wherein the arbitrating network node is a network node related to parties involved in an arbitration event and having a trustworthiness value above an arbitration threshold, the related network node being any network node that ever interacted with the first or second network node;

a memory; and

at least one processor, coupled to the communication interface and the memory, configured to:

generating an arbitration event based on the request, wherein the arbitration event comprises information related to the authenticity of the data;

prioritizing arbitration events to be processed before a next transaction of the arbitrating network node;

processing the arbitration event based on information contained in the arbitration event, generating an arbitration result for the arbitrated network node, and providing the arbitration result to the blockchain, wherein generating the arbitration result comprises determining a vote for the first network node or the second network node;

a final result is generated based on the collected arbitration results.

10. The network node of claim 9, wherein the processor is further configured to

receiving the information relating to the authenticity of the data from at least one of the first network node or the second network node.

11. The network node of claim 9, wherein the at least one processor is further configured to:

12. The network node of claim 9, wherein the at least one processor is further configured to:

13. The network node of claim 12, wherein the trustworthiness value of the first network node that submits data increases when the data is determined to be trustworthy and decreases when the data is determined to be untrustworthy.

14. The network node of claim 12, wherein the data submitted by the first network node is marked as a true final result.

15. The network node of claim 13, wherein the first network node's permission to transact in the blockchain is revoked in response to the first network node's trustworthiness value being below a second threshold.

16. A non-transitory computer-readable medium storing a set of instructions that, when executed by at least one processor of an arbitrating network node, cause the arbitrating network node to perform a method for arbitrating the authenticity of data in a blockchain, the method comprising:

receiving data submitted by a first network node of a plurality of network nodes and a request submitted by a second network node of the plurality of network nodes for arbitrating data authenticity, the second network node being different from the first network node, wherein the arbitrating network node is a network node related to parties involved in an arbitration event and having a trustworthiness value above an arbitration threshold, the related network node being any network node that ever interacted with the first or second network node;

generating an arbitration event based on the request, wherein the arbitration event comprises information related to authenticity of the data;

prioritizing arbitration events to be processed before a next transaction of the arbitrating network node; and

a final result is generated based on the collected arbitration results.