Classifications

• • 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/104—Peer-to-peer [P2P] networks
  • H04L67/1044—Group management mechanisms 
  • H04L67/1051—Group master selection mechanisms
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
  • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/10—File systems; File servers
  • G06F16/11—File system administration, e.g. details of archiving or snapshots
  • G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
  • G06F16/125—File system administration, e.g. details of archiving or snapshots using management policies characterised by the use of retention policies
• • 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
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
  • G06Q10/063—Operations research, analysis or management
  • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• • 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
  • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
• • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• • 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/104—Peer-to-peer [P2P] networks
  • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
  • H04L67/1076—Resource dissemination mechanisms or network resource keeping policies for optimal resource availability in the overlay network
• • 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/104—Peer-to-peer [P2P] networks
  • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
  • H04L67/1093—Some peer nodes performing special functions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• • 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
• • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/10—File systems; File servers
  • G06F16/18—File system types
  • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/10—File systems; File servers
  • G06F16/18—File system types
  • G06F16/182—Distributed file systems
  • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
  • G06F16/1837—Management specially adapted to peer-to-peer storage networks
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
  • G06F7/58—Random or pseudo-random number generators
  • G06F7/588—Random number generators, i.e. based on natural stochastic processes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
  • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q2220/00—Business processing using cryptography
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
• • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• • 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

Definitions

• This application relates to methods for blockchain systems.
• the application relates to a consensus method for a blockchain system and a corresponding framework for operating the 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.
• 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. 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.
• node 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 to 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.
• Some proof of work protocols have attempted to reduce the wastage of this computer processing and corresponding power usage by targeting computational problems that can be used in other areas, such as the
• the present disclosure relates to a method for a blockchain system operated at a node participating in the blockchain system.
• the method comprises receiving, at a participant node, a node participation document comprising a list of node identifiers that uniquely identify each node participating in the blockchain system; receiving, at the participant node, a true random number associated with a current time interval; and determining, at the participant node, a leader node for the current time interval from the nodes listed in the node participation document based on a numerical disparity between the true random number associated with the current time interval and the node identifiers from the node participation document.
• the blockchain system identifies the leader node as the only node that can generate one or more new blocks during the corresponding time interval to be validly appended to a blockchain of the blockchain system
• the method advantageously identifies a leader node for a given time interval in a truly random manner, with the leader node being given the exclusive ability to write one or more new blocks during that time interval for valid inclusion in the blockchain system by appending the new blocks to a blockchain of the blockchain system. This is possible because all of the participant nodes participating in the blockchain system can
• the method may optionally comprise receiving, at the leader node, from the nodes participating in the blockchain system, new transactions for inclusion in the blockchain system;
• the method may optionally comprise sending, from the participant node, any new transactions for inclusion in the blockchain system to the determined leader node for the duration of the current time interval.
• This method further advantageously removes the need for a gossip protocol because each next new block can be sent directly from the originating node of the blockchain system that received the transaction to the leader node, or a corresponding buffer for the leader node. Furthermore, the need for a resource intensive distributed consensus protocol is also avoided whilst still providing a distributed and decentralised blockchain system.
• the leader node may generate new blocks comprising a block header and a block body, with the block header comprising: a hash of the previous block in the blockchain, a hash of the block body of the block, the true random number associated with the current time interval and a cryptographic signature of the block using a private key associated with the leader node.
• the block header comprising: a hash of the previous block in the blockchain, a hash of the block body of the block, the true random number associated with the current time interval and a cryptographic signature of the block using a private key associated with the leader node.
• the block header further comprises a Merkle tree root and a timestamp. This advantageously improves the integrity and immutable nature of the blockchain of the blockchain system.
• the node participation document further identifies a cryptographic public key associated with each of the nodes participating in the blockchain system. If the participant node determines that it is not the leader node for the current time interval, the method may further comprise receiving, by the participant node, one or more new blocks generated by the leader node, from the leader node; verifying, by the participant node, the block header data of the one or more new blocks and the cryptographic signature of the one or more new blocks using the public key associated with the determined leader node for the time interval associated with the one or more new blocks; and adding, by the participant node, the one or more new blocks to a local blockchain stored at the participant node if the blocks are verified.
• the participant nodes further receive one or more new blocks to be appended to their locally stored blockchain comprising a block header that can be used to verify the integrity of the block data of each block using digital signature public- key cryptography.
• the received and verified blocks are then used to update the locally stored blockchain so that it is up-to-date.
• one or more new blocks generated by the leader node may be written without a block size limit. This advantageously means that the number of transactions to be included in the new block can be scaled with the rate of new transactions in the blockchain system and therefore higher transactions rates can be achieved.
• the node participation document may identify a subset of the nodes participating in the blockchain system as being authorised for selection as the leader node; and the leader node determined by the participant node for the current time interval may be based on a numerical disparity between the true random number associated with the current time interval and the node identifiers of the nodes identified as being authorised for selection as the leader node in the node participation document.
• the received node participation document may be cryptographically signed and the method may further comprise verifying, at the participant node, the authenticity and/or integrity of the received node participation document based on the cryptographic signature.
• the participant node may advantageously verify that the locally stored version of the node participant document is a valid version that has not been tampered with.
• the participant node may periodically receive updated versions of the node participation document, each version being associated with a valid from time and a valid until time; and the method may further comprise performing the determination, at the participant node, of the leader node for the current time interval based on the node participation document that is currently valid and has the most recent valid from time.
• determining, at the participant node, a leader node for the current time interval may comprise determining the node listed in the node participation document for which the numerical disparity between the true random number associated with the current time interval and the corresponding node identifier is closest to zero.
• the blockchain method further comprises deleting the block body and
• the present disclosure relates to a further method for a blockchain system operated at a node participating in the blockchain system.
• the method comprises receiving, at a participant node participating in the blockchain system, a plurality of true random numbers, each associated with a given time interval; and receiving, at the participant node, one or more new blocks for appending to a local blockchain stored at the participant node, wherein each new block comprises a block header and a block body; wherein the block header comprises a hash of the previous block in the blockchain, a hash of the block body of the block, a Merkle tree root of the block, a timestamp, the true random number associated with the time interval corresponding to the timestamp and a
• the method further comprises verifying, by the participant node, the block header data of each new block and the cryptographic signature of each new block using a public key associated with the node that generated each new block; adding, by the participant node, each new block to the local blockchain stored at the participant node if the new block is verified; and deleting, from the local blockchain stored at the participant node, the block body for blocks stored at the participant node that do not meet a threshold, without deleting the block header corresponding to the deleted block body.
• the method of the second aspect advantageously structures the blocks in the blockchain in a manner that enables blockchain data that does not meet the threshold to be deleted from the locally stored versions of the blockchain at individual participant nodes without affecting the integrity of the blockchain.
• This data structure at the participant nodes enables nodes to confirm or validate previous transactions without requiring the full blockchain to be stored locally and thus enables devices with limited storage space to fully participate in the blockchain network, for example the threshold may be set to a certain number of days or a certain storage size of the local blockchain.
• the method further comprises:
• the methods of the first and second aspects may optionally further comprise deleting, by the participant node, transaction data stored in the block bodies of blocks of the local blockchain stored at the participant node having no unspent transaction output. This advantageously further reduces the local storage requirement for participant nodes to store a local version of the blockchain as transaction data that does not include unspent transaction outputs will not be required for the verification of future transactions. This also advantageously improves the efficiency of transaction verification on the blockchain system.
• a subset of the nodes participating in the blockchain system are archive nodes that each store a local blockchain comprising the block header and block body of a genesis block and all subsequent blocks. If the participant node determines that it is the leader node and the block comprising an unspent transaction output required for confirming a new transaction has been deleted from the local blockchain stored at the leader node, the method may further comprise polling, by the leader node, one or more archive nodes for a copy of the unspent transaction output required for confirming the new transaction; verifying, by the leader node, the integrity of the copy of the unspent transaction output based on the Merkle tree root of the block header stored in the local blockchain of the leader node corresponding to the deleted block body; confirming, by the leader node, the new transaction based on the verified copy of the unspent transaction output; and generating, by the leader node, a new block, comprising the confirmed new transaction, to be appended to the blockchain.
• this method enables leader nodes that have deleted the block body of certain blocks of the blockchain, that include the required unspent transaction outputs, from their local copy to obtain a copy of these for verification of transactions to be included in the new blocks generated by the leader node. For example, this enables the verification of new transactions that involve unspent transaction outputs from previous transactions that are older than the threshold.
• the method may further comprise polling, by the leader node, one or more archive nodes for a copy of the block required for confirming the new transaction; and verifying, by the leader node, the integrity of the copy of the block by comparing a hash of the block body of the copy of the block with the hash from the block header corresponding to the copy of the block that is stored in the local blockchain stored at the leader node.
• the confirming, at the leader node, of the received new transactions comprises searching for corresponding unspent transaction outputs in the verified copy of the block.
• this method enables leader nodes that have deleted the block body of certain blocks of the blockchain from their local copy to obtain this block body data from other nodes participating in the blockchain system, referred to as archive nodes, if and when required for confirming new transactions that are to be written into new blocks of the blockchain by the leader node. For example to confirm new transactions that involve unspent transaction outputs of previous transactions that are older than the threshold.
• the true random number associated with the current time interval received at the participant node may be a quantum random number. This advantageously provides a true random number that cannot be attacked and guessed in advance, even with the use of third party quantum computing.
• Figure 1 is a block diagram of a plurality of nodes participating in a blockchain system
• Figure 2 is a block diagram of an individual node for participating in the blockchain system
• Figure 3 is a flowchart illustrating a method according to a first aspect of the present disclosure
• Figure 4 is a flowchart illustrating a method according to a second aspect of the present disclosure
• Figure 5 is a flowchart illustrating a first verification method for use in the second aspect of the disclosure.
• Figure 6 is a flowchart illustrating a second verification method for use in the second aspect of the disclosure.
• FIG 1 is a block diagram of a plurality of nodes participating in a blockchain system 10.
• there are four participant nodes 12, 12A each of which are in communication with the other participant nodes of the blockchain system.
• One of the participant nodes 12 may be referred to as an archive node 12A.
• Each of the participant nodes 12 are configured to receive a data input from a data source 14.
• the data source 14 may act as a beacon broadcasting the relevant data to each of the participant nodes 12, or alternatively the participant nodes may poll the data source 14 in order to obtain the relevant data.
• a single participant node 12 is shown in further detail in Figure 2, some of these features have been omitted from Figure 1 for the sake of clarity.
• the participant node 12 comprises an input network interface 20, a processor 22, an output network interface 24.
• the input network interface 20 and the output network interface 24 are shown as separate units in Figure 2, however the skilled person will appreciate that these two units may alternatively be embodied in a single bidirectional network interface.
• the purpose of these network interfaces is to enable the respective participant nodes 12 in the blockchain system 10 to communicate with each other, for example to form a peer-to-peer network.
• the respective network interfaces may utilise any known wired or wireless network topology over local area networks, wide area networks and the internet.
• Each of the participant nodes 12 stores a local version of the blockchain of the blockchain system 10 in a data store 16 and a node participation document in a store 18.
• the participant node may be referred to as an archive node 12A.
• Other participant nodes 12 i.e. the participant nodes 12 that are not archive nodes 12A
• the node participation document 18 is a list that identifies all of the nodes that are participating in the blockchain system 10 at the time that the node participation document 18 is generated and issued.
• the node participation document 18 also includes the basic data of each node so that they can be contacted by any other node in the blockchain system 10.
• This basic data includes a public key for cryptographic digital signatures and a unique public identity to enable other nodes to direct message to and communicate with a given participant node 12.
• This unique public identity may simply be the IP address of the participant node 12; 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.
• human readable nicknames may also be provided for each of the nodes identified in the node participation document 18 in order to improve usability.
• this unique public identity, or another unique node identifier listed in the node participation document 18, can be used as a kind of raffle number for selecting one of the nodes 12 listed in the node participation document 18 based on a randomised selection.
• a random number is generated and the selected node is the node 12 for which the difference between the random number and a numerical representation of the unique node identifier or other unique public identity (if not already in a numerical format) is closest to zero.
• a maximum or other numerical disparity could be used instead of being closest to zero.
• the selected node 12 will then be considered to be the leader node.
• the leader node 12 which may also be referred to as a confirming node, will then be recognised by the blockchain system 10 as having the right to validly confirm any new transactions and write or generate the corresponding new blocks that are to be included in and appended to the end of the blockchain.
• the leader node is analogous to the first node to solve the computational problem in a proof of work protocol.
• the data source 14 is configured to generate a new random number every minute
• the selected node 12 will only be the leader node for the minute, or other selected period, corresponding to the generated random number.
• each of the nodes 12 participating in the blockchain system 10 can independently determine, using their respective processors 22, the identity of the node selected as the leader node for the corresponding period using a series of simple calculations that will result in each node arriving at the same answer. This dramatically reduces the amount of computational resource required by each processor 22 in order to determine the leader node in comparison to proof of work methods as well as reducing the corresponding energy usage, which may otherwise be a wasted end product of the proof of work protocol.
• the processor 22 of the leader node 12 can then start confirming the validity of the received transactions in the usual manner and writing these into new blocks. Because the above consensus protocol is quick and easy for the nodes to complete, new blocks can be created at a faster rate, thus reducing the transaction confirmation wait times of prior art systems and also improving the resistance of the blockchain to attack by moving newly appended blocks away from the end of the blockchain more quickly by appending further new blocks.
• the newly created blocks are then broadcast from the output network interface 24 of the leader node to all of the other nodes participating in the blockchain system for appending to the local versions of the blockchain stored at each node.
• the participant nodes 12 can then verify, using the processor 22, that the hash of the previous block identified in the new block header matches that of the most recent block in the blockchain currently stored at the participant node 12.
• the processor 22 of the participant node 12 further validates the digital signature contained in the block header using the public-key associated with the leader node in the node participation document 18. If the block is determined to be valid by the processor 22, then the participant node 12 will append the received block to the locally stored blockchain 16; 16A.
• FIG. 3 illustrates a flowchart according to the above first aspect of the present disclosure.
• the participant node 12 receives the node participation document comprising a list of node identifiers that uniquely identify each node participating in the blockchain system 10; and a true random number associated with a current time interval.
• the participant node 12 determines a leader node for the current time interval from the nodes listed in the node participation document 18 based on a numerical disparity between the true random number associated with the current time interval and the node identifiers from the node participation document 18.
• step 33 the participant node 12 sends any new transactions for inclusion in the blockchain system 10 to the determined leader node for the duration of the current time interval. Conversely, if the participant node 12 determines that it is the leader node at step 32, then the flowchart proceeds to step 34 where the participant node 12, which may now be referred to as the leader node, receives any new transactions for inclusion in the blockchain system 10 from the other nodes 12 participating in the blockchain system 10.
• the leader node 12 confirms the received new transactions by searching for corresponding unspent transaction outputs in the blockchain system 10. These unspent transaction outputs are the outputs of previous transactions that can be validly spent as the input in new transactions. Then, at step 36, the leader node 12 generates a new block comprising the confirmed new transactions, appends this new block to the local blockchain stored at the leader node, and broadcasts the new block to all of the other nodes participating in the blockchain system 10.
• the blocks written do not have a block size limit, this means that there is no theoretical limit on how many transactions can be included in a block.
• the only limitation in the number of transactions per second is the hardware and the network bandwidth; indeed 120,000 transactions per second have been simulated in a lab environment.
• the network automatically scales and can handle increases in the number of transactions per second by fully utilizing the network and the resources available to the network as demand increases.
• the selection in advance of a single leader node 12 that will confirm subsequent transactions for a given period has also been found to improve the possible number of transactions per second.
• the processor 22 of the leader node 12 creates blocks having a block structure divided into a block header and a block body.
• the block header comprises the hash of the previous block in the blockchain, a hash of the data in the body of the current block, the random number associated and a cryptographic signature of the block using a private key associated with the leader node.
• the block header may also comprise a Merkle tree root for the block and a UNIX timestamp associated with the block.
• the block body comprises the transaction data (including the amount of the transaction, the sending user address and the receiving user address), typically encoded in a Merkle tree data structure.
• leader node 12 Should, for whatever reason, the leader node 12 become offline and/or some of the new transactions are not confirmed into a new block by the leader node, these will be maintained in a transaction pool memory buffer so that they can be forwarded to and confirmed by the following leader node. In this manner, the process continues and all new transactions that have not yet been confirmed (or indeed rejected) get rolled into the next leader’s block.
• the only computationally expensive operations here are the processes of confirming that the new transactions are valid (by searching for the relevant unspent transaction outputs in the blockchain) and creating the hash of the whole block (once all transactions in the period are confirmed). This means that the computation can be performed on the processor 22 of a low resource device such as a mobile device because the required computation is no more expensive than other common tasks.
• Each version of the node participation document 18 and the random number for each interval are archived so that further validations can be carried out after the fact.
• These archived versions of the node participation document and the random number for each interval may be stored locally at the participant node 12, or alternatively they may be accessed from a trusted third party server.
• all the other nodes 12 can look up archived versions of the random numbers and corresponding node participation documents 18 in order to determine who the selected leader node was for each block and can then cryptographically verify the digital signatures in the headers of these blocks using the public-keys associated with the leader nodes in the node participation document 18. Accordingly, for an immutability attack to be successful, the adversary would need to have access to the private-key of each of the leader nodes involved.
• an adversary may, regardless of economic cost, have decided to attack the blockchain system 10 of the present disclosure, and have been patient enough to control more than 50% of nodes on the blockchain system 10 and establish a reputation such that their nodes 12 are eligible to be chosen as the leader node.
• an adversary may, regardless of economic cost, have decided to attack the blockchain system 10 of the present disclosure, and have been patient enough to control more than 50% of nodes on the blockchain system 10 and establish a reputation such that their nodes 12 are eligible to be chosen as the leader node.
• All of the other participant nodes 12 on the blockchain system 10 will also be able to see which compromised node created and/or confirmed the invalid transaction and thus the compromised node can then be removed from the node participation document 18 in order to prevent it from further participating in the blockchain system 10.
• a true random number generator In order to prevent any parties from being able to guess the random number and identify the corresponding node 12 that would be selected as the leader node or to pre-emptively modify a unique node identifier so that the node to be selected is altered, a true random number generator should be used.
• 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.
• quantum random numbers can ensure random values that are unpredictable even if an attacker is able to gain access to and observe the random number generator source 14.
• the source may use quantum entangled photons as the source of the digital bits of the quantum random number as they are fundamentally unpredictable. This dramatically increases the cost to attack the blockchain system 10 by orders of magnitude greater than prior embodiments.
• two independent hardware random number generators each provide 512 bits of randomness, and these two values are then XOR’ed together to yield a Seed Value.
• This Seed Value is then collected together with a plurality of descriptive data (for example a version number, frequency of output, time stamp, a code for a chaining status, and the value of the previous output) to link the random number to the time that it was created as well as linking to the previous random number.
• This is then hashed with SHA- 512 and signed with a private key linked to the data source 14 to produce a digital signature.
• the public key linked to the data source 14 can then be used to verify that the signature corresponds to the relevant data and is signed by the data source 14.
• the signature is hashed with SHA-512 again to create the final output value.
• This final output value preserves the original entropy from the seed value, but additionally makes the output value dependant on the private key of the data source 14 and all the relevant background data in a verifiable way.
• the blockchain system 10 is able to confirm transactions on nodes 12 comprising very low power computational devices at very high speed with a very high degree of security. Further, the network 10 can be scaled rapidly and at very low cost. Moreover, the complete integrity of the blockchain is maintained at all times, and all transactions appear on the chain.
• the blockchain system 10 may further comprise one or more authority nodes that are responsible for the creation, maintenance and distribution of the node participation document 18.
• the authority nodes will not be considered to be participant nodes 12 because they do not take part in the storage of the blockchain or the confirmation of new transactions - they are only responsible for the node participation document 18.
• Every authority node has a very-secret, long-term “Authority Identity Key”. This key is used to sign "key certificate” documents. Every key certificate contains a medium- term “authority signing key” which is then used by the authority node to sign the node participation document information 18. This digital signature may be verified by the participant nodes prior to using a new node participation document.
• Participant nodes 12 periodically inform the authority nodes of any changes in the data stored about them. Any changes to the node participation document 18 requires the majority agreement of the authority nodes and the updated version will then be published to all of the participant nodes 12. Each participant node 12 requires an up to date version of the node participation document 18 so that it can correctly select the leader node for a given time period based on the associated true random number. Participant nodes 12 may be able to obtain updated versions of the node participation document 18 from other participant nodes 12; however, due to the cryptography used, no one other than the authority nodes can validly alter the node participation document 18, and any invalid alterations will be detectable by any of the participant nodes 12.
• the use of the node participation document 18 avoids the need for a DNS server.
• the authority nodes can monitor the activity of the participant nodes 12 and update the node participation document 18 to prevent malicious nodes from being eligible for selection as the leader node.
• New nodes 12 may also be prevented from selection as the leader node by only considering a subset of the nodes identified in the node
• leader node participation document 18 for example those nodes that have built up a reputation of respectable behaviour, as being eligible to become the leader node. This could be indicated in the node participation document using a flag. In this manner, in one embodiment, the leader node that is indicated as being eligible for leader selection and that has the numerical disparity closest to zero between the participant node identifier and the true random number may be selected as the leader node.
• the node participation document 18 has a finite time period during which it is valid so as to ensure that the participant nodes 12 have the most up to date version of the node participation document 18. Accordingly, node participation documents 18 are assigned a "valid-after" time, a "fresh-until” time and a “valid-until” time. The valid-after time is set to precede the fresh until time, which in turn precedes the valid until time. These times are chosen so that each node participation document 18 will be "fresh” until the next node participation document becomes valid, and "valid" for a while after. In a preferred embodiment, three node participation documents 18 may be valid at any given time (e.g. a historic, current and future version of the node participation document). If all node participation documents at a participant node expire, then the node 12 may continue to operate on the basis of the expired node participation document as this is not a vector for attack.
• the valid-after time is set to precede the fresh until time, which in turn precedes the valid until time.
• the node participation document 18 may further identify the uptime and bandwidth of each node 12 participating in the blockchain system 10 and the IP address may further identify the TCP ports at which the participant node 12 is configured to function.
• certain properties and requirements may be enforced such as only allowing one node identity to be linked to an IP address and requiring a node 12 to be online for a period of two weeks prior to being flagged as entitled for selection as the leader node. This makes it significantly more expensive for a would be attacker to try and flood the node participation document 18 with compromised participant nodes that are entitled for selection as the leader node.
• the authority nodes have no incentive to behave maliciously as they do not participate in the mining or confirmation of transactions. Further, since majority agreement of the authority nodes is required for updates to the node participation document 18, it is very difficult for malicious nodes to influence the node participation document.
• the node participation document 18 is preferably updated hourly.
• participant nodes 12 may be allowed to delete data from their locally stored blockchain 16 without significant impact to the confirming of new transactions.
• a reduced blockchain may be stored at the participant node 12.
• This aspect of the present disclosure may be used with the above consensus protocol for leader / confirming node selection, or it may instead be used with alternative consensus protocols (such as proof of work, proof of authority and proof of stake).
• FIG. 4 illustrates a flowchart according to the second aspect of the present disclosure.
• the participant node 12 receives a plurality of true random numbers, each associated with a given time interval, and one or more new blocks for appending to a local blockchain 16 stored at the participant node 12.
• Each new block comprises a block header and a block body and each block header comprises a hash of the previous block in the blockchain, a hash of the block body of the block, a Merkle tree root of the block, a timestamp, the true random number associated with the time interval corresponding to the timestamp and a cryptographic signature of the block using a private key associated with a node that generated each new block.
• the participant node 12 verifies the block header data of each new block and the cryptographic signature of each new block using a public key associated with the node that generated each new block. Then, if the new block is verified, the block is added to the local blockchain 16 stored at the participant node 12 at step 44.
• the participant node 12 deletes, from the locally stored blockchain 16, the block body for blocks stored at the participant node 12 that do not meet a threshold, however the block headers corresponding to the deleted block bodies are not deleted. Accordingly, the block headers of the genesis block and each and every subsequent block are maintained in the locally stored version of the blockchain 16.
• archive nodes 12A can be provided where the archive nodes are a subset of the participant nodes 12 that, in addition to acting as a normal participant node in the blockchain system 10, also store the full blockchain history. While any participant node 12 can choose to store the full blockchain history and act as an archive node 12A, it is expected that these archive nodes 12A will be fewer in number than the other participant nodes due to the increased storage resources required.
• participant nodes 12 can choose to delete data to save storage resources and the amount of data held by the participant node 12 can be a variable.
• This allows more capable nodes e.g. servers, to locally store a larger amount of the blockchain 16, whilst mobile devices would locally store a smaller amount due to their comparatively limited resources.
• the first strategy is a simple deletion of the block body data from all blocks that do not meet a certain threshold, such as a number of days or a total storage size limit.
• a certain threshold such as a number of days or a total storage size limit.
• the user operating the participant node can limit the amount of the blockchain stored locally on their device by fixing a given storage size limit, or by only storing transactions that have occurred within a given time frame (which will result in a variable size of locally stored blockchain dependent on the number of transactions that were confirmed during that period).
• the block headers are comparatively small and may be advantageously used to validate the integrity of the blockchain and thus all of the block headers of the blockchain are maintained, even when the corresponding block body data is deleted.
• the second strategy involves the deletion of transaction data that does not have any unspent transaction output from blocks that are stored in the local blockchain 16 at the participant node 12, for example even if the transactions are more recent than the above threshold.
• the first and second strategies may be used independently or in combination. The second strategy will be explained in further detail below.
• transactions reference tokens in the transaction inputs and reassign the value to the recipients in the transaction outputs.
• the tokens referenced in the transaction inputs are considered spent and any new "unspent transaction outputs" (UTXO) are created according to the transaction's outputs.
• Unspent transaction outputs are how every participant node 12 in the blockchain system 10 keeps track of the ownership of the tokens in the system. Unspent transaction outputs are not only created for change, but they are created any time a transaction defines a recipient. Unspent transaction outputs are spent whenever they get used as a transaction input; however, the transaction remains a part of the blockchain and is then considered to be a transaction output (rather than an unspent transaction output) that everyone can review to see the previous chain of transactions.
• the transaction spends the two UTXO referenced in the inputs.
• every participant node 12 removes them from their UTXO database.
• the reference still exists in the blockchain as the outputs of the transactions that created those UTXOs.
• the transaction also creates two new UTXOs, the Recipient Output and the Change Output. Every participant node 12 in the blockchain system 10 adds these two UTXO to their database. Let's say that the sender spends the token in the change output quickly thereafter, removing the change output from the UTXO database, but the recipient TXO remains unspent. In that case, (or any other where at least one of the two outputs remains unspent) the transaction would be considered to form part of the "Total Transactions With Unspent Outputs".
• a participant node 12 determines that it is the leader node for the current time interval and unspent transaction outputs dating back further than the threshold, or otherwise deleted, are required, then the leader node 12 can poll one of the archive nodes 12A, which may be identified in the node participation document 18, in order to obtain a copy of the unspent transaction outputs required for confirming the new
• the leader node 12 will be able to check the integrity of the block based on the Merkle tree root of the block header stored in the local blockchain 16 of the leader node 12 corresponding to the deleted block body as set out in step 52 of Figure 5.
• the leader node 12 can then confirm the received new transactions based on the verified copy of the unspent transaction output at step 54 and generate the new block to be appended to the blockchain, comprising the confirmed new transactions, at step 56.
• the archive node 12A may send all unspent transaction outputs relating to the relevant user. This also allows the leader node 12 to confirm the new transactions for inclusion in a new block of the blockchain. Alternatively or in combination with the above embodiment, if a participant node 12 determines that it is the leader node for the current time interval and unspent transaction outputs dating back further than the threshold, or otherwise deleted, are required, then the leader node 12 can poll one of the archive nodes 12A, which may be identified in the node participation document 18, in order to obtain the relevant / required block bodies that are missing from the local blockchain 16 of the leader node 12 as set out in step 60 of Figure 6.
• the leader node 12 will be able to check the integrity of the block by confirming that the hash of the received missing block matches the hash shown in the corresponding block header that is stored in the local blockchain 16 of the leader node 12 as set out in step 62 of Figure 6.
• the properties of the blockchain ensure that a malicious archive node 12A could not forge a transaction into a previous block, since the transaction hash would not match to the Merkle tree kept by the leader node, and thus would be detected as malicious.
• the leader node 12 may also check that the random number used is the correct value.
• the leader node 12 can then confirm the received new transactions by searching for the corresponding unspent transaction outputs in the verified copy of the block at step 64 and generate the new block to be appended to the blockchain, comprising the confirmed new transactions, at step 66.
• the block structure enables some nodes 12 in the blockchain system 10 to delete a portion of the transaction data from the locally stored blockchain, while ensuring that deleted data can be retrieved and that even if an archive node 12A becomes compromised, it cannot be used to alter the history of the blockchain without detection.
• hashing collision resistance means that the probability of an attacker being able to generate a block with different contents with a valid hash is extremely low, such that this attack is not realistic even if the private-key is known.
• the blockchain system 10 of the present disclosure has overcome the following issues:
• the token of the blockchain system 10 of the present disclosure may become a leading cryptocurrency and an alternative to fiat money that can serve as both a store of value and a medium of exchange.
• the token may be used in closed loop payment systems and kept for investment purposes. Due to the high transaction rates possible, the token may also be used for high frequency trading on exchanges.
• the token may further be used to establish rights and ownership over a process and can be securely transferred as required by process.
• 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)
• Business, Economics & Management (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Strategic Management (AREA)
• Accounting & Taxation (AREA)
• General Business, Economics & Management (AREA)
• Human Resources & Organizations (AREA)
• General Engineering & Computer Science (AREA)
• Computing Systems (AREA)
• Economics (AREA)
• Computer Hardware Design (AREA)
• Finance (AREA)
• Entrepreneurship & Innovation (AREA)
• Development Economics (AREA)
• Educational Administration (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• Health & Medical Sciences (AREA)
• Software Systems (AREA)
• Bioethics (AREA)
• Mathematical Physics (AREA)
• General Health & Medical Sciences (AREA)
• Game Theory and Decision Science (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Related Child Applications (1)

Publications (1)

Family

ID=68240765

Family Applications (2)

Family Applications After (1)

Country Status (3)

Families Citing this family (17)

Family Cites Families (8)

• 2018
  • 2018-10-05 GB GB1816291.7A patent/GB2577751A/en not_active Withdrawn
• 2019
  • 2019-10-04 EP EP19787053.8A patent/EP3861494A1/de active Pending
  • 2019-10-04 EP EP21211948.1A patent/EP4002181A1/de active Pending
  • 2019-10-04 WO PCT/GB2019/052810 patent/WO2020070515A1/en unknown

Also Published As

Similar Documents

Legal Events