WO2020061822A1

WO2020061822A1 - Method and system for arbitrating authenticity of data in a blockchain

Info

Publication number: WO2020061822A1
Application number: PCT/CN2018/107625
Authority: WO
Inventors: Chuan Liang; Mengke YANG; Cunsheng LIU
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2018-09-26
Filing date: 2018-09-26
Publication date: 2020-04-02
Also published as: CN111201751B; CN111201751A

Abstract

Embodiments of the disclosure provide methods and network nodes for arbitrating authenticity of data in a blockchain. The method can include: receiving, by an arbitration network node, a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system; generating, by the arbitration network node, an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data; prioritizing, by the arbitration network node, the arbitration event to be processed prior to a next transaction of the arbitration network node; and processing, by the arbitration network node, the arbitration event based on the information included in the arbitration event to generate an arbitration result of the network node, and providing the arbitration result to the blockchain system.

Description

METHOD AND SYSTEM FOR ARBITRATING AUTHENTICITY OF DATA IN A BLOCKCHAIN

TECHNICAL FIELD

The present disclosure relates to computer technologies, more particularly, to methods and systems for arbitrating data in a blockchain.

BACKGROUND

A blockchain may be used for storing and sharing information due to the nature of a shared ledger system. The system can store information, for example, financial data associated with a transaction in the blockchain, and prevent the stored financial data from being tampered. The financial data can include transaction time, transaction amount, collateral information, and the like.

While the blockchain can prevent the stored information from being tampered, the blockchain may not determine whether the stored information is true. It may also be difficult to manually evaluate the stored information, as the blockchain can store massive information.

To address the above problem, embodiments of the disclosure provide methods and systems for arbitrating authenticity of data in a blockchain.

SUMMARY

Embodiments of the disclosure provide a computer-implemented method for arbitrating authenticity of data in a blockchain. The method can include: receiving, by an arbitration network node, a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system; generating, by the arbitration network node, an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data; prioritizing, by the arbitration network node, the arbitration event to be processed prior to a next transaction of the arbitration network node; and processing, by the arbitration network node, the arbitration event based on the information included in the arbitration event to generate an arbitration result of the network node, and providing the arbitration result to the blockchain system.

Embodiments of the disclosure further provide an arbitration network node for arbitrating authenticity of data in a blockchain. The arbitration network node can include: a communication interface configured to receive a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system; a memory; and at least one processor coupled to the communication interface and the memory. The at least one processor can be configured to: generate an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data; prioritize the arbitration event to be processed prior to a next transaction of the arbitration network node; and process the arbitration event based on the information included in the arbitration event to generate an arbitration result of the arbitration network node, and provide the arbitration result to the blockchain system.

Embodiments of the disclosure also provide a non-transitory computer-readable medium that stores a set of instructions, when executed by at least one processor of an arbitration network node, cause the arbitration network node to perform a method for arbitrating authenticity of data in a blockchain. The method can include: receiving a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system; generating an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data; prioritizing the arbitration event to be processed prior to a next transaction of the arbitration network node; and processing the arbitration event based on the information included in the arbitration event to generate an arbitration result of the network node, and providing the arbitration result to the blockchain system.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic diagram of a blockchain system, according to an exemplary embodiment of the disclosure.

FIG. 2 illustrates a schematic diagram of a network node in a blockchain system, according to an embodiment of the disclosure.

FIG. 3 illustrates a schematic diagram of a plurality of network nodes using a smart contract, according to an exemplary embodiment of the disclosure.

FIG. 4 illustrates a flowchart of a method for arbitrating authenticity of data in a blockchain, according to an embodiment of the disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to the 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 illustrates a schematic diagram of a blockchain system 100, according to an exemplary embodiment of the disclosure. A blockchain can be typically managed by a decentralized peer-to-peer network, including a plurality of network nodes. As shown in FIG. 1, blockchain system 100 may include a chain of blocks 120 and network nodes 102-110 connected with chain of blocks 120. For example, each of blocks 120 may be a data block, and each of network nodes 102-110 may be a computer system including a processor and a memory. Network nodes 102-110 can collectively manage chain of blocks 120. Chain of blocks 120 can include a block 122, a block 124, a block 126, and the like. Each block can include a cryptographic hash of the previous block, a timestamp, and stored data. A hash is known in the art as a function that converts an input of, e.g., letters and numbers into an encrypted output of, e.g., a fixed length. Chain of blocks 120 can be used as a distributed ledger to record data (e.g., transaction data) across network nodes 102-110. In other words, each of network nodes 102-110 can have a copy of the ledger recording the data. To record a new piece of data, blockchain system 100 generate one extra block to add to chain of blocks 120, which include cryptographic hash of a prior block in chain of blocks 120. Therefore, integrity of the recorded data is associated with the prior block, and recorded data cannot be tampered unless all prior blocks are altered.

In exemplary embodiments, blockchain system 100 may include a public blockchain, a private blockchain, or a consortium blockchain. The public blockchain (e.g., as used in Bitcoin, Ethereum, or the like) allows any network node to join the blockchain. The private blockchain is controlled by a single administrator, and only sends invitations to selected network nodes as participants having limited access. The consortium blockchain, instead of being controlled by a single administrator, can be operated by a group of administrators, e.g., a group of financial institutions.

In exemplary embodiments, blockchain system 100 may run software corresponding to a smart contract, which can be fully or partially executed without human interaction. For example, multiple parties, using their respective computer systems, can program agreed terms into the smart contract, and when the terms are met, the smart contract can be automatically executed. It is appreciated that, as each network node (computer system) in the blockchain holds a copy of the blockchain, copies of the smart contract are also distributed across all network nodes.

In exemplary embodiments, contribution made to blockchain system 100 can be rewarded with a number of tokens, such as Bit Coins, Ether, and the like. For example, network node 102 can share desired information in blockchain system 100 and be rewarded with tokens. What information is desired may depend on nature of blockchain 100, and different blockchain systems may have different desired information. For example, when blockchain system 100 is designed as a financial consortium blockchain, the desired information may include financial transaction data, such as parties involved in a transaction, transaction amount, transaction time, and the like. In another example, when blockchain system 100 is a medical consortium blockchain, the desired information may be physician data, medical records, and the like. On the other hand, an action of a network node may consume a token. For example, network node 102 may spend a token to make a transaction with another, create a smart contract, and the like.

FIG. 2 illustrates a schematic diagram of a network node, such as network node 102 (FIG. 1) , in a blockchain, according to an exemplary embodiment of the disclosure. 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 chain of blocks 120 (FIG. 1) , and configured to receive, from chain of blocks 120, a request for arbitrating 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 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented by communication interface 202. In such an implementation, communication interface 202 can send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network. The network can typically include a cellular communication network, a Wireless Local Area Network (WLAN) , a Wide Area Network (WAN) , or the like.

In exemplary embodiments, memory 204 may be configured to store a set of instructions. When the set of instructions is executed by processor 206, processor 206 can perform a method of arbitrating authenticity of data in a blockchain, described below. Memory 204 may be implemented as any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random access memory (SRAM) , an electrically erasable programmable read-only memory (EEPROM) , an erasable programmable read-only memory (EPROM) , a programmable read-only memory (PROM) , a read-only memory (ROM) , a magnetic memory, a flash memory, or a magnetic or optical disk.

In exemplary embodiments, network node 102 may perform a method of arbitrating authenticity of data submitted to the blockchain system by another network node, such as a first network node. The data may include any data that can be exchanged with other network nodes. For example, the data may include financial data of a transaction, physical data of an anonymous user, device data associated with the condition of the device, and the like. In some embodiments, the financial data may be purchased by another network node, for example, to determine the credibility of 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 evaluate the value of the device.

In some embodiments, each of the network nodes in the blockchain system may be assigned with a credibility value associated with a permission for transaction in the blockchain system. If the credibility value of a network node is lower than a transaction threshold, the blockchain system may prohibit the network node from making a transaction. In other words, the network node may not use the blockchain when its credibility value is lower than the transaction threshold.

In exemplary embodiments, a network node may be rewarded with a token after submitting data to the blockchain system. The token may be a cryptocurrency and be used to purchase information stored in chain of blocks 120. In some embodiments, a network node may spend a token to create or join a smart contract. The smart contract may be used to trigger a predetermined action when a preset condition is met, and the condition may be set along with the smart contract, as described below.

In exemplary embodiments, a request for arbitrating authenticity of data may be submitted by a second network node of the blockchain system. As submitting data may be rewarded with tokens, it is possible that a network node (e.g., the first network node) may submit fake data in exchange for the tokens. In the exemplary embodiments, any other network node can submit a request for arbitrating authenticity of the data submitted by the first network node.

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

In exemplary embodiments, event generation unit 2062 is configured to generate an arbitration event based on a request for arbitrating authenticity of data, e.g., submitted by the second network node. The arbitration event can be generated for use by a smart contract. As described above, software corresponding to the smart contract performs an action when a preset condition is met. In some embodiments, the action can include decreasing or increasing a credibility value of a network node associated with the smart contract. And the preset condition can be that whether the network node wins the arbitration. For example, the software corresponding to the smart contract may require arbitration network nodes to vote, and determine whether the first network node or the second network node wins. The credibility value of the network node winning the arbitration event may be increased, and the credibility value of the network node losing the arbitration may be decreased. In some embodiments, to ensure that each vote made by the arbitration network nodes is evaluated, event generation unit 2062 may further determine whether an arbitration network node has a credibility value that is higher than an arbitration threshold. For example, network nodes having credibility values higher than the arbitration threshold may be invited to be arbitration network nodes. In some embodiments, event generation unit 2062 may further select, among the network nodes having credibility values higher than the arbitration threshold, network nodes related to parties involved in the arbitration event. The related network nodes may include any network node that has once interacted with the first or second network node. For example, if a network node has reviewed the data submitted by the first network node before, then the network node can be invited as an arbitration network node to arbitrate the event.

In exemplary embodiments, event generation unit 2062 may collect information relating to authenticity of the data as evidence, e.g., from the first or second network node. For example, the first network node may submit evidence to prove the integrity of the submitted data, and the second network node may submit evidence to support an accusation against the submitted data and the first network node. It is appreciated, in some embodiments, the software corresponding to the smart contract may require the second network node to submit evidence before the arbitration event can be generated.

FIG. 3 illustrates a schematic diagram of network nodes 102-110 (FIG. 1) using a smart contract 300, according to an exemplary embodiment of the disclosure. For example, software corresponding to smart contract 300 can run on each of network nodes 102-110 in the blockchain system. For illustrative purposes only, it is assumed that among network nodes 102-110, a first network node 104 and a second network node 106 are the parties involved in an arbitration, and

network nodes

102, 108, and 110 are the arbitration network nodes. In the exemplary embodiments, first network node 104 and second network node 106 submit information relating to the authenticity of the data as evidence to software corresponding to smart contract 300. And when the software corresponding to smart contract 300 updates on each of

arbitration network nodes

102, 108, and 110,

arbitration network nodes

102, 108, and 110 may each generate an arbitration event and perform arbitration based on the submitted information.

With reference back to FIG. 2, in exemplary embodiments, prioritizing unit 2064 is configured to prioritize the arbitration event to be processed prior to a next transaction of network node 102 the arbitration network node. For example, the arbitration network node places in a task queue the arbitration event before the next transaction. In other words, the arbitration network node may be forced to process the arbitration event first. It is appreciated that, not all arbitration network nodes can perform transactions in a short time after the arbitration event is placed. For example, an arbitration network node may try to perform a transaction several days after the arbitration event is placed. Therefore, the time when the arbitration network nodes process the arbitration events and return the results may be different.

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

In some embodiments, the software corresponding to the smart contract may collect the arbitration results of each arbitration network node in the blockchain system, and generate a final result based on the collected arbitration results. For example, the software corresponding to the smart contract may determine which one of the first and second network nodes wins a majority. Thus, the final result may indicate one of the first and second network nodes wins the arbitration finally. The data associated with the arbitration event can be tagged with the final result of being authentic, so that a network node requesting the data can see the history of the arbitration. As described above, the software corresponding to the smart contract may not be able to receive the votes of all arbitration network nodes at the same time. Therefore, it is appreciated that the software corresponding to the smart contract may retrieve votes that are made within a given period of time.

It is appreciated that, the winning rule can be different than a majority rule. For example, the software corresponding to the smart contract may require that the second network node wins only if the second network node wins two thirds of the votes. In this way, it can prevent network nodes in the blockchain system from generating too many arbitration events, which may waste resources of the blockchain system.

As discussed above, the credibility value of the network node losing the arbitration may be decreased. If the credibility value of the network node is lower than a transaction threshold, the permission for transaction within the blockchain may be revoked for the network node.

FIG. 4 illustrates a flowchart of a method 400 for arbitrating authenticity of data in a blockchain, according to an exemplary embodiment of the disclosure. For example, method 400 may be implemented by a network node, e.g., network node 102 (FIG. 1) , and may include steps S402-S408 as described below.

In step S402, network node 102 can receive a request for arbitrating authenticity of 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) .

In step S404, 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, software corresponding to the smart contract performs an action when a preset condition is met. In some embodiments, the action may include decreasing or increasing a credibility value of a network node associated with the smart contract, and the preset condition may be that whether the network node wins the arbitration. For example, the software corresponding to the smart contract may require arbitration network nodes to vote, and determine whether the first network node or the second network node wins. The credibility value of the one winning the arbitration may be increased, the credibility value of the one losing the arbitration may be decreased. In some embodiments, to ensure that each vote made by the arbitration network node can be evaluated, whether the arbitration network node has a credibility value that is higher than an arbitration threshold may be further determined. For example, network nodes having credibility values higher than the arbitration threshold may be invited to be arbitration network nodes. In some embodiments, among the network nodes having credibility values higher than the arbitration threshold, network nodes related to the parties involved in the arbitration may be further selected. The related network nodes may include any network node that has once interacted with the first or second network node. In addition, the information relating to the authenticity of the data may be collected from the first and second network nodes.

In step S406, network node 102 may prioritize the arbitration event to be processed prior to a next transaction of the network node. For example, network node 102 places in a task queue the arbitration event before the next transaction of the network node, such that the arbitration network node is required to process the arbitration event before the next transaction. In other words, the arbitration network node is forced to the process the arbitration event first.

In step S408, network node 102 may process the arbitration event based on the submitted information to generate an arbitration result of the network node. The arbitration result may include a vote for the first network node or the second network node. The vote for the first network node may indicate that the arbitration network node determines the data submitted by the first network node is authentic. The vote for the second network node may indicate that the arbitration network node determines the data submitted by the first network node is not authentic.

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

It is appreciated that, the winning rule can be different than a majority rule. For example, the software corresponding to the smart contract may require that the second network node wins only if the second network node wins two thirds of the votes. In this way, it can prevent network nodes in the blockchain system from generating too many arbitration events, which may waste resources of the blockchain.

As discussed above, the credibility value of the network node losing the arbitration may be decreased. If the credibility value of the network node is lower than a transaction threshold, the permission for transaction within the blockchain can be revoked for the network node.

Embodiments of the disclosure can further provide a non-transitory computer-readable medium storing instructions which, when executed, cause one or more processors to perform the above described methods. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices. For example, the computer-readable medium may be the storage device or the memory module having the computer instructions stored thereon, as disclosed. In some embodiments, the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon.

It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system and related methods. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed system and related methods.

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

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

receiving, by an arbitration network node, a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system;

generating, by the arbitration network node, an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data;

prioritizing, by the arbitration network node, the arbitration event to be processed prior to a next transaction of the arbitration network node; and

processing, by the arbitration network node, the arbitration event based on the information included in the arbitration event to generate an arbitration result of the network node, and providing the arbitration result to the blockchain system.
The method of claim 1, further comprising:

receiving the data that is submitted by a first network node of the plurality of network nodes; and

receiving the request that is submitted by a second network node of the plurality of network nodes, the second network node being different from the first network node.
The method of claim 2, wherein generating the arbitration event further comprises:

determining that the arbitration network node has a credibility value higher than a first threshold; and

receiving the information relating to the authenticity of the data from at least one of the first network node or the second network node.
The method of claim 1, wherein prioritizing the arbitration event comprises;

placing, in a task queue, the arbitration event prior to the next transaction of the arbitration network node.
The method of claim 3, wherein generating the arbitration result comprises:

determining a vote for the first network node or the second network node.
The method of claim 5, further comprising:

assigning a credibility value to each of the plurality of network nodes, the credibility value being associated with a permission for transaction in the blockchain system.
The method of claim 6, wherein:

when it is determined that the data is authentic, the credibility value of the first network node from which the data is submitted is increased, and when it is determined that the data is not authentic, the credibility value of the first network node is submitted is decreased.
The method of claim 6, wherein the data submitted by the first network node is tagged with a final result of being authentic.
The method of claim 1, wherein the blockchain is a consortium blockchain.
The method of claim 7, wherein in response to the first network node having a credibility value lower than a second threshold, the permission for transaction in the blockchain system is revoked for the first network node.
An arbitration network node for arbitrating authenticity of data in a blockchain, comprising:

a communication interface configured to receive a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system;

a memory; and

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

generate an arbitration event based on the request, wherein the arbitration event includes information relating to the authenticity of the data;

prioritize the arbitration event to be processed prior to a next transaction of the arbitration network node; and

process the arbitration event based on the information included in the arbitration event to generate an arbitration result of the arbitration network node, and provide the arbitration result to the blockchain system.
The network node of claim 12, wherein the communication interface is further configured to:

receive the data that is submitted by a first network node of the plurality of network nodes; and

receive the request that is submitted by a second network node of the plurality of network nodes, the second network node being different from the first network node.
The network node of claim 12, wherein the processor is further configured to

determine that the arbitration network node has a credibility value that is higher than a first threshold; and

receive the information relating to the authenticity of the data from at least one of the first network node or the second network node.
The network node of claim 11, wherein the at least one processor is further configured to:

place, in a task queue, the arbitration event prior to the next transaction of the arbitration network node.
The network node of claim 13, wherein the at least one processor is further configured to:

determine a vote for the first network node or the second network node.
The network node of claim 15, wherein the at least one processor is further configured to:

assign a credibility value to each of the plurality of network nodes, the credibility value being associated with a permission for transaction in the blockchain system.
The network node of claim 16, wherein when it is determined that the data is authentic, the credibility value of the first network node from which the data is submitted is increased, and when it is determined that the data is not authentic, the credibility value of the first network node is submitted is decreased.
The network node of claim 16, wherein the data submitted by the first network node is tagged with a final result of being authentic.
The network node of claim 17, wherein in response to the first network node having a credibility value lower than a second threshold, the permission for transaction in the blockchain system is revoked for the first network node.
A non-transitory computer-readable medium that stores a set of instructions, when executed by at least one processor of an arbitration network node, cause the arbitration network node to perform a method for arbitrating authenticity of data in a blockchain, the method comprising:

receiving a request for arbitrating authenticity of the data, wherein the arbitration network node is one of a plurality of network nodes in a blockchain system;

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

prioritizing the arbitration event to be processed prior to a next transaction of the arbitration network node; and

processing the arbitration event based on the information included in the arbitration event to generate an arbitration result of the network node, and providing the arbitration result to the blockchain system.