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 ^c l 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 _i H + b _i G 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 _i H and b _i G 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 _H H, 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 _i G, 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 _i H + b _i G 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 _t G, 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

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

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 _H H, 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 _i G. 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 ^ma P 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 ^ma y 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 _c P 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 _V P 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 _U C _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.