EP3891952A2 - A node testing method and apparatus for a blockchain system - Google Patents

A node testing method and apparatus for a blockchain system

Info

Publication number
EP3891952A2
EP3891952A2 EP19821171.6A EP19821171A EP3891952A2 EP 3891952 A2 EP3891952 A2 EP 3891952A2 EP 19821171 A EP19821171 A EP 19821171A EP 3891952 A2 EP3891952 A2 EP 3891952A2
Authority
EP
European Patent Office
Prior art keywords
node
nodes
confirming
time
data
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
EP19821171.6A
Other languages
German (de)
French (fr)
Inventor
Richard Matthew DENNIS
Gareth Huw OWENSON
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.)
Dragon Infosec Ltd
Original Assignee
Dragon Infosec 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 Dragon Infosec Ltd filed Critical Dragon Infosec Ltd
Publication of EP3891952A2 publication Critical patent/EP3891952A2/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3414—Workload generation, e.g. scripts, playback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • 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/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • 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/12—Applying verification of the received information
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions

Definitions

  • This application relates to methods and an apparatus for blockchain systems.
  • the application relates to a method and apparatus for testing the capability and reputation of the nodes participating in a blockchain system.
  • Blockchain systems are a distributed record system using a sequence of blocks of data that are each consecutively linked using cryptography. Each block typically encapsulates a plurality of documents or transactions that are then shared between the nodes of a peer-to- peer network. The plurality of blocks act as a ledger that is distributed with local versions of the blockchain stored at each of the nodes in the peer-to-peer network running the blockchain system.
  • Blockchain concepts were initially devised to create a record of fact that is immutable and cannot subsequently be changed or modified covertly. This has typically been applied to transactions of digital cash, however this can be more generally applied to digital tokens that can be transferred between parties to establish rights and ownership over a process or item. These transfers, or uses of the digital tokens, are recorded as transactions in the blocks of the blockchain, which may be referred to as a transaction blockchain.
  • the most common consensus protocol today is the proof of work protocol, which sets a computational problem with an answer that is simple to validate, but not simple to determine, and pits the various nodes in a race to determine the answer.
  • the first node to arrive at the answer writes a block incorporating this answer and a collection of
  • the completed block is then sent from this first node to the other nodes that it is aware of in the blockchain system, who then forward the completed block to any other nodes that they are in turn aware of.
  • the other nodes can easily validate that the new block meets the requirements of the proof of work protocol and the race then begins for the next block. If more than one node solves the proof of work at a similar time then two or more versions of the blockchain will be in existence. There will usually be a rating mechanism for a node to determine which of the known versions of the blockchain should be selected as the authoritative version of the blockchain; however, due to the peer-to-peer nature of the network a node may not be aware of all of the versions of the blockchain and so different sets of nodes may begin working on the next block for respective versions of the blockchain. This may lead to the authoritative version of the blockchain changing from one version to another in a process known as forking. This reintroduces the possibility of a double spend and opens the system to a vulnerability of attack.
  • the proof of work protocol results in the expenditure of a large amount of computer processing in order to attempt to avoid such an attack and to provide the distributed system with a level of trust.
  • One alternative example is the proof of stake protocol, where the responsibility for writing new blocks is distributed amongst the largest stakeholders in the blockchain. The trust in such a protocol is inferred on the basis that these largest stakeholders have the most to lose if the blockchain is compromised and accordingly they may be considered to be the most likely to act in the best interests of the blockchain system.
  • Another similar example is the proof of authority protocol, where only authorised nodes are able to write and confirm new blocks, but these authorised nodes are required to be linked to a user’s public identity such that the user’s reputation is at stake. This incentivises the authorised nodes to act in the best interests of the blockchain system in order to maintain their own personal reputation.
  • the present disclosure relates to a method for a blockchain system comprising a plurality of nodes, the method being operated at a first node of the blockchain system to test a second node of the blockchain system.
  • the test comprises sending, from the first node to the second node, a volume of data to be hashed by the second node, wherein the volume of data is sent at a first time; and receiving at the first node, from the second node, the hash of the volume of data, wherein the hash of the volume of data is received at a second time.
  • the method further comprises determining, by the first node, whether the received hash of the volume of data matches an expected hash of the volume of data; determining, by the first node, a time difference between the first time and the second time; and determining, by the first node, whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
  • the method of the first aspect of the present disclosure advantageously determines a measure of the downlink network bandwidth / speed of the second node’s network connection by performing tests on the second node participating in the blockchain system and then uses this test data to determine whether the second node should be eligible to be in a pool of nodes that can be selected to be a confirming node of the blockchain for a given period of time, i.e. a node of the blockchain that processes and confirms received transactions that are to be appended to the blockchain by including them, and distributing them to other nodes in the blockchain system, in confirmed blocks.
  • This method can be carried out autonomously in the blockchain system, without the need for manual user intervention, and accordingly the invention also further improves the robustness of such blockchain systems.
  • this minimum requirement also provides a certain level of cost to any would be attacker that might try to introduce a large number of nodes that are eligible to be selected as confirming nodes in an attempt to increase the probability of control of the confirmed blocks to be appended to the blockchain, since each node would individually require a certain amount of network bandwidth in order to receive the respective volume of data and to send the expected corresponding hash back to the first node within a given time difference. This advantageously improves the security of the blockchain system and its resilience to attack.
  • the second node may be determined, by the first node, to be eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash. This advantageously provides a simple way for the first node to test whether the second node is eligible to be selected as a confirming node.
  • the testing, by the first node of the blockchain system, of the second node of the blockchain system may be performed at a random time during each time period of a series of consecutive time periods.
  • This advantageously enables the method to give a realistic view of the test results for the second node and prevents the second node from being able to anticipate the test time and to prioritise bandwidth availability during that anticipated test time, which would lead to an unrepresentative view of the available bandwidth of the second node during any given period of time.
  • the second node may be determined, by the first node, to not be eligible to be selected as a confirming node if the determined time difference for the given volume of data is above the threshold time and/or the received hash does not match the expected hash for n consecutive time periods, where n is a positive non-zero integer.
  • the method advantageously provides an n number of retries / retests and the second node is only determined to not be eligible to be selected as a confirming node if the second node is unable to return the correctly expected hash of the volume of data within the threshold time difference in any of the n retries.
  • This allows a second node that is, for example, momentarily effected by packet loss in the download of the volume of the data from, or the upload of the hash of the volume of the data to the first node (for example due to short term network downtime) to continue to be eligible to be selected as a confirming node in the event that they are able to reach the threshold time difference requirement in one of the tests / retests or retries.
  • the received hash and the expected hash may be rolling hashes.
  • the method further comprises determining, by the first node, an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration.
  • This period of time in which the second node is active on the blockchain system and responding to the testing of the first node may be referred to as an uptime of the second node, which further increases the cost to any would be attacker as the threshold requirements would need to be maintained for each node controlled by the attacker for an extended period of time until the threshold duration of uptime is met.
  • the method may further comprise testing, by the first node of the blockchain system, a plurality of further nodes of the blockchain system; and ranking, by the first node, the second node and the plurality of further nodes based on the respective determined time differences; wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system.
  • This advantageously forms a pool of nodes that are eligible to be selected as a confirming node where the pool of eligible nodes represents the nodes with the best available network bandwidth as tested by the test of the first aspect of the present disclosure.
  • Each of the plurality of nodes may be considered to be a second node in the framework set out above and in the following detailed description, with the first node being a trusted party.
  • the method may further comprise appending the determined time difference and/or the determined eligibility of the second node to a further blockchain.
  • appending the determined time difference and/or the determined eligibility of the second node to a further blockchain. This enables a history of the test results for each second node of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective second nodes over time.
  • the first aspect of the present disclosure also relates to a node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to test a second node of the blockchain system.
  • This first node comprises a network interface configured to send a volume of data to the second node at a first time, wherein the volume of data is to be hashed by the second node; the network interface being further configured to receive the hash of the volume of data from the second node at a second time; and one or more processors configured to determine whether the received hash of the volume of data matches an expected hash of the volume of data; to determine a time difference between the first time and the second time; and to determine whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
  • the first node apparatus of the first aspect of the present disclosure advantageously determines a measure of the downlink network bandwidth / speed of the second node’s network connection by performing tests on the second node participating in the blockchain system and then uses this test data to determine whether the second node should be eligible to be in a pool of nodes that can be selected to be a confirming node of the blockchain for a given period of time, i.e. a node of the blockchain that processes and confirms received transactions that are to be appended to the blockchain by including them, and distributing them to other nodes in the blockchain system, in confirmed blocks.
  • This enables the first node to select the best second nodes for confirming node eligibility and thus ensures that any confirming nodes selected from that pool of eligible nodes will be able to process any transactions for producing confirmed blocks quickly and efficiently.
  • this minimum requirement also provides a certain level of cost to any would be attacker that might try to introduce a large number of nodes that are eligible to be selected as confirming nodes in an attempt to increase the probability of control of the confirmed blocks to be appended to the blockchain, since each node would individually require a certain amount of network bandwidth in order to receive the respective volume of data and to send the expected corresponding hash back to the first node within a given time difference. This advantageously improves the security of the blockchain system and its resilience to attack.
  • the one or more processors may be configured to determine that the second node is eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash. This advantageously provides a simple way for the first node to test whether the second node is eligible to be selected as a confirming node.
  • the network interface may be configured to send a volume of data to the second node at a random time during each time period of a series of consecutive time periods.
  • the one or more processors may be configured to determine that the second node is not eligible to be selected as a confirming node if the determined time difference for a given volume of data is determined to be above the threshold time and/or the received hash is determined to not match the expected hash for n consecutive time periods, where n is a positive non-zero integer.
  • the first node advantageously provides an n number of retries / retests and the second node is only determined to not be eligible to be selected as a confirming node if the second node is unable to return the correctly expected hash of the volume of data within the threshold time difference in any of the n retries.
  • the received hash and the expected hash may be rolling hashes.
  • the one or more processors may be further configured to determine an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the one or more processors are only configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration.
  • This period of time in which the second node is active on the blockchain system and responding to the testing of the first node may be referred to as an uptime of the second node, which further increases the cost to any would be attacker as the threshold requirements would need to be maintained for each node controlled by the attacker for an extended period of time until the threshold duration of uptime is met.
  • the apparatus may be further configured to test a plurality of nodes of the blockchain system by sending volumes of data to and receiving corresponding hashes from each of the plurality of nodes of the blockchain system and determining the respective time differences; wherein the one or more processors are further configured to rank the second node and the plurality of further nodes based on the respective determined time differences; and wherein the one or more processors are configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system only if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system.
  • the node apparatus may be further configured to append the determined time difference and/or the determined eligibility of the second node to a further blockchain.
  • This enables a history of the test results for each second node of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective second nodes over time.
  • the present disclosure relates to a method for a blockchain system comprising a plurality of nodes, the method comprising: determining, by a first node, a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of a plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time; receiving, by the first node, one or more confirmed blocks of data from each of the plurality of confirming nodes; and determining, by the first node, whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, identifying any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time
  • the method of the second aspect of the present disclosure advantageously provides for a blockchain system in which a plurality of nodes are selected, from a pool of eligible nodes, as being confirming nodes in the blockchain system for a given duration of time, whereby the reputation of each of the confirming nodes can be monitored by the first node by determining whether each selected confirming node creates and distributes confirmed blocks matching those confirmed by other selected confirming nodes. If a proportion of the selected confirming nodes have been compromised, for example by a would be attacker, then these confirming nodes may attempt to create and distribute modified confirmed blocks that do not match those distributed by confirming nodes that have not been compromised.
  • the method of the second aspect of the disclosure can advantageously identify selected confirming nodes that distribute blocks that do not match the majority of the respective blocks received from corresponding other confirming nodes as potentially having been compromised and thus the method can remove the eligibility for future selection as a confirming node of these potentially compromised nodes in order to protect the integrity of the blockchain system.
  • confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received may only be identified as not being eligible to be a confirming node for future periods of time if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other.
  • a larger agreement majority or supermajority may be required in order for those nodes that do not agree with the majority to be identified as potentially having been compromised and to be prevented from being eligible for selection as a confirming node in the future. This advantageously reduces the likelihood that nodes may be mistakenly identified as compromised by requiring a higher threshold of agreement before disagreeing nodes are stripped of their eligibility to be selected as a confirming node again in the future.
  • the method may further comprise monitoring, by the first node, a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and identifying, by the first node, any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time. This advantageously also removes nodes that do not distribute any confirmed blocks from eligibility to be a confirming node in future periods of time.
  • the determined plurality of confirming nodes for a given period of time may be an odd number of confirming nodes. This advantageously ensures that a majority agreement can be reached between the nodes.
  • the determined plurality of confirming nodes for a given period of time may represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node. This advantageously keeps the chance of an eligible node being selected as a confirming node the same in the event that one or more nodes are identified as not being eligible to be a confirming node for future periods of time.
  • the method may further comprise appending to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
  • the second aspect of the present disclosure also relates to a node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to assess a plurality of nodes each identified as being eligible to be a confirming node of the blockchain system.
  • This first node comprises one or more processors configured to determine a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of the plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time; and a network interface configured to receive one or more confirmed blocks of data from each of the plurality of confirming nodes; wherein the one or more processors are further configured to determine whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, to identify any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time.
  • the first node apparatus of the second aspect of the present disclosure advantageously provides for a blockchain system in which a plurality of nodes are selected, from a pool of eligible nodes, as being confirming nodes in the blockchain system for a given duration of time, whereby the reputation of each of the confirming nodes can be monitored by the first node by determining whether each selected confirming node creates and distributes confirmed blocks matching those confirmed by other selected confirming nodes. If a proportion of the selected confirming nodes have been compromised, for example by a would be attacker, then these confirming nodes may attempt to create and distribute modified confirmed blocks that do not match those distributed by confirming nodes that have not been compromised.
  • the first node of the second aspect of the disclosure can advantageously identify selected confirming nodes that distribute blocks that do not match the majority of the respective blocks received from corresponding other confirming nodes as potentially having been compromised and thus the first node can remove the eligibility of these potentially compromised nodes for future selection as a confirming node in order to protect the integrity of the blockchain system.
  • the one or more processors may be further configured to identify confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time only if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other.
  • the first node may require a larger agreement majority or supermajority for nodes that do not agree with the majority to be identified as potentially having been compromised and to be prevented from being eligible for selection as a confirming node in the future.
  • the one or more processors may be further configured to monitor a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and to identify any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time. This advantageously also removes nodes that do not distribute any confirmed blocks from eligibility to be a confirming node in future periods of time.
  • the determined plurality of confirming nodes for a given period of time may be an odd number of confirming nodes. This advantageously ensures that a majority agreement can be reached between the nodes.
  • the determined plurality of confirming nodes for a given period of time may represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node. This advantageously keeps the chance of an eligible node being selected as a confirming node the same in the event that one or more nodes are identified as not being eligible to be a confirming node for future periods of time.
  • the node apparatus may be further configured to append to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
  • a further blockchain for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
  • Figure 1 is a block diagram of a first node according to the first aspect of the present disclosure interacting with a plurality of further nodes participating in a blockchain system;
  • Figure 2 is a flowchart illustrating a method according to a first aspect of the present disclosure.
  • Figure 3 is a flowchart illustrating a method according to a second aspect of the present disclosure.
  • FIG. 1 is a block diagram of a plurality of nodes participating in a blockchain system 8.
  • a first node 10 and two participant nodes 20 are illustrated, although it will be appreciated that, in practice, a plurality of further participant nodes 20 would also typically form part of the blockchain system.
  • These participant nodes 20 may be referred to as a plurality of second nodes or further nodes. Although a single second node may be described below, it will be appreciated that the methods and processes may be repeated for many or all of the plurality of nodes participating in the blockchain system and that each of these nodes may be considered to be a‘second node’ in this context.
  • the first node 10 comprises a network interface 12, a processor 14 and a local further blockchain 16.
  • the processor 14 may represent a plurality of processors each arranged to perform certain calculations / determinations in line with the following description, or alternatively a single processor 14 may perform all of these functions.
  • the network interface has been shown as a single bidirectional interface in Figure 1 , it will be appreciated that this could alternatively be implemented with separate input and output network interfaces.
  • the purpose of the network interface 12 is to enable the first node 10 to communicate with the participant nodes of the blockchain system 8.
  • Each participant node 20 comprises a local transaction blockchain 18.
  • each participant node 20 may also comprise a network interface 12, a processor 14.
  • the first node 10 and the plurality of participant nodes 20 of the blockchain system 8 may communicate with each other, for example to form a peer-to-peer network.
  • the plurality of participant nodes may also communicate directly between themselves, although this is not illustrated in Figure 1 for the sake of clarity.
  • the respective network interfaces may utilise any known wired or wireless network topology over local area networks, wide area networks and the internet.
  • the local transaction blockchain 18 refers to the local copy of the blockchain of the blockchain system that encapsulates a plurality of documents or transactions in blocks of data to form the distributed record system by cryptographically linking the sequence of blocks of data.
  • Each block of the blockchain is shared between the participant nodes 20 of the blockchain system 8, typically using a peer-to-peer network.
  • the plurality of blocks act as a ledger that is distributed with these local versions of the transaction blockchain 18 being stored locally at each of the participant nodes of the blockchain system and network.
  • the blocks to be appended to all of the versions of the blockchain may be confirmed by and broadcast / distributed from a single participant node 20, or alternatively a plurality of participant nodes 20 may agree on the confirmed blocks to be distributed to the other participant nodes in the blockchain system 8.
  • the identity of the participant node that is, or nodes that are, responsible for confirming blocks and distributing these confirmed blocks to other nodes during one time period will typically be different to the identity of the participant node, or nodes, that are responsible for confirming blocks and distributing them in the following time period.
  • Each node that is responsible for confirming blocks and distributing them at the current point in time will be referred to as the confirming nodes or leader nodes.
  • all nodes are typically eligible to become the confirming node for a given time interval and the node that becomes the confirming node is the node that is first to solve the relevant computational problem that has been set.
  • the node or nodes that will become the confirming nodes are typically selected from a subset of the participant nodes that have been identified as being eligible to be a confirming node.
  • the first aspect of the present disclosure provides a method and apparatus for evaluating participant nodes 20 using a resource test performed by the first node 10.
  • the first node 10 does not need to store a local copy of the transaction blockchain 18, however the first node may still be considered to be a node of the blockchain system 8 and may be referred to as an authority node or a reputation node herein.
  • the first node 10 will be aware of the participant nodes 20 participating in the blockchain system and preferably stores the basic data required to contact each participant node.
  • This basic data includes a unique public identity to enable other nodes to direct messages to and communicate with a given participant node 20.
  • This unique public identity may simply be the IP address of the participant node 20; however, the unique public identity may be set to maintain user anonymity, for example by using an onion address for access through the Tor hidden service.
  • the basic data further includes a public key for
  • cryptographic digital signatures of the given participant node 20 details of the configuration and/or capabilities of the node machine and a human readable nicknames may also be provided for each of the participant nodes in order to improve usability.
  • the first node 10 can contact each of the participant nodes 20 in order to initiate a resource test.
  • the blockchain system 8 may be provided with a plurality of first nodes 10 and that this may scale with the number of participant nodes 20 in order to perform the resource tests in a given time frame.
  • Figure 2 illustrates a flowchart according to the first aspect of the present disclosure and relates to a test of the network bandwidth or download speed of the second node 20 from the first node 10 and, by analogy, the blockchain system 8.
  • the first node 10 sends a volume of data to one of the participant nodes 20, which will be referred to as a second node 20 herein, wherein the volume of data is sent at a first time and it is to be hashed by the second node upon receipt.
  • the second node will be aware that it is required by the blockchain system 8 to calculate a hash of the volume of data received from the first node 10 and it will compute this hash and send it back to the first node as soon as possible, for example when the final piece of data of the volume of data has been received.
  • the first node 10 receives the hash of the volume of data from the second node 20 at a second time.
  • the hash may be any cryptographic hash function, for example a Secure Hash Algorithm 2 function with a 512 bit digest (SHA512).
  • the hash may be computed as a rolling hash or a recursive hash; this means that the second node 20 can start to compute the hash before the entire volume of data has been received and thus minimises the amount of time taken for the second node 20 to compute the hash once the volume of data has been received from the first node 10. This enables this aspect of the resource test to only test network bandwidth / download connection speed of the second node 20 and to minimise the impact of the CPU processing power required to process the hash of the volume of data.
  • SHA512 Secure Hash Algorithm 2 function with a 512 bit digest
  • step 26 the first node 10 determines a time difference between the first time, when the first node sent the volume of data to the second node 20, and the second time, when the first node received the hash of the volume of data from the second node 20.
  • the first node 10 also verifies whether the hash received from the second node matches the expected hash for the volume of data sent to the second node 20.
  • the first node 10 determines whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data. If the received hash of the volume of data does not match the expected hash of the volume of data then it may be determined that the second node has a poor connection that has resulted in some of the packets of the volume of data being lost and thus the second node 20 may be considered to have failed the network bandwidth test.
  • the processor of the first node may proceed to consider whether the second node passes the network bandwidth test and is eligible to be selected as a confirming node based on the determined time difference between the first and second times.
  • This determination may be based on a threshold time, wherein the second node 20 is required to send the hash of the volume of data to the first node 10 such that the time taken (the determined time difference) is less than the threshold time.
  • This simple comparison can be used to determine whether the second node is able to receive the volume of data and send the hash back within the requirements of the blockchain system.
  • This provides a simulation of the amount of time it may take for the second node to receive transactions to be included in the transaction blockchain and to send the block comprising these transactions to the other participant nodes in the blockchain system and thus a measure of the efficiency and suitability of the second node in performing the function of a confirming node.
  • a volume of data having the same total storage size is sent to each of the second nodes / participant nodes 20, the performance of each of the plurality of participant nodes of the blockchain system can be compared.
  • This network bandwidth test is preferably performed periodically for each of the participant nodes 20 of the blockchain system 8 to ensure that the performance of the participant nodes identified as being eligible to be selected as a confirming node is maintained. For example, this test may be performed once a day. It would be preferable for the time of day or other periodicity of the test to be randomised such that the participant node / second node 20 is not able to anticipate the time of the test and attempt to improve the second nodes network bandwidth performance during that period of time in order to provide a result that is not representative of the second node’s typical performance.
  • the data content of the volume of data sent is preferably different each time (or taken from a sufficiently large set of volumes of data) so that the data being sent cannot be identified or anticipated by the second node 20 before it has been received in full by that node. This prevents the second node from anticipating the corresponding hash of the data and sending this hash to the first node prior to the full volume of data having been received from the first node, which would cause the test to arrive at an inaccurate result for that second node 20.
  • the data size of the volume of data may vary and the comparison may be based on a threshold download speed.
  • the total size of the volume of data sent can be divided by the determined time difference in order to provide a speed value that can be used to compare multiple tests across different participant nodes even if the data size of the volume of data varies from test to test.
  • the second node 20 in the event that a second node 20 is determined to fail the network bandwidth test (either by providing an incorrect hash or not meeting the required time frame for response), the second node 20 may be subsequently re-tested and afforded a grace period within which the second node 20 will continue to be determined to be eligible to be selected as a confirming node if the second node passes the network bandwidth test (by providing the expected hash within the required time for response at least once during that grace period).
  • the second node may be re-tested on each of the three subsequent days and the second node may only be determined to be ineligible to be selected as a confirming node if the second node fails all three subsequent re-tests.
  • the frequency / periodicity of the re-testing may differ from the frequency with which a participant node would be tested in the event that it passed the network bandwidth test.
  • the second node may be further required to have been active in the blockchain system 8 and to have met the requirements of the network bandwidth test for a given consecutive period of time / threshold time duration, for example this may be set to thirty days. This may be achieved by recording the time of the second node’s first pass of the above network bandwidth test and then resetting this to the current time (such that the consecutive period of time is zero) if the second node is determined to fail the network bandwidth test according to the first aspect of the present disclosure. This consecutive period of time may be referred to as the“uptime” of the second node 20.
  • the second node may be deemed to have not failed the network bandwidth test and the uptime may not be reset to zero.
  • the Computer Processing Unit (CPU) processing power of each of the participant nodes 20 / second nodes 20 may be tested by the first node 10.
  • this test may be achieved by generating, at the first node 10, a random cryptographic nonce and sending this nonce to the second node 20 to be tested.
  • the second node 20 will send the random nonce and the additional nonce to the first node for verification. If the first x bits of the concatenated value are not zeros then the second node 20 will add one to increment the value of the additional nonce and then perform the concatenation of the random nonce with this new additional nonce. This process will then be repeated until the requirement of the first x bits of the
  • the time taken between the first node 10 sending the random nonce to the second node 20 and the second node returning the random nonce with a successful additional nonce may then be taken as a measure of the CPU processing power resources of the second node.
  • a threshold CPU processing power may then be considered in the determination of whether the second node 20 is eligible to be selected as a confirming node.
  • a 64-bit random nonce may be used with SHA512 hashing.
  • the second node 20 may be afforded a grace period within which the second node 20 will be determined to be eligible to be selected as a confirming node if the second node sends a correct pair in one of a limited number of re-tests.
  • the performance of the plurality of participant nodes 20 of the blockchain system 8 may ranked from best to worst.
  • the first node 10 may identify a given participant node 20 of the plurality of participant nodes as being eligible to be selected as a confirming node only if the participant node 20 is ranked within the top number or percentage of the plurality of participant nodes of the blockchain system.
  • this percentage may be set to be the top 40% of the eligible nodes or all participant nodes.
  • the eligibility of the respective participant nodes 20 may be recorded in one or more flags associated with the unique public identification of each of the participant nodes. For example, a flag may be recorded to specify whether the relevant participant node is eligible for selection as a confirming node. Furthermore, flags may also be used to specify that the relevant participant node is untested where the node has not yet completed a complete set of resource tests or that it is a new node where the node may have passed the resource tests, but not yet achieved the required uptime described above. Additionally, a flag may specify that the node has been determined to have insufficient resources.
  • data regarding the results of the testing, and any corresponding scores or ranking may be stored along with the basis data regarding each participant node.
  • This data may be stored in a separate blockchain and serve as a history of the activity and rating of the participant nodes of the blockchain system, which can then be used for subsequent analysis.
  • This optional separate blockchain storing historical data may be a local further blockchain 16 stored locally at the first node 10 as shown in Figure 1 and, in some embodiments, this local further blockchain 16 may also be considered to form part of the blockchain system 8.
  • the first node 10 is preferably a trusted node that is accepted by all of the participant nodes 20 that are participating in the blockchain system 8.
  • the blockchain system 8 may then select one or more participant nodes to become confirming nodes for a given period of time. This in turn improves the speed and efficiency of the blockchain system in confirming new blocks while also increasing the cost of attack for a potential attacker to impact the nature of the blocks that are confirmed by the blockchain system.
  • Figure 3 illustrates a flowchart according to the second aspect of the present disclosure, which will be described with reference to the general block diagram of a first node 10 interacting with a plurality of further participant nodes 20 of the blockchain system 8 illustrated in Figure 1.
  • a plurality of nodes are selected randomly, from the participant nodes 20 that have been identified as being eligible for selection as a confirming node, to be the confirming nodes for a given period of time with the confirmed blocks to be accepted and appended onto the blockchain being those blocks distributed by the majority of the confirming nodes for that period of time. If one or more confirmed blocks are not able to be agreed upon by a majority of the confirming nodes then these confirmed blocks will be rejected and the relevant transactions will be held in a buffer, or transaction pool, for a subsequent set of confirming nodes corresponding to a subsequent period of time to process the transactions into confirmed blocks that are agreed upon by the majority of the confirming nodes for that period of time.
  • the first node 10 of the blockchain system determines the identity of the plurality of confirming nodes for a given period of time.
  • this plurality of confirming nodes is a subset of the plurality of nodes each identified as being eligible to be a confirming node, and the identified plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time.
  • the first node 10 receives one or more confirmed blocks of data from each of the plurality of confirming nodes.
  • step 34 the first node 10 determines whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other. If the majority of the confirming nodes have produced confirmed blocks that match each other, then the confirmed blocks may be accepted and appended to the transaction blockchain of the blockchain system 8.
  • the method and apparatus of the second aspect of the present disclosure may automatically monitor the behaviour of the participant nodes 20 of the blockchain system 8 and update the list of participant nodes that are eligible to be selected as confirming nodes accordingly.
  • confirming nodes that do not distribute a corresponding confirmed block i.e. the absence of a confirmed block rather than the distribution of a confirmed block that does not match the majority of the respective confirmed blocks
  • a qualified majority may be required for the corresponding minority of confirming nodes / participant nodes 20 to be identified as not being eligible to be a confirming node for future periods of time.
  • data regarding the participant nodes that were selected as confirming nodes for given periods of time and whether the confirmed blocks submitted by them agreed with the majority of other respective confirmed blocks may be stored in a separate blockchain so as to serve as a history of the activity and behaviour of the participant nodes 20 of the blockchain system 8, which can then be used for subsequent analysis of the behaviour of the participant nodes 20.
  • This optional separate blockchain storing historical data may be the local further blockchain 16 stored locally at the first node 10 as shown in Figure 1 , or it may be another similar blockchain.
  • the participant nodes to be selected as confirming nodes from those eligible may be identified by a numerical disparity between a random number and a numerical
  • This unique public identity may simply be the IP address of the participant node 20; however, the unique public identity may be set to maintain user anonymity, for example by using an onion address for access through the Tor hidden service. In this manner, this unique public identity, or another unique node identifier, can be used as a kind of raffle number for selecting one of the participant nodes 20 based on a randomised selection.
  • the random number may be generated by a true random number generator, for example a hardware random number generator based on a physical process such as the noise monitored in classical or quantum systems or quantum randomness at the atomic level and below. Due to the unpredictability of such random numbers, it is impossible for any party to predict the random number before it is published by the source. This means that the random number is resistant to attempts by outside parties to alter the distribution of a random number bits forming the random number.
  • a plurality of different sources of random numbers may be used with the respective different random numbers generated by the sources being hashed together in order to create a new random number. This further increases the resistance to any attempt by outside parties to control the random number generated, and thus control the selection of the first confirming node, since the outside party would need to gain control of each of the random number sources.
  • the unique public identity of the participant nodes 20 may be a hash of each participant node’s public key.
  • a first confirming node may then be determined by ordering the participant nodes that have been identified as being eligible to be selected as a confirming node in ascending or descending order according to the hash of their public key and then choosing the participant node with the next largest value above the random number or hash thereof.
  • the next confirming node may then be selected by hashing the random number (or hash thereof) to generate a new random number for comparison. By repeating this iterative process until the desired number of confirming nodes has been selected, a random selection of the eligible participant nodes may be selected as the confirming nodes for the given time period.
  • the confirming nodes may each digitally sign the confirmed blocks such that there would, for example, be five digital signatures on the confirmed block if five confirming nodes considered that version of the confirmed block to be the true next confirmed block to be appended to the blockchain.
  • other participant nodes in the blockchain may determine / verify the majority agreement regarding a given block, and thus that it is the appropriate confirmed block to be appended to their local version of the blockchain, by counting the relevant number of digital signatures on each of the versions (if more than one) of the confirmed block or blocks that are distributed from the confirming nodes.
  • the number of confirming nodes chosen may optionally be a fixed number of confirming nodes, or alternatively be a percentage of the numbers of the nodes, e.g. a percentage of the total number of participant nodes eligible to be selected as confirming nodes.
  • the number of confirming nodes chosen may be fixed as an odd number in order to ensure that a majority agreement is possible.
  • the total number of confirming nodes to be selected is based on a percentage, the total number may be increased or decreased by 1 if the percentage results in an even number, as will be appreciated by the person skilled in the art.
  • each block in the flowcharts may represent a module comprising one or more executable computer instructions, or a portion of an instruction, for implementing the logical function specified in the block.
  • the order of blocks in the figures are only intended to be illustrative of an example. In alternative implementations, the logical functions illustrated in particular blocks may occur out of the order noted in the figures. For example, the processes associated with two blocks may be carried out simultaneously or, depending on the functionality, in the reverse order.
  • Each block in the flowchart may be implemented in software, hardware or a combination of software and hardware.
  • the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product including computer readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, firmware, hardware and/or any other suitable approach or apparatus.
  • the computer readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • SRAM static random access memory
  • CD-ROM compact disc read-only memory
  • DVD digital versatile disk
  • memory stick a floppy disk.

Abstract

A method for a blockchain system is disclosed, the method comprising testing, by a first node of the blockchain system, a second node of the blockchain system, the test comprising: sending, from the first node to the second node, a volume of data to be hashed by the second node, wherein the volume of data is sent at a first time;and receiving at the first node, from the second node, the hash of the volume of data, wherein the hash of the volume of data is received at a second time. The test further comprises determining, by the first node, whether the received hash of the volume of data matches an expected hash of the volume of data;determining, by the first node, a time difference between the first time and the second time; and determining, by the first node, whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.

Description

A NODE TESTING METHOD AND APPARATUS FOR A BLOCKCHAIN SYSTEM
This application relates to methods and an apparatus for blockchain systems. In particular, the application relates to a method and apparatus for testing the capability and reputation of the nodes participating in a blockchain system.
Blockchain systems are a distributed record system using a sequence of blocks of data that are each consecutively linked using cryptography. Each block typically encapsulates a plurality of documents or transactions that are then shared between the nodes of a peer-to- peer network. The plurality of blocks act as a ledger that is distributed with local versions of the blockchain stored at each of the nodes in the peer-to-peer network running the blockchain system.
Blockchain concepts were initially devised to create a record of fact that is immutable and cannot subsequently be changed or modified covertly. This has typically been applied to transactions of digital cash, however this can be more generally applied to digital tokens that can be transferred between parties to establish rights and ownership over a process or item. These transfers, or uses of the digital tokens, are recorded as transactions in the blocks of the blockchain, which may be referred to as a transaction blockchain.
Because the tokens themselves are digital, it may be possible for the corresponding data to be duplicated or otherwise edited. This is known as the double spending flaw, which arises out of the decentralised nature of most blockchain systems. Blockchain systems typically attempt to remove the reliance on a trusted third party / central counterparty and
accordingly this central single version of the truth is unavailable in truly decentralised blockchain systems. Accordingly, it has been necessary to devise protocols for each of the nodes of the blockchain system to arrive at a consensus of the true and valid state of the blockchain.
The most common consensus protocol today is the proof of work protocol, which sets a computational problem with an answer that is simple to validate, but not simple to determine, and pits the various nodes in a race to determine the answer. The first node to arrive at the answer writes a block incorporating this answer and a collection of
transactions that have been confirmed as being valid by that first node. The completed block is then sent from this first node to the other nodes that it is aware of in the blockchain system, who then forward the completed block to any other nodes that they are in turn aware of.
Because the burden of the work associated with the computational problem is asymmetric, the other nodes can easily validate that the new block meets the requirements of the proof of work protocol and the race then begins for the next block. If more than one node solves the proof of work at a similar time then two or more versions of the blockchain will be in existence. There will usually be a rating mechanism for a node to determine which of the known versions of the blockchain should be selected as the authoritative version of the blockchain; however, due to the peer-to-peer nature of the network a node may not be aware of all of the versions of the blockchain and so different sets of nodes may begin working on the next block for respective versions of the blockchain. This may lead to the authoritative version of the blockchain changing from one version to another in a process known as forking. This reintroduces the possibility of a double spend and opens the system to a vulnerability of attack.
By design, the proof of work protocol results in the expenditure of a large amount of computer processing in order to attempt to avoid such an attack and to provide the distributed system with a level of trust. One alternative example is the proof of stake protocol, where the responsibility for writing new blocks is distributed amongst the largest stakeholders in the blockchain. The trust in such a protocol is inferred on the basis that these largest stakeholders have the most to lose if the blockchain is compromised and accordingly they may be considered to be the most likely to act in the best interests of the blockchain system. Another similar example is the proof of authority protocol, where only authorised nodes are able to write and confirm new blocks, but these authorised nodes are required to be linked to a user’s public identity such that the user’s reputation is at stake. This incentivises the authorised nodes to act in the best interests of the blockchain system in order to maintain their own personal reputation.
However, each of these alternatives tend towards a comparatively centralised system that is not distributed and thus go against the typical aims of blockchain systems. Therefore, we have appreciated that it would be desirable to provide an improved blockchain system with a low energy and computational power requirement for operation with improved distribution while preventing the cost of attack from becoming too low. Furthermore, we have appreciated that nodes that have been identified as being involved in a potential attack, or other malicious behaviour, should be prevented from being selected by the consensus protocol to decide on the confirmed blocks.
SUMMARY
The invention is defined in the independent claims to which reference should now be directed. Advantageous features are set out in the dependent claims.
In a first aspect, the present disclosure relates to a method for a blockchain system comprising a plurality of nodes, the method being operated at a first node of the blockchain system to test a second node of the blockchain system. The test comprises sending, from the first node to the second node, a volume of data to be hashed by the second node, wherein the volume of data is sent at a first time; and receiving at the first node, from the second node, the hash of the volume of data, wherein the hash of the volume of data is received at a second time. The method further comprises determining, by the first node, whether the received hash of the volume of data matches an expected hash of the volume of data; determining, by the first node, a time difference between the first time and the second time; and determining, by the first node, whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
The method of the first aspect of the present disclosure advantageously determines a measure of the downlink network bandwidth / speed of the second node’s network connection by performing tests on the second node participating in the blockchain system and then uses this test data to determine whether the second node should be eligible to be in a pool of nodes that can be selected to be a confirming node of the blockchain for a given period of time, i.e. a node of the blockchain that processes and confirms received transactions that are to be appended to the blockchain by including them, and distributing them to other nodes in the blockchain system, in confirmed blocks. This enables the method to select the best second nodes for confirming node eligibility and thus ensures that any confirming nodes selected from that pool of eligible nodes will be able to process any transactions for producing confirmed blocks quickly and efficiently. This method can be carried out autonomously in the blockchain system, without the need for manual user intervention, and accordingly the invention also further improves the robustness of such blockchain systems. Moreover, this minimum requirement also provides a certain level of cost to any would be attacker that might try to introduce a large number of nodes that are eligible to be selected as confirming nodes in an attempt to increase the probability of control of the confirmed blocks to be appended to the blockchain, since each node would individually require a certain amount of network bandwidth in order to receive the respective volume of data and to send the expected corresponding hash back to the first node within a given time difference. This advantageously improves the security of the blockchain system and its resilience to attack.
Optionally, the second node may be determined, by the first node, to be eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash. This advantageously provides a simple way for the first node to test whether the second node is eligible to be selected as a confirming node.
Optionally, the testing, by the first node of the blockchain system, of the second node of the blockchain system may be performed at a random time during each time period of a series of consecutive time periods. This advantageously enables the method to give a realistic view of the test results for the second node and prevents the second node from being able to anticipate the test time and to prioritise bandwidth availability during that anticipated test time, which would lead to an unrepresentative view of the available bandwidth of the second node during any given period of time.
Optionally, the second node may be determined, by the first node, to not be eligible to be selected as a confirming node if the determined time difference for the given volume of data is above the threshold time and/or the received hash does not match the expected hash for n consecutive time periods, where n is a positive non-zero integer.
In this manner, the method advantageously provides an n number of retries / retests and the second node is only determined to not be eligible to be selected as a confirming node if the second node is unable to return the correctly expected hash of the volume of data within the threshold time difference in any of the n retries. This allows a second node that is, for example, momentarily effected by packet loss in the download of the volume of the data from, or the upload of the hash of the volume of the data to the first node (for example due to short term network downtime) to continue to be eligible to be selected as a confirming node in the event that they are able to reach the threshold time difference requirement in one of the tests / retests or retries.
Optionally, the received hash and the expected hash may be rolling hashes. This advantageously enables the second node to begin the computation of the rolling hash while the volume of data is still being received from the first node, which in turn reduces the data processing delay to compute the final hash once the volume of data has been received from the first node. This improves the accuracy of the determination of the network bandwidth available to the second node since the impact of the time taken for the processor of the second node to determine the hash of the volume of data in the total time difference determined by the first node will be reduced. In this manner, the second node cannot use a fast processor to make up for a deficiency in the network bandwidth available to it.
Optionally, the method further comprises determining, by the first node, an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration.
This advantageously improves the reliability of the blockchain system and resilience to attack by requiring the nodes that are eligible to be selected as confirming nodes to maintain the threshold required network bandwidth for a given period of time. This period of time in which the second node is active on the blockchain system and responding to the testing of the first node may be referred to as an uptime of the second node, which further increases the cost to any would be attacker as the threshold requirements would need to be maintained for each node controlled by the attacker for an extended period of time until the threshold duration of uptime is met.
Optionally, the method may further comprise testing, by the first node of the blockchain system, a plurality of further nodes of the blockchain system; and ranking, by the first node, the second node and the plurality of further nodes based on the respective determined time differences; wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system. This advantageously forms a pool of nodes that are eligible to be selected as a confirming node where the pool of eligible nodes represents the nodes with the best available network bandwidth as tested by the test of the first aspect of the present disclosure. This further increases the cost required for any would be attacker to control a plurality of nodes that would be determined by the first node to be eligible to be selected as a confirming node of the blockchain system. Each of the plurality of nodes may be considered to be a second node in the framework set out above and in the following detailed description, with the first node being a trusted party.
Optionally, the method may further comprise appending the determined time difference and/or the determined eligibility of the second node to a further blockchain. This enables a history of the test results for each second node of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective second nodes over time.
The first aspect of the present disclosure also relates to a node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to test a second node of the blockchain system. This first node comprises a network interface configured to send a volume of data to the second node at a first time, wherein the volume of data is to be hashed by the second node; the network interface being further configured to receive the hash of the volume of data from the second node at a second time; and one or more processors configured to determine whether the received hash of the volume of data matches an expected hash of the volume of data; to determine a time difference between the first time and the second time; and to determine whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
The first node apparatus of the first aspect of the present disclosure advantageously determines a measure of the downlink network bandwidth / speed of the second node’s network connection by performing tests on the second node participating in the blockchain system and then uses this test data to determine whether the second node should be eligible to be in a pool of nodes that can be selected to be a confirming node of the blockchain for a given period of time, i.e. a node of the blockchain that processes and confirms received transactions that are to be appended to the blockchain by including them, and distributing them to other nodes in the blockchain system, in confirmed blocks. This enables the first node to select the best second nodes for confirming node eligibility and thus ensures that any confirming nodes selected from that pool of eligible nodes will be able to process any transactions for producing confirmed blocks quickly and efficiently.
Moreover, this minimum requirement also provides a certain level of cost to any would be attacker that might try to introduce a large number of nodes that are eligible to be selected as confirming nodes in an attempt to increase the probability of control of the confirmed blocks to be appended to the blockchain, since each node would individually require a certain amount of network bandwidth in order to receive the respective volume of data and to send the expected corresponding hash back to the first node within a given time difference. This advantageously improves the security of the blockchain system and its resilience to attack.
Optionally, the one or more processors may be configured to determine that the second node is eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash. This advantageously provides a simple way for the first node to test whether the second node is eligible to be selected as a confirming node.
Optionally, the network interface may be configured to send a volume of data to the second node at a random time during each time period of a series of consecutive time periods.
This advantageously enables the first node apparatus to give a realistic view of the test results for the second node and prevents the second node from being able to prioritise bandwidth availability during the test time, which would lead to an unrepresentative view of the available bandwidth of the second node during any given period of time.
Optionally, the one or more processors may be configured to determine that the second node is not eligible to be selected as a confirming node if the determined time difference for a given volume of data is determined to be above the threshold time and/or the received hash is determined to not match the expected hash for n consecutive time periods, where n is a positive non-zero integer. In this manner, the first node advantageously provides an n number of retries / retests and the second node is only determined to not be eligible to be selected as a confirming node if the second node is unable to return the correctly expected hash of the volume of data within the threshold time difference in any of the n retries. This allows a second node that is, for example, momentarily effected by packet loss in the download of the volume of the data from, or the upload of the hash of the volume of the data to the first node to continue to be eligible to be selected as a confirming node in the event that they are able to reach the threshold time difference requirement in one of the tests / retests or retries.
Optionally, the received hash and the expected hash may be rolling hashes. This advantageously enables the second node to begin the computation of the rolling hash while the volume of data is still being received from the first node, which in turn reduces the data processing delay to compute the final hash once the volume of data has been received from the first node. This improves the accuracy of the determination of the network bandwidth available to the second node since the impact of the time taken for the processor of the second node to determine the hash of the volume of data in the total time difference determined by the first node will be reduced. In this manner, the second node cannot use a fast processor to make up for a deficiency in the network bandwidth available to it.
Optionally, the one or more processors may be further configured to determine an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the one or more processors are only configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration. This advantageously improves the reliability of the blockchain system and resilience to attack by requiring the nodes that are eligible to be selected as confirming nodes to maintain the threshold required network bandwidth for a given period of time. This period of time in which the second node is active on the blockchain system and responding to the testing of the first node may be referred to as an uptime of the second node, which further increases the cost to any would be attacker as the threshold requirements would need to be maintained for each node controlled by the attacker for an extended period of time until the threshold duration of uptime is met.
Optionally, the apparatus may be further configured to test a plurality of nodes of the blockchain system by sending volumes of data to and receiving corresponding hashes from each of the plurality of nodes of the blockchain system and determining the respective time differences; wherein the one or more processors are further configured to rank the second node and the plurality of further nodes based on the respective determined time differences; and wherein the one or more processors are configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system only if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system. This advantageously forms a pool of nodes that are eligible to be selected as a confirming node where the pool of eligible nodes represents the nodes with the best available network bandwidth as tested by the test of the first aspect of the present disclosure. This further increases the cost required for any would be attacker to control a plurality of nodes that would be determined by the first node to be eligible to be selected as a confirming node of the blockchain system.
Optionally, the node apparatus may be further configured to append the determined time difference and/or the determined eligibility of the second node to a further blockchain. This enables a history of the test results for each second node of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective second nodes over time.
In a second aspect, the present disclosure relates to a method for a blockchain system comprising a plurality of nodes, the method comprising: determining, by a first node, a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of a plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time; receiving, by the first node, one or more confirmed blocks of data from each of the plurality of confirming nodes; and determining, by the first node, whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, identifying any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time.
The method of the second aspect of the present disclosure advantageously provides for a blockchain system in which a plurality of nodes are selected, from a pool of eligible nodes, as being confirming nodes in the blockchain system for a given duration of time, whereby the reputation of each of the confirming nodes can be monitored by the first node by determining whether each selected confirming node creates and distributes confirmed blocks matching those confirmed by other selected confirming nodes. If a proportion of the selected confirming nodes have been compromised, for example by a would be attacker, then these confirming nodes may attempt to create and distribute modified confirmed blocks that do not match those distributed by confirming nodes that have not been compromised. It is to be expected that compromised nodes would only make up a minority of the nodes selected as confirming nodes for a given duration of time and accordingly the majority of the respectively received confirmed blocks of data would be expected to be the true unadulterated blocks, which would match each other. In this manner, the method of the second aspect of the disclosure can advantageously identify selected confirming nodes that distribute blocks that do not match the majority of the respective blocks received from corresponding other confirming nodes as potentially having been compromised and thus the method can remove the eligibility for future selection as a confirming node of these potentially compromised nodes in order to protect the integrity of the blockchain system.
Optionally, confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received may only be identified as not being eligible to be a confirming node for future periods of time if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other. In this manner, a larger agreement majority or supermajority may be required in order for those nodes that do not agree with the majority to be identified as potentially having been compromised and to be prevented from being eligible for selection as a confirming node in the future. This advantageously reduces the likelihood that nodes may be mistakenly identified as compromised by requiring a higher threshold of agreement before disagreeing nodes are stripped of their eligibility to be selected as a confirming node again in the future.
Optionally, the method may further comprise monitoring, by the first node, a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and identifying, by the first node, any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time. This advantageously also removes nodes that do not distribute any confirmed blocks from eligibility to be a confirming node in future periods of time.
Optionally, the determined plurality of confirming nodes for a given period of time may be an odd number of confirming nodes. This advantageously ensures that a majority agreement can be reached between the nodes. Optionally, the determined plurality of confirming nodes for a given period of time may represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node. This advantageously keeps the chance of an eligible node being selected as a confirming node the same in the event that one or more nodes are identified as not being eligible to be a confirming node for future periods of time.
Optionally, the method may further comprise appending to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
This enables a history of the behaviour and majority agreement results for each of the nodes of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective nodes over time.
The second aspect of the present disclosure also relates to a node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to assess a plurality of nodes each identified as being eligible to be a confirming node of the blockchain system. This first node comprises one or more processors configured to determine a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of the plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time; and a network interface configured to receive one or more confirmed blocks of data from each of the plurality of confirming nodes; wherein the one or more processors are further configured to determine whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, to identify any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time.
The first node apparatus of the second aspect of the present disclosure advantageously provides for a blockchain system in which a plurality of nodes are selected, from a pool of eligible nodes, as being confirming nodes in the blockchain system for a given duration of time, whereby the reputation of each of the confirming nodes can be monitored by the first node by determining whether each selected confirming node creates and distributes confirmed blocks matching those confirmed by other selected confirming nodes. If a proportion of the selected confirming nodes have been compromised, for example by a would be attacker, then these confirming nodes may attempt to create and distribute modified confirmed blocks that do not match those distributed by confirming nodes that have not been compromised. It is to be expected that compromised nodes would only make up a minority of the nodes selected as confirming nodes for a given duration of time and accordingly the majority of the respectively received confirmed blocks of data would be expected to be the true unadulterated blocks, which would match each other. In this manner, the first node of the second aspect of the disclosure can advantageously identify selected confirming nodes that distribute blocks that do not match the majority of the respective blocks received from corresponding other confirming nodes as potentially having been compromised and thus the first node can remove the eligibility of these potentially compromised nodes for future selection as a confirming node in order to protect the integrity of the blockchain system.
Optionally, the one or more processors may be further configured to identify confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time only if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other. In this manner, the first node may require a larger agreement majority or supermajority for nodes that do not agree with the majority to be identified as potentially having been compromised and to be prevented from being eligible for selection as a confirming node in the future.
This advantageously reduces the likelihood that nodes may be mistakenly identified as compromised by requiring a higher threshold of agreement before disagreeing nodes are stripped of their eligibility to be selected as a confirming node again in the future.
Optionally, the one or more processors may be further configured to monitor a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and to identify any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time. This advantageously also removes nodes that do not distribute any confirmed blocks from eligibility to be a confirming node in future periods of time.
Optionally, the determined plurality of confirming nodes for a given period of time may be an odd number of confirming nodes. This advantageously ensures that a majority agreement can be reached between the nodes. Optionally, the determined plurality of confirming nodes for a given period of time may represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node. This advantageously keeps the chance of an eligible node being selected as a confirming node the same in the event that one or more nodes are identified as not being eligible to be a confirming node for future periods of time.
Optionally, the node apparatus may be further configured to append to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks. This enables a history of the behaviour and majority agreement results for each of the nodes of the blockchain system to be stored in a separate blockchain of the blockchain system, which can in turn be used to further analyse the behaviour and eligibility of the respective nodes over time.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:
Figure 1 is a block diagram of a first node according to the first aspect of the present disclosure interacting with a plurality of further nodes participating in a blockchain system;
Figure 2 is a flowchart illustrating a method according to a first aspect of the present disclosure; and
Figure 3 is a flowchart illustrating a method according to a second aspect of the present disclosure.
DETAILED DESCRIPTION
Figure 1 is a block diagram of a plurality of nodes participating in a blockchain system 8. In the blockchain system of Figure 1 , a first node 10 and two participant nodes 20 are illustrated, although it will be appreciated that, in practice, a plurality of further participant nodes 20 would also typically form part of the blockchain system. These participant nodes 20 may be referred to as a plurality of second nodes or further nodes. Although a single second node may be described below, it will be appreciated that the methods and processes may be repeated for many or all of the plurality of nodes participating in the blockchain system and that each of these nodes may be considered to be a‘second node’ in this context.
The first node 10 comprises a network interface 12, a processor 14 and a local further blockchain 16. The processor 14 may represent a plurality of processors each arranged to perform certain calculations / determinations in line with the following description, or alternatively a single processor 14 may perform all of these functions. Although the network interface has been shown as a single bidirectional interface in Figure 1 , it will be appreciated that this could alternatively be implemented with separate input and output network interfaces. The purpose of the network interface 12 is to enable the first node 10 to communicate with the participant nodes of the blockchain system 8. Each participant node 20 comprises a local transaction blockchain 18.
Although not shown for the sake of simplicity, it will be appreciated that each participant node 20 may also comprise a network interface 12, a processor 14. In this manner, the first node 10 and the plurality of participant nodes 20 of the blockchain system 8 may communicate with each other, for example to form a peer-to-peer network. It is noted that the plurality of participant nodes may also communicate directly between themselves, although this is not illustrated in Figure 1 for the sake of clarity. The respective network interfaces may utilise any known wired or wireless network topology over local area networks, wide area networks and the internet.
The local transaction blockchain 18 refers to the local copy of the blockchain of the blockchain system that encapsulates a plurality of documents or transactions in blocks of data to form the distributed record system by cryptographically linking the sequence of blocks of data. Each block of the blockchain is shared between the participant nodes 20 of the blockchain system 8, typically using a peer-to-peer network. The plurality of blocks act as a ledger that is distributed with these local versions of the transaction blockchain 18 being stored locally at each of the participant nodes of the blockchain system and network. The blocks to be appended to all of the versions of the blockchain may be confirmed by and broadcast / distributed from a single participant node 20, or alternatively a plurality of participant nodes 20 may agree on the confirmed blocks to be distributed to the other participant nodes in the blockchain system 8.
In keeping with the distributed aim of most blockchain systems, the identity of the participant node that is, or nodes that are, responsible for confirming blocks and distributing these confirmed blocks to other nodes during one time period will typically be different to the identity of the participant node, or nodes, that are responsible for confirming blocks and distributing them in the following time period. Each node that is responsible for confirming blocks and distributing them at the current point in time will be referred to as the confirming nodes or leader nodes.
In the proof of work protocol, all nodes are typically eligible to become the confirming node for a given time interval and the node that becomes the confirming node is the node that is first to solve the relevant computational problem that has been set. In other consensus protocols, the node or nodes that will become the confirming nodes are typically selected from a subset of the participant nodes that have been identified as being eligible to be a confirming node.
While these other consensus protocols broadly speaking do away with the need to solve a difficult computational problem, the applicant has appreciated that it would still be beneficial to set a threshold level of resources that a participant node is required to have in order to be eligible to be selected as a confirming node. In particular, the applicant has appreciated that it is undesirable to have low resourced nodes confirm blocks for appending to the blockchain as these low resourced nodes may perform this process slowly and thus reduce the speed and efficiency of the overall system. Moreover, allowing low resourced nodes to be eligible to be selected as a confirming node presents a low equipment and resources cost to potential attackers who may seek to control a large number of nodes that are eligible to be selected as confirming nodes. This is particularly relevant for consensus protocols that select confirming nodes from a subset of eligible participant nodes using a randomised process.
Accordingly, the first aspect of the present disclosure provides a method and apparatus for evaluating participant nodes 20 using a resource test performed by the first node 10. The first node 10 does not need to store a local copy of the transaction blockchain 18, however the first node may still be considered to be a node of the blockchain system 8 and may be referred to as an authority node or a reputation node herein. The first node 10 will be aware of the participant nodes 20 participating in the blockchain system and preferably stores the basic data required to contact each participant node. This basic data includes a unique public identity to enable other nodes to direct messages to and communicate with a given participant node 20. This unique public identity may simply be the IP address of the participant node 20; however, the unique public identity may be set to maintain user anonymity, for example by using an onion address for access through the Tor hidden service. In some embodiments, the basic data further includes a public key for
cryptographic digital signatures of the given participant node 20, details of the configuration and/or capabilities of the node machine and a human readable nicknames may also be provided for each of the participant nodes in order to improve usability.
Using this basic data, the first node 10 can contact each of the participant nodes 20 in order to initiate a resource test. It will be appreciated that the blockchain system 8 may be provided with a plurality of first nodes 10 and that this may scale with the number of participant nodes 20 in order to perform the resource tests in a given time frame.
Figure 2 illustrates a flowchart according to the first aspect of the present disclosure and relates to a test of the network bandwidth or download speed of the second node 20 from the first node 10 and, by analogy, the blockchain system 8. In step 22, the first node 10 sends a volume of data to one of the participant nodes 20, which will be referred to as a second node 20 herein, wherein the volume of data is sent at a first time and it is to be hashed by the second node upon receipt. The second node will be aware that it is required by the blockchain system 8 to calculate a hash of the volume of data received from the first node 10 and it will compute this hash and send it back to the first node as soon as possible, for example when the final piece of data of the volume of data has been received. In step 24, the first node 10 receives the hash of the volume of data from the second node 20 at a second time.
The hash may be any cryptographic hash function, for example a Secure Hash Algorithm 2 function with a 512 bit digest (SHA512). Optionally, the hash may be computed as a rolling hash or a recursive hash; this means that the second node 20 can start to compute the hash before the entire volume of data has been received and thus minimises the amount of time taken for the second node 20 to compute the hash once the volume of data has been received from the first node 10. This enables this aspect of the resource test to only test network bandwidth / download connection speed of the second node 20 and to minimise the impact of the CPU processing power required to process the hash of the volume of data.
In step 26, the first node 10 determines a time difference between the first time, when the first node sent the volume of data to the second node 20, and the second time, when the first node received the hash of the volume of data from the second node 20. The first node 10 also verifies whether the hash received from the second node matches the expected hash for the volume of data sent to the second node 20.
In step 28, the first node 10 determines whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data. If the received hash of the volume of data does not match the expected hash of the volume of data then it may be determined that the second node has a poor connection that has resulted in some of the packets of the volume of data being lost and thus the second node 20 may be considered to have failed the network bandwidth test. If the received hash of the volume of data does match the expected hash of the volume of data then the processor of the first node may proceed to consider whether the second node passes the network bandwidth test and is eligible to be selected as a confirming node based on the determined time difference between the first and second times.
This determination may be based on a threshold time, wherein the second node 20 is required to send the hash of the volume of data to the first node 10 such that the time taken (the determined time difference) is less than the threshold time. This simple comparison can be used to determine whether the second node is able to receive the volume of data and send the hash back within the requirements of the blockchain system. This provides a simulation of the amount of time it may take for the second node to receive transactions to be included in the transaction blockchain and to send the block comprising these transactions to the other participant nodes in the blockchain system and thus a measure of the efficiency and suitability of the second node in performing the function of a confirming node. In this embodiment, provided a volume of data having the same total storage size is sent to each of the second nodes / participant nodes 20, the performance of each of the plurality of participant nodes of the blockchain system can be compared.
This network bandwidth test is preferably performed periodically for each of the participant nodes 20 of the blockchain system 8 to ensure that the performance of the participant nodes identified as being eligible to be selected as a confirming node is maintained. For example, this test may be performed once a day. It would be preferable for the time of day or other periodicity of the test to be randomised such that the participant node / second node 20 is not able to anticipate the time of the test and attempt to improve the second nodes network bandwidth performance during that period of time in order to provide a result that is not representative of the second node’s typical performance. As the test will be repeated for each participant node multiple times and across multiple participant nodes, the data content of the volume of data sent is preferably different each time (or taken from a sufficiently large set of volumes of data) so that the data being sent cannot be identified or anticipated by the second node 20 before it has been received in full by that node. This prevents the second node from anticipating the corresponding hash of the data and sending this hash to the first node prior to the full volume of data having been received from the first node, which would cause the test to arrive at an inaccurate result for that second node 20.
In a further embodiment, the data size of the volume of data may vary and the comparison may be based on a threshold download speed. As will be appreciated by the skilled person, the total size of the volume of data sent can be divided by the determined time difference in order to provide a speed value that can be used to compare multiple tests across different participant nodes even if the data size of the volume of data varies from test to test.
In one embodiment of the disclosure of the first aspect of the present application, in the event that a second node 20 is determined to fail the network bandwidth test (either by providing an incorrect hash or not meeting the required time frame for response), the second node 20 may be subsequently re-tested and afforded a grace period within which the second node 20 will continue to be determined to be eligible to be selected as a confirming node if the second node passes the network bandwidth test (by providing the expected hash within the required time for response at least once during that grace period).
For example, if the second node is tested daily and fails the network bandwidth test on a given day, the second node may be re-tested on each of the three subsequent days and the second node may only be determined to be ineligible to be selected as a confirming node if the second node fails all three subsequent re-tests. It will be appreciated that the frequency / periodicity of the re-testing may differ from the frequency with which a participant node would be tested in the event that it passed the network bandwidth test.
In one embodiment, for a participating node / second node 20 to be identified as eligible for selection as a confirming node, the second node may be further required to have been active in the blockchain system 8 and to have met the requirements of the network bandwidth test for a given consecutive period of time / threshold time duration, for example this may be set to thirty days. This may be achieved by recording the time of the second node’s first pass of the above network bandwidth test and then resetting this to the current time (such that the consecutive period of time is zero) if the second node is determined to fail the network bandwidth test according to the first aspect of the present disclosure. This consecutive period of time may be referred to as the“uptime” of the second node 20.
Where the second node passes the network bandwidth test within one of the retries in the embodiment above that provides a grace period, the second node may be deemed to have not failed the network bandwidth test and the uptime may not be reset to zero.
Alternatively or additionally, the Computer Processing Unit (CPU) processing power of each of the participant nodes 20 / second nodes 20 may be tested by the first node 10. In one embodiment, this test may be achieved by generating, at the first node 10, a random cryptographic nonce and sending this nonce to the second node 20 to be tested. The second node may then hash the random nonce using concatenation with an additional nonce of equal length that is made up entirely by zeros, with the result being as follows: result = SHA512(Random Nonce || Additional Nonce)
where || represents a concatenation and SHA512 is used as an example.
If the first x bits of the concatenated value (where the integer value of x is set by the first node 10) are zeros then the second node 20 will send the random nonce and the additional nonce to the first node for verification. If the first x bits of the concatenated value are not zeros then the second node 20 will add one to increment the value of the additional nonce and then perform the concatenation of the random nonce with this new additional nonce. This process will then be repeated until the requirement of the first x bits of the
concatenated value being zeros has been met, at which point the second node will send the random nonce and the successful additional nonce to the first node for verification.
The time taken between the first node 10 sending the random nonce to the second node 20 and the second node returning the random nonce with a successful additional nonce may then be taken as a measure of the CPU processing power resources of the second node.
A threshold CPU processing power may then be considered in the determination of whether the second node 20 is eligible to be selected as a confirming node. In one embodiment, a 64-bit random nonce may be used with SHA512 hashing. In a similar manner to the network bandwidth test, in some embodiments, if the second node 20 sends a random nonce and additional nonce pair that does not meet the required number of x zeros, then the second node 20 may be afforded a grace period within which the second node 20 will be determined to be eligible to be selected as a confirming node if the second node sends a correct pair in one of a limited number of re-tests.
Based on the results of the network bandwidth test and/or the CPU processing power test, the performance of the plurality of participant nodes 20 of the blockchain system 8 may ranked from best to worst. In a further embodiment, the first node 10 may identify a given participant node 20 of the plurality of participant nodes as being eligible to be selected as a confirming node only if the participant node 20 is ranked within the top number or percentage of the plurality of participant nodes of the blockchain system. This enables the blockchain system 8 to maintain a high transaction processing speed and to maintain a relatively high performance threshold for any potential attackers to meet in order to be eligible for selection as the or a confirming node while still providing a relatively large pool of participant nodes that are eligible for selection as confirming nodes and thus maintaining the distributed nature of the blockchain system 8. For example, this percentage may be set to be the top 40% of the eligible nodes or all participant nodes.
In each of the above embodiments, the eligibility of the respective participant nodes 20 may be recorded in one or more flags associated with the unique public identification of each of the participant nodes. For example, a flag may be recorded to specify whether the relevant participant node is eligible for selection as a confirming node. Furthermore, flags may also be used to specify that the relevant participant node is untested where the node has not yet completed a complete set of resource tests or that it is a new node where the node may have passed the resource tests, but not yet achieved the required uptime described above. Additionally, a flag may specify that the node has been determined to have insufficient resources.
Furthermore, in each of the above embodiments, data regarding the results of the testing, and any corresponding scores or ranking, may be stored along with the basis data regarding each participant node. This data may be stored in a separate blockchain and serve as a history of the activity and rating of the participant nodes of the blockchain system, which can then be used for subsequent analysis. This optional separate blockchain storing historical data may be a local further blockchain 16 stored locally at the first node 10 as shown in Figure 1 and, in some embodiments, this local further blockchain 16 may also be considered to form part of the blockchain system 8. As will be appreciated from the above, the first node 10 is preferably a trusted node that is accepted by all of the participant nodes 20 that are participating in the blockchain system 8.
From the above first aspect of the present disclosure, an improved method and apparatus for determining participant node eligibility for selection as a confirming node based on participant node resource testing has been described. Once the participant nodes that are eligible to be selected as a confirming node have been determined, the blockchain system 8 may then select one or more participant nodes to become confirming nodes for a given period of time. This in turn improves the speed and efficiency of the blockchain system in confirming new blocks while also increasing the cost of attack for a potential attacker to impact the nature of the blocks that are confirmed by the blockchain system.
According to a second aspect of the present disclosure, a method and node apparatus for determining which participant node should be a confirming node for a given time period and for monitoring the behaviour of these confirming nodes is described. Figure 3 illustrates a flowchart according to the second aspect of the present disclosure, which will be described with reference to the general block diagram of a first node 10 interacting with a plurality of further participant nodes 20 of the blockchain system 8 illustrated in Figure 1.
In the blockchain system of the second aspect of the present disclosure, a plurality of nodes are selected randomly, from the participant nodes 20 that have been identified as being eligible for selection as a confirming node, to be the confirming nodes for a given period of time with the confirmed blocks to be accepted and appended onto the blockchain being those blocks distributed by the majority of the confirming nodes for that period of time. If one or more confirmed blocks are not able to be agreed upon by a majority of the confirming nodes then these confirmed blocks will be rejected and the relevant transactions will be held in a buffer, or transaction pool, for a subsequent set of confirming nodes corresponding to a subsequent period of time to process the transactions into confirmed blocks that are agreed upon by the majority of the confirming nodes for that period of time.
In step 30, the first node 10 of the blockchain system, which may be referred to as a reputation node, determines the identity of the plurality of confirming nodes for a given period of time. As noted above, this plurality of confirming nodes is a subset of the plurality of nodes each identified as being eligible to be a confirming node, and the identified plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time. Then in step 32, the first node 10 receives one or more confirmed blocks of data from each of the plurality of confirming nodes.
Next, in step 34 the first node 10 determines whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other. If the majority of the confirming nodes have produced confirmed blocks that match each other, then the confirmed blocks may be accepted and appended to the transaction blockchain of the blockchain system 8.
It may be the case that a minority of the confirming nodes did not agree with the majority. These minority confirming nodes, that distributed confirmed blocks not matching the majority of the respective confirmed blocks, are then identified as not being eligible to be a confirming node for future periods of time. This is because these minority confirming nodes do not appear to be functioning normally and may have been compromised by a malicious third-party. In this manner, the method and apparatus of the second aspect of the present disclosure may automatically monitor the behaviour of the participant nodes 20 of the blockchain system 8 and update the list of participant nodes that are eligible to be selected as confirming nodes accordingly. Furthermore, confirming nodes that do not distribute a corresponding confirmed block (i.e. the absence of a confirmed block rather than the distribution of a confirmed block that does not match the majority of the respective confirmed blocks) may also be identified as no longer being eligible to be a confirming node for future periods of time.
In some embodiments, a qualified majority may be required for the corresponding minority of confirming nodes / participant nodes 20 to be identified as not being eligible to be a confirming node for future periods of time.
Optionally, data regarding the participant nodes that were selected as confirming nodes for given periods of time and whether the confirmed blocks submitted by them agreed with the majority of other respective confirmed blocks may be stored in a separate blockchain so as to serve as a history of the activity and behaviour of the participant nodes 20 of the blockchain system 8, which can then be used for subsequent analysis of the behaviour of the participant nodes 20. This optional separate blockchain storing historical data may be the local further blockchain 16 stored locally at the first node 10 as shown in Figure 1 , or it may be another similar blockchain. The participant nodes to be selected as confirming nodes from those eligible may be identified by a numerical disparity between a random number and a numerical
representation of a unique public identification associated with each of the participant nodes. This unique public identity may simply be the IP address of the participant node 20; however, the unique public identity may be set to maintain user anonymity, for example by using an onion address for access through the Tor hidden service. In this manner, this unique public identity, or another unique node identifier, can be used as a kind of raffle number for selecting one of the participant nodes 20 based on a randomised selection.
The random number may be generated by a true random number generator, for example a hardware random number generator based on a physical process such as the noise monitored in classical or quantum systems or quantum randomness at the atomic level and below. Due to the unpredictability of such random numbers, it is impossible for any party to predict the random number before it is published by the source. This means that the random number is resistant to attempts by outside parties to alter the distribution of a random number bits forming the random number. A plurality of different sources of random numbers may be used with the respective different random numbers generated by the sources being hashed together in order to create a new random number. This further increases the resistance to any attempt by outside parties to control the random number generated, and thus control the selection of the first confirming node, since the outside party would need to gain control of each of the random number sources.
The unique public identity of the participant nodes 20 may be a hash of each participant node’s public key. A first confirming node may then be determined by ordering the participant nodes that have been identified as being eligible to be selected as a confirming node in ascending or descending order according to the hash of their public key and then choosing the participant node with the next largest value above the random number or hash thereof. The next confirming node may then be selected by hashing the random number (or hash thereof) to generate a new random number for comparison. By repeating this iterative process until the desired number of confirming nodes has been selected, a random selection of the eligible participant nodes may be selected as the confirming nodes for the given time period.
It will be appreciated that this form of numerical disparity (the next largest value) is just one example and that the skilled person would be aware of many alternative calculations that could be used to select the confirming nodes for a given period without departing from the contribution of the present disclosure.
In some embodiments, the confirming nodes may each digitally sign the confirmed blocks such that there would, for example, be five digital signatures on the confirmed block if five confirming nodes considered that version of the confirmed block to be the true next confirmed block to be appended to the blockchain. In this manner, other participant nodes in the blockchain may determine / verify the majority agreement regarding a given block, and thus that it is the appropriate confirmed block to be appended to their local version of the blockchain, by counting the relevant number of digital signatures on each of the versions (if more than one) of the confirmed block or blocks that are distributed from the confirming nodes.
The number of confirming nodes chosen may optionally be a fixed number of confirming nodes, or alternatively be a percentage of the numbers of the nodes, e.g. a percentage of the total number of participant nodes eligible to be selected as confirming nodes.
Additionally, the number of confirming nodes chosen may be fixed as an odd number in order to ensure that a majority agreement is possible. In the case where the total number of confirming nodes to be selected is based on a percentage, the total number may be increased or decreased by 1 if the percentage results in an even number, as will be appreciated by the person skilled in the art.
For completeness, it is noted that the flowcharts of Figures 2 and 3 illustrate the operation of example implementations of methods according to the present disclosure. Each block in the flowcharts may represent a module comprising one or more executable computer instructions, or a portion of an instruction, for implementing the logical function specified in the block. The order of blocks in the figures are only intended to be illustrative of an example. In alternative implementations, the logical functions illustrated in particular blocks may occur out of the order noted in the figures. For example, the processes associated with two blocks may be carried out simultaneously or, depending on the functionality, in the reverse order. Each block in the flowchart may be implemented in software, hardware or a combination of software and hardware.
As will be appreciated by the skilled person, the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product including computer readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, firmware, hardware and/or any other suitable approach or apparatus.
Any computer readable program instructions may be stored on a non-transitory, tangible computer readable medium. The computer readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.

Claims

1. A method for a blockchain system comprising a plurality of nodes, the method comprising:
testing, by a first node of the blockchain system, a second node of the blockchain system, the test comprising:
sending, from the first node to the second node, a volume of data to be hashed by the second node, wherein the volume of data is sent at a first time; receiving at the first node, from the second node, the hash of the volume of data, wherein the hash of the volume of data is received at a second time;
determining, by the first node, whether the received hash of the volume of data matches an expected hash of the volume of data;
determining, by the first node, a time difference between the first time and the second time; and
determining, by the first node, whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
2. The method of claim 1 , wherein the second node is determined, by the first node, to be eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash.
3. The method of claim 2, wherein the testing, by the first node of the blockchain system, of the second node of the blockchain system is performed at a random time during each time period of a series of consecutive time periods.
4. The method of claim 3, wherein the second node is determined, by the first node, to not be eligible to be selected as a confirming node if the determined time difference for the given volume of data is above the threshold time and/or the received hash does not match the expected hash for n consecutive time periods, where n is a positive non-zero integer.
5. The method of any preceding claim, wherein the received hash and the expected hash are rolling hashes.
6. The method of any of claims 2 to 5, further comprising determining, by the first node, an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration.
7. The method of any preceding claim, further comprising:
testing, by the first node of the blockchain system, a plurality of further nodes of the blockchain system; and
ranking, by the first node, the second node and the plurality of further nodes based on the respective determined time differences;
wherein the second node is only determined to be eligible to be selected as a confirming node of the blockchain system if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system.
8. The method of any preceding claim, further comprising appending the determined time difference and/or the determined eligibility of the second node to a further blockchain.
9. A node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to test a second node of the blockchain system, the first node comprising:
a network interface configured to send a volume of data to the second node at a first time, wherein the volume of data is to be hashed by the second node; the network interface being further configured to receive the hash of the volume of data from the second node at a second time;
one or more processors configured to determine whether the received hash of the volume of data matches an expected hash of the volume of data; to determine a time difference between the first time and the second time; and to determine whether or not the second node is eligible to be selected as a confirming node of the blockchain system based on the determined time difference and whether the received hash of the volume of data matches the expected hash of the volume of data.
10. The apparatus of claim 9, wherein the one or more processors are configured to determine that the second node is eligible to be selected as a confirming node if the determined time difference for a given volume of data is below a threshold time and the received hash matches the expected hash.
11. The apparatus of claim 10, wherein the network interface is configured to send a volume of data to the second node at a random time during each time period of a series of consecutive time periods.
12. The apparatus of claim 11 , wherein the one or more processors are configured to determine that the second node is not eligible to be selected as a confirming node if the determined time difference for a given volume of data is determined to be above the threshold time and/or the received hash is determined to not match the expected hash for n consecutive time periods, where n is a positive non-zero integer.
13. The apparatus of any of claims 9 to 12, wherein the received hash and the expected hash are rolling hashes.
14. The apparatus of any of claims 10 to 13, wherein the one or more processors are further configured to determine an uptime for the second node based on the duration for which each test has determined that the time difference for a given volume of data is below the threshold time and the received hash matches the expected hash; wherein the one or more processors are only configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system if the uptime is longer than a threshold duration.
15. The apparatus of any of claims 10 to 14, wherein the apparatus is further configured to test a plurality of nodes of the blockchain system by sending volumes of data to and receiving corresponding hashes from each of the plurality of nodes of the blockchain system and determining the respective time differences;
wherein the one or more processors are further configured to rank the second node and the plurality of further nodes based on the respective determined time differences; and wherein the one or more processors are configured to determine that the second node is eligible to be selected as a confirming node of the blockchain system only if the second node is determined to be ranked in the top number or percentage of the plurality of nodes of the blockchain system.
16. The apparatus of any of claims 10 to 15, wherein the node apparatus is further configured to append the determined time difference and/or the determined eligibility of the second node to a further blockchain.
17. A method for a blockchain system comprising a plurality of nodes, the method comprising:
determining, by a first node, a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of a plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time;
receiving, by the first node, one or more confirmed blocks of data from each of the plurality of confirming nodes; and
determining, by the first node, whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, identifying any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time.
18. The method of claim 17, wherein confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received are only identified as not being eligible to be a confirming node for future periods of time if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other.
19. The method of claim 17 or 18, wherein the method further comprises monitoring, by the first node, a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and identifying, by the first node, any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time.
20. The method of any of claims 17 to 19, wherein the determined plurality of confirming nodes for a given period of time is an odd number of confirming nodes.
21. The method of any of claims 17 to 20, wherein the determined plurality of confirming nodes for a given period of time represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node.
22. The method of any of claims 17 to 21 , further comprising appending to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
23. A node apparatus for a blockchain system comprising a plurality of nodes, wherein the node apparatus is a first node of the blockchain system that is configured to assess a plurality of nodes each identified as being eligible to be a confirming node of the blockchain system, the first node comprising:
one or more processors configured to determine a plurality of confirming nodes for a given period of time, wherein the plurality of confirming nodes are a subset of the plurality of nodes each identified as being eligible to be a confirming node, and wherein the plurality of confirming nodes correspond to the nodes that will confirm new blocks of data to be appended to a blockchain of the blockchain system for the given period of time; and
a network interface configured to receive one or more confirmed blocks of data from each of the plurality of confirming nodes;
wherein the one or more processors are further configured to determine whether a majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes match each other; and, if so, to identify any confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time.
24. The apparatus of claim 23, wherein the one or more processors are further configured to identify confirming nodes from which a confirmed block not matching the majority of the respective confirmed blocks was received as not being eligible to be a confirming node for future periods of time only if a qualified majority of the respective one or more confirmed blocks of data received from each of the plurality of confirming nodes are determined to match each other.
25. The apparatus of claim 23 or 24, wherein the one or more processors are further configured to monitor a time limit for the one or more confirmed blocks of data to be received from each of the plurality of confirming nodes; and to identify any confirming nodes from which a confirmed block was not received during the time limit as not being eligible to be a confirming node for future periods of time.
26. The apparatus of any of claims 23 to 25, wherein the determined plurality of confirming nodes for a given period of time is an odd number of confirming nodes.
27. The apparatus of any of claims 23 to 26, wherein the determined plurality of confirming nodes for a given period of time represent a percentage of the plurality of nodes each identified as being eligible to be a confirming node.
28. The apparatus of any of claims 23 to 27, wherein the node apparatus is further configured to append to a further blockchain, for each of the plurality of confirming nodes, information regarding whether the respectively received confirmed blocks match the majority of the corresponding received confirmation blocks.
EP19821171.6A 2018-12-07 2019-12-06 A node testing method and apparatus for a blockchain system Pending EP3891952A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1820008.9A GB2579635A (en) 2018-12-07 2018-12-07 A node testing method and apparatus for a blockchain system
PCT/GB2019/053449 WO2020115496A2 (en) 2018-12-07 2019-12-06 A node testing method and apparatus for a blockchain system

Publications (1)

Publication Number Publication Date
EP3891952A2 true EP3891952A2 (en) 2021-10-13

Family

ID=65029967

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19821171.6A Pending EP3891952A2 (en) 2018-12-07 2019-12-06 A node testing method and apparatus for a blockchain system

Country Status (3)

Country Link
EP (1) EP3891952A2 (en)
GB (1) GB2579635A (en)
WO (1) WO2020115496A2 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110162470B (en) * 2019-04-28 2023-08-18 创新先进技术有限公司 Block chain testing method and device
CN110347609B (en) * 2019-07-18 2023-05-23 腾讯科技（深圳）有限公司 Method and device for testing blockchain software
CN111464394B (en) * 2020-03-31 2022-04-15 腾讯科技（深圳）有限公司 Node monitoring method and device and storage medium
CN112738172B (en) * 2020-12-23 2022-03-08 平安科技（深圳）有限公司 Block chain node management method and device, computer equipment and storage medium
CN112738262B (en) * 2020-12-30 2024-04-02 普华云创科技(北京)有限公司 Computing method and system for selecting optimal node
GB2606712A (en) * 2021-05-13 2022-11-23 Univ Glasgow Court Information consensus in distributed critical systems
CN115174572B (en) * 2022-06-30 2024-01-05 蚂蚁区块链科技(上海)有限公司 Data multicasting method in blockchain, blockchain node and storage medium

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180063238A1 (en) * 2016-08-25 2018-03-01 Jiangang Zhang Massively Scalable, Low Latency, High Concurrency and High Throughput Decentralized Consensus Algorithm
US10360191B2 (en) * 2016-10-07 2019-07-23 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
US10657526B2 (en) * 2016-10-28 2020-05-19 International Business Machines Corporation System and method to dynamically setup a private sub-blockchain based on agility of transaction processing
CN108712307B (en) * 2018-05-11 2021-01-29 北京奇虎科技有限公司 Bandwidth capacity calculation method and device based on block chain
CN108665274A (en) * 2018-05-14 2018-10-16 北京链享未来科技有限公司 A kind of accounting nodes intelligent selecting method
CN108717630B (en) * 2018-05-19 2020-12-22 上海分布信息科技有限公司 Block output method and implementation system thereof
CN108898021B (en) * 2018-06-04 2021-06-01 北京奇虎科技有限公司 Threat information processing method, system and computing device based on block chain

Also Published As

Publication number Publication date
WO2020115496A3 (en) 2020-07-23
GB2579635A (en) 2020-07-01
WO2020115496A2 (en) 2020-06-11
GB201820008D0 (en) 2019-01-23

Similar Documents

Publication Publication Date Title
EP3891952A2 (en) A node testing method and apparatus for a blockchain system
CN110832825B (en) Method and node for network for increasing verification speed by tamper-proof data
CN107171810B (en) Verification method and device of block chain
US20200403776A1 (en) Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance
JP7208930B2 (en) Release of controlled cryptographic private keys
EP4002181A1 (en) A consensus method and framework for a blockchain system
JP6034927B1 (en) Secret calculation system, secret calculation device, and program
KR20200074912A (en) Change of primary node in distributed system
US20210326867A1 (en) Fork-Tolerant Consensus Protocol
EP3981104A1 (en) Lightweight blockchain based on split-trust
De Domenico et al. Modeling structure and resilience of the dark network
WO2022217807A1 (en) Blockchain consensus node selection method and apparatus, and computer device and storage medium
CN110493207B (en) Data processing method and device, electronic equipment and storage medium
AU2018422776A1 (en) Sybil-resistant identity generation
KR20220164460A (en) Method and appartaus for selecting distributed consensus node based on proof-of-nonce
WO2020229925A1 (en) Systems and methods for mining on a proof-of-work blockchain network
CN111679978B (en) Program testing method, program testing device, electronic equipment and storage medium
CN111431802B (en) Block chain node communication optimization system and method
US20200153622A1 (en) System and method for enforcement of correctness for key derivation
KR20210077136A (en) A Program for operation of blockchain network system
CN110225103B (en) Service recommendation method, device and equipment
GB2590009A (en) A Node Testing Method and Apparatus For a Blockchain System
CN112119608A (en) System and asynchronous protocol for verifiable secret sharing
CN112181599B (en) Model training method, device and storage medium
KR102447063B1 (en) Managing method for blockchain based on enhanced practical byzantine fault tolerance, blockchain system and node apparatus

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210706

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230509

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DRAGON INFOSEC LTD