WO2021009496A1

WO2021009496A1 - Peer-to-peer network and method

Info

Publication number: WO2021009496A1
Application number: PCT/GB2020/051673
Authority: WO
Inventors: Pauline Geneviève Lucienne BERNAT
Original assignee: Atlas 3T Limited
Priority date: 2019-07-12
Filing date: 2020-07-10
Publication date: 2021-01-21
Also published as: GB201910000D0

Abstract

A peer-to-peer computer network (100) comprising: a plurality of peer computer nodes (102) in communication with one another, a distributed ledger database stored by the plurality of peer computer nodes, wherein the distributed ledger database comprises a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset, the distributed ledger database having a current ledger state comprising the plurality of identifiers and current balances; the plurality of peer computer nodes (102) adapted to exchange transaction messages over the peer-to-peer network, the transaction messages comprising at least two transaction entries, each transaction entry comprising an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component; a plurality of producer nodes selected from the peer computer nodes, a consensus algorithm operated by the producer nodes for processing said transaction messages to reach a consensus on at least one valid transaction message and, at intervals, producing an approved ledger state update comprising details of the at least one valid transaction message, the producer nodes transmitting the approved ledger state update to said peer-to-peer computer network; every peer computer node (102) updating said current balances in its version of the distributed ledger database according to the approved ledger state update; wherein each transaction message comprises a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively.

Description

PEER-TO-PEER NETWORK AND METHOD

FIELD OF THE INVENTION

At least some embodiments described herein relate to a peer-to-peer computer network, to a computer device, to a computer-implemented method for a peer-to-peer computer network, to a computer-readable medium, and to a transaction message for use in the peer-to-peer computer network.

BACKGROUND OF THE INVENTION

A distributed ledger database is a type of shared database that is distributed among participants and spread across computer nodes located at multiple sites and organisations. For example, a distributed ledger database may be implemented using a peer-to-peer computer network. A blockchain is a peer-to-peer, distributed ledger database that is cryptographically secure, append-only, immutable, and only updateable via consensus amongst peers. Whilst all blockchains are distributed ledgers, not all distributed ledgers are blockchains.

An advantage of a blockchain is that it is decentralised, meaning that there is no need for a trusted third party to validate transactions. Instead, a consensus mechanism is used to agree the validity of transactions amongst peers. Since anyone can inspect the blockchain it is transparent, which increases trust. Another advantage is immutability. Once a transaction is stored on the blockchain it is very difficult to change it.

Despite these advantages, blockchains also have a number of disadvantages. Two of these are scalability and privacy.

A first aspect of the scalability problem is the consensus mechanism. A consensus mechanism is a set of steps that are taken by some or all of the nodes to agree on a proposed state or value. The consensus mechanisms used by a number of blockchains and distributed ledgers rely on the Proof-of-Work (PoW) algorithm in which a proof is required that adequate computational resources have been spent before proposing a value to the network. Consensus mechanisms that use PoW rely on a plurality of nodes, called miners, competing to generate at fairly regular intervals of time a valid block of transactions to append to the blockchain. Part of the competition consists in solving a cryptographic puzzle that ensures the validity of the content of a block.

However, this competition amongst nodes wastes a tremendous amount of energy as all miner nodes expend computational power to solve the same problem, yet only the work performed by one node is used to update the blockchain. The energy consumption per year for Ethereum and Bitcoin combined is 66.6 TWh per year which is comparable to yearly energy consumption of Switzerland (61.6 TWh per year). It is clear that this is not sustainable or environmentally friendly. Moreover, as the difficulty associated with the cryptographic puzzle increases over time, miners are forced to invest in more computer resources (and therefore electrical energy) to have a chance of earning miner rewards. Consensus mechanisms that rely on PoW are inefficient in terms of energy usage and lack scalability.

A second aspect of the scalability problem is the size of the blockchain itself. One well-known example of a blockchain is Bitcoin. As of July 2019, the size of the Bitcoin blockchain is over 225GB. The size will only continue to grow as more transactions are validated and added to the Bitcoin blockchain. For the Bitcoin blockchain to function it is necessary that at least some of the nodes obtain and store the complete blockchain. Although there are so-called lightweight clients (e.g. Simple Verification Clients, SPVs) which may transact on Bitcoin without a full copy of the blockchain, the most secure approach for any node joining a blockchain is to be a‘full client’ in which a complete copy of the blockchain is obtained so that any previous transaction may be checked. For nodes to download, store and process hundreds of GBs of data is time-consuming and inefficient. Furthermore, the size of the blockchain limits the kind of computer devices that can take part in the Bitcoin network as full clients. Any device which is limited by communication bandwidth, memory storage space and/or processing power may not be able to be a full client in Bitcoin. Examples of such computer devices include, but are not limited to, smart phones, tablet computers, and single board computers such as the Raspberry Pi.

Turning to privacy an individual is anonymous when the individual cannot be named or identified through their public actions. It is a common misconception that public blockchains and distributed ledgers guarantee complete anonymity to the participants. Public blockchains like Bitcoin do offer a certain level of pseudo anonymity to their users through the digital address and keys holding the participants’ digital tokens. However, transactions recorded on a public blockchain are publicly available and reveal these digital addresses and the amounts exchanged between them. The token flow and therefore the activity of users is public information. By using techniques to cluster addresses into a single entity and extract a pattern it is possible to reveal the identity of an individual using the data available on such public blockchains.

SUMMARY

According to an embodiment a peer-to-peer computer network may comprise a plurality of peer computer nodes in communication with one another, and a distributed ledger database stored by the plurality of peer computer nodes. The distributed ledger database may comprise a plurality of identifiers and current balances of at least one digital asset, whereby each identifier may be mapped to at least one current balance of the at least one digital asset. The distributed ledger database may have a current ledger state comprising the plurality of identifiers and current balances. The plurality of peer computer nodes may be adapted to exchange transaction messages over the peer-to- peer network. The transaction messages may comprise at least two transaction entries. Each transaction entry may comprise an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component. A plurality of producer nodes may be selected from the peer computer nodes. A consensus algorithm or consensus mechanism may be operated by the producer nodes for processing said transaction messages to reach a consensus on at least one valid transaction message. At intervals, the producer nodes may produce an approved ledger state update which may comprise details of the at least one valid transaction message, and the producer nodes may transmit the approved ledger state update to said peer-to-peer computer network. Every peer computer node may update the current balances in its version of the distributed ledger database according to the approved ledger state update. Each transaction message may comprise a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively. In an embodiment a digital asset may be a token, which may be fungible and tradeable. In an embodiment a token may represent an asset, digital or physical. In another embodiment a digital asset may be a digital record, a digital file, or other digital object.

In an embodiment the distributed ledger database may be permission-less, meaning that no permission is required for a node to join the peer-to-peer network and participate in the distributed ledger management. In an embodiment the distributed ledger database may be permissioned, meaning that permission is required for a node to join the peer-to-peer network and participate in the distributed ledger management.

In an embodiment the consensus mechanism may be a distributed consensus mechanism, meaning that it is operated by different nodes across the peer-to-peer network and is able to reach an agreement on the ledger state update despite failure of some nodes and/or the presence of some malicious nodes.

In an embodiment each identifier of the plurality of identifiers may comprise a portion enabling the associated digital asset and/or current balance to be identified. In one embodiment, the portion may be a prefix or suffix of the identifier. In some embodiments the prefix or suffix may be a few bits or bytes in size.

In an embodiment each peer computer node may not require access to transaction messages contained in any earlier ledger state update to apply the most recent ledger state update to the current ledger state.

In an embodiment any one current balance may be mapped to only one identifier.

In an embodiment a first group of nodes may store at least one first portion of the identifiers and current balances of the current ledger state, and a second group of nodes may store at least one second portion of the identifiers and current balances of the current ledger state. Each node of the first group of nodes may be adapted to apply approved ledger state updates affecting current balances of said first portion, and each node of the second group of nodes may adapted to apply approved ledger state updates affecting current balances of said second portion. In an embodiment the digital signature of each transaction message may comprise a single aggregate digital signature capable of validating a first group of the transaction entries in a transaction message. The producer nodes may be adapted to validate each single aggregate digital signature of a respective transaction message.

In an embodiment the first group may comprise all of the transaction entries in a transaction message and the single aggregate digital signature. In an embodiment the transaction message may comprise unsigned transaction entries, and said producer nodes are adapted to validate said unsigned transaction entries.

In an embodiment the single aggregate digital signature may require only the public keys of the participants to validate the digital signature, such as a digital signature generated using a Schnorr-based aggregated signature scheme.

In an embodiment each peer computer node may be adapted to initiate construction of a transaction message by: generating a core transaction message comprising said at least two transaction entries; and generating a first partial digital signature for one of said at least two transaction entries. Each peer computer node may be adapted to send the core transaction message and said first partial digital signature to at least one other peer computer node, the at least one other peer computer node representing a participant for at least one of said transaction entries in the core transaction message for which a partial digital signature is missing.

In an embodiment each peer computer node may be adapted such that if it receives the first partial digital signature and a core transaction message for which a partial digital signature is missing the peer computer node may check the validity of the first partial digital signature. The peer computer node may generate a second partial digital signature for the missing partial digital signature, and may forward the transaction core message and the first and second partial digital signatures to at least one other peer computer node, the at least one other peer computer node representing a participant for at least one of said transaction entries in the core transaction message for which a partial digital signature is missing. In an embodiment each peer computer node may be further adapted such that, if a peer computer node receives a transaction core message where just one partial digital signature is missing, the peer computer node may check the validity of the or each partial digital signature accompanying the core transaction message. The peer computer node may create the missing partial digital signature and may generate said single aggregate digital signature using all of the partial digital signatures. The peer computer node may then generate the transaction message comprising the at least two transaction entries and the single aggregate digital signature, but not comprising any of the partial digital signatures, and may transmit the transaction message to said peer- to-peer network.

In an embodiment the consensus algorithm may comprise a set of computer- executable instructions stored by each producer node that, when executed, cause each producer node to generate a candidate ledger state update for the current ledger state. The instructions may cause each producer node to transmit the candidate ledger state update toward the other producer nodes for comparison with other candidate ledger state updates. The approved ledger state update for the current ledger state may be transmitted toward all the peer computer nodes only once a majority of the producer nodes have agreed on the same candidate ledger state update.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to gather a plurality of transaction messages and check the validity of the transaction message which includes a verification of the digital signature of each transaction message. Invalid transaction messages may be discarded. The instructions may cause each producer node, for each valid transaction message, to extract the transaction entries and then to construct a producer quantity (h_j) comprising a partial candidate ledger state update (DL_n,) including a list of the transaction entries extracted from the valid transaction messages. The producer quantity may then be transmitted to other producer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to re-order the transaction entries whereby links between transaction entries are blurred in the partial candidate ledger state update to improve anonymity, such as an alphanumerical ordering. In an embodiment the computer-executable instructions may be further adapted to cause each producer node to: combine each transaction entry with a salt; apply a hash function to the combination of the transaction entry and the salt to generate a hash variable; add each hash variable to a hash variable list; and to re-order the hash variable list.

In an embodiment, the computer-executable instructions may be further adapted to cause each producer node to extract each digital signature of each valid transaction message, to generate a compressed data structure comprising the digital signatures, and to include the compressed data structure in said partial candidate ledger state update. In an embodiment the compressed data structure may be a hash tree of the digital signatures. In an embodiment the computer-executable instructions may be further adapted to cause each producer node to apply a hash function to said partial candidate ledger state update to generate a first hash value ( h_Dj ), and to use said first hash value in said producer quantity. In an embodiment the computer-executable instructions may be further adapted to cause each producer node to include a peer identifier in said producer quantity, the peer identifier for identifying the producer node to the peer computer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to receive and store producer quantities generated and transmitted by other producer nodes, the list of transaction entries in at least one producer quantity possibly differing from the list of transaction entries in at least one other producer quantity. In an embodiment the computer-executable instructions may be further adapted to cause each producer node to search for matching partial candidate ledger state updates amongst the received producer quantities, and to determine the most common partial candidate ledger state update in the producer quantities. In an embodiment the computer-executable instructions may be further adapted to cause each producer node to determine if the most common partial candidate ledger state update appears in a majority of producer quantities.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate a first list ( L_j(prod )) of producer nodes who transmitted a producer quantity comprising the most common partial candidate ledger state update. The instructions may cause each producer node to generate a producer candidate ( C_j ) comprising (i) the most common partial candidate ledger state update, (ii) the first list of producer nodes and (iii) a peer identifier of the producer node generating the producer candidate, and to transmit the producer candidate to the producer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate said first list of producer nodes as a compressed data structure, such as a hash tree of the list of producer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to receive and store producer candidates generated and transmitted by other producer nodes, the list of transaction entries in at least one producer candidate possibly differing from the list of transaction entries in at least one other producer candidate.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to search for matching lists of transaction entries amongst the received producer candidates, and to determine the most common list of transaction entries in the producer candidates.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to determine if the most common list of transaction entries appears in the majority of producer candidates.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate a second list of producer nodes

who transmitted a producer candidate comprising the most common list of transaction entries.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to examine each first list of producer nodes accompanying each the most common partial candidate ledger state update, and to generate a third list ( L_n(prod )) of producer nodes, the third list comprising only those producer nodes present in at least a certain proportion of the first lists for resistance to manipulation of a ledger state update by a malicious entity. The certain proportion may be chosen according to the security of the peer-to-peer network. In networks that are perceived to be more secure (such as permissioned peer-to-peer networks, where nodes may only join the network when given permission by an authorisation and authentication server for example), the certain proportion may be a lower value than networks that are perceived to be less secure (such as public permission-less networks, where any node is free to join the network). In an embodiment of a permissioned network the certain proportion may be at least P/4 or P /3 for example, where P is the number of producer nodes. In an embodiment of a permission-less network the certain proportion may be at least P/2 for example.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate a fourth list ( L_CE ) of producer nodes, said fourth list comprising a list of rewards receivable by the producer nodes on the third list.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate a candidate ledger state update ( LSU_j ) comprising (i) the most common list of transaction entries in the producer candidates, (ii) the digital signatures of those transaction entries and (iii) the fourth list.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to generate a producer vote (v_j) for the ledger state update by applying a hash function to said candidate ledger state update to generate a second hash value

), the producer vote comprising (i) said second hash value, (ii) a compressed data structure representing said second list of producer nodes,

and (iii) the peer identifier of the producer node generating the producer vote, and to transmit the producer vote to the producer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to receive and store producer votes generated and transmitted by other producer nodes, the list of transaction entries in at least one producer vote possibly differing from the list of transaction entries in at least one other producer vote.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to search for matching second hash values amongst the received producer votes. The producer node may determine the approved ledger state update ( DL_n ) as the most common candidate ledger state update corresponding to most common second hash value.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to count and store the number of producer votes containing the most common second hash value.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to examine each second list

of producer nodes in the producer votes having the most common candidate ledger state update and to generate a fifth list of producer nodes. The fifth list may comprise only

those producer nodes present in at least a certain proportion of the second lists, namely the producer nodes who correctly computed the first hash value matching the most common list of transaction entries in their producer quantity. The certain proportion may be chosen according to the security of the peer-to-peer network. In networks that are perceived to be more secure (such as permissioned peer-to-peer networks, where nodes may only join the network when given permission by an authorisation and authentication server for example), the certain proportion may be a lower value than networks that are perceived to be less secure (such as public permission-less networks, where any node is free to join the network). In an embodiment of a permissioned network the certain proportion may be at least C_n/4 or C_n/3 for example, where P is the number of producer nodes. In an embodiment of a permission-less network the certain proportion may be at least C_n/2 for example. In an embodiment the computer-executable instructions may be further adapted to cause each producer node in possession of the approved ledger state update to store the approved ledger state update on the peer-to-peer network. The approved ledger state update may comprise an address where it can be accessed by peer computer nodes of the network. The instructions may cause each producer node to generate a producer output (o_j) comprising (i) the address of the approved ledger state update, (ii) the fifth list and (iii) the peer identifier of the producer node generating the producer output, and to transmit the producer output to the peer computer nodes.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to collect and store the producer outputs from different producer nodes. When the peer computer node has collected producer outputs in which more than a certain proportion contain identical addresses of the approved ledger state update and identical fifth lists, the address of the approved ledger state update may be used to obtain from the peer-to-peer network a copy of the transaction entries in the approved ledger state update.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to apply the transaction entries of the approved ledger state update to the current ledger state.

In an embodiment each current balance may represent at least one state of the digital asset, and the ledger state update may be intended to change the state of the digital asset recorded in the current ledger state. In an embodiment a state of a digital asset may be a probability, for example the probability that the digital asset has a particular feature or features. In an embodiment a state of a digital asset may be a number, for example a number representing the quantity of the digital asset. In an embodiment a state of a digital asset may be an attribute, for example a characteristic. In an embodiment a state of a digital asset may be an ownership of the digital asset or other data.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to apply a cryptographic technique to the amount components of the at least two transaction entries to generate at least two encrypted amount components, whereby a link between any two or more transaction entries is hidden and sending identifiers and receiving identifiers of digital assets are indistinguishable. The peer computer node may apply the cryptographic technique to each current balance stored in the current ledger state whereby the current ledger state comprises encrypted current balances.

In an embodiment the cryptographic technique in the computer-executable instructions may cause each peer computer node to obfuscate the amount components and current balances by application of a commitment scheme to each amount component. In an embodiment the commitment scheme may be a perfectly binding information commitment scheme.

In an embodiment the perfectly binding information commitment scheme may be binding under the discrete logarithm assumption. In an embodiment the commitment scheme may comprise a Pedersen commitment.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to check the validity of a transaction message by determining if the sum of the amount components listed in the transaction message are a commitment to zero to ensure no digital assets are created or destroyed by a transaction entry, and to determine if, after application of each transaction entry, the corresponding new current balance is positive but does not exceed a predetermined threshold.

In an embodiment the computer-executable instructions may be further adapted to cause each producer node to check the validity of a transaction message by applying a range proof to prove that the encrypted current balance remains within a predetermined range after application of the corresponding encrypted amount component in a transaction entry.

In an embodiment the cryptographic technique in said computer-executable instructions may cause each peer computer node to encrypt said amount components and said current balances using homomorphic encryption.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to add said encrypted amount components to said encrypted balances.

In an embodiment the cryptographic technique in said computer-executable instructions causes each peer computer node to encrypt said amount components and said current balances using elliptic curve cryptography.

In an embodiment the computer-executable instructions may be further adapted to cause each peer computer node to construct the encrypted amount component of a transaction entry using a cyclic generator group in the elliptic curve to represent negative numbers as positive numbers.

In an embodiment each identifier of said plurality of identifiers comprises a public key of public-private key pair constructed by an asymmetric encryption algorithm.

In an embodiment a computer device may comprise a processor, a network interface, and a memory. The memory may store computer-executable instructions that, when executed, may cause the computer device to join a peer-to-peer computer network comprising a plurality of peer computer nodes in communication with one another. The instructions may cause the computer device to obtain from the peer-to- peer network and store in the memory a copy of a distributed ledger database. The distributed ledger database may comprise a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset. The distributed ledger database may have a current ledger state comprising the plurality of identifiers and current balances. The instructions may cause the computer device to exchange transaction messages over the peer-to-peer network. The transaction messages may comprise at least two transaction entries, and each transaction entry may comprise an identifier and an amount component. Each transaction entry may be intended to change the corresponding current balance in the distributed ledger database by the amount component. The computer-executable instructions may further comprise a consensus algorithm or consensus mechanism that may be operated by the computer node. The consensus algorithm may cause the computer node to become a producer node for the peer-to- peer network. The consensus algorithm may cause the producer node to process the transaction messages to reach a consensus with other producer nodes on at least one valid transaction message. At intervals the producer nodes may produce an approved ledger state update comprising details of the at least one valid transaction message, and the producer node may transmit the approved ledger state update to the peer-to-peer computer network. The producer node may use a digital signature in each transaction message to validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively. The instructions may cause the computer device to update the current balances in its version of the distributed ledger database according to the approved ledger state update.

In an embodiment a computer device may be further adapted to permit said computer executable instructions to be transmitted via said network interface to another computer device, whereby said other computer device may install and execute said computer executable instructions and participate in said peer-to-peer network. In an embodiment the computer device may be a server or servers accessible by other computer devices. In various embodiments, the computer-executable instructions may be stored on a distributed file storage network, and/or a peer-to-peer file sharing network, and/or in a cloud-computing environment, and/or other remotely accessible location. In an embodiment, the computer executable instructions may be stored in various formats including source code, object code, bytecode or machine code.

In an embodiment a computer-implemented method for a peer-to-peer computer network, comprising a plurality of peer computer nodes in communication with one another, may comprise storing a distributed ledger database across the plurality of peer computer nodes. The distributed ledger database may comprise a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset. The distributed ledger database may have a current ledger state comprising the plurality of identifiers and current balances. The method may comprise exchanging transaction messages over the peer-to-peer network between the plurality of peer computer nodes. The transaction messages may comprise at least two transaction entries, each transaction entry comprising an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component. The method may comprise selecting a plurality of producer nodes from the peer computer nodes. A consensus algorithm or consensus mechanism may be operated by the producer nodes for processing said transaction messages to reach a consensus on at least one valid transaction message and, at intervals, producing an approved ledger state update comprising details of the at least one valid transaction message. The producer nodes may transmit the approved ledger state update to said peer-to-peer computer network. The method may comprise updating said current balances held by every peer computer node in its version of the distributed ledger database according to the approved ledger state update. Each transaction message may comprise a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively.

In an embodiment there is provided a computer-readable medium storing the computer-executable instructions defined above.

In an embodiment an electronic transaction message may be transmissible between peer computer nodes. The electronic transaction message may have a data structure. The data structure may comprise at least two transaction entries, each transaction entry comprising an identifier and an amount component. The data structure may comprise a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic representation of a distributed computer network for implementing some embodiments of the present invention;

Fig. 2 is a schematic block diagram of a computer device, or node, that may be used in the distributed computer network of Fig. 1;

Fig. 3 is a flowchart illustrating the process of a new node joining a distributed computer network operating a blockchain;

Fig. 4 is a flowchart illustrating general operation of a blockchain;

Fig. 5 is a schematic block diagram of a distributed ledger according to embodiments that may be stored across the distributed computer network of Fig. 1;

Fig. 5A is a schematic diagram of an account type that may be stored in the distributed ledger of Fig. 5, shown at a time t = t₀;

Fig. 5B is a schematic diagram of a transaction object comprising a set of valid transaction entries broadcast on the distributed computer network during time [t₀— Dt, t₀]; Fig. 5C is a schematic diagram of the account type of Fig. 5A at a later time t = t₀ + Dt after updating with the transaction entries of Fig. 5B;

Fig. 5D is a schematic diagram showing the structure of a transaction message; Fig. 6A is a flowchart illustrating the process of a new node joining a distributed computer network according to some embodiments;

Fig. 6B is a flowchart illustrating general operation of a distributed computer network according to some embodiments;

Fig. 7 is a schematic diagram showing worker pools and worker queues for nodes in embodiments of the distributed computer network;

Fig. 8A is a schematic diagram illustrating phases of a consensus algorithm in embodiments of the distributed computer network;

Fig. 8B is a schematic diagram showing some of the data objects that are created and transmitted in an embodiment of a consensus algorithm Fig. 9 is a schematic flowchart of the steps performed by a node in a construction phase of the consensus algorithm in embodiments of the distributed computer network;

Fig. 10 is a schematic flowchart of the steps performed by a node in a campaigning phase of the consensus algorithm in embodiments of the distributed computer network;

Fig. 11 is a schematic flowchart of the steps performed by a node in a voting phase of the consensus algorithm in embodiments of the distributed computer network

Figs. 12A - 12D are graphs illustrating the probability of successful control of more than 50% of Producer Nodes for varying numbers of malicious nodes;

Figs. 13A and 13B are graphs showing the minimum ratio of Producer Nodes to Worker Nodes to maintain the probability of a 51% attack below a threshold value, shown for different percentages of malicious nodes in a worker pool;

Fig. 14 is a graph showing how the confidence ratio varies with the number of Producer nodes for a fixed ratio of two types of first hash value;

Fig. 15 is a graph showing how varying the number of Producer Nodes affects whether or not a first hash value can be accepted with a certain confidence ratio; and

Figs. 16A and 16B are n-ary trees showing the minimum sets of parameters for different numbers of Producer Nodes.

DETAILED DESCRIPTION

In the description, the following meanings may be ascribed:

Account - a digital account may be a record of a class of digital assets (tokens) held by an entity (individual(s) or device(s)). It may be defined by a digital address, associated to a user's identifier, and may be a number (current balance) of digital assets. There may be several types of accounts in the distributed ledger. For instance a type of account may be a non-confidential account, within which the user's identifier is held, along with a current balance is readable by anyone. There may also be a confidential account, within which the user's identifier is held, along with a current balance that is obfuscated and held in the form of a commitment scheme.

Blockchain - a blockchain may be a peer-to-peer immutable decentralised ledger of information. It can be considered a decentralised or distributed database. Transactions created on a blockchain may be bundled together into blocks, which are linked together using the hash of the previous block. A blockchain may provide an indefinitely traceable history of all transactions that have taken place on the network.

Confidential Transaction - may be a transaction within which a number of tokens transferred may be hidden through the use of cryptographic commitment scheme. The validity of the transaction may still be checked without revealing the actual number.

Consensus Algorithm or Mechanism - a consensus algorithm may be a method for nodes in a distributed network to reach agreement on a set of proposed changes put forward by those nodes during a period of time. This may be used to change the state of the distributed ledger to reflect these agreed changes.

Digital Asset - a digital asset may be a medium of exchange used on the distributed ledger, enabling nodes (which may be controlled by users) to perform actions or making decisions on the ledger such as accessing services provided on the network or storing and retrieving files.

Digital Asset Class -a class of digital asset may be a token, the base currency of the ledger, or other digital objects.

Distributed File System (DFS) - may be a storage mechanism, within which there is no single point of storage, but in which data is stored in a distributed manner across nodes of a network. This may allow data to be stored in an efficient and distributed manner. DFS may be used to store data, files, and historical ledger state updates. DFS may be maintained by some nodes on the network. In order to locate content in the DFS a content address may be used.

Distributed Ledger Database - may be a database comprising records of digital assets, the database stored across a plurality of computer nodes and managed by at least some of those computer nodes.

Distributed Ledger Technology (DLT) - all blockchains are distributed ledgers, but not all distributed ledgers are blockchains. DLT may comprise a distributed ledger having no central source of storage. Embodiments may use a ledger-based system where updates are made to the ledger state of the distributed ledger at each ledger cycle. These updates are used to change the overall state of the ledger.

Identifier - may be a unique object or number that serves as pseudonym of an entity or group of entities (individual(s) or device(s)). An identifier may be a public key in the context of asymmetric cryptographic public/private key pair or a digital address derived from a public key.

Ledger Cycle - may be a fixed period of time after which the ledger state is updated using a consensus reached by Producer Nodes. It may comparable to the block time in traditional blockchain.

Node - may be a device connected to the other nodes (its peers) in a peer-to-peer network. A node could be a physical device, like a single-board computer, or running in a virtual machine or containers.

Pedersen Commitment - a cryptographic primitive that uses elliptic curve operations to obfuscate a value (or statement). The value is hidden to others but can be revealed.

Producer Nodes - may be a group of peers that have been selected to perform management work on the ledger for a specific ledger cycle. Producer Nodes may collect new tokens as reward for the work they performed.

Range Proof - may be used to determine the validity of a hidden value. The range proof may allow the user to demonstrate unequivocally that the value being declared is within a specified range, without revealing the actual value.

Smart Contract - may comprise computer executable instructions that define sets of rules and requirements and are deployed on a blockchain or a distributed ledger. Such compute instructions may be triggered by transactions or messages generated by other computer instructions, and/or once certain requirements have been fulfilled.

Token - a medium of exchange used on the distributed ledger, enabling nodes (which may be controlled by users) to perform actions on the ledger such as accessing services provided on the network or storing and retrieving files.

Transaction - may be a digital message broadcast on the network that represents the transfer of tokens to and from a set of identifiers. A transaction may be non- confidential (amount being transferred is visible to all) or confidential (amount in an entry is obfuscated using commitment schemes).

Worker Node - may be a node in the peer-to-peer network that has been granted a worker pass for a finite period of time which makes it eligible to contribute to the ledger database management. Worker Nodes may be selected at random to become a Producer Node for a ledger cycle.

Worker Pool - may be the group of Worker Nodes that have been granted a worker pass. Worker Queue - may be a queue of all the nodes that have declared themselves ready and capable of performing work for the ledger, yet have not been granted a worker pass. A worker pass allows nodes to move from the worker queue to the worker pool.

Some embodiments of the present invention may relate to a form of computer- implemented distributed ledger database which retains some of the advantages of a blockchain, but which addresses one or more of its disadvantages. It is important to note, however, that embodiments of the present invention are not only concerned with distributed ledgers. In particular, some embodiments of the present invention may have utility outside the field of distributed ledgers. In some embodiments the distributed ledger database may be a distributed database and the digital assets could be messages exchanged between participants to provide a secure communication channel, or could be electronic votes to provide a de-centralised decision making process.

The description is divided into the following sections, merely to aid understanding:

A. Specifications;

B . N etwork S tructure ;

C. Distributed ledger Architecture;

D. Joining the Peer-to-Peer Network;

E. Peer Roles, Node Registration and Worker Pools;

F. Transactions in the Peer-to-Peer Network;

G. Consensus Algorithm; and

H. Security.

A. Specifications This section provides an overview of some cryptographic libraries and tools that may be used in some embodiments to generate, sign and verify transactions, and that may be used in some embodiments of a consensus algorithm or mechanism.

A distributed ledger may be described as a distributed database managed by a peer-to-peer network of computers. Many forms of data, from simple text files to media files or bank accounts may be stored on a database. In a centralised network, a database is typically managed by a central computer or server and some part of the database is accessible to users. On the contrary, a distributed database is replicated across the peer- to-peer network, and each computer (or node) stores a local copy of the database. The database is no longer managed by a central authority but instead by a plurality of computers (or nodes) in the peer-to-peer network. The replication of the database across multiple nodes may reduce the vulnerability of single point of failure found with centralised databases. Users can exchange digital data stored on a distributed database via exchange requests, referred to as transactions. To generate an exchange of data, the transactions are signed by the owners of the data being exchanged. Nodes on the network agree on the validity of the transactions issued by users via a consensus-based protocol, thus authorising the transactions to take place and the database to be updated accordingly across the peer-to-peer network.

In embodiments a distributed ledger may rely on the generation of cryptographically secure ledger state updates in order to remove the need for a central authority. The ownership and exchange of data may be made possible via the use of asymmetric encryption where users hold public / private key pairs. The public key may be made visible to all users and is derived from the private key solely known by the user. Public keys may act as users' pseudonyms on the network. Knowledge of the private key may be necessary to successfully sign a transaction, the digital signature therefore proving ownership of the data being transferred to another user. While it may be impossible to derive the private key from a public key or digital signature (with classic computers) it is easy to verify, given a public key, that a signature could only have been generated by the user in possession of the associated private key.

Two common asymmetric cryptosystems are Rivest-Shamir-Adleman (RSA) and Elliptic Curve (EC). RSA's security relies on the difficulty of integer factorisation of large prime numbers. EC cryptography relies on the difficulty of the discrete logarithm problem. In embodiments a distributed ledger may utilise EC cryptography in preference to RSA due to the significantly smaller key size for the same level of security. In some embodiments EC-based private keys have a 256-bit size which provides a 128-bit security. An equivalent RSA-based key would have a 3072-bit size. A.1 Elliptic Curve In some embodiments Elliptic Curve (EC) cryptography may be used to sign messages and generate proofs of knowledge of information amongst users and nodes without having to reveal the information. In some embodiments EC points may be used for the creation of public keys and a perfectly binding commitment scheme, such as a Pedersen Commitment (PC) scheme. In embodiments EC cryptography techniques may be used to generate and verify the signature of a transaction encompassing the transfer of tokens from or to accounts locked by the private keys of users. In embodiments EC cryptography techniques may be used for the generation and verification of a range proof that any number (e.g. an amount of tokens) hidden in a PC can be provably shown to lie within a range of acceptable values.

There exist many types of EC that could be used, some of which are part of National Institute of Standards and Technology (NIST) curves. While the NIST curves, such as the secp256rl curve, are said to be chosen verifiably at random, there is little explanation for the seeds used to generate these. In contrast, the process used to pick non-NIST curves, such as the twisted Edwards Curve25519 used in Monero project, is fully documented and rigid enough so that independent verifications can and have been done. This is widely seen as a security advantage, since it prevents the generating party from maliciously manipulating the curve parameters. Moreover, EC such as Curve25519 are designed to facilitate the production of high-performance constant time implementations.

In some embodiments the twisted Edwards Curve25519 is used for EC points, that is a birational equivalent of the Montgomery curve Curve25519. It is defined over the prime field

where p = 2²⁵⁵— 19, by the following equation:

The order of Curve25519 can be expressed as N = 2^cl with c a positive integer and l a 253 -bit prime number. N is a 76-digit number equal to:

Elements in are 255-bit integers and can thus be represented in 32 bytes with the

most significant bit set to 0. An EC point on the twisted Edwards Curve25519 would therefore be represented with 64 bytes. But given point compression techniques described in Monero, it is possible to reduce an EC point to 32-bytes in size where 255 bits represents the x coordinate of the EC point and the last bit indicates the y coordinate.

In general terms, an EC of the form y² = x³ + ax + h is defined over a prime field where p determines the maximum values of x and y, the two coordinates of an elliptic curve point. The elliptic curve has a cyclic group of n points. An EC generator, G for instance, is an EC point itself generating a cyclic subgroup of order I_Q < n. This subgroup is composed of the set of points: {0G, 1 G, 2 G, . . . , (l_G - 1)G} with 0G = I_Q G known as the point at infinity. This subgroup is defined by the relation xG = (x mod I_G)G . The order of the subgroup l_G is a divisor of n. For instance, if n = 100, then l_G can take a value in {2,5,10,25,50}. Note that n can not be a prime number. If l_G = n, the subgroup of G includes all the points of the EC.

A.2 Hashing Algorithm

Hashing may refer to computer-implemented algorithms used to obfuscate data by generating a summary of the data, or hash, in such a way that the original data cannot be restored using the hash, i.e. the hashing function is a one-way function. The hash may be used to prove knowledge or ownership of the original data. A hashing function may generate a pseudo-random string of fixed length from a data of arbitrary length. The hashing algorithm is said to be collision-resistant when the probability to generate the same hash from two different data is negligible. Furthermore, a hashing algorithm has the property that two similar data will lead to very different hashes. In other words, knowledge of a collection of hashes does not allow an entity to acquire knowledge about the original data from which the hashes were generated.

In some embodiments the Blake2b-256 (or simply Blake2b) hashing algorithm may be used. The Blake2b algorithm produces a 256-bit strings and is known to be amongst the fastest hashing algorithms and may be particularly suitable for mobile applications. Other hashing algorithms could be used such as Keccak (also known as SHA-3) or SHA-256. Throughout the remainder of the document, the hashing function is referenced by the symbol

.

A.3 Zero-Knowledge Proofs

Confidential transactions on blockchains enable the transfer of tokens between digital addresses (or identifiers) in such a way that the amount or number of tokens exchanged is hidden, offering more privacy to the users. The amount is obfuscated by using a Pedersen Commitment (PC). A PC is of the form C = vH + bG where G and H are two distinct generators of the EC, v is a number of tokens hidden in C and b is the PC mask, sometimes referred to as a blinding factor.

In some embodiments, a PC may be used to obfuscate a balance of tokens v_i of an account stored on the distributed ledger. The PC may have the following form: C_t = V_iH + b_iG and obfuscates the balance ,

with M the maximum number of tokens defined in the distributed ledger). The balance may be hidden using a blinding factor . The generators G and H may be two different base points of

the same subgroup of EC points such that the discrete logarithm is preserved, i.e. the x value in the relation xG = H (or xH = G) is unknown. As a result, the two EC points V_iH and b_iG are added to form a valid EC point, e.g the Pedersen Commitment. As mentioned above, the PC size may be 32 bytes.

Given the cyclical property of an EC, a PC of the form C = vH + bG can be rewritten as:

C = ( v mod I_h)H + (b mod I_g)G where l_G is the order of the generator G (or number of points on the elliptic curve defined over G ) and l_H is the order of generator H.

In embodiments the use of PC may provide a cryptographically secure method to mask an amount spent (or received) in a transaction. Furthermore, the sum of the PCs in a transaction may be used to prove that the sum of the amounts spent and received in a transaction amounts to 0 tokens, i.e. the transaction does not create or destroy tokens. For example, assume a transaction with n PCs, the sum of the amounts spent and received must verify:

In embodiments the cyclical nature of elliptic curve may be exploited to allow for both positive and negative numbers of tokens to be indicated within a PC. The negative numbers may be positive and very large. For example a user sending 5 tokens may create a commitment including a negative amount—5 as follows: C = ( l_H— 5 mod I_h)H + (b mod l_G)G. The ability to use both positive and negative numbers in digital transactions is advantageous. Indeed it may offer an improved anonymity solution to users as the nature of a transfer embedded in a commitment (whether it consists in spending or receiving tokens) need not be specified in a transaction. The group of commitments in a transaction may simply be added together in order to verify no new tokens are created (or tokens destroyed) in the transaction.

Since OH = I_HH, it may be possible for a user to generate a PC with a very large number of tokens, with the malicious aim to create new tokens while producing a valid PC sum. In order to address this problem, embodiments may use range proofs to check PCs in a transaction. Range proofs enable a user to prove that an amount lies within a specific range of values without revealing the amount. In some embodiments the range of values chosen for a range proof is [0, L] where L represents an upper limit on the number of tokens (L « l_H).

Confidential transactions may have some disadvantages compares to non- confidential transactions, such as an increase in transaction size and in the generation and verification times. Inclusion of a range proof with a PC may be the main cause of an increase in transaction size. This may lead to a lack of scalability and a significant increase in transaction fees compared to non-confidential transactions. In some embodiments the Bulletproof protocol may be used to generate range proof for confidential transactions on the distributed ledger (see B. Bunz et al., Bulletproofs: Short proofs for confidential transactions and more. https://eprint.iacr.org/2017/1066.pdf, 2019). Bulletproof is a zero-knowledge proof protocol proposing an improved inner product argument algorithm which results in a greatly reduced size of the range proof associated to a PC. While traditional range proof sizes are typically linear in the bit-length n of the range proof (where L = 2ⁿ), Bulletproof provides a significant saving by creating range proof where only [2 log₂ (n) + 9] group and field elements are required. Moreover, Bulletproof protocol allows generation of aggregated range proofs with a size that grows logarithmically in the number of commitments, offering a faster batch verification time.

A.4 Tokens name and units

Embodiments may employ tokens that are tradeable amongst users by means of the distributed ledger. The tokens may be a medium of exchange to facilitate the sale, purchase or trade of services on the network. Such trades take place via the use of transactions created by nodes and broadcast on the peer-to-peer network. A token may derive its intrinsic value from the development and use of the peer-to-peer network and hence provides utility for both work undertaken by Producer Nodes and use of the peer-to-peer network.

Tokens may be divided into smaller units. For example the smallest amount may be 0.0000000000001 token, or a thousand-billionth of a token.

In some embodiments the tokens may be utility tokens and may aim to provide users with access to services supported by decentralised applications and Smart Contracts.

In some embodiments the transfer of tokens between user accounts (which may be represented by identifiers) may be embedded in transactions. The transactions may be processed by Producer Nodes on the peer-to-peer network which are tasked with verifying the transactions and using these to produce a valid update to the balances of these accounts stored on the distributed ledger. The ledger database may be frequently and securely updated to account for these token transfers. Embodiments may utilise a consensus algorithm to incentivise nodes on the network to contribute to the distributed ledger management, offering them tokens as reward for their work. This reward may comprise two components: a) tokens paid by the users issuing transactions and directly debited from their accounts, in the form of transaction fees; b) new tokens injected (or released) into the system. B. Network Structure

Referring to Fig. 1 a distributed computer network 100 comprises a plurality of computer devices 102 in communication with one another. The computer devices 102 may be geographically dispersed, for example within a country, region or around the world. Communication between computer devices is shown by paths 104, although it is to be noted that the communication is usually not direct between the computer devices. The physical network topology between any two of the computer devices may comprise other computer devices (e.g. routers, switches, satellites) and physical media (e.g. wired, wireless, optic fibre) between any two of the computer devices 102 across which communication is established. For example communication between at least some of the computer devices 102 may take place over the Internet.

B.1 Computer devices or nodes

Fig. 2 illustrates some of the hardware components of one of the computer devices 102. In particular, the computer device 102 may be a digital computer which may be in many different forms. For example, the computer device 102 may be in the form of a server computer, a desktop computer, an application specific integrated circuit (ASIC), a mobile computer device (e.g. smartphone, smartwatch, tablet, wearable computer device), laptop or notebook computer. In some embodiments the computer device may be a cloud computer. In such embodiments, data storage and computing power are provided from one or more data centres accessible over the Internet. The data storage, computing power and any other functions that are required can be distributed over multiple locations from different servers at one or more different data centres. In other embodiments the computer device 102 may be in the form of a virtual machine.

The computer device 102 may comprise a housing 202. The housing 202 may house a number of hardware components including a central processing unit (CPU) 204, a random access memory (RAM) 206, a storage memory 208, and a network interface 210. These components may be connected so that the CPU 204 may send data to and receive data from the network interface 210, amongst other functions. The computer device 102 may comprise a power supply 212 which may comprise a power supply unit (PSU) if the computer device is powered by mains electricity, or the power supply 212 comprise a battery if the computer device 102 is in the form of a smartphone, smartwatch, laptop or notebook for example. The computer device 102 map comprise a display 214. In some embodiments the display 214 is part of the computer device 102 (e.g. a touchscreen on a phone or tablet). In other embodiments, the display 214 is external or remote from the computer device 102. The computer device 102 may comprise an input/output 216 to which hardware peripherals may be connected.

The computer device 102 may store an operating system in the storage memory 208. The operating system may be Unix or Unix-like, a Linux operating system, macOS, Windows, or a BSD operating system. In some embodiments the computer device is a mobile computer device and the operating system is one of the many available mobile operating systems such as iOS, Android, Chrome OS, Ubuntu Touch, etc.

Although the phrase‘computer device’ has been used above, this document will also refer to a computer device in the peer-to-peer computer network 100 as a ‘node’ and the two terms are intended to be synonymous.

B.2 Peer-to-peer network

Referring again to Fig. 1 the nodes 102 may be organized in an unstructured peer-to-peer computer network topology in which a virtual overlay network may be formed on top of the physical network topology. The computer devices in the overlay may be a subset of the computer devices in the physical network. In the peer-to-peer computer network data may be exchanged directly over the underlying TCP/IP network, but at the application layer the nodes 102 may be able to communicate with each other directly, via the communication paths 104 or logical overlay links (each of which corresponds to a path through the underlying physical network). In this way the peer-to-peer computer network may be independent from the underlying physical network topology.

B.3 Blockchains

To help understanding of some embodiments of the present invention, it is imagined that the peer-to-peer network 100 is used to operate a blockchain. Figs. 3 and 4 are flow diagrams illustrating the process of a new node 102 joining a blockchain network, this example the Bitcoin network, and the processes performed by nodes in the Bitcoin network respectively. It is assumed that the new node joining the network wishes to be a‘full node’ meaning that it may perform all actions on the blockchain network, i.e. wallet, mining, full block chain storage, and network routing functions. Referring to Fig. 3, a new node 102 firstly obtains and installs the Bitcoin Core client at step 302. The Bitcoin Core client is a suite of software that enables the new node 102 to join and participate in the Bitcoin network and is available at htps://bitcoin.org/eii/download for example. In particular the Bitcoin Core client enables each node running the client decide which block chain contains valid transactions, and to broadcast that on the Bitcoin network.

At step 304 the new node 102 finds other nodes (or peers) in the Bitcoin network. At step 306 the new node 102 downloads the entire blockchain data set from the Bitcoin network. The new node 102 must download the entire blockchain in order to validate new transactions and new blocks to be appended to the blockchain. As of July 2019 the Bitcoin blockchain exceeded 225GB in size, and will continue to increase in size.

At step 308, the new node 102 creates a private key and a public key, with the latter being used to derive a bitcoin address that can be used by the node 102. Once a bitcoin address has been created the new node 102 may transact with bitcoin. In step 310, the new node 102 may generate transactions and send them into the bitcoin network, and will also validate and relay transactions created by other nodes in the network.

Referring to Fig. 4 the outer rectangle 400 illustrates a process performed by all nodes, and the inner rectangle 410 illustrates a process additionally performed by miner nodes in the Bitcoin network. At step 402 a node receives new transactions from other nodes in the Bitcoin network. At step 404 the node verifies each transaction; if valid, the transaction is relayed to other nodes at step 406.

Blockchains rely on at least some nodes in the network operating a consensus mechanism, the purpose of which is to reach agreement on the final state of data when the nodes may not trust one another and/or when one or more nodes have failed, and then to propagate the agreed data around the network. In some public permission-less blockchains (e.g. the Bitcoin network), the consensus algorithm used is Proof of Work (PoW). A PoW-based consensus mechanism relies on proof that adequate computational resources have been spent before proposing a value for acceptance by other nodes in the network. In this way, it becomes much harder for an attacking node to alter the blockchain (to enable a double- spend of a token for example). The computational operations followed by a node under PoW are widely known as‘mining’ in the context of the Bitcoin network and requires a mining node (or miner) to solve a computationally difficult puzzle before proposing the next block of data to the Bitcoin network. Referring again to Fig. 4, when a transaction has been verified by a node in step 404, it is stored by that node in its ‘mempool’ at step 408. Each node has a mempool, or memory pool, in which transactions which have been verified are stored pending inclusion in a new block by a miner. At step 410 the miner generates a new block of transactions and begins the mining process at step 412 in which it attempts to solve the puzzle for the new block of transactions. In particular, the miner combines a random nonce value with the new block of transactions and then hashes the new block. If the hash value is less than a target hash value (step 412), the miner broadcasts the result to other nodes in the Bitcoin network and the new block is appended by all nodes to the blockchain at step 416. However, if the hash value is higher than the target hash value, the miner tries a different nonce value and the process is repeated either until the solution is verified or until the miner learns a solution from another miner.

C. Distributed ledger Architecture

Putting aside the Bitcoin network mentioned above, embodiments described herein may relate to a distributed ledger stored by the nodes 102 in the peer-to-peer network 100. A function of the distributed ledger may be to store an identifier, such as a public key or an identifier derived from a public key, such as a digital address, mapped to a current balance of a digital asset owned by that identifier. The digital assets may be divided into classes (one class being tokens for example). Each digital asset class may itself be divided into account types, for example one account type comprising non-confidential current balances and another account type comprising confidential current balances. The distributed ledger may be updated from time-to-time to change a current balance if there is one or more valid transaction transferring some or all of the digital assets from a set of one or more identifiers to another set of one or more identifiers. The validity of a transfer may be tested by production of a digital signature proving ownership of at least one of the identifiers in the transaction, and in some embodiments by production of a digital signature corresponding to each identifier in the transaction. In this way, the distributed ledger may only be required to store the current number of digital assets for each identifier, and does not need to store some or all of the transaction history. Furthermore, the distributed ledger may enable low resource computer devices to participate in at least some of the functions of the peer-to-peer network 100, but without compromising on data integrity or accessibility. An example of a low resource computer device is the Raspberry Pi which has approximately lGHz CPU, 1 - 4 GB RAM and stores an operating system and data on a micro SD card. However, it should be noted that this is not an exclusive meaning of a‘low resource’, and other computer device architectures could also be considered low resource.

Fig. 5 illustrates the structure of the distributed ledger 500 which has a multi- levelled data architecture. Although the structure of the distributed ledger is shown on a single drawing, it is important to note that this structure may not be stored on every node 102 in the peer-to-peer network 100, but is stored in a distributed manner across those nodes. The distributed ledger may comprise three levels: a top level 502, a middle level 504 and a bottom level 506. As a minimum requirement, all nodes 102 in the peer-to-peer network 100 may store the top level of the database. In addition to the top level 502 all nodes may also store the middle level 504. In addition to the top level 502 and the middle level 504 some nodes may also store the bottom level 506. Nodes that may store the middle level and/or the bottom level 506 may utilise a distributed file system (DFS), illustrated by dashed line 508. In this way the memory storage requirements may be reduced in the peer-to-peer network 102 compared to the memory storage requirements of a blockchain network as described above. Furthermore, since each node may be required to store only the top level 502 of the distributed ledger, participation in the peer-to-peer network 100 may be open to nodes with smaller physical or available memory storage capacity than is required for some blockchains, such as Bitcoin.

The top level 502 of the distributed ledger 500 may comprise a current ledger state (CLS). In order for the distributed ledger 500 to function, it is not necessary for the CLS to record any previous transaction that changed the current balance of each digital asset in the CLS.

Referring to Fig. 5A, the CLS in the top level 502 is shown at time t₀. There may be n unique identifiers, 510. In some embodiments each identifier 510

may be a public key controlled by one or more users. In some embodiments, each identifier 510 may comprise an address that is derived from a public key that is controlled by one or more user. This particular snapshot of the CLS illustrates one account type (non-confidential) for m digital asset classes.

In one embodiment a digital asset may be a token, which may be fungible and tradeable. In another embodiment a token may represent an asset, digital or physical. In another embodiment a digital asset may be a digital record, a digital file, or other digital object.

The CLS stored by each node may be updated from time-to-time, which may be at predetermined intervals or may be when certain conditions are met. In some embodiments the CLS may updated at the end of a certain period of time called a ledger cycle. In some embodiments, a ledger cycle may last between about 30 seconds and about 1 minute.

An update to the CLS is called a ledger state update (LSU). As will be described in greater detail below, a LSU may be generated by a pool of nodes (Producer Nodes) selected to manage the distributed ledger. The LSU may be distributed to the all nodes 102 on the peer-to-peer network 100. Each node 102 may apply the LSU to update their local copy of the CLS. The process followed by Producer Nodes to generate a LSU is described in detail below.

Fig. 5B illustrates the concept of how a transaction may cause a LSU. A transaction set 515 is generated in the time interval t₀ + Dt and may comprises two valid transactions, in this case a first transaction 517 within which identifier A₁ transfers 2 tokens to A_n, and a second transaction 519 within which identifier A₄ transfers 13 tokens to identifier A₅ and identifier A₆. If at least some of the nodes 102 in the network 100 find the transactions valid, they will be included in a LSU 521. The LSU 521 may comprise a list 523 of identifiers affected by the LSU and a list 525 of the changes to be applied to the CLS. As can be see, all of the identifiers affected by the two transactions are included in the list 523. The LSU 521 indicates that nodes 102 should change the CLS by adding -2 tokens to the current balance of A₁ and by adding +2 tokens to the balance of A_n. The LSU 521 indicates that nodes 102 should change the CLS by adding -13 tokens to the current balance of A₄, by adding +8 tokens to the balance of A₅, and by adding +5 tokens to the balance of A₆. All nodes 102 in the network 102 apply the LSU 521 to their local version of the CLS.

Referring to Fig. 5C the top level 502 of the distributed ledger 500 is shown at time t₀ + Dt after the LSU 521 has been applied to the CLS. Comparing Fig. 5 and 5C it can be seen how the current balances 513 of each identifier 510 affected by the LSU 521 have changed. Following application of the LSU 521, the CLS shown in Fig. 5C does not contain any link to the underlying transactions 517 and 519.

Referring again to Fig. 5 the middle level 504 of the distributed ledger 500 may comprise one or more recent LSUs, that is a number of recent LSUs accepted by Producer Nodes and broadcast across the peer-to-peer network 100. How many recent LSUs (i.e. the middle level 504) of the ledger database are stored by a node may be determined by each node, for example according to available hardware storage space and decided individually by a node (or the user of the node). In some embodiments there may be a minimum number of LSUs required to be stored.

Eventually every LSU may be stored in the bottom level 506 of the distributed ledger. Both middle and bottom levels may be maintained by a Distributed File System (DFS) module. The top and middle levels sit on every node on the peer-to-peer network and are thus immediately accessible. The bottom level 506 may be maintained by some but not necessarily all nodes in the peer-to-peer network 100. In this way historic data may be available with a short delay whilst the CLS maintained by every node is relatively compact. In some embodiments, the CLS may be less than about 1Gb for 50 million non-confidential accounts.

C.1 Digital Asset Classes and Account Types in the Distributed ledger

As shown in Fig. 5, the distributed ledger 500 may comprise different digital asset classes 530 and there may be up to m digital asset classes.

Furthermore, each digital asset class 530 may comprise any number of account types that are stored the CLS and for which adjustments are indicated in LSUs. Fig. 5 shows an example of some different account types that may be stored for a digital asset:

• Non-confidential user-based accounts 514, or standard accounts, with a current balance 513 of the digital asset 530. Fig. 5A shows some non-confidential accounts across some of the digital asset classes, where those digital assets support non-confidential accounts (not all digital assets may support non- confidential accounts). In a non-confidential account, each current balance 513 may be visible to all nodes 102 in the peer-to-peer network 100.

• Confidential user-based accounts 516, with a current balance 510 of the digital asset 530. Confidential accounts are not illustrated in Fig. 5A. The current balance 510 may be hidden, and only known to the account holder(s). Updates to the current balance are also confidential.

• Smart contract-based accounts 518. A smart contract-based account may comprise an associated code that can be triggered by transactions or messages generated by other codes. Smart contract-based accounts are not illustrated in Fig. 5A.

The different account types used for each digital asset 530 may be called ‘partitions’. A node 102 in the peer-to-peer network 100 may not maintain a copy of every partition but may remain aware of the possible dependencies among partitions.

Referring to Fig. 5A each account type may comprise the following components:

• An identifier 510: a 21 -byte identifier A_i, which may be derived from a public/private key pair { Q_i, k_i } (where (Q_i = k_iG, and G is an EC generator point) using a collision-resistant hash function

. The last 20 bytes of the hash may be used to create the identifier 510. A 1-byte prefix may be added to each identifier to help distinguish which current balance of which digital asset class each identifier 510 is mapped to.

• A current balance 513: when the account is non-confidential, the or each current balance 513 may be an 8-byte number . If the digital asset class is

tokens, the current balance is a number of tokens (with M a threshold on the maximum number of tokens). When the account is confidential, the current balance 513 may comprise a 32-byte Pedersen Commitment C_i = V_iH + b_iG that hides the current balance v_i of the account using a blinding factor

·

• An optional data component: reserved for smart contract-based accounts and which may used to store data, or a reference to data stored on Distributed File System. In one embodiment this optional data component may be 64 bytes in size.

C.2 LSU Structure

As described above the CLS may comprise one or more digital asset class, each of which may comprise one or more account types (or partitions). Each account type may comprise n identifiers 510, each identifier

mapped to a respective current balance 513. Each current balance 513 may be up-to-date according to any changes indicated in the LSU issued at the end of the ledger cycle. For non-confidential accounts any node 102 may access any current balance 513 of any identifier held in the account.

When users of the peer-to-peer network 100 wish to transfer digital assets to other users, they may issue transactions that are broadcast to the nodes 102 in the network 100. The structure of these transactions is discussed in greater detail below. The transactions may be collected by so-called Producer Nodes assigned to the management of the ledger database and used to generate a LSU. The production of valid LSUs in a trust- less environment is also discussed section G. The LSU may be a cryptographically secure structured data object that allow nodes 102 to update their local copy of the CLS.

As described above with reference to Fig. 5B a LSU may comprise a summary of the digital asset transfers embedded in valid transactions broadcast by the nodes 102. Transactions broadcast during a ledger cycle may be collected by Producer Nodes who may use these to generate a LSU during the next ledger cycle. An LSU may be viewed as a structured database comprising a series of rows, each row having two components: an identifier referring to the address of an account stored in the CLS and an amount (positive or negative) that represents a digital asset transfer. In some embodiments, the identifier may comprise a public key.

In the following example, it is assumed that the distributed ledger 500 comprises a single digital asset class, in this case tokens. Within each account type each identifier 510 is mapped to a single current balance 513. Assume that Alice wishes to transfer 5 tokens to Bob. The transfer may be represented by a transaction with two entries, and the LSU may include two rows: one with Alice's identifier Ai and a negative amount -5 and one with Bob's identifier A2 and a positive amount 5 (transaction fees are ignored for this example). When a node 102 receives a valid LSU, the local copy of the CLS is updated to include the transaction: -5 tokens is applied to the current balance associated with Alice's identifier A;, and +5 tokens is applied to the current balance associated with Bob's identifier A2. Note that the LSU produced for any ledger cycle may only include balance changes of identifiers 510 named in valid transactions broadcast on the peer-to-peer network 100 during one or more earlier ledger cycle. This may enable a compact LSUs as there may be many more identifiers stored in the CLS that are not updated during a ledger cycle.

Returning again to the Bitcoin network example above, transactions may comprise data objects created and cryptographically signed by users and propagated as messages on the peer-to-peer network 100. Generally each input to the transaction spends an output of a previous transaction. Thus a Bitcoin transaction typically includes:

• a set of inputs where each input comprises a so-called Unspent Transaction Output, UTXO, of an earlier transaction. Each input includes a hash of the previous transaction with the UTXO, the value of the UTXO, and the unlocking script which satisfies the requirements of the locking script of the UTXO, i.e. that the digital address claiming to be able to spend the UTXO has the ability to do so.

• a set of outputs where each output comprises the number of tokens (in Satoshis) to be transferred, and the locking script itself. The locking script ensures that only the digital address for which the transfer is intended is able unlock the script and spend the tokens in a future transaction. In the Bitcoin network a digital signature associated to a transaction input allows the owner of the associated private key to prove (via the unlocking script) that they have authorised the spending of the funds locked in the output of a transaction stored somewhere in the blockchain. A valid signature further guarantees the non-repudiation of the message (the sender cannot deny having sent the message) and the message integrity (the latter has not and cannot be tampered with).

In the Bitcoin blockchain, valid blocks of transactions are appended to the blockchain in such a way that any new block is cryptographically sealed and linked to the last block appended to the blockchain. A block contains a set of transactions that transfer tokens from a set of digital addresses to another set, as well as an extra transaction, called coinbase transaction, that rewards the miner who successfully produced that block with new bitcoin. Each transaction input contained in a valid block (except the coinbase transaction input) refers to the output of a transaction stored on a previous block. First the output is unspent, locked and stored on a valid block. Secondly, the output is used as input in a new transaction and unlocked by the owner of the unlocking key. Eventually an old block in the blockchain will solely contain spent transaction outputs usable as inputs in transactions stored in other later blocks. As such the old block becomes obsolete as it no longer holds any spendable tokens.

As will be clear from the description above, the distributed ledger 500 stored on the peer-to-peer network 100, and in particular the CLS, may operate differently in the sense that nodes 102 do not store unspent transaction outputs. The nodes 102 may only be required to store the or each current balance 513 mapped to the corresponding identifier 510 in the CLS. The or each current balance 513 may change over time as LSUs are received containing valid transactions which transfer a digital asset and thereby debit or credit one or more of the current balances 513. A LSU is not sent if there are no valid transactions within a ledger cycle. Once a LSU is used to update the CLS, the LSU is stored on DFS and can be accessed by any node 102 as it is either locally stored or accessible upon request to special nodes storing historical data (i.e. the middle level 504 and/or bottom level 506). Of note, User Nodes may not need access to old LSUs to be able to apply future LSUs to the CLS that they hold.

The Distributed File System (DFS) used in the peer-to-peer network 100 may comprise an implementation of the Interplanetary File System (IPFS) protocol, a peer- to-peer distributed file system. DFS may be used to store files as well as previous LSUs. This may remove the burden on user nodes to maintain the full history of the distributed ledger 500 while allowing for fast retrieval of files as well as old ledger state updates. DFS may be maintained by all nodes 102 in the peer-to-peer network 100. However, DFS may comprise a multitude of compartments and each node 102 may not be required to hold all compartments.

The design of a ledger compartment dedicated to the storage of files and historical LSUs (in DFS) is an approach taken to prevent the bloating of the ledger and allow the network to support services at scale. This may allow the distributed ledger 500 to remain both lean and cryptographically secure. As described in more detail below, some embodiments may not need to rely on unspent transaction outputs to keep track of tokens. Instead, a transaction object utilized in the distributed ledger 500 may comprise cryptographic signatures of the participants in each transaction, thereby providing authorization and enabling nodes in the network to validate the transaction.

D. Joining the Peer-to-Peer Network Referring again to Fig 1, in order to join and participate in the peer-to-peer computer network 100, each node 102 may execute a computer program, details of which will be described in greater detail below. The computer program may be provided as a component of the operating system of the node 102, or may be installed by any node 102 that wishes to join the peer-to-peer computer network 100. The computer program may be in the form of application software that may be downloaded as an executable file from one or more remote node 106 (e.g. server) and installed by the node 102. Fig. 1 shows that node 102 may obtain the application software from one remote computer device 106 that may not be part of the peer-to-peer computer network 100. In other embodiments the or each remote computer device 106 may be part of the peer-to-peer computer network 100. In other embodiments one or more of the nodes 102 in the peer-to-peer computer network 100 may provide another node 102 (wishing to join the network 100) with the application software by means of file sharing application software.

Fig. 6A illustrates the process 600 of a new node 102 joining the peer-to-peer network 100. Once the new node 102 has obtained the application software, it may be installed on to the new node 102 at step 602. Following installation of the application software, the node 102 may execute the software to enable it to join the peer-to-peer network 100 and take part in the functioning of the distributed ledger 500 as will be described below.

At step 604 the new node 102 may find other nodes or peers in the peer-to-peer network 100 with which to communicate with. To that end the application software may include a peer-to-peer communication module, a peer identification module and a peer discovery module.

Fig. 6B illustrates the steps 620 that may be performed by nodes 102 once they have joined the network 100. Steps inside the box 630 may be performed only by certain nodes, called Producer Nodes (to be described below), that are tasked with producing a LSU. At step 622 a node 102 receives transactions from other nodes in the network. At step 624 a node verifies the validity of each transaction, and at step 626 will forward only transactions that are found to be valid to its peers.

Producer Nodes store valid transactions in their mempool at step 632 and at step 634 each generates a proposed LSU which is transmitted to other Producer Nodes. At step 636 the Producer Nodes collaborate to vote on and agree the most popular LSU. At step 638 the Producer Nodes approve the LSU, store it on DFS and begin to transmit the corresponding DFS address to nodes 102 across the network 100. At step 640 all nodes 102 in the network apply the LSU to their local copy of the CLS.

Further details of the steps shown in Fig. 6A and Fig. 6B will be described below.

D.1 Peer-to-Peer Communication Module

The peer-to-peer communication module may comprise computer-executable instructions that, when executed, enable each node 102 to communicate with other nodes 102 who have joined the peer-to-peer network 100. The peer-to-peer communication module may enable electronic messages (including but not limited to transaction messages) to be propagated across the peer-to-peer computer network 100. The peer-to-peer communication module may comprise a protocol that enables nodes 102 to receive messages in a timely manner, for example with a low latency such as within about 100 to 500 microseconds. Upon execution, the peer-to-peer communication module in the application software may cause each node 102 to implement a gossip-type communication protocol (also known as an epidemic communication protocol) in order to propagate messages amongst other nodes 102 in the peer-to-peer network. Gossip-type protocols may propagate messages through a network by relying on each node to communicate with their neighbours. Since the peer- to-peer network 100 may be ad-hoc (in the sense that nodes 102 can join and leave at will), the gossip protocol may ensure that data and messages are routed to all nodes 102 in the network 100. When the gossip protocol is run by the computer devices 102, each computer device may propagate messages to a number of its connected peers, randomly chosen amongst computer devices in the peer-to-peer computer network 100. As each node 102 receives that message they may propagate the message their peers. This may allow the message to spread rapidly with a high level of coverage across the peer-to-peer computer network 100.

D.2 Peer Identification Module The peer-to-peer identification module may comprise a peer identification module. The peer identification module may be implemented by each node 102 in the peer-to-peer computer network 100. Each node 102 that joins the network 100 may be assigned a peer identifier that describes the identity of that particular node. This may allow other nodes 102 to track the node 102 and may permit the other nodes 102 to associate a reputation to the node 102 to track badly performing nodes. A peer identifier may comprise the following set of parameters:

• Client ID - a 2-byte number to differentiate test networks from live network

• Client Version - a 2-byte version number of the application software running on a node

• IP - a 16-byte IP address, IPv4 or IPv6

• Port - a 2 byte port number

• Public Key - a 32-byte public key

Each peer identifier on the peer-to-peer computer network 100 may be unique. Use of the peer identification module by each node 102 may allow the peer-to-peer computer network 100 to assign a reputation to any peer identifier. The reputation of a node 102 may be determined by how its peer identifier is formed. To maintain a good reputation, each node 102 may need to respond correctly to requests from other nodes 102 in the network 100. For example a first node 102 may send the IP: Port number chunk of a second node 102, and the second node 102 may be required to respond with an associated public key. The node reputation may decrease if the wrong public key is provided or if the second node 102 is not available, while a correct response may be rewarded by an increase in reputation.

D.3 Peer Discovery Module

As mentioned the application software may further comprise a peer discovery module. The peer discovery module may comprise a Metropolis-Hastings Random Walk with Delayed Acceptance (MHRWDA) protocol. When a new node 102 joins the peer-to-peer computer network 100, it connects to one of the other nodes 102 at random (the randomly selected node 102 called a‘seed peer’). In one embodiment seed peers may be hard coded into the application software obtained and installed by each node 102. The new node 102 then performs a random walk through the peer network, recording discovered peers only after an initial burning period. This algorithm may reduce the chance of revisiting previously checked nodes, as well as reducing any bias towards nodes which have a large number of peers.

Referring again to Fig. 6A which illustrates a new node 102 joining the peer- to-peer network 100, at step 606 the new node may obtain the CLS for some or all partitions of the distributed ledger. As mentioned above, all nodes 102 in the network 100 may store the CLS and the middle level 504 of the distributed ledger, and the new node may simply request neighbour nodes to send the CLS. The new node may also wish to obtain one or more recent LSUs, and/or one or more historical LSUs. As described above, some nodes 102 in the network store the bottom level 506 of the distributed ledger in DFS. The new node 102 may send requests to the peer-to-peer network 100 to obtain the copies of the recent and/or historic LSUs.

At step 608, the new node 102 may generate an identifier At 510 as described above, or the user of the node 102 may import an identifier 510 generated previously. Once the node has generated (or obtained) the identifier 510, the user of the identifier may control the node 102 to transact on the peer-to-peer network 100. At step 610, the node 102 may participate in the peer-to-peer network 100 as a User Node (described in more detail below) by receiving and validating transactions from the network, and relaying valid transactions to other nodes.

The node 102 may determine that it is willing to perform work for the peer-to- peer network 100. In some embodiments whether or not a node 103 is willing to work can be set in the application software by a user. If the node 102 is willing to work, the node may submit proof of its available computing resources at step 612 and become a Reservist Node, or register to be a Worker Node and join a worker pool, which is described in greater detail below.

E. Peer Roles, Node Registration and Worker Pools

E.1 Peer Role Types

As well as identification, the peer identification module may allow each node 102 to check the roles of other nodes 102 in the network 100. In particular nodes 102 in the peer-to-peer network 100 may assume one or more roles, including:

• User Node - the default state of all nodes 102 in the peer-to-peer network 100.

The role of a user node may be to receive transactions, check the validity of each transaction and, when valid, forward to their peer nodes. User nodes may also generate transactions and observe the network 100. However, they may neither be entitled nor required to perform any other work in the network 100.

• Reservist Node - may be a node 102 that has signaled its intent to perform work for the network 100 and which may have provided proof of its available computing resource that can be dedicated to the network 100.

• Worker Node - may be a node 102 that has been granted a worker pass for a finite period of time.

Producer Node - may be a Worker Node that has been selected to perform work for a particular ledger cycle. A Producer Node may be rewarded for performing good quality work by receiving tokens.

• Storage Node - may be a node 102 able to sell some of its spare storage to allow other nodes 102 to store their data (e.g. recent LSUs and other data such as files) in a decentralised manner.

All nodes 102 on the peer-to-peer network 100 may receive transaction messages, validate and forward these transaction messages to other nodes 102 that they are connected with. This is to allow efficient propagation of transaction messages across the network.

As mentioned above, optionally the node 102 may be able to perform work for the peer-to-peer network. If the node 102 wishes to perform work for the network, the node may submit proof of available computing resources at step 512 and may register to join a worker pool as described below. The submission may be made to one or more other nodes 102 that store a distributed hash table of registered nodes.

E.2 Proof of computing capabilities

Nodes 102 may utilise a benchmark that measures performance of central processing units, such as CoreMark (https://www.eembc.org/coremark/). CoreMark produces a single number score enabling quick comparisons between processors of the nodes 102.

E.3 Node registration to be Worker Node

Fig. 7 illustrates the process of a node registering to join a worker pool 700. The node 102 firstly sends a request to the network 100. Nodes storing the distributed hash table of registered nodes may add the node to the table, and return a score to the node 102. The score may be an integer value that increases in an incremental manner. For example the first node to join would receive score 1 , the second node would receive score 2, etc. Eventually the score would be reset and start from 1 again. The worker pool 700 is shown at times t, t + D_t and t + 2 D_t. The state of a primary queue, or worker queue 702, is shown at the same time intervals. By providing proof of their available computing resources to the peer-to-peer network 100, nodes 102 may immediately join the worker queue 702. Every node on the network 100 may store such proof alongside the respective peer identifier in a first distributed hash table ( DHT_q ).

Upon registering to perform work, each node 102 becomes a Reservist Node and may be placed at the back of the worker queue 702 where it must wait to be given a worker pass. The list of nodes in the worker queue 702 may be stored in the first hash table DHT_q that is ordered chronologically according to the time at which each node joined the worker queue. Nodes in the worker queue 702 may be granted a worker pass strictly in order, i.e. on a First-in-First-Out (FIFO) basis. There may be no limit to the number of nodes which may join the worker queue 702.

Thus the worker pool 700 may be a plurality of nodes that have been granted a worker pass and therefore is a sub-set of all the nodes 102 in the peer-to-peer network 100. Worker passes are granted for a period of time and then expire. When a worker pass expires, the node loses its Worker Node statues and leaves the worker pool 700. In an embodiment the worker pool size N may be approximately at least 2000. The list of peer identifiers of Worker Nodes in the worker pool 700 at any time may be maintained in a second distributed hash table ( DHT_w ) stored across all nodes in the peer-to-peer network 100. At the end of a ledger cycle, any nodes in the network may deduce which worker passes have expired, and each node may update their local copy of the hash table DHT_w. If any slot(s) is freed, that may be taken by the next node(s) waiting in the worker queue 702.

In theory a Sybil-identity attack may be possible on the peer-to-peer network 100 if an entity controls a large number nodes 102 at the top of the worker queue 702 (at least equal to half the worker pool size N/2) and frequently adds many nodes to the worker queue such that the size of the worker queue is large enough to create an impression of a large demand for work.

In one embodiment steps may be taken to reduce the chance of a successful Sybil attack and incentivize nodes 102 to join the worker queue 702 during periods of low demand for work. A ranking (or score) may be given to each node when it joins the worker queue. Nodes in the worker queue can then be ordered based on their ranking in descending order, so that the nodes with the lowest ranking are at the top of the worker queue 702 and are the first nodes to leave the worker pool and join the worker pool 700 when some slots in the worker pool are freed. The method to assign a ranking is not chronological. Instead the method may depend on the volume or flux of nodes trying to join the worker queue 702 during same allotted time period D_t Nodes wanting to join the worker queue 702 during the time widow [t, t + At] may be placed in a secondary queue. At the end of the time period, a fixed number of nodes, equal to the number of nodes who left the worker pool a t, from the secondary queue may be randomly selected. These nodes may be given a ranking drawn from a normal distribution centred on a predetermined threshold of the worker queue, which means that some selected nodes may obtain a ranking higher than nodes currently at the bottom of the worker queue 702. The rest of the nodes in the secondary queue may be given a lower ranking drawn from a normal distribution, centred around a lower rank value shifted from the threshold of the worker queue, the shift being proportional to the volume of nodes in the secondary queue.

As mentioned above, nodes registering to join the worker queue 702 are assigned a score and ordered according to their score. The worker queue may comprise a threshold 704 having a score R_q which divides in the worker queue 702 into a first portion 706 and a second portion 708. Nodes registering to join the worker queue which have a score lower than R_q may be assigned to the first portion 706 of the worker queue 702, and nodes registering to join the worker queue which have a score higher than R_q may be assigned to the second portion 708 of the worker queue 702. In the example of Fig. 7 there are four nodes at time t having a score higher than the threshold 704.

In the time interval [t, t + D_t] a first group of nodes 710 may try to register to join the worker queue 702. Since there are nodes in the worker queue 702 with scores below the threshold, the first group of nodes 710 may be stored in a secondary queue being a list DHT_S separate from the worker queue 702. The list DHT_S may have a length S_t which may be equal to the number in the first group of nodes. In this example, at time t there are j Worker Nodes leaving the worker pool 700. In this particular example j = 3. Following that j randomly selected nodes (labelled A, B, and C in the example of Fig. 7) in the first group of nodes 710 may be randomly assigned a score according to a normal distribution 712 centred on the value R_q of the threshold 704. The remaining nodes in the first group 710 (all referenced D in the Fig. 7 example) are also randomly assigned scores, but centred on a value R_t which is function of value R_q and length S_t of list DHT_s. The first group of nodes 710 may then be permitted to join the worker queue 702. As shown in Fig. 7, each node in the first group of nodes 710 is placed at a position in the worker queue 702 according to its randomly assigned score.

During the time interval [t + D_t, t + 2 D_t] a second group of nodes 714 may try to register to join the worker queue 702. The length of the list DHT_S is now S_{t+ Dt}. At time t + D_t, j =5 Worker Nodes leave the worker pool 700 and the five nodes at the top of the worker queue 702 take their place in the worker pool 700. The second group of nodes 714 are then assigned scores in a similar way to the first group, and are permitted to join the worker queue 702 at the correct position.

E.4 Selection of Producer Nodes from the Worker Pool

A worker pass may grant a node 102 the right to become a Worker Node and a member of a worker pool 700 for a finite period of time. During this period of time, which may include more than one ledger cycle, the Worker Node may have a chance of being randomly selected to become a Producer Node for any ledger cycle. The Producer Nodes may be the nodes 102 that build LSUs, as described in greater detail below.

The selection of Producer Nodes from the worker pool may be achieved for each ledger cycle using a randomised approach. Since a Producer Node may generate a LSU for a ledger cycle based on transactions collected during the previous ledger cycle(s), such selection may be revealed at least one cycle ahead. For example, assume that at the beginning of a ledger cycle C_n at time t = t_{n 0}, a pseudo-random number r is drawn using the Merkel tree root, or other digest of the LSU produced one cycle before (C_{n- 1}) as a seed to pseudo-random number generator (PRNG). The pseudo- random number r is used to define the list of Worker Nodes selected to become Producer Nodes for the next ledger cycle C_n+1 in the following way: for each Worker Node with a peer identifier Idi the quantity

is defined, where

is an XOR function (for binary -based modulus addition). The list of new peer identifiers

(N is the total number of Worker Nodes in the worker pool 700) is sorted in ascending order and the first P identifiers in that list are the nodes selected to be Producer Nodes {P_j}_jÎp for the cycle C_{n+ 1}. If the peer-to-peer network 100 is large, for example more than about 2000 Worker Nodes, (a significant proportion of nodes 102 may meet the requirements for available computing resources in order to be a Worker Node and a Producer Node. In that case many nodes may register to join the worker pool, i.e. there is a high demand for work. As there may be more nodes willing to work than required for the worker pool 700, nodes may join the worker queue 702 and wait to be called to join the worker pool. In order for these nodes to join the worker pool 700, there may be a mechanism that controls the time period during which a node 102 can be a Worker Node. As mentioned above, each Worker Node may be granted a worker pass and each worker pass may be valid for a limited period of time.

F. Transaction Messages in the Peer-to-Peer Network Transactions may be messages broadcast by users of the nodes 102 on the peer- to-peer network 100 that encompass the transfer of digital assets such as tokens between at least two identifiers 510 stored in the CLS. In other words there must be at least one identifier sending tokens and at least one identifier receiving tokens, so that the sum of the tokens sent and received in a transaction sums to zero.

F.1 Transaction Types

A transaction may comprise a digital message having a data structure (hereinafter transaction message). Such a transaction message may comprise different types of transfer depending on the types of account involved in the transaction. Generally a single transaction message may comprise multiple transaction entries, but all entries relate to one account type for one class of digital asset. As mentioned in section C.l, the distributed ledger 500 may comprise different digital asset classes, each class being operated with one or more account type, such as a non-confidential account, a confidential account and a smart contract-based account. Specific transaction components (described below) of a transaction message may allow any node 102 on the network 100 to differentiate between transactions that affect each type of account.

F.2 Transaction Structure Nodes 102 may co-operate to compile transaction messages in the peer-to-peer network 100. A transaction message may comprise the following components:

• A transaction type field specifying the account type affected by the transaction entries in the transaction message (for example non-confidential or confidential asset transfer, data storage request and retrieve, smart contracts- related token and/or data transfer).

• A timestamp field corresponding to the point in time where the transaction message is complete and ready to be broadcast on the network.

• A set of n transaction entries . Transaction entries may be specific

to the digital asset class and the account type indicated in the transaction type field.

• An aggregated signature T proving ownership of the set of identifiers called in the transaction entries.

• A locking time field corresponding to a point in time after which the transaction can be processed by a worker pool.

• The transaction fees paid by the transaction participants.

• A data field that may contain data transferred in data storage or smart contract- related transactions.

In order to be valid a transaction message may be required to contain a transaction type, a timestamp and locking time (the latter is set to 0 if there is no waiting period prior to processing a digital asset exchange embedded in the transaction message), a list of transaction entries and an aggregated signature. Another field of fields can be included in the transaction message, depending on the nature of the token exchange.

F.3 Transaction Entries

Transaction entries may be used in transaction messages to represent a requested change to one of the current balance(s) 513 of the associated identifier 510 in the CLS of distributed ledger 500. This may take the form of debit or credit of the current balance 513. There may be no differentiation within a transaction entry between a debit or credit of a current balance 513 other than in the amount to be transferred. Whether spending or receiving tokens, a user may sign their transaction entry and a transaction may be considered complete if and only if all transaction entries have been signed. Accordingly the presence of a transaction entry in a transaction message does not guarantee that the CLS will be updated until the transaction entry has been validated and accepted in a LSU agreed by Producer Nodes in the network.

A transaction entry in a transaction message may comprise two components:

• A public key, from which an identifier 510 stored in the CLS may be derived; and

• An amount component that may be a number or a more complex structure and represents the amount of tokens (or other quantity representing a digital asset class) spent from or transferred to the identifier 510 associated to the public key.

In a transaction entry a number or amount of tokens may be positive (when receiving) or negative (when spending). This may allow for (a) keeping a simple transaction entry structure (since there may be no need for an extra field to specify the type of transfer embedded in a transaction entry); and (b), in the case of confidential asset transfer, there may be an improved anonymity as an observer will be unable to differentiate between a sender and a recipient in the transaction entry.

The public key Q_i in transaction entry E_i may always be a 32-byte element from which one identifier 510, A_i, stored in the CLS can be derived by application of a hash function

to the public key Q_i. The amount component of a transaction entry may differ depending on the nature of the digital asset exchange:

• For non-confidential asset transfer, the amount component may be an 8-byte (positive or negative) number

that represents the number of tokens spent from or transferred to the identifier A_i, communicated in clear text.

• For confidential asset transfer, the amount component may comprise two elements:

o A 32-byte Pedersen Commitment

that represents the commitment of tokens spent from or transferred to the identifier A_i o A range proof

(as discussed in section A.3) that proves that the current balance 513 of the account associated with the identifier A_i remains within an acceptable range of value (typically greater than 0 and smaller than a threshold M of number of tokens) after the transaction has taken place.

The balance of the identifier A_i may be represented initially in the CLS by the Pederson Commitment (PC):

where bi is a mask, also refer to as blinding factor, chosen by the owner of the identifier A_i, and l_H and l_G are the order of the elliptic curve generator points H and G respectively. Assume that the owner wishes to transfer or receive a_i tokens to the identifier A_i. To obfuscate the amount of tokens transferred in a transaction entry E_i, the node 102 controlled by the owner creates a first PC representing the transaction:

where

if receiving the tokens (a_i > 0) and if spending

the tokens ( a_i < 0).

Given the properties of the Elliptic curve, l_H is much greater than the threshold number of tokens, M, in the second case. As a result, it would not be possible to construct a valid range proof for . The User Node 102, U_t, may create a second PC:

defined as:

This may represent the new PC of the current balance 510 after the transaction has taken place. If spending the tokens

. It is only possible to generate a valid range proof associated to the new . Note that v_i is necessarily smaller than M (the

threshold number of tokens) as the balance of the account would have been determined by a previous transaction entry, itself including a range proof that v_i Î [0, M] . As discussed in A.3, a range proof generated using the bulletproof protocol amounts to 672 Bytes.

Fig. 5D shows one embodiment of the different components of a transaction message and their respective sizes, including transaction entries for non-confidential and confidential transactions.

As mentioned above, each transaction entry in a transaction message may need to be cryptographically signed to authorise the transfer of tokens (or other digital asset). This may be achieved through the use of an aggregated signature scheme as described below.

Another type of transaction entry may be used, namely a stand-alone entry. It is not included in a transaction message but is added to the LSU generated by the Producers Nodes during the ledger cycle and includes the reward allocated to a specific Producer Node for its contribution in producing a valid LSU. Such entry, which may be referred to as a ledger compensation entry (or simply compensation entry), is similar to a non-confidential entry. It comprises an 8 -byte amount or number of tokens, that is however always positive, and a 32-byte public key from which the address of an account stored on the ledger is derived. However, unlike a transaction entry, a compensation entry need not be signed to authorise the transfer of tokens to the account address specified.

F.4 Confidential transaction message example By way of example consider a simple case in which Alice, holder of an account

Acc , is transfering 5 tokens to the account Acc₂ held by Bob. Transaction fees are ignored and both accounts are confidential so the current balances are hidden or obfuscated. To assist understanding, small numbers are used in the example for token amounts and blinding factors. In reality, these numbers would be very large, ensuring the required level of security provided by elliptic curve cryptography is achieved. Alice's account Acc₁ is defined by:

• C₁ = v₁H + b_tG, where v₁ represents the current balance and is the blinding factor of .

· derived from her public key

.

• In this example, we chose the following values: v₁ = 13 and b₁ = 27, leading to C₁ = 13 H + 27 G.

Bob’s account Acc₂ is defined by:

• C₂ = V₂H + b₂G, where v₂ represents the current balance and b₂ is the blinding factor of C₂.

•

derived from his public key .

• We chose the following values v₂ = 2 and b₂ = 11, leading to C₂ = 2 H + 11 G.

To initiate the transfer of 5 tokens from Alice to Bob, the following steps take place:

• Alice choses a random blinding factor

and creates a new Pedersen Commitment obfuscating the amount of tokens

transferred to Bob, tokens giving .

• Alice then creates a second , representing the balance of her account

Acc , v_a', after sending 5 tokens to Bob’s account Acc₂:

o

• Bob choses a random blinding factor

and creates a new P

obfuscating the amount of tokens transferred to his account Acc₂ by Alice: o

.

• Bob then creates a second PC that represents his current balance, v_2l, after receiving 5 tokens:

o

Two conditions must be fulfilled in order to create a transaction with valid entries (ignoring the users' signature at this stage):

1. The difference between the first two PCs created by Alice and Bob that obfuscate the amount of tokens transferred in the transaction,

, must be a commitment to 0 in

, proving that no new tokens are created (or destroyed) in the transaction.

2. The new balance of the accounts Acc₁ and Acc₂ following the transfer of 5 tokens must be positive, yet not exceed the threshold M.

The second condition can be met by building a range proof on and , as discussed

in section A.3.

E_i and E₂ are the two transaction entries created to represent the token exchange between Alice and Bob. They are defined by the sets:

and

, where

represents a range proof of x generated for the entry E_i, proving that the amount of tokens hidden in x lies within a range of values. At this stage, the transaction message m is then composed of the pair of entries: m = {E_lt E₂}. We later discuss the generation of the transaction signature, proving Alice and Bob respective ownership of the accounts Acc₁ and Acc₂, of which the addresses are respectively derived from the public keys Q₁ and Q₂.

At this stage, a distinction was made between a transaction entry spending tokens and a transaction entry receiving tokens. Indeed, the

constructed by Alice was computed differently to that of Bob,

. We have realised Alice could create a different PC for her token transfer and compute her new balance by adding rather than subtracting from C₁. This would enable Alice and Bob to use the same set of

operations to produce their new current balances.

We have realised that negative numbers (token amounts or blinding factors) may be represented as positive numbers when used to multiply a generator, given the cyclic property of the generator group. For instance,

is written as

. Because l_G is a very large number, l_G— 5 is close to modulo number l_G. Using this property one can commit to a negative number and create the transaction entry as follows:

which implies that Alice commits to—5 tokens. Alice’s new current balance

can be rewritten as follows:

The multiplier of H does not change since OH = I_HH, while the number multiplying G changes since the two bliding factors are now added.

The condition (1) for a valid transaction would be fulfilled by adding together the two PCs obfuscating the amount transferred via the transaction, in order to preserve a commitment to

. Since the transaction commitment is now obtained via the sum of the PCs in the transaction entries, we rename DC^t to åC^t, to highlight the summation of PCs. In this example

.

A benefit of building transaction entries with this approach is that it removes the need for additional information within the transaction to specify whether a current balance should be debited or credited when updating the accounts on the ledger state. This means that Alice could initiate a transaction that would result in her current balance increasing and Bob's decreasing. The direction of digital asset flow is indistinguishable to anyone else on the network, so the sender and receiver are hidden from anyone but the transaction participants. This may offer an extra layer of privacy.

F.5 Transaction Signatures

In the distributed ledger 500, all the transaction entries may be signed to authorise the transfer of tokens listed in a transaction message. Only once all the participants in the transaction have signed their respective transaction entry may a transaction message be considered complete. When signing a transaction entry E_i a participant may need to prove ownership of the identifier Q_i referred to in the transaction entry. In other words, the participant needs to prove knowledge of the private key k_i paired to the public key Q_i from which the identifier A_i is derived. In this way any node 102 in the peer-to-peer network 100 may verify the validity of the signature given the public key Q_i specified in a transaction entry E_i.

Signatures for a transaction entry in a transaction object may be formed in a similar way regardless of whether the asset transfer embedded in the transaction entry is confidential or non-confidential. The signature scheme described below may apply to both transaction types unless explicitly stated.

In blockchains such as Bitcoin and Ethereum, transaction inputs are signed using an ECDSA scheme, where a public key is recovered from the signature and used to retrieve the account or UTXO address, thus ensuring that the rightful owner of the tokens is authorised to spend these. The use of a second temporary, often called ephemeral public/private key pair in the signature adds a layer of protection against malicious attempt to retrieve the private key of a user when signing multiple transactions spending tokens from the same address.

We have realized that public key recovery is not compatible with batch validation, i.e. it is not possible to recover a set of public keys from an aggregated signature on multiple transaction inputs. In some embodiments a Schnorr-based signature scheme may be used to enable multiple users to use their private keys to produce an aggregated signature for a transaction message.

As described above, the transaction message may comprise a set of n transaction entries {Ei}_{i=1 ,.. n} and additional information X, but excluding the transaction timestamp. We may define a core message m of the transaction message as:

A user or participant U_i (holder of the identifer A_i), and responsible for transaction entry E_i, creates the following challenge:

where:

•

is the hashing function described in section A.2

• m is the transaction core message

• II denotes the concatenation between strings • is the aggregated public key such that:

• L is the hash of all the public keys used in the transaction expressed as

It will be noted that the transaction message may comprise the transaction core message, i.e. all transaction entries. However, the transaction entries are not complete and require addition of partial signatures by each participant in the transaction as described in more detail below.

The participant U_i may then create the following partial signature:

where r_i is a pseudo-random number chosen by participant U_i using a node 102 and kept secret.

Recall that each transaction entry E_i in a confidential transaction includes a PC obfuscating the amount component

defined by

. For a confidential transaction the pseudo-random number r_i may be defined as

where d_i is a pseudo-random number chosen by participant U_i and kept secret.

The node 102 creates a tuple (s_i, R_i combining the partial signature s_i and R_i = r_iG. The tuple (s_i, R_i may then be forwarded to the other nodes 102 representing transaction participants. In order to check the validity of the partial signature the node 102 controlled by each participant U_k(k ¹ i) in the transaction entry can use the public key Q_i of participant U_i to compute:

where Q_i = k_i · G. Recalling that s_i · G = r_i · G + e_i · k_i · G, where k_i · G = Q_i, if the node determines that , the validity of the partial signature s_i is verified.

This process may be repeated between participants in the transaction. In short, each participant spending tokens must create a partial signature and each participant receiving tokens must create a partial signature. For any one transfer of tokens between two participants, the transfer cannot be validated until each participant has created a partial signature and incorporated it into the transaction message. In this way nodes 102 in the network build each transaction message using partial signatures of the participants who wish to send and receive tokens (or other digital asset). The node 102 controlled by the last participant may complete the set of partial signatures by adding their own partial signature. Having done so, that node 102 may build the aggregated transaction signature T for the entire transaction message. The aggregated transaction signature T_NC of a non-confidential transaction is composed of the pair:

Having compiled the aggregated transaction signature T_NC, the node 102 may add T_NC to the‘aggregated signature’ field of the transaction message, add the time stamp and begin transmitting the complete transaction message to other nodes in the network for validation.

When a node 102 in the network 100 receives the transaction message it may check the aggregated transaction signature T_NC of any non-confidential transaction object as follows:

1. Compute the list of n challenges

given the public keys embedded in the transaction entries {Ei}_{i=1 ,.. n} included in the core message m of the transaction object;

2. Compute the quantity

3. Verify that R' = R_i

If the node finds (3) true, the aggregated transaction signature T_NC = (s, R) is valid. The transaction signature may comprise a 32-byte integer and a 32-byte EC point, being a compact 64-byte signature for the entire transaction object. The aggregated transaction signature T_C of a transaction message containing confidential transaction entries may be defined differently, although its structure may be the same as that of a non-confidential transaction. Using the public key pairs {D_t = d_i G }_{i=1 ,... ,n}, the transaction signature T_C may comprise the pair:

When a node 102 in the network 100 receives the transaction message it may check the transaction signature T_C of any confidential transaction object by computing:

If

, the aggregated transaction signature T_C = (s, D) is valid. The validity of T_C proves to the node 102 that the sum of the Pedersen Commitments in the transaction entries results in a commitment to zero after adding the transaction fees paid by the different participants, thus ensuring that no tokens are created or lost in the transaction message. F.6 Transaction Message Validity

Nodes 102 in the peer-to-peer network 100 may receive and forward transaction messages to their peers. In order to prevent spamming attack over the network, nodes 102 may only forward transaction objects that are considered valid against a validity check list. Before forwarding it to its peers, a peer may verify each transaction object against the following list of criteria:

• The transaction message syntax and data structure must be correct.

• The transaction message size in bytes is greater than or equal to 160 bytes (defined by a parameter MIN_STD_SIZE for non-confidential transaction) or 800 bytes (defined by a parameter MIN_CON_SIZE for confidential transaction).

• The transaction message size in bytes is less than 1 Mbyte (defined by the parameter MAX_STD_SIZE or MAX_CON_SIZE depending on the transaction type).

• The list of transaction entries in the transaction message must comprise at least two elements (i.e. sender and receiver), and each element must have a correct syntax.

For a non-confidential transaction, an individual transaction entry E_i must have a total size of 40 bytes and must comprise 2 components: o A public key Q_i (stored in a 32-byte field) corresponding to an identifier A_i stored in the CLS where the identifier A_i has at least one current balance 513 (an 8-byte field).

o An amount component (stored in an 8 -byte field) that once

added to the balance v_i of the identifier 510 mapped with the public key leaves the current balance positive

For a confidential transaction, an individual transaction entry E_i must have a total size of 736 bytes and 3 components:

o A public key Q_t (stored in a 32-byte field) corresponding to an identifier A_i stored in the CLS where the identifier A_i has at least one current hidden balance 513 (a 32-byte field).

o A 32-byte Pedersen Commitment

o A 672-byte range proof must validate against a new Pedersen Commitment comprising the sum of

and the hidden balance C_i associated to A_i.

• A transaction fee amount v^f is greater than a (positive) minimum fee values MIN_TX_FEE

• The relation must be verified for a list of non-confidential

transaction entries.

• The aggregated transaction signature must validate against the public key built out of the public keys stored in the transaction entries, as explained above in the section F.4

Verification of the range proofs in the transaction object is costly in computer resources, and may therefore be performed only by Producer Nodes.

G. Consensus Algorithm Embodiments of the consensus algorithm may utilise the principle that every node 102 participating in the peer-to-peer network 100 may contribute to LSUs and may be rewarded accordingly. In particular:

· every node 102 may not need to validate every transaction message for the network 100 to be secure and a ledger fully decentralised.

• collectively across a network of nodes 102 there may be significant distributed computer resources to securely maintain the distributed ledger 500. Network performance may improve as the network scales up.

Embodiments of a consensus algorithm may not be based on a competitive process. Instead, the nodes 102 in the network 100 may collaborate to collectively build the correct LSU. The consensus algorithm operated by nodes 102 to produce a valid LSU may not require the execution of computationally expensive tasks, allowing nodes with limited resources to contribute. At the end of a ledger cycle, new tokens may be injected into the peer-to-peer network 100 and all the nodes (a sub-set of the Worker Nodes) that contributed to producing the correct LSU may receive a share of those tokens. As mentioned above, nodes 102 that contribute to maintaining the ledger state are called Producer Nodes (rather than miners). In the consensus algorithm Producer Nodes may not solve a computationally hard problem, but instead may validate transaction messages broadcast to the network 100 and use these to collaboratively build (produce) a LSU.

Fig. 8A shows an embodiment of the consensus algorithm 800. The consensus algorithm 800 may comprise the following phases during each ledger cycle 802:

1. a construction phase 900 (described with reference to Fig. 9);

2. a campaigning phase 1000 (described with reference to Fig. 10);

3. a voting phase 1100 (described with reference to Fig. 11);

4. a synchronisation phase 1200.

In the embodiment described below the distributed ledger 500 may comprise one single account type, or partition, comprising a fixed set of identifiers. Furthermore the account type is non-confidential in this example. In this embodiment there is one single worker pool 700 and one subset of Producer Nodes selected from the worker pool per ledger cycle. In some embodiments, there may be different worker pools for different account types and/or digital asset classes.

The Producer Nodes may be tasked with generating the approved LSU for the or each partition of the ledger database. As such the Producer Nodes may select and group transaction messages according to the partition. In order to do that the Producer Nodes may group transaction messages by examining the transaction type field in each transaction message.

Fig. 8B shows the various messages that are generated by Producer Nodes during the phases of the consensus algorithm, and Fig. 8B should be referred to during the following description of each phase.

Referring again to Fig. 8A a ledger cycle 802, C_n, starts at time t = t_n,0 and lasts for a period of time Dt_cycle, therefore ending at t = t_n,0 + Dt_cycle. P Producer Nodes {P_j}_jÎp are selected to build the LSU during the ledger cycle C_n. Each Producer Node P_j can be identified by its peers as well as the rest of the network via its peer identifier Id_j in the list DHT_w, described above.

During the ledger cycle 802 C_n the P Producer Nodes collaborate to create a LSU DL_n based on the set of m_n-1 transaction messages broadcast on the network 100 during the previous ledger cycle 804, C_{n- 1}. The m_n-1 transaction messages are those selected by the Producer Nodes based on partition type (which this embodiment is a single partition, namely non-confidential accounts). To limit discrepancies in the set of transaction messages collected by the different Producer Nodes and processed during C_n a small time window 806, Dt_freeze, is considered before the start of each ledger cycle. The m_n-1 transaction messages are actually collected during the

period of time [t_{n- 1,} - Dt_freeze, t_n,0] ( [t_{n- 1,} = t_{n 0}- Dt_cycle) and the transaction messages must have a timestamp between t_{n- 1,} - Dt_freeze andt_{n ,} - Dt_freee.

In general, each Producer Node may compile a LSU and interact with its peers to vote on the most popular LSU produced by the set of Producer Nodes. Each Producer Node may be tasked with two responsibilities: compiling a partial LSU (excluding compensation entries) and issuing a candidate on the correct (most popular) partial LSU. Each task may entitle the Producer Node to receive part of a reward allocated to Producer Nodes for maintaining the CLS. An amount of reward individually collected depends on the quality of work performed by a Producer Node. During the ledger cycle 802, C_n, two lists of peer identifiers may be created: a first list

and a second list . The former may comprise the peer identifiers of Producer Nodes who

correctly built the partial LSU, while the latter may comprise the peer identifiers of Producer Nodes who correctly generated the correct candidate of partial LSU built by the Producer Nodes included in the first list.

Throughout the different phases of the ledger cycle 802, the Producer Nodes may exchange quantities that are hashes of data (using the Blake2b hashing function described in section A.2) to which they append their respective peer identifiers. The exchange of hashes may allow for fast and efficient communication rounds amongst the Producer Nodes as hashes of data are each smaller pieces of data than the actual data.

The process followed by Producer Nodes during the ledger cycle 802 is described in phases. The first three phases may comprise producing the correct partial or complete LSU before its broadcast to the entire peer-to-peer network 100. During each phase, a Producer Node P_t generates a quantity and broadcasts it to the network, while collecting the quantities generated by the other Producer Nodes . The

final phase ensures the ledger state is updated across the network 100.

G.l Construction Phase

During the construction phase 900 of the ledger cycle 802,

, a Producer Node

may create a partial LSU and exchange it with the other Producer Nodes chosen for the ledger cycle. The first phase starts at t = t_p = t_{n, 0} and lasts for a period of time Dt_p, therefore ending at t_p + Dt_p.

Referring to Fig. 900 when t = t_p at step 902, the Producer Node P_j may flush its mempool of the m_n-1 transaction messages collected during the

period of time [ [t_{n- 1,}— Dt_freeze, t_{n, 0}] and may process these transaction messages to create a partial LSU, DL_{n, j} . The production of DL_{n, j} may last for a period of time [t_p, t_p + Dt_p0\ (Dt_c0 < Dt_p). The Producer Node may use a salt s, defined using a pseudo-random number generator that is used as a seed for a Merkel tree root, or other digests, of the previous valid LSU DL_{n- 1}. The Producer Node may also create a new hash tree (or other compressed data structure) d_n, ready to store the aggregated transaction signature T_NC of any of the m_n-1 transaction messages that are valid. Producer Node P_j may then follow a series of steps. At step 904 the Producer Node may verify the validity of each transaction message

(as described in section F.5). If any transaction message is not valid, it may be discarded at step 906 and the next transaction message may be examined. For any valid transaction message, at step 908 the Producer Node may extract the n_i transaction entries {E_a}_{a=1 n.}, contained in the transaction message T x_t. The Producer Node may also extract the aggregated transaction signature T_NC of the corresponding transaction message and add the hash tree d_n created above. Note that the transaction signatures in d_n may be sorted in alphanumerical order, as to ensure that two same sets of aggregated transaction signatures (generated by different Producer Nodes for example) result in the same hash tree (or other compressed data structure).

Still at step 908, for each transaction entry E_a, the Producer Node P_j may create a corresponding hash variable:

Each pair ( E_a , O_a) is added to a list . This process may be repeated until it is

determined at step 910 that all transaction objects have been processed,

that is until all valid transaction entries of all valid transaction messages have been included in the list .

At step 912 Producer Node P_j may create a new list using the M

transaction entries listed in (assuming all transactions are valid) such that the transaction entries in

are sorted following a lexicographical order based on their associated hash variable: O₁ <. .. < O_k <.. . < 0_M (1 < k < M). This approach may help to blur the links between the token flows embedded in the transaction entries for a better anonymity of the users involved in said transactions.

At step 912 the Producer Node P_j may also extract the transaction fees paid

in each transaction Tx_t and creates the following sum:

The Producer Node P_j may then compute a partial candidate LSU which may comprise the list of transaction entries concatenated with the hash tree of the

aggregated transaction message signatures d_n:

In step 914 each Producer Node may then compute a producer quantity, h_j, representing its individual contribution:

where h_Dj is a first hash value of the partial candidate LSU:

In this way the producer quantity h_j may comprise both a hash of the partial candidate LSU and the corresponding transaction signatures, and the peer identifier Id_j of the Producer Node that produced the partial candidate LSU DL_{n, j} . In this way the producer quantity h_j may be used to verify that P_j is a Producer Node for the selected the ledger cycle and may be used to evaluate the quality of work performed by P_j.

At step 916 the Producer Node checks whether t £ t_p + Dt_p0. If so, the Producer Node P_j may broadcast the producer quantity h_j to the other Producer Nodes in the network 100 at step 918. If not, the construction phase 900 ends for Producer Node P_j. After step 902, and whilst performing steps 904 to 918, the Producer Node may collect producer quantities

from other Producer Nodes at step 920. This continues as long as t £ t_p + Dt_p, otherwise the construction phase 900 ends. Referring again to Fig. 8, it is noted that Dt_p0 is shorter than Dt_p meaning that each Producer Node attempts to generate a producer quantity h_j for a shorter period of time than the time spent gathering producer quantities from other Producer Nodes.

As mentioned, during construction phase 900 of the ledger cycle 802, Producer Node P_j may collect other producer quantities generated by its Producer

Node peers

and store these in its cache. At the end of the construction phase 900 (when t = t_p + Dt_p), there may be a total of C_j producer quantities stored in P_j's cache (including the producer quantity constructed by Producer Node P_j). Given the set of P Producer Nodes selected for the ledger cycle 802, C_n, the Producer Node P_j may collect at most P— 1 producer quantities (e.g. C_j = P), with each comprising a hash and a unique peer identifier. Two Producer Nodes P_j and P_k may use the same set of transaction messages and compute the same partial candidate LSUs, i.e. with DL_{n, j} = DL_{n k}. However, another Producer Node may not collect exactly P— 1 producer quantities during the time Dt_p (e.g. C_j £ P) and may not process an identical set of transaction messages as the other Producer Nodes. As a result, different versions of the producer quantity may be proposed and circulated amongst the Producer Nodes, whilst only a single approved LSU is required for the present ledger cycle. In order to address that, the consensus algorithm 800 may comprise a campaigning phase as described below in which Producer Nodes select a producer quantity to be a candidate LSU. G.2 Campaigning Phase

During the campaigning phase of the ledger cycle 802, a Producer Node P_j may designate one of the received producer quantities h_k as a partial candidate LSU, that is the LSU that the particular Producer Node believes should be applied to the CLS by all of the nodes 102 in the network 100 at the end of the ledger cycle. The campaigning phase may start at t = t_c where t_c = t_p + Dt_p and last for a period of time Dt_c, ending at t_c + Dt_c.

Referring again to Fig. 8, at time t = t_c Producer Node P_j may process the C_j producer quantities stored in its cache, lasting for a period of time Dt_c0 (Dt_c0 < Dt_c). Referring now to Fig. 10, the steps of the campaigning phase 1000 are illustrated. At step 1002, the Producer Node P_j may check that the number C_j of producer quantities h_k stored in its cache is greater than a minimum value C_min. If not, the campaigning phase ends. If the number of producer quantities is greater than C_min the Producer Node may proceed to step 1004 in which it determines the most common first hash value embedded in a majority C^maj of the producer quantities h_k received from other

Producer Nodes (including the locally generated producer quantity). This may be achieved by determining and the number

. At step 1006, a threshold value, C_threshold,

may be used by the Producer Node to determine if a majority of Producer Nodes agrees on the same first hash value. The threshold value C_threshold may be greater than 50%. The relevant variables for a Producer Node to determine if the same first hash value is found by a majority of the Producer Nodes may be C_min and C^maj. Threshold considerations are discussed in detail in section H.2.

In some embodiments if C_j > C_min and C^maj > C_threshold then the Producer Node P_j may proceed to step 1008 in which:

• P_j may create a first list

and includes in this list the peer identifiers of any producer P_k who forwarded a producer quantity h_k containing a first hash value satisfying .

• If the Producer Node did the same, i.e. may also appends its

peer identifier to the first list .

• The Producer Node P_j may then compute a producer candidate, C_j, as follows:

Where # represents a hash tree or some other compressed data structure of the first list L_j(prod). In this example, the producer candidate Cj includes the most popular partial candidate LSU according to Producer Node P_j. The compressed first list #(L_j(prod) may be useful to protect the list of Producer Nodes who correctly generated the most popular partial candidate LSU according to P_j.

If the time t < t_c + Dt_c0, the Producer Node P_j may broadcast its producer candidate Cj to the other Producer Nodes in the network 100 at step 1010. If the time since the start of the ledger cycle 802 is not less than t_c + Dt_c0, the Producer Node may stop its participation in the campaigning phase 1000.

Shortly after the campaigning phase starts (at t » t_c), at step 1012 the Producer Node P_j may start receiving and storing in its cache other producer candidates c_k generated by other Producer Nodes {P_k}_kÎp/j The collection may last for a period of time Dt_c (which is greater than the time Dt_c0 for computation and broadcast of the Producer Node's own producer candidate). At the end of the collection time Dt_c, the Producer Node may hold V_j producer candidates in its mempool. G.3 Voting Phase

During the voting phase 1100 of the ledger cycle 802, a Producer Node P_j may elect a partial candidate LSU from the collection of producer candidates c_k that it has received. At the end of the voting phase 1100, each Producer Node may forward to its peers a producer vote including the selected partial candidate LSU which may include a reward to some of the Producer Nodes.

The voting phase 1100 starts at t = t_v where t_v = t_p + Dt_p + Dt_c and lasts for a period of time Dt_v, therefore ending at t_v + Dt _v.

Referring to Fig. 11 at t = t_v the Producer Node begins processing the 1/,- producer candidates c_k in its cache. At step 1102 the Producer Node may check whether the number of producer candidates V_j is greater than a minimum number, V_min (V_min £ V_j £ P). If not, the voting phase 1100 may end immediately for that Producer Node. If the number of producer candidates is greater than the minimum number, the Producer Node P_j may proceed to step 1104 in which it may process the Vj producer candidates to identify the most common partial candidate LSU. That may be determined by identifying the most common first hash value h^maj that is embedded in a majority V^maj of producer candidates c_k. This most common first hash value, h^maj , may be determined as

and the number of those matching as .

It will be recalled that the first hash value h_Dj is a hash value of the partial candidate LSU, the latter comprising a list

of the transaction entries and signatures proposed by the Producer Node P_j as part of the producer quantity that it created in the construction phase. The hash value h^maj identified in the step above is the most common first hash value embedded in the list of producer candidates c_k at the end of the campaigning phase. The Producer Node may only participate in the remainder of the voting phase if the first hash value, h_Dj, determined by that Producer Node in the construction phase 900 is the same as the hash value h^maj determined in step 1104. The reason is that Producer Node needs to have compiled and stored (during the construction phase) the list of transaction entries L_E and signatures corresponding to the local hash h^maj as will be explained below. At step 1106 the Producer Node P_j checks if h_Dj = h^maP If not, the Producer Node ends its participation in the voting phase.

If the Producer Node did generate a producer quantity comprising a first hash value h_Dj that matches the most common hash value h^maj , then the Producer Node proceeds to step 1106. In this step the Producer Node may check if the number V^maj of producer candidates comprising the hash value h^maj is greater than a threshold number, V_threshold (i.e V^maj ³ V_threshold) (see section H.2). If not, the Producer Node ends its participation in the voting phase.

If the number V^maj of producer candidates comprising h^maj is greater than the threshold number, the Producer Node proceeds to step 1108 in which it may perform the following during a period of time Dt_v0 (where Dt_v0 < Dt_v). In a first sub-step Producer Node P_j may create a second list

and add to the list the peer identifier Id_k of any Producer Node P_k who broadcast a producer candidate c_k satisfying . The purpose of may be to record the participation

of the Producer Node in the campaigning phase, even if it does not generate the correct partial candidate LSU. This is explained in greater detail below.

It will be recalled that during the campaigning phase 1000, each Producer Node P_j identifies the most common producer quantity that comprises the same first hash value h_Dj, and generates a first list of the Producer Nodes, , who broadcast

that producer quantity. Recalling also that there are V_j producer candidates c_k, the various first lists generated by the Producer Nodes in the campaigning phase are represented by · In a second sub-step the Producer Node Pj may

determine those peer identifiers which satisfy and that are found in at

least a proportion of the first lists , where P is the total number of

Producer Nodes for the current ledger cycle. In one embodiment the proportion could be P/2. The peer identifiers that meet these two criteria are stored in a third list

which represents the list of Producer Nodes that the Producer Node P_j believes produced the correct partial candidate LSU.

The second sub-step may help to inhibit Producer Nodes falsely claiming a reward by including their peer identifier Id_j in the first list , when that

Producer Node did not generate a producer quantity with a first hash value h_Dj matching the most common first hash value i_n the construction phase. If the

Producer Node tried to do so, its peer identifier Id_j would be an element of the first list £_j(prod ) included in the producer candidate C_j created by the Producer Node (or any other Producer Node controlled by P_j), but would not be an element of any other first list created by other Producer Nodes . By processing the first

lists of the peer identifiers in the way described above, the peer

identifier Id_j (of the malicious Producer Node) would not be found in sufficient proportion number of the first lists and therefore not included in

. This may reduce the risk of unethical behaviour by a Producer Node. On

the other hand this may also mean that there may be a reduced incentive for a Producer Node to broadcast its producer candidate during the campaigning phase if its peer identifier was not also included in the third list , as there may be no reward

for the Producer Node if it did not generate the correct partial candidate LSU in the construction phase, but did not appear on enough of the first lists ·

However, the probability that a Producer Node compiles the correct third list

strongly depends on the number of producer candidates collected. The greater the number of producer candidates collected by a Producer Node, the greater the probability that it will compile the complete the correct third list

. Although a Producer Node may not have produced the correct producer quantity during the construction phase, participation in the campaigning phase may be an important contribution to the outcome of the consensus algorithm. Accordingly, mere participation in the campaigning phase may entitle a Producer Node to some reward. As described above, Producer Node P_j generates the second list to account

for their participation in the campaigning process, and this list may be used as the basis of some reward as described below.

In a third sub-step Producer Node P_j may create a fourth list L_CE of compensation entries for each Producer Node whose peer identifier is included in the third list . Each Producer Node may receive x_h tokens. Assume that C_n £ P

peer identifiers are included in

and X is the total number of tokens injected per cycle for the pool of P Producer Nodes. The number of tokens x_h may be defined such that where x_f represents the total number of fees collected

from the m_n-1 transactions and f_prod represents the fraction of new tokens injected per cycle and distributed to the Producer Nodes who built the correct partial candidate LSU. The remaining (1— f_prod)X tokens may be distributed to other contributing nodes 102 in the network 100, for example the Producer Nodes who issued the correct partial candidate LSU during the previous ledger cycle update. Lor example, let be the

list of the peer identifiers of the Producer Nodes who issued the correct partial candidate LSU in the previous ledger cycle C_n-1. We explain below how such list is derived during the synchronisation phase of a ledger cycle. Lor now let's assume that L_CE includes compensation entries for Producer Nodes involved the production of the ledger state update for this ledger cycle C_n and the Producer Nodes involved in the campaigning phase of the preceding cycle C_n-1. At step 1110 Producer Node P_j may create its suggested version of the candidate ledger state update, LSU_j, for the current ledger cycle 802, C_n, including the reward allocated to the Producer Nodes for their contribution:

where

is the list of final transaction entries indicated by the most common first hash value h^maj embedded in the producer candidates proposed by the Producer Nodes, i.e. those on the third list

is the compressed data structure of the associated aggregated transaction message signatures; and L_CE is a list of compensation entries of Producer Nodes to be rewarded.

Step 1110 continues in which Producer Node P_j may compute its producer vote (or ballot) for the LSU:

which includes: a second hash value of the candidate ledger state update

LSU_j; the second list of Producer Nodes who designated the correct partial

candidate LSU included in the producer candidates c_k containing the most common first hash value h^maj ; and the peer identifier of Producer Node producing the producer vote.

At step 1112, Producer Node P_j may check if the time t < t_v + Dt_v0 and, if so, may forward its producer vote V_j to the other Producer Nodes at step 1114. Since the beginning of the voting phase, the Producer Node has also been receiving and storing producer votes v_k transmitted by other Producer Nodes at step 1116. At step 1118 the Producer Node checks if the time t < t_v + Dt_v (where Dt_v > At_v0) and, if so, it continues to collect the producer votes at step 1116. Once step 1118 returns false, the Producer Node finishes the voting phase 1100. At the end of the voting phase (t = t_v + Dt_v), the Producer Node P_j may hold U_j producer votes in its mempool with U_j £ C_n where C_n £ P is the actual total number of Producer Nodes who correctly computed h^maj . G.4 Synchronisation Phase

The synchronisation phase of a ledger cycle starts at t = t_s, with t_s = t_{n, 0} + Dt_p + Dt_c + Dt_v, and lasts for a period of time Dt_s, therefore ending at t_s + Dt_s =

^71,0 T Dt_CyClg.

During a period of time Dt_s0 < Dt_s, Producer Node P_j may execute the following steps:

Firstly, P_j may determine the approved LSU AL_n for the ledger cycle C_n as

and the associated number of votes collected:

and verifies that U^maj > U_threshold, where U_threshold is a threshold value for the number of votes, discussed in section H.2 below.

Secondly P_j may create a fifth list and append to the peer

identifier of a Producer Node included in the second list

of a vote v_k satisfying

if and only if the identifier is included in a proportion of the second lists

. In one embodiment the proportion could be at least C_n/2 of the second lists. Note that C_n can be easily computed as it corresponds to the number of peer identifiers of Producer Nodes who correctly computed the partial candidate LSU in the construction phase and are therefore included in

. Thirdly, if P_j generated the correct candidate LSU LSU_j = DL_n, P_j may write it to a local instance of DFS and in return receive a content address .

Fourthly P_j may generate a producer output quantity:

Finally, the Producer Node may then broadcast O_j to the entire peer-to-peer network 100. G.5 Ledger state synchronisation across the network

During the time period [t_s, t_s + Dt_cycle], User Nodes in the network 100 may collect

producer output quantities from Producer Nodes. Extracting the peer identifier Id_k in o_k a User Node may compile a list of peer identifiers of those Producer Nodes who sent identical content address

concatenated with the same list

. Once a User Node has collected more than a certain proportion (e.g. P/2) identical content addresses, it can read the approved LSU ( DL_n ) using the common content address from DFS.

In this way the User Node may ensure that the list of transaction entries to be applied to the CLS agrees with the LSU broadcast by Producer Nodes. When valid, the User Node may apply the transaction entries to their local CLS. At this point (i.e. the end of the current ledger cycle) the current balances 513 affected by the LSU may be updated and the Producer Nodes effectively collect their rewards.

Worker Nodes in the worker pool 712 may also store the list

embedded in each producer output quantity o_k. If selected to be a Producer Node for the next cycle C_n+1, the Worker Node may use the list

to generate the reward allocated to the Producer Nodes who issued the correct partial candidate LSU during C_n.

H. Security Considerations

Whenever financial value is stored on a distributed system, there may be greater incentive to attack the system in the attempt to take control of financial assets or simply disrupt the system to create or destroy existing assets. Without a centralised entity to control access and check validity it is up to the peers on the network to ensure its security. Through consensus and the underlying protocols of the network a secure environment must be created to allow transactions to take place in a trust-less environment.

H.1 Selection of Worker and Producer Nodes The primary attack of concern for all blockchain and DLT platforms is the subversion of the consensus protocol and is generally referred as a 51% attack. Such an attack is made possible when an entity or group of entities collude to have enough influence on the network to produce a block or ledger state update with invalid transactions, in the attempt to alter the ledger integrity. Depending on the protocol, the influence can be in computing power or number of nodes and exceeds 50% of the relevant resource.

An attack could be performed for many reasons aside attempting to steal money from a network, including to discredit or shake trust in a network. A consequence of a successful attack would likely be to reduce token prices. Although there is no tangible proof of this, it could explain why 51% attacks are not too common. Nevertheless, it remains important to prevent and mitigate the risk of an attack as much as possible. The probability of a 51% attack (P₅₁) typically depends on the algorithm used to produce a valid block or LSU. When considering PoW-based algorithms, P₅₁ can be expressed as a function of the hash rate of network nodes. Since the consensus-based protocol on the distributed ledger 500 as laid out in section G does not rely on solving a cryptographic puzzle, the concept of hash rate of nodes involved in the ledger state update is not relevant to quantify the probability or the cost of an attack on the distributed ledger 500. The number of nodes involved in the production of a ledger state update is however relevant, as explained in this section.

The probability of a successful 51% attack on the distributed ledger 500 implies that a malicious entity (or group of entities) succeeds in controlling more than half the Producer Nodes selected to produce the LSU during a ledger cycle, giving that entity the power to tamper with the ledger state. The probability P₅₁ depends on the following parameters:

• N : the total number of nodes 102 in the worker pool 702.

• P : the subset of Producer Nodes selected to perform work for one ledger cycle ( P £ N).

• 0 : the number of malicious nodes in the worker pool (0 £ 0 £ N). This is a total subset of malicious nodes colluding to perform an attack on the network.

• p : the number of malicious nodes in the subset P of Producer Nodes. (0 £ p £ P )·

• An attack can be considered successful for any value p Î [p₀, P] where p₀ = P/2 + 1 which is equivalent to p > 50%P. When P » N, .e. the number of Producer Nodes selected during a ledger cycle is very close to the total number of nodes in the worker pool, the absence of a randomness element in the selection of P Producer Nodes makes it easy to compute the probability of a successful attack on the network: P₅₁ » O/N . A malicious entity would know exactly when an attack can successfully be performed, that is when 0 > N / 2. When N » P, P₅₁ can be expressed by the discrete sum:

where P_A(p) represents the probability of having p malicious nodes in the set P. When the ratio between the total number of nodes N and the number of Producer Nodes P is large (N > 20 X P) it can be expressed as follows:

A represents the number of possible combinations for choosing p nodes from 0 malicious nodes. B represents the number of possible combinations for choosing good (non-malicious) nodes for the remaining N— 0 nodes in the worker pool. Finally, C corresponds to the number of available combinations for choosing P nodes from the pool of N nodes. P_A(p) is the probability mass function of a hypergeometric distribution over the set of parameters {N, 0, P}. Note that such expression is valid for max( 0, 0 + P— N) £ p £ min(0, P). There are two main arguments behind having a large number of N nodes 102 in the peer-to-peer network:

• To account for the fact that most nodes with sufficient resources may want to join the worker pool 700 and receive tokens as reward for their contribution to the ledger state management

• To make it increasingly costly for any malicious entity to control more than half the nodes.

As explained in section E, prior to joining the worker pool, nodes may be part of a worker queue 702. Nodes in the worker pool 700 may be granted a worker pass valid for a finite period time. As a result, a varying number of nodes leaves the worker pool at the end of each ledger cycle. Although the size of the worker pool 700 might be constant (N nodes), the selection of nodes actually forming the worker pool changes over time. The mechanism used to define a score for nodes in the worker queue is designed to prevent malicious nodes from gaining control of a large fraction of worker nodes. Nevertheless, the fraction O/N may change (increase or decrease) over time and should be taken into account if computing the probability over a series of ledger cycles.

When N » P the probability of a successful attack can therefore be estimated using the cumulative hypergeometric distribution function (CDF) for p E [p₀, P]. Below we have determined the probability estimate obtained using scipy . stats Python library. The graphs presented are obtained using matplotlib. pyplot library. Rather than computing the CDF, the probability measurements are obtained using the survival probability (SDF), which is the inverse of CDF but is known to provide more accurate results (see https://docs.scipy.org/doc/scipy-

0.14.0/reference/generated/scipy.stats.hypergeom.htm for more details).

As an example, assume number of nodes in the worker pool 700, N = 20,000, out of which 5% are selected as Producer Nodes for a given cycle (P = 1,000). Further assume a ratio O/N = 20%, e.g. 1 every 5 nodes in the worker pool is controlled by a malicious entity (0 = 4000). The probability of a successful attack is calculated using the SDF of a hypergeometric distribution using these set of parameters and amounts to: P₅₁ = 1— SDF(20000, 4000, 1000) » 10^-9%. For the same set ( N, P ), the probability of a successful attack reaches 0.04% for O/N = 45% of malicious nodes in the worker pool.

Figs. 12A - 12D show the probability of a successful control of more than 50% of the Producer Nodes as a function of the number of Producer Nodes for four different worker pool sizes and two attack scenarios: when a malicious entity controls O/N = 45% of the worker nodes in blue, and in orange when a malicious controls O/N = 35% of the worker nodes in blue. For N = 20000, the probability remains below 10^-9 if P < » 4000 while for a smaller worker pool size (N = 5000), the ratio P/N must be at close to 50% to prevent a successful control of more than 50% of the Producer Nodes.

Figs. 13A and 13B display the minimum ratio P/N required to maintain a probability below 10^-6 and 10^-9 respectively for various malicious node scenarios (O/N ratio between 30% and 45%). This shows that as N increases the required P/N ratio required for the same security level decreases.

This series of Figs gives a good indication on what pair of parameters ( N , P) may be used increase resilience to a 51% attack. Given a number of nodes in the worker pool 700, we may deduce the number of Producer Nodes to select during one ledger cycle. Conversely, given a selected number of Producer Nodes for a ledger cycle, we can define a minimum size for the worker pool 700. As detailed in the next section, the number of Producer Nodes selected for a ledger cycle is important to ensure that a consensus can be reached on the correct ledger state update to distribute to the rest of the network.

H.2 Production of a Ledger State Update

The previous section discusses the level of security against 51% attack when a malicious entity controlling more than half the Producer Nodes can attempt to tamper with the ledger update. Specifically, the security of the consensus algorithm is considered as a function choice of parameters (P, N). As N becomes large and the ratio P/N is low, it becomes very unlikely for a malicious entity to gain control of the worker pool, notwithstanding an increasingly expensive cost of attack.

In this section, we explore the confidence level associated with the production of a LSU. During the last phase of the consensus algorithm each node 102 on the network 100 may update their local copy of the CLS with what they perceive as being the approved LSU generated by the Producer Nodes. Each User Node may be required to collect x > P / 2 identical DFS content addresses from the Producer Nodes to safely conclude that a consensus was reached amongst the Producer Nodes. Recall that a Producer Node P_j may broadcast to the network 100. The

Producer Node peer identifier Id_j may be used by a User Node to distinguish between the DFS content address generated by two Producer Nodes. The correct address

may be defined by

with (a/ |b) represents the removal of b in a, and x = coiint

. Note that if x = P, all

Producer Nodes agree on the correct LSU update for ledger cycle C_n.

As described in section G, a Producer Node may execute a series of steps in each phase of the consensus algorithm in a consecutive manner. The Producer Node may only move to the next phase if a set of conditions are fulfilled in the previous phase. In the first three phases the Producer Node P_j may generate a producer quantity h_j that obeys certain criteria and broadcasting it to its Producer Node peers while collecting the producer quantities h_k produced and broadcast by other Producer Nodes

{ P_k}kÎP/j

1. Construction phase: hj is the producer quantity comprising the partial candidate LSU (excluding any compensation entry) generated by Pj , using the set of transactions stored in its mempool, concatenated with its identifier , where h_Dj is the first

hash value.

All Producer Nodes

participate in the construction phase.

h_j may be required to be broadcast before t_p + Dt_p0. Other producer quantities may be collected during the time period [t_p, t_p + Dt_p\.

Each transaction included in the LSU must verify a list of validity checks (see section F.5).

2. Campaigning phase:

C_j is the producer candidate generated by P_j :

with the most common first hash value

found by P_j given the set of producer quantities collected during the construction phase. L_j(prod) is the first list of peer identifiers compiled by P_j which includes the peer identifier of any Producer Node having broadcast a first hash value corresponding to the most common first hash value, i.e. the most common partial candidate LSU.

* All Producer Nodes

^may participate in the campaigning phase.

* C_j may be required to be broadcast before t_c + Dt_c0. Other producer candidates are collected during the time period [t_c, t_c + Dt_c ] .

* The number C_j of producer quantities collected by P_j may be required to satisfy C_j ³ C_min.

* The number of identical producer quantities

may be required to satisfy C^maj ³ C_threshold.

3. Voting phase:

V_j is the producer vote generated by with

the candidate LSU locally elected by P_j which includes the

compensation entries for the Producer Nodes {P_k} that generated a correct producer candidate satisfying . is the second list of peer identifiers

compiled by P_j which includes the peer identifier of any Producer Node having broadcast a producer candidate corresponding to most common partial candidate LSU. L_CE is the list of compensation entries created using the peer identifiers included in

, the complete and final list of C_n Producer Nodes having broadcast a first

hash value corresponding to the most common partial candidate LSU.

* All Producer Nodes may participate in the voting phase but only the ones finding a satisfying h^maj = h_j

may broadcast a vote.

* V_j may be required to be broadcast before t_v + Dt_v0. Other producer votes may be collected during the time period [ t_v, t_v + Dt_v].

* The number V_j of candidates collected by P_j must verify V_j ³ V_min.

* The number of identical first hash values

must verify V^maj ³ V_threshold .

* includes the peer identifier of Producer Nodes included

in at least a proportion (e.g. P/2) of the lists associated to a producer vote v_k satisfying

4. Synchronisation phase:

O_j is the producer output quantity generated and broadcast by P_j and contains the content address

of the approved LSU DL_n stored on DFS: o_j =

.

* All Producer Nodes

may participate in the synchronisation phase but only the ones having successfully compiled the correct candidate LSU LSU_j = DL_n may broadcast a producer output quantity to the network 100.

* O_j may be required to be broadcast before t_s + Dt_s0. User Nodes may be required to collect at least x identical addresses _<A_n during the time period [t_s, t_s + Dt_s] and request the corresponding approved LSU to synchronise their local copy of the CLS.

* The number U_j of votes collected by P_j may be required to satisfy

Uj ³ U_min .

* The number of identical hashes

may be required to satisfy U^maj >

U _threshold ^.

*

includes the identifier of Producer Nodes included in at least a proportion (e.g. C_n/ 2) of the lists

associated to a producer vote v_k satisfying

corresponds to the number of peer identifiers of

Producer Nodes who correctly computed the partial LSU and are therefore included in .

The probability P(x > P/2) that x > P/2 at the synchronisation phase may depend on a series of criteria: a· ( C _min, C_threshold) A Producer Node may need to collect enough individual producer quantities (at least C_min ) and find a majority (at least C_threshold) of identical partial candidate LSUs included in producer quantities to be able to issue a producer candidate. C_min may be defined as a fraction of P: C_min = f_cP with 0 < f_c < 1. On the other hand, the definition of C_threshold is more complex and depends on the number of producer quantities, C_j.

Although in theory C_threshold could be set at C_j/2, a higher threshold may be chosen to allow a Producer Node to decide on a partial candidate LSU in good confidence. Indeed, one may account for the statistical uncertainty associated to the ratio C^maj /C_j due to the size of the data sample used to compute this ratio. Moreover, there may be no ambiguity on the choice of a partial candidate LSU if a second set of identical partial candidate LSUs included in producer quantities of size close to C_j/ 2 is found (for example in an attempt to tamper with the CLS by a malicious entity controlling a large number of Worker Nodes). The confidence interval on a ratio r = C^maj /C_j may be defined as:

Where z is a score associated to the confidence level in r (z = 4.22 for a

99.999% confidence level) and the remaining expression is the standard error of the ratio estimate.

In a scenario where only two types of first hash value are collected by a Producer Node compiles the two ratios = h₁/C_j

and r₂ = h₂/C_j. Since h₂ = C_j— the two ratios have the same margin error: Dr₁ = Dr₂. AS illustrated in Fig. 14, if the margin error associated to the two ratios are such that r₁— Dr₁ < r₂ + Dr₂, P_j cannot say with certainty that a majority of Producer Nodes agrees, even if r₁ > 50%. A decision can only really be made if r₁ > 50% + Dr_c. Fig. 14 shows that for a r₁ = 70% the Producer Node must collect at least C_j = 110 producer quantities in order to remove any ambiguity with a confidence level (CL) at 99.999%. Indeed, if r₁ = 70% and C_j = 2000, the second ratio r₂ would represent at best 30% of the data collected by the Producer Node, the statistical uncertainty on these two ratios would leave a significant gap between 34.3% and 65.7%. For C_j = 1000, that gap would be reduced to [36.1%, 63.9%], still large enough to give enough confidence to a Producer Node that a clear majority of nodes agree on a common data. This is illustrated in Fig. 15 when r₁ = 60%. It can be seen that when C_j = 200 that there would be an overlap between the margin errors around r₁ and r₂, while when C_j = 2000 the Producer Node can conclude with a confidence level of 99.999% that r₁ > r₂. C_threshold may therefore be defined for confidence level (CL) as:

For a confidence level at 99.999%, C_threshold can be expressed as:

( V_min’ V_threshold) · A Producer Node may need to collect enough individual producer candidates

(at least V_min ) and find a majority (at least V_threshold) of identical partial candidate LSUs embedded in the producer candidate to be able to issue a vote. V_min is typically defined as a fraction of P: V_min = f_VP with 0 < f_V < 1. V_threshold may be defined following the same approach considered for C_threshold:

C. ( U_min’ U_threshold ^, C_n):

A Producer Node may need to collect enough individual votes (at least U_min) and find a majority (at least U_threshold ) of votes with identical hash values to be able to confidently broadcast the content address of the next LSU stored on DFS across the network. Two votes may be considered identical if they include the same DFS address of a complete LSU including the compensation entries that reward the Producer Nodes for their work. Two complete LSUs may be considered identical if the lists

used to create some compensation entries are identical. The list

comprises the identifiers of the C_n Producer Nodes that produced the right partial candidate LSU (without compensation entries) during the construction phase. C_n is typically defined as a fraction of P: C_n = f_prod P with 0 < f_prod < 1. U_min may be defined as a fraction of C_n: U_min = f_UC_n with 0 < f_U < 1. Indeed U_min is a fraction of Producer Nodes among those that had produced a candidate partial candidate LSU such that the partial LSU embedded in the candidate corresponding to

may be defined following the same approach considered for C_threshold:

In summary the probability T(x > P/2) that x > P/2 can be expressed as a function of P, C_min, C_n, V_min, U_min .

Tests conducted on the gossip protocol implemented on Catalyst suggest that a high percentage of nodes (approximately 95— 99%) in a network of about 50,000 nodes may successfully collect data from all their peers. Furthermore tests on a smaller networks of about 1000 nodes such as the sub-networks of Worker Nodes and Producer Nodes tasked with producing a LSU during a ledger cycle gives the percentage of nodes collecting the data from all their peers as close to 99—100%. As a result, the numbers ( C_j , V_j, U_j ) of data collected by a Producer Node P_j are naturally expected to be close to the number of Producer Nodes, P. We have conducted a simulation analysis to determine a preferred set of parameters (C_min, C_n, V_min, U_min) in some embodiments to ensure a probability

greater than 99.999% for various numbers of Producer Nodes. Fig. 16 shows a n-ary tree illustrating the minimum sets of parameters ( f_P , f_prod, f_V, f_U ) found for a pool of Producer Nodes made of (a) 200 nodes (Fig. 16A) and (b) 500 nodes (Fig. 16B). As the number of Producer Nodes increases, the thresholds decrease.

H.3 Rogue Key Attack

When Schnorr signatures used to generate aggregated signature of a transaction are vulnerable to an attack known as Rogue Key attack. Rogue Key attacks performed by a malicious entity consists of generating an aggregated signature in such a way that they possess the public/private key pair for that signature. In the Schnorr signature scheme, the public key of participants are aggregated and the sum represent the public key associated to the signature. Assume that an honest participant use its public key Q_a in the transaction and a malicious participant possesses Q_b. By sending the public key Q_m = Q_b— Q_a to the honest participant, the malicious entity may have access to the transaction as they will hold the private key for Q_b. This is because when the keys are aggregated i.e. Q_m + Q_a the aggregated signature would be Q_b, for which the malicious user holds the private key (the honest user would not). For an aggregated public key, there should be no user that has a private key equivalent as it should be used to create a signature that can be verified that all users in the transaction participated.

The aggregation of public keys which may be used in the distributed ledger 500 is based on the use of a multi-signature scheme that is provably secure in the plain public-key model. This type of multi- signature scheme may be resistant to a rogue key attack as the scheme does not require a user to demonstrate ownership of the private key corresponding to their public key, only the sum of all the public keys. Furthermore only one public key is needed for the verification (the aggregated key) for which there will not be an equivalent private key.

Claims

1. A peer-to-peer computer network comprising:

a plurality of peer computer nodes in communication with one another, a distributed ledger database stored by the plurality of peer computer nodes, wherein the distributed ledger database comprises a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset, the distributed ledger database having a current ledger state comprising the plurality of identifiers and current balances;

the plurality of peer computer nodes adapted to exchange transaction messages over the peer-to-peer network, the transaction messages comprising at least two transaction entries, each transaction entry comprising an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component; a plurality of producer nodes selected from the peer computer nodes, a consensus algorithm operated by the producer nodes for processing said transaction messages to reach a consensus on at least one valid transaction message and, at intervals, producing an approved ledger state update comprising details of the at least one valid transaction message, the producer nodes transmitting the approved ledger state update to said peer-to-peer computer network;

every peer computer node updating said current balances in its version of the distributed ledger database according to the approved ledger state update;

wherein each transaction message comprises a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively.

2. A peer-to-peer computer network as claimed in claim 1, wherein each peer computer node does not require access to transaction messages contained in any earlier ledger state update to apply the most recent ledger state update to the current ledger state.

3. A peer-to-peer computer network as claimed in claim 1 or 2, wherein any one current balance is mapped to only one identifier.

4. A peer-to-peer computer network as claimed in claim 1, 2 or 3, wherein a first group of nodes store at least one first portion of the identifiers and current balances of the current ledger state, and a second group of nodes store at least one second portion of the identifiers and current balances of the current ledger state;

wherein each node of the first group of nodes is adapted to apply approved ledger state updates affecting current balances of said first portion, and each node of the second group of nodes is adapted to apply approved ledger state updates affecting current balances of said second portion.

5. A peer-to-peer computer network as claimed in claim 1, 2, 3 or 4, wherein said digital signature of each transaction message comprises a single aggregate digital signature capable of validating a first group of the transaction entries in a transaction message, and said producer nodes are adapted to by validate each single aggregate digital signature of a respective transaction message.

6. A peer-to-peer computer network as claimed in claim 5, wherein said first group comprises all of the transaction entries in a transaction message and the single aggregate digital signature.

7. A peer-to-peer computer network as claimed in any preceding claim, wherein said transaction message comprises unsigned transaction entries, and said producer nodes are adapted to validate said unsigned transaction entries.

8. A peer-to-peer computer network as claimed in claim 5 or 6, wherein said single aggregate digital signature requires only the public keys of the participants to validate the digital signature, such as a digital signature generated using a Schnorr based aggregated signature scheme.

9. A peer-to-peer computer network as claimed in any preceding claim, wherein each peer computer node is adapted to:

initiate construction of a transaction message by: generating a core transaction message comprising said at least two transaction entries;

generating a first partial digital signature for one of said at least two transaction entries; and

send the core transaction message and said first partial digital signature to at least one other peer computer node, the at least one other peer computer node representing a participant for at least one of said transaction entries in the core transaction message for which a partial digital signature is missing.

10. A peer-to-peer computer network as claimed in claim 9, wherein each peer computer node is adapted such that if it receives the first partial digital signature and a core transaction message for which a partial digital signature is missing, the peer computer node:

checks the validity of the first partial digital signature;

generates a second partial digital signature for the missing partial digital signature; and

forwards the transaction core message and the first and second partial digital signatures to at least one other peer computer node, the at least one other peer computer node representing a participant for at least one of said transaction entries in the core transaction message for which a partial digital signature is missing.

11. A peer-to-peer computer network as claimed in claim 10 or 11, wherein each peer computer node is further adapted such that, if a peer computer node receives a transaction core message where just one partial digital signature is missing, the peer computer node:

checks the validity of the or each partial digital signature accompanying the core transaction message;

creates the missing partial digital signature;

generates said single aggregate digital signature using all of the partial digital signatures;

generates the transaction message comprising the at least two transaction entries and the single aggregate digital signature, but not comprising any of the partial digital signatures; and

transmits the transaction message to said peer-to-peer network.

12. A peer-to-peer computer network as claimed in any preceding claim, wherein said consensus algorithm comprises a set of computer-executable instructions stored by each producer node that, when executed, cause each producer node to generate a candidate ledger state update for the current ledger state and to transmit the candidate ledger state update toward the other producer nodes for comparison with other candidate ledger state updates, the approved ledger state update for the current ledger state being transmitted toward all the peer computer nodes only once a majority of the producer nodes have agreed on the same candidate ledger state update.

13. A peer-to-peer computer network as claimed in claim 12, wherein said computer-executable instructions are further adapted to cause each producer node to: gather a plurality of transaction messages;

check the validity of the transaction message which includes a verification of the digital signature of each transaction message, and to discard invalid transaction messages;

for each valid transaction message, to extract the transaction entries and then to construct a producer quantity (h_j) comprising a partial candidate ledger state update ( DL_{n, j} ) including a list of the transaction entries extracted from the valid transaction messages; and

to transmit the producer quantity to other producer nodes.

14. A peer-to-peer computer network as claimed in claim 13, wherein said computer-executable instructions are further adapted to cause each producer node to re-order the transaction entries whereby links between transaction entries are blurred in the partial candidate ledger state update to improve anonymity, such as an alphanumeric ordering.

15. A peer-to-peer computer network as claimed in claim 14, wherein said computer-executable instructions are further adapted to cause each producer node to: combine each transaction entry with a salt;

apply a hash function to the combination of the transaction entry and the salt to generate a hash variable;

add each hash variable to a hash variable list; and

to re-order the hash variable list.

16. A peer-to-peer computer network as claimed in claim 13, 14 or 15, wherein said computer-executable instructions are further adapted to cause each producer node to extract each digital signature of each valid transaction message, to generate a compressed data structure comprising the digital signatures, and to include the compressed data structure in said partial candidate ledger state update.

17. A peer-to-peer computer network as claimed in any of claims 13 to 16, wherein said computer-executable instructions are further adapted to cause each producer node to apply a hash function to said partial candidate ledger state update to generate a first hash value ( h_Dj ), and to use said first hash value in said producer quantity.

18. A peer-to-peer computer network as claimed in claim 17 wherein said computer-executable instructions are further adapted to cause each producer node to include a peer identifier in said producer quantity, the peer identifier for identifying the producer node to the peer computer nodes.

19. A peer-to-peer computer network as claimed in any of claims 13 to 18, wherein said computer-executable instructions are further adapted to:

cause each producer node to receive and store producer quantities generated and transmitted by other producer nodes, the list of transaction entries in at least one producer quantity possibly differing from the list of transaction entries in at least one other producer quantity.

20. A peer-to-peer computer network as claimed in claim 19, wherein said computer-executable instructions are further adapted to cause each producer node to search for matching partial candidate ledger state updates amongst the received producer quantities, and to determine the most common partial candidate ledger state update in the producer quantities.

21. A peer-to-peer computer network as claimed in claim 20, wherein said computer-executable instructions are further adapted to cause each producer node to determine if the most common partial candidate ledger state update appears in a majority of producer quantities.

22. A peer-to-peer computer network as claimed in claim 20 or 21, wherein said computer-executable instructions are further adapted to cause each producer node to generate a first list of producer nodes who transmitted a producer quantity

comprising the most common partial candidate ledger state update, and to generate a producer candidate ( C_j ) comprising (i) the most common partial candidate ledger state update, (ii) the first list of producer nodes and (iii) a peer identifier of the producer node generating the producer candidate, and to transmit the producer candidate to the producer nodes.

23. A peer-to-peer computer network as claimed in claim 22, wherein said computer-executable instructions are further adapted to cause each producer node to generate said first list of producer nodes as a compressed data structure, such as a hash tree of the list of producer nodes.

24. A peer-to-peer computer network as claimed in claim 23, wherein said computer-executable instructions are further adapted to cause each producer node to receive and store producer candidates generated and transmitted by other producer nodes, the list of transaction entries in at least one producer candidate possibly differing from the list of transaction entries in at least one other producer candidate.

25. A peer-to-peer computer network as claimed in claim 24, wherein said computer-executable instructions are further adapted to cause each producer node to search for matching lists of transaction entries amongst the received producer candidates, and to determine the most common list of transaction entries in the producer candidates.

26. A peer-to-peer computer network as claimed in claim 25, wherein said computer-executable instructions are further adapted to cause each producer node to determine if the most common list of transaction entries appears in the majority of producer candidates.

27. A peer-to-peer computer network as claimed in claim 25 or 26, wherein said computer-executable instructions are further adapted to cause each producer node to generate a second list of producer nodes who transmitted a producer

candidate comprising the most common list of transaction entries.

28. A peer-to-peer computer network as claimed in claim 27, wherein said computer-executable instructions are further adapted to cause each producer node to examine each first list of producer nodes accompanying each the most common partial candidate ledger state update, and to generate a third list

of producer nodes, the third list comprising only those producer nodes present in at least a certain proportion of the first lists for resistance to manipulation of a ledger state update by a malicious entity.

29. A peer-to-peer computer network as claimed in claim 28, wherein said computer-executable instructions are further adapted to cause each producer node to generate a fourth list ( L_CE ) of producer nodes, said fourth list comprising a list of rewards receivable by the producer nodes on the third list.

30. A peer-to-peer computer network as claimed in claim 29, wherein said computer-executable instructions are further adapted to cause each producer node to generate a candidate ledger state update comprising (i) the most common list of transaction entries in the producer candidates, (ii) the digital signatures of those transaction entries and (iii) the fourth list.

31. A peer-to-peer computer network as claimed in claim 30, wherein said computer-executable instructions are further adapted to cause each producer node to generate a producer vote (v_j) for the ledger state update by applying a hash function to said candidate ledger state update to generate a second hash value, the producer vote comprising (i) said second hash value, (ii) a compressed data structure representing said second list of producer nodes, and (iii) the peer identifier of the

producer node generating the producer vote, and to transmit the producer vote to the producer nodes.

32. A peer-to-peer computer network as claimed in claim 31, wherein said computer-executable instructions are further adapted to cause each producer node to receive and store producer votes generated and transmitted by other producer nodes, the list of transaction entries in at least one producer vote possibly differing from the list of transaction entries in at least one other producer vote.

33. A peer-to-peer computer network as claimed in claim 32, wherein said computer-executable instructions are further adapted to cause each producer node to search for matching second hash values amongst the received producer votes, and to determine the approved ledger state update ( DL_n ) as the most common candidate ledger state update corresponding to most common second hash value.

34. A peer-to-peer computer network as claimed in claim 33, wherein said computer-executable instructions are further adapted to cause each producer node to count and store the number of producer votes containing the most common second hash value.

35. A peer-to-peer computer network as claimed in claim 33 or 34, wherein said computer-executable instructions are further adapted to cause each producer node to examine each second list of producer nodes in the producer votes having

the most common candidate ledger state update and to generate a fifth list

of producer nodes, the fifth list comprising only those producer nodes present in at least a certain proportion of the second lists, namely the producer nodes who correctly computed the first hash value matching the most common list of transaction entries in their producer quantity.

36. A peer-to-peer computer network as claimed in claim 35, wherein said computer-executable instructions are further adapted to cause each producer node in possession of the approved ledger state update to store the approved ledger state update on the peer-to-peer network, the approved ledger state update having an address where it can be accessed by peer computer nodes of the network, and to generate a producer output (o_j) comprising (i) the address of the approved ledger state update, (ii) the fifth list and (iii) the peer identifier of the producer node generating the producer output, and to transmit the producer output to the peer computer nodes.

37. A peer-to-peer computer network as claimed in claim 36, wherein said computer-executable instructions are further adapted to cause each peer computer node to collect and store the producer outputs from different producer nodes; and

when said peer computer node has collected producer outputs in which more than a certain proportion contain identical addresses of the approved ledger state update and identical fifth lists, the address of the approved ledger state update is used to obtain from the peer-to-peer network a copy of the transaction entries in the approved ledger state update.

38. A peer-to-peer computer network as claimed in claim 37, wherein said computer-executable instructions are further adapted to cause each peer computer node to apply the transaction entries of the approved ledger state update to the current ledger state.

39. A peer-to-peer network as claimed in any preceding claim, wherein said each current balance represents at least one state of the digital asset, and the ledger state update is intended to change the state of the digital asset recorded in the current ledger state. State could be a probability or a number or an attribute or a characteristic or an ownership of the digital asset or other data.

40. A peer-to-peer computer network as claimed in any preceding claim, wherein said computer-executable instructions are further adapted to cause each peer computer node to

apply a cryptographic technique to the amount components of the at least two transaction entries to generate at least two encrypted amount components, whereby a link between any two or more transaction entries is hidden and sending identifiers and receiving identifiers of digital assets are indistinguishable; and

to apply said cryptographic technique to each current balance stored in the current ledger state whereby the current ledger state comprises encrypted current balances.

41. A peer-to-peer computer network as claimed in claim 40, wherein said cryptographic technique in said computer-executable instructions causes each peer computer node to obfuscate the amount components and current balances by application of a commitment scheme to each amount component, such as a perfectly binding information commitment scheme.

42. A peer-to-peer computer network as claimed in claim 41 , wherein said perfectly binding information commitment scheme is binding under the discrete logarithm assumption, such as a Pedersen commitment.

43. A peer-to-peer computer network as claimed in claim 41 or 42, wherein said computer-executable instructions are further adapted to cause each peer computer node to check the validity of a transaction message by determining if the sum of the amount components listed in the transaction message are a commitment to zero to ensure no digital assets are created or destroyed by a transaction entry, and to determine if, after application of each transaction entry, the corresponding new current balance is positive but does not exceed a predetermined threshold.

44. A peer-to-peer computer network as claimed in claim 43, wherein said computer-executable instructions are further adapted to cause each producer node to check the validity of a transaction message by applying a range proof to prove that the encrypted current balance remains within a predetermined range after application of the corresponding encrypted amount component in a transaction entry.

45. A peer-to-peer computer network as claimed in any of claims 40 to 44, wherein said cryptographic technique in said computer-executable instructions causes each peer computer node to encrypt said amount components and said current balances using homomorphic encryption.

46. A peer-to-peer computer network as claimed in claim 45, wherein said computer-executable instructions are further adapted to cause each peer computer node to add said encrypted amount components to said encrypted balances.

47. A peer-to-peer computer network as claimed in claim 46, wherein said cryptographic technique in said computer-executable instructions causes each peer computer node to encrypt said amount components and said current balances using elliptic curve cryptography.

48. A peer-to-peer computer network as claimed in claim 47, wherein said computer-executable instructions are further adapted to cause each peer computer node to construct the encrypted amount component of a transaction entry using a cyclic generator group in the elliptic curve to represent negative numbers as positive numbers.

49. A peer-to-peer computer network as claimed in any preceding claim, wherein each identifier of said plurality of identifiers comprises a public key of public -private key pair constructed by an asymmetric encryption algorithm.

50. A computer device comprising:

a processor;

a network interface; and

a memory storing computer-executable instructions that, when executed, cause the computer device to:

(a) join a peer-to-peer computer network comprising a plurality of peer computer nodes in communication with one another,

(b) obtain from the peer-to-peer network and store in the memory a copy of a distributed ledger database, wherein the distributed ledger database comprises a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset, the distributed ledger database having a current ledger state comprising the plurality of identifiers and current balances;

(c) exchange transaction messages over the peer-to-peer network, the transaction messages comprising at least two transaction entries, each transaction entry comprising an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component; the computer-executable instructions further comprising a consensus algorithm that may be operated by the computer node that causes the computer node to become a producer node for the peer-to-peer network, the consensus algorithm causing the producer node to:

(i) process said transaction messages to reach a consensus with other producer nodes on at least one valid transaction message and, at intervals, producing an approved ledger state update comprising details of the at least one valid transaction message, the producer node transmitting the approved ledger state update to said peer-to-peer computer network;

(ii) the producer node using a digital signature in each transaction message to validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively; and (d) update said current balances in its version of the distributed ledger database according to the approved ledger state update.

51. A computer device as claimed in claim 50, further adapted to permit said computer executable instructions to be transmitted via said network interface to another computer device, whereby said other computer device may install and execute said computer executable instructions and participate in said peer-to-peer network.

52. A computer-implemented method for a peer-to-peer computer network comprising a plurality of peer computer nodes in communication with one another, which method comprises the steps of:

storing a distributed ledger database across the plurality of peer computer nodes, wherein the distributed ledger database comprises a plurality of identifiers and current balances of at least one digital asset, whereby each identifier is mapped to at least one current balance of the at least one digital asset, the distributed ledger database having a current ledger state comprising the plurality of identifiers and current balances;

exchanging transaction messages over the peer-to-peer network between the plurality of peer computer nodes, the transaction messages comprising at least two transaction entries, each transaction entry comprising an identifier and an amount component, each transaction entry intended to change the corresponding current balance in the distributed ledger database by the amount component;

selecting a plurality of producer nodes from the peer computer nodes, operating a consensus algorithm by the producer nodes for processing said transaction messages to reach a consensus on at least one valid transaction message and, at intervals, producing an approved ledger state update comprising details of the at least one valid transaction message, the producer nodes transmitting the approved ledger state update to said peer-to-peer computer network;

updating said current balances held by every peer computer node in its version of the distributed ledger database according to the approved ledger state update;

53. A computer-readable medium storing the computer-executable instructions defined in claim 50.

54. For use in the peer-to-peer communication network of any of claims 1 to 49, an electronic transaction message transmissible between peer computer nodes, which transaction message has a data structure comprising:

at least two transaction entries, each transaction entry comprising an identifier and an amount component; and

a digital signature by which said producer nodes validate that the inclusion of at least one identifier in the at least two transaction entries was by an entity that controls each identifier respectively.