WO2020115496A2 - Procédé et appareil de test de nœud pour un système de chaîne de blocs - Google Patents

Procédé et appareil de test de nœud pour un système de chaîne de blocs Download PDF

Info

Publication number
WO2020115496A2
WO2020115496A2 PCT/GB2019/053449 GB2019053449W WO2020115496A2 WO 2020115496 A2 WO2020115496 A2 WO 2020115496A2 GB 2019053449 W GB2019053449 W GB 2019053449W WO 2020115496 A2 WO2020115496 A2 WO 2020115496A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
nodes
confirming
time
data
Prior art date
Application number
PCT/GB2019/053449
Other languages
English (en)
Other versions
WO2020115496A3 (fr
Inventor
Richard Matthew DENNIS
Gareth Huw OWENSON
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
Priority to EP19821171.6A priority Critical patent/EP3891952A2/fr
Publication of WO2020115496A2 publication Critical patent/WO2020115496A2/fr
Publication of WO2020115496A3 publication Critical patent/WO2020115496A3/fr

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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Environmental & Geological Engineering (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Mathematical Physics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un procédé pour un système de chaîne de blocs, le procédé consistant à tester, par un premier nœud du système de chaîne de blocs, un second nœud du système de chaîne de blocs, le test consistant à : envoyer, du premier nœud au second nœud, un volume de données à hacher par le second nœud, le volume de données étant envoyé dans un premier temps ; et recevoir au niveau du premier nœud, du second nœud, le hachage du volume de données, le hachage du volume de données étant reçu dans un second temps. Le test consiste en outre à déterminer, par le premier nœud, si le hachage reçu du volume de données correspond à un hachage attendu du volume de données ; à déterminer, par le premier nœud, une différence de temps entre le premier temps et le second temps ; et à déterminer, par le premier nœud, si le second nœud est éligible ou non comme nœud de confirmation du système de chaîne de blocs sur la base de la différence de temps déterminée et si le hachage reçu du volume de données correspond au hachage attendu du volume de données.
PCT/GB2019/053449 2018-12-07 2019-12-06 Procédé et appareil de test de nœud pour un système de chaîne de blocs WO2020115496A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19821171.6A EP3891952A2 (fr) 2018-12-07 2019-12-06 Procédé et appareil de test de noeud pour un système de chaîne de blocs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1820008.9 2018-12-07
GB1820008.9A GB2579635A (en) 2018-12-07 2018-12-07 A node testing method and apparatus for a blockchain system

Publications (2)

Publication Number Publication Date
WO2020115496A2 true WO2020115496A2 (fr) 2020-06-11
WO2020115496A3 WO2020115496A3 (fr) 2020-07-23

Family

ID=65029967

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2019/053449 WO2020115496A2 (fr) 2018-12-07 2019-12-06 Procédé et appareil de test de nœud pour un système de chaîne de blocs

Country Status (3)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347609A (zh) * 2019-07-18 2019-10-18 腾讯科技（深圳）有限公司 一种测试区块链软件的方法及装置
CN112738262A (zh) * 2020-12-30 2021-04-30 普华云创科技(北京)有限公司 一种选择最优节点的计算方法和系统
CN112738172A (zh) * 2020-12-23 2021-04-30 平安科技（深圳）有限公司 区块链节点的管理方法、装置、计算机设备和存储介质
CN115174572A (zh) * 2022-06-30 2022-10-11 蚂蚁区块链科技(上海)有限公司 区块链中的数据组播方法和区块链节点

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110162470B (zh) * 2019-04-28 2023-08-18 创新先进技术有限公司 一种区块链的测试方法和装置
CN111464394B (zh) * 2020-03-31 2022-04-15 腾讯科技（深圳）有限公司 一种节点监控方法、装置以及存储介质
GB2606712A (en) * 2021-05-13 2022-11-23 Univ Glasgow Court Information consensus in distributed critical systems

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 (zh) * 2018-05-11 2021-01-29 北京奇虎科技有限公司 一种基于区块链的带宽能力计算方法及装置
CN108665274A (zh) * 2018-05-14 2018-10-16 北京链享未来科技有限公司 一种记账节点智能选择方法
CN108717630B (zh) * 2018-05-19 2020-12-22 上海分布信息科技有限公司 一种出块方法及其实现系统
CN108898021B (zh) * 2018-06-04 2021-06-01 北京奇虎科技有限公司 基于区块链的威胁情报处理方法、系统及计算设备

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347609A (zh) * 2019-07-18 2019-10-18 腾讯科技（深圳）有限公司 一种测试区块链软件的方法及装置
CN110347609B (zh) * 2019-07-18 2023-05-23 腾讯科技（深圳）有限公司 一种测试区块链软件的方法及装置
CN112738172A (zh) * 2020-12-23 2021-04-30 平安科技（深圳）有限公司 区块链节点的管理方法、装置、计算机设备和存储介质
CN112738262A (zh) * 2020-12-30 2021-04-30 普华云创科技(北京)有限公司 一种选择最优节点的计算方法和系统
CN115174572A (zh) * 2022-06-30 2022-10-11 蚂蚁区块链科技(上海)有限公司 区块链中的数据组播方法和区块链节点
CN115174572B (zh) * 2022-06-30 2024-01-05 蚂蚁区块链科技(上海)有限公司 区块链中的数据组播方法、区块链节点和存储介质

Also Published As

Publication number Publication date
EP3891952A2 (fr) 2021-10-13
GB201820008D0 (en) 2019-01-23
WO2020115496A3 (fr) 2020-07-23
GB2579635A (en) 2020-07-01

Similar Documents

Publication Publication Date Title
WO2020115496A2 (fr) Procédé et appareil de test de nœud pour un système de chaîne de blocs
US20230239157A1 (en) Network for improved verification speed with tamper resistant data
CN107171810B (zh) 区块链的验证方法及装置
US20200403776A1 (en) Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance
EP4002181A1 (fr) Procédé et cadre de consensus pour un système de chaîne de blocs
US20190268142A1 (en) Systems and methods for blockchains with serial proof of work
JP6034927B1 (ja) 秘密計算システム、秘密計算装置、およびプログラム
KR20200074908A (ko) 분산 시스템 내의 네트워크 노드들 간의 합의 달성
US20210326867A1 (en) Fork-Tolerant Consensus Protocol
US20210021412A1 (en) Method and apparatus for electing representative node device, computer device, and storage medium
WO2022217807A1 (fr) Procédé et appareil de sélection de nœuds de consensus de chaîne de blocs, et dispositif informatique et support de stockage
CN110493207B (zh) 一种数据处理方法、装置、电子设备和存储介质
KR20220164460A (ko) 난스 증명 기반 분산합의 노드 선정 방법 및 장치
CN111431802B (zh) 区块链节点通信优化系统及方法
US10630471B1 (en) System and method for enforcement of correctness for key derivation
JP2022523447A (ja) ブロックチェーンネットワークにおいてロールベース合意プロトコルを使用してリーダーノードを選出する方法
WO2020229925A1 (fr) Systèmes et procédés de minage sur un réseau de chaînes de blocs à preuve de travail
CN111679978B (zh) 一种程序测试方法、程序测试装置、电子设备及存储介质
CN114039733B (zh) 一种针对联盟链的存证业务转移方法、装置及设备
KR20210077176A (ko) 뉴럴 블록 클러스터 기반의 안전한 블록 체인 네트워크 시스템
US11818249B2 (en) Nodes and methods of operating the same
CN112181599B (zh) 模型训练方法、装置及存储介质
KR20210077136A (ko) 블록 체인 네트워크 시스템의 동작 방법
CN110225103B (zh) 一种业务推荐方法、装置及设备
GB2590009A (en) A Node Testing Method and Apparatus For a Blockchain System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19821171

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019821171

Country of ref document: EP

Effective date: 20210707