WO2019243235A1

WO2019243235A1 - Distributed ledger technology

Info

Publication number: WO2019243235A1
Application number: PCT/EP2019/065840
Authority: WO
Inventors: Daniel Patrick HUGHES
Original assignee: Radix Dlt Limited
Priority date: 2018-06-19
Filing date: 2019-06-17
Publication date: 2019-12-26

Abstract

A computer-implemented method for performing by a node of a network of nodes maintaining at least part of a distributed ledger maintained by the network of nodes is disclosed. The method comprises receiving a record intended for the distributed ledger and verification data for the record, wherein the verification data comprises a node identifier and corresponding assigned event state for each node which has previously verified the record. The method further comprises assigning an event state to the record, wherein the event state is provided by a logical clock for the node. The method further comprises, conditional on the node verifying the record: updating the verification data to include an identifier for the node and the assigned event state; storing, in the at least part of the distributed ledger maintained by the node, the record and the updated verification data; and transmitting the record and the updated verification data to at least one node of the network of nodes which has not previously verified the record.

Description

Distributed Ledger Technology

Technical Field

The present disclosure relates to distributed ledger technology and, in particular, to computer- implemented methods for performing by a node of a network of nodes which maintain a distributed ledger as well as corresponding computer programs and computer nodes.

Background

Distributed ledger technology is the technology used to maintain a distributed ledger (sometimes called a shared ledger). A distributed ledger is a replicated, shared, and synchronised collection of digital records spread across multiple computer nodes (or simply“nodes”), with nodes typically located across multiple sites, countries, or institutions.

A distributed ledger is typically maintained across a network of nodes, often a peer-to-peer network, the topology of which may vary depending on the requirements of application. A consensus mechanism is required to ensure that all nodes can agree on both legitimate and illegitimate activity and act accordingly.

In the case of illegitimate activity, this could be honest faults leading to incorrect operation of a node or a set of nodes, or malicious activity on the part of a node operator to profit or disrupt. As it is generally impossible to determine honest faults from malicious intent, most consensus mechanisms therefore assume that all faults are by cause of dishonest actors.

In many cases the consensus mechanism serves an additional purpose of allowing new nodes to verify that they are synchronizing correctly with existing nodes.

A distributed ledger in its purest form eliminates the need for a single central authority to maintain the integrity of the data stored in the ledger. Instead this task becomes the responsibility of the network as a whole, with the nodes of the network participating together to ensure overall integrity of the data.

All information in the ledger typically uses cryptography techniques to ensure consistency, integrity, security and permissions using cryptographic keys, encryption and digital signatures. Once data is committed and stored in the ledger it is considered as an immutable entry in the database of records which is governed by the rules of the consensus mechanism of the network.

While centralised ledgers are frequently affected by various forms of cyber-attacks, distributed ledgers are inherently much harder to mount a successful attack against because multiple distributed copies exist in many locations, all of which need to be attacked simultaneously in order to achieve a successful attack. The larger the network supporting a distributed ledger, the more expensive the attack becomes both logistically and in terms of resource requirements. Similarly, the records stored in a distributed ledger are resistant to malicious changes by a single party due to the consensus mechanism requiring all nodes to agree to any change, and the cryptographic proofs required to initiate any change.

Distributed ledgers (or“digital distributed ledgers” to make clear that the term relates to computer-stored data) can be considered as immutable, distributed databases storing a single version of the truth.

Distributed ledger technology has great potential to revolutionize the way organisations operate day to day in many industry verticals. For example, the technology can be used to assist governments with various administrative procedures such as tax collection, issuing licences, administrating social security benefits and voting procedures. The technology also has application in areas such as finance, provenance, music and entertainment,

precious assets, the internet of things, and supply chains of various commodities. While distributed ledger technology has great potential, the incumbent distributed ledger architectures suffer from many technical problems and limitations.

One form of a distributed ledger architecture is a block chain. This is the technology that underlies the digital currency Bitcoin and was the first distributed ledger that enabled permissionless and trustless value transfer without a central controlling entity.

In this design, transactions are batched together and recorded at periodic intervals in blocks, which are appended to the last previous valid block to create a chain, hence the name block chain. Independent entities within the network referred to as“miners” perform the task of creating the blocks by collecting transactions from the network, batching them together, and attempting to find a hash value that meets the current requirements as defined by the network.

In Bitcoin, this process involves a miner attempting to discover a SHA-256 hash for the block that contains a number of leading zero bits as defined by a deterministic network requirement known as the “difficulty”. If the current hash a miner has generated does not meet these requirements, he can increment a“nonce” value and try again. If the miner has not found an acceptable hash after a number of nonce increments (in Bitcoin the nonce is a 32 bit value), they can replace some transactions in the block, reset the nonce value and start again. The chances of an individual miner discovering a hash that meets these requirements reduces as more miners join the network and the difficulty increases.

This process is known as“proof of work” as discovering a valid hash for a block requires a significant amount of effort, yet it is trivial for anyone to verify that a hash is valid given the block contents and the nonce value.

Once a miner has discovered a valid block hash, they submit it to the network in the hope that no other miner has generated a competing block hash with more leading zero bits then theirs in the same interval. If not, then their block will be appended to the end of the chain and all miners will then reset and attempt to discover a valid hash for the next block.

The consensus rules of proof of work are simple: in each interval, the block with the hash containing the most leading zero bits is the one which is accepted by the network, therefore the accepted block chain is the one with the most cumulative work across all blocks.

Miners are rewarded for their work by being awarded a number of Bitcoins for successfully generating a block and also collect the fees for the transactions included in the block. The award of new Bitcoins for block generation also acts as an economic mechanism for issuing and distributing new currency units.

Bitcoin is but one example of how a distributed ledger is used to record events and facilitate transfer of ownership without a central entity, of which there are now many. While many use differing consensus mechanisms, hashing algorithms, economic parameters and block intervals along with the development of a multitude of new features, nearly all employ a similar block chain based architecture and thus inherit many, if not all, of its limitations. Some distributed ledger architecture such as Ripple and a Directed Acyclic Graph (DAG) are not block chain based, but suffer from various problems similar to those described here in detail for block chain.

Perhaps the most critical of these is the lack of scalability possible with such an architecture. Being vertical in nature, all nodes and miners within the network need to receive a copy of all blocks, past, present and future, in order to be in synchronization with a global state and operate correctly.

Currently the size of a Bitcoin block is 1 MB, and is sufficient to process 3-5 transactions per second without issue. However, as the block size increases to facilitate higher transactional throughput, the propagation time of a block to all nodes in the network also increases. Eventually this propagation time is longer than the interval, 10 minutes for Bitcoin, in which blocks are created. Miners do not receive the latest blocks in a timely manner and so create new blocks based on old knowledge. The network becomes saturated with blocks that are competing with each other and network throughput drops drastically. At this point, increasing the block size further only exaggerates the problem due to CAP theorem and data transmission limits due to speed of light limitations.“CAP” stands for Consistency, Availability and Partition tolerance.

This saturation point has been calculated to begin at around 400-500 transactions per second and to become critical at 800-1000 transactions per second, or at block sizes of 125MB to 250MB respectively. For comparison, global debit and credit card payments average in the region of 3000-5000 transactions per second, with peaks in the 10,000s and would require blocks Gigabytes in size. Further adding to the scalability issues is the requirement that miners need as much knowledge about current pending transactions in the network as possible in order to create blocks efficiently. T ransactions are broadcast around the network individually to all nodes prior to being included in a block, which results in transactions being broadcast twice, once when created, and again when included within a block. This further consumes available network bandwidth and increases overall block propagation time.

Another pressing issue is the resource consumption of the consensus mechanisms. Most distributed ledgers utilize some form of resource consumption to drive the consensus mechanism. The most popular is proof of work, the resource consumed being computing power by calculating hashes in order to discover a valid block hash, which in turn consumes electricity. Presently Bitcoin has been calculated to be consuming around 10GW of electricity to perform its consensus, with Ethereum not far behind, with consumption increasing as these networks grow and competition between miners intensifies. There is also no correlation between the amount of resources consumed to provide consensus with the throughput capacity of the network.

Other consensus mechanisms include proof-of-stake, proof-of-activity, proof-of-burn, proof-of-capacity, and proof-of-elapsed-time. Each has been criticised. For example, in proof-of-stake there is little incentive to act well (the“nothing-at-stake” problem). Proof-of-activity suffers from the same problem, and is also computationally intense like proof-of-work. Proof-of-burn requires the destruction of value and is financially expensive. Proof-of-capacity suffers from the nothing-at-stake problem and requires vast amounts of storage resources. Proof-of-elapsed-time has potential issues with trust.

Secondary consumption is also a factor as the act of mining requires large amounts of hardware to perform the task and to stay competitive, which itself wears out over time, becomes unserviceable and is then a waste product.

Another concerning issue is the tendency of current distributed ledger technologies to centralize over time, especially when operating in a public environment. This centralization is a two-fold issue, and is a consequence of both the consensus mechanisms currently employed and the lack of incentive for nodes in the network to keep a copy of the ledger.

Centralization due to the consensus mechanism revolves around the fact that they are resource based and employ a rising difficulty parameter as competition between miners increases. As this difficult parameter increases, it becomes more expensive to take part in the mining process and be profitable. Miners with smaller operations, or limited capital to buy the resources they need, halt their operations as they can no longer compete. This ultimately leads to a small number of very large mining operations, which compromises general security, reduces the attack surface, and makes collusion and abuse between these miners much easier. The second centralization effect concerns the nodes that keep a copy of the full ledger present in the network. Due to the vertical architecture of block chains, and the fact that all blocks are required to ensure a correct global state, the amount of storage space needed to store a full copy is forever increasing in size. These“full nodes” are also the main data providers to new nodes that join the network who wish to synchronize, which places an additional requirement upon them for fast internet connections. Full nodes are not rewarded in any way for providing this critical and necessary function, yet there is a significant cost associated with operating one. As these costs increase, the operators of these full nodes may decide to halt providing this critical service as it is purely voluntary. This may again lead to a small number of entities controlling the majority of these nodes, therefore compromising general security, reducing the attack surface, and enabling possible collusion and abuse.

A further disadvantage of block chain is that, in order to retrieve information regarding past events, for example to obtain an entity’s balance, one must access and scan the entire block chain. This takes a long time and makes real time transactions, for example retrieval of money from cashpoints, problematic. Technical solutions exist that can mitigate this problem to a degree, such as smart caching of frequently accessed information to memory, but ultimately these solutions only push the issue to another area over the long term (there will be large memory requirements to store the cache) as the block chain continues to grow in size.

Ethereum is an open-source, public, block chain based distributed computing platform similar to Bitcoin but with the inclusion of a feature allowing turing complete logic (scripting) to be executed upon various actions. These scripts are known as smart contracts and allow developers to create markets, store registries of debts or promises, move funds in accordance with instructions given long in the past (like a will or a futures contract) and provides a platform for development of other decentralised applications. Ethereum provides a digital currency token called "ether", which can be transferred between accounts and used to compensate participant nodes for computations performed. Ethereum’s transactional throughput is similar to Bitcoin’s and suffers from the same saturation effect in much the same manner.

It would be advantageous to provide distributed ledger technology or architecture which addresses one or more of the above-described problems. In particular, it would be advantageous to provide distributed ledger technology or architecture which is scalable for use in a wide range of applications. For example, as far as digital currency transactions are concerned, it would be advantageous to provide improved transaction throughput and reduced settlement times from those of the current technology or architectures. It would also be advantageous to provide an improved consensus mechanism or, in more general terms, an improved verification mechanism, that does not centralize over time, nor consume large amounts of resources. Summary

The present disclosure effects an improved digital ledger technology or architecture that is based on cooperation/collaboration between nodes. This is in contrast to the resource-intensive competition approach of block chain.

According to an aspect of the present disclosure, a computer-implemented method for performing by a node (or “computer node”, the terms being used interchangeably herein) of a network of nodes maintaining at least part of a distributed ledger maintained by the network of nodes is disclosed. The method may comprise receiving a record intended for the distributed ledger and may comprises receiving verification data for the record. The verification data may comprise a node identifier and may also comprise a corresponding assigned event state for each node which has previously verified the record. The method may comprise assigning an event state to the record, wherein the event state may be provided by a logical clock for the node. The method may comprise, conditional on the node verifying the record, updating the verification data to include an identifier for the node and the assigned event state. The method may also comprise, conditional on the node verifying the record, storing, in the at least part of the distributed ledger maintained by the node, the record and the updated verification data. The method may also comprise, conditional on the node verifying the record, transmitting the record and the updated verification data to at least one node of the network of nodes which has not previously verified the record.

The event state for a node at a given time may be considered a local event state for that node. Typically, each node in the network will update its event state for each record received by the node.

The local event state may be provided by a logical clock for the respective node, such as a Lamport clock, Vector clock, Matrix clock or any other logical clock or counter operable to produce partial or total ordering when updating its local event state. Updating a local event state may comprise incrementing a logical clock value. The local event state will typically be updated based on receipt of a record.

Nodes may be configured to maintain at least part of the distributed ledger. The distributed ledger (or part of the ledger) is configured to store records and associated verification data for the records.

As the verification data stored by each node contains a record of the sequence (or series) of nodes which received the record prior to that node, and the respective event states assigned to the record by those nodes, the ledgers of any nodes that attempt to change the record or verification data (e.g. through malfunction or malicious activity) will no longer match the copies of the ledger of the rest of the network. Verification data stored at the nodes of the network will therefore be able to verify the record and detect the malfunctioning or malicious node.

The method performed by the node may be considered to be part of a verification procedure (or cooperative verification procedure) which comprises multiple nodes in the network verifying the record when they receive a record and associated verification data from another node in the network. Suitably, each node can perform the method.

The verification procedure may be considered to implement at least part of a verification mechanism. The verification procedure may be considered as a consensus procedure which, in turn, may be considered to implement at least part of a consensus mechanism. The verification data may be considered as consensus data.

The sequence or branch of nodes along which the record passes during the verification procedure for the record may be considered as a path (or“causality path”) which preserves the sequential order and corresponding event states of each of the nodes which verified the record as it passed through the network. Each node can store its own unique sequence of nodes, the sequence identifying the path preserving the sequential order and corresponding event states of each of the nodes which verified the record as it passed through the network before being received by the node. Typically, the path will also include the position in the order and corresponding event state of the node itself.

The transmitting may comprise transmitting the record and the updated verification data to a plurality of nodes of the network of nodes which have not yet verified the record.

An efficient transmission mechanism for transmitting records and verification data to nodes of the network is typically used. For example, the transmitting may comprise transmitting using a gossip protocol.

The verification data may comprise, for each node which has previously verified the record, an associated digital signature for the respective node. Any form of digital signature or digital signing may be used. This includes the commonly used hashing and signing using public and private encryption keys. Digital signatures from each node may be applied to construct a hash chain as the verification data is passed along a series of nodes. Digital signatures are not necessary in certain implementations, for example those using secure or permissionless networks.

The verification data may comprise, for each node which has previously verified the record, a check value for the corresponding assigned event state. The check value may be used to verify that the event states assigned or reported by one or more nodes of the network are accurate. The check values may involve the use of Merkle trees and/or checksums.

The verification data may comprise a hash of the record. Typically, though not necessarily, only one node need incorporate a hash of the record in the verification data. The hash of the record may be considered a record identifier for the record. The level of verification that a node performs to verifying a record is implementation specific. For example, for simple implementations, verifying the record may simply involve the node accepting the record inclusion in the distributed ledger. Verifying may comprise checking the record for compliance with one or more defined criteria. For example, the checking may be to check for format, the contents of the payload, encryption properties or any other defined criteria. Different nodes may perform different levels of verification of a record.

The record may consume a respective association of a respective item with a respective entity. Verifying the record may comprise verifying against the distributed ledger that the association has not already been consumed.

The record may comprise a digital currency transaction. Verifying the record may comprise verifying the transaction against the distributed ledger. More specifically, verifying the record may comprise verifying the transaction against the distributed ledger to check for a conflict between the received record and a record already stored in the ledger which has already transacted or spent the digital currency consumable (e.g. token, coin or one-time use coupon) that the digital currency transaction is attempting to transact or spend. That is verifying the record may be to mitigate against“double spends”.

The method may comprise, conditional on the node not verifying the record, rejecting the record. Typically rejected records are not used during the processing of further records, but a log of records that have been rejected may be maintained. A node may therefore reject a record but still store the record in a rejected state, for example in a ledger or table of rejected records.

One or more nodes may have a respective endorsement weight. An endorsement weight of a node can be considered a measure of the node’s trustworthiness or activity in maintaining the network. Optionally, the record may have an endorsement weight which may be used to increase the endorsement weight of one or more nodes that verify the record.

The node may have an endorsement weight. Optionally, the endorsement weight may be increased by verifying the record.

The node may have an endorsement weight which may be increased by verifying the transaction.

A particular node’s endorsement weight may increase as the node processes records. This may occur every time a node processes a record or only sometimes. For example, in various implementations the endorsement weight of a record may be (i) shared between all or some nodes which verify the record; (ii) given, in totality, to one node which verified the record; or (iii) given, in totality, to some or all nodes which verified the record. Where a record consumes a respective association of a respective item with a respective entity, the endorsement weight of the record may be based on the value of the item consumed by the record and/or the amount of time since the item was last consumed.

Where a record comprises a digital currency transaction, the endorsement weight of the record may be based on the value of a digital currency consumable (e.g. token, coin or one-time use coupon), transacted by the digital currency transaction and/or the amount of time since the digital currency consumable was last transacted. This helps mitigate against a malicious actor accumulating endorsement weight by flooding the network with many low-value transactions in a short period of time.

At least some of the nodes of the network may have a respective endorsement weight. Where records consume a respective association of a respective item with a respective entity, the method may comprise resolving a conflict between received records attempting to consume the same consumable association. This resolving may be by using the logical clock values in the verification data of each record to see which record was presented to the network first. Additionally or alternatively, for example when comparing the logical clock values in the verification data would be inefficient, this resolving may be by performing a comparison based on endorsement weights for the records. Where records comprise digital currency transactions, the method may comprise resolving a conflict between received digital currency transactions attempting to transact the same digital currency consumable. This resolving may be by performing a comparison based on endorsement weights for the transactions. It will therefore be apparent that the use of endorsement weights provide an additional way of mitigating against“double spends” or, more specifically, of resolving conflicts between conflicting records. As the disclosed methods are not limited to digital currency transactions,“double spends” are here taken to mean any conflicting attempt to use, transact or register an item more than once.

A respective endorsement weight for at least some of the nodes of the network may be stored in a table of endorsement weights. This advantageously means that nodes can quickly look up the endorsement weights of other nodes. Of course, it will be apparent that this is not necessary and in some arrangements endorsement weights may be retroactively calculated by determining which transactions or records a particular node has processed and received endorsement from.

According to another aspect of the present disclosure, a computer-implemented method is disclosed. The method may comprise configuring at least some of a network of nodes to perform any of the methods described above or elsewhere in this disclosure. In use, records and verification data may be transmitted through branching paths across the network.

According to another aspect of the present disclosure, computer-executable instructions are disclosed, when executed on a computer, cause the computer or network to perform any of the methods described above or elsewhere in this disclosure. According to another aspect of the present disclosure, a computer node comprising at least one computer processor and at least one computer memory is disclosed, wherein the computer memory comprises computer-executable instructions which, when executed, cause the computer node to perform any of the methods described above or elsewhere in this disclosure.

Nodes of the network, which may be a peer-to-peer network, may be configured to perform a method described above or elsewhere in this disclosure.

According to an aspect of the present disclosure, a network of nodes maintains a distributed ledger. Nodes in the network maintain at least part of the distributed ledger. The distributed ledger is configured to store records and associated verification data for the records. The verification data for a record is constructed using a method described above or elsewhere in this disclosure. One or more nodes can be queried to verify a record which is stored in the at least part of the distributed ledger maintained by the respective node(s). The verification data associated with the record can be used to verify the record.

Accordingly, it will be appreciated that an improved distributed ledger technology or architecture is provided. Improved speeds of storing to a distributed ledger can be achieved. A digital ledger technology is provided which is scalable for use in a wide range of applications. As far as digital currency transactions are concerned, improved transaction throughputs are provided. When using the disclosed ledger technology / architecture to store digital currency transactions, transactions per second (tps) throughput can increase linearly with the number of nodes present within the network. Generally, every 10 nodes in the network increases network throughput by around 1000 tps when using commodity hardware. Verification procedures (or consensus procedures) that form at least part of an improved verification or consensus mechanism are also provided. For example, a verification mechanism is provided which is not prone to centralization over time and which does not consume the large amount of resources that known architectures consume.

Brief Description of the Figures

Illustrative implementations of the present disclosure will now be described, by way of example only, with reference to the drawings. In the drawings:

Figure 1 shows a schematic representation of a network of computer nodes;

Figure 2 depicts a stack model for the distributed ledger;

Figure 3 shows a schematic representation of a computer;

Figure 4 shows data stored in a ledger maintained by a computer node for a first implementation; Figure 5 shows a record for inclusion in a distributed ledger as well as associated verification data for the record;

Figure 6 shows the verification data comprising verification coordinates for a record for the first implementation;

Figure 7 shows an overview of the method performed by a node of the network to verify a record as part of a verification procedure;

Figure 8 shows data stored in a ledger maintained by a computer node for a second implementation; and

Figure 9 shows a method of resolving a conflict between records.

Detailed Description

This detailed description begins by describing with reference to Figure 1 a network of computer nodes on which implementations of a distributed ledger can be maintained. A conceptual stack model showing how the same ledger functionality can support different applications is then described with reference to Figure 2. Figure 3 is used to describe the components of a computer that can be used as a computer node in the network. A first, simple implementation relating to the storing of emails is then described with reference to Figures 4 to 6. Figure 7 describes a method applicable to all implementations. A second implementation relating to records comprising digital currency transactions is then described with reference to Figure 8. A third implementation relating more generally to consumable associations is then described. The features of the different implementations and those of the variations are not mutually exclusive. Rather, the features of all implementations and those of the variations can be used with one another and with those recited in the claims.

Referring to Figure 1 , a network 100 comprising a plurality of nodes 102 to 1 12 is shown. Computers A and B are computers that can connect to the network 100. Computers A and B are user computers (or other electronic devices) which typically play no active part in storing and maintaining the distributed ledger, or in the associated verification procedures that will be described.

Nodes 102 to 1 12 are connected by the network 100. Network 100 may be any suitable network, such as the internet. User computers A and B can connect to the network using any suitable technology, for example via a wireless or wired connection.

Figure 2 depicts a conceptual stack model for the distributed ledger architecture. The Network Layer 101 provides data routing paths for network communication between nodes. The Ledger Layer 103 is the layer that handles the non-application specific elements of the distributed ledger technology, which include processing and verifying records intended for the ledger, storing records in the ledger, and storing verification data associated with each record. The Application Layer 105 supports the application specific functionality including application specific functionality for the particular implementation, the structure of the record and user interaction. Records comprising record data are created in the Application Layer and are then passed to the Ledger Layer for processing. Example applications that may be supported in the Application Layer 105 include applications relating to digital currency transactions, the recording of ownerships of items or of other non-currency related transactions, and storing records of legal documents.

Figure 3 shows a schematic and simplified representation of a computer node 200 which can be used to perform the described methods. Computer nodes 102 to 1 12 and user computers A and B can have the general structure of computer node 200.

The computer 200 comprises various data processing resources such as a processor 202 coupled to a central bus structure. Also connected to the bus structure are further data processing resources such as memory 204. A display adapter 206 connects a display device 208 to the bus structure. One or more user-input device adapters 210 connect a user-input device 212, such as a keyboard and/or a mouse to the bus structure. One or more communications adapters 214 are also connected to the bus structure to provide a connection to the network 100.

In operation, the processor 202 executes a computer program comprising computer executable instructions that may be stored in memory 204. The results of the processing performed may be displayed to a user via the display adapter 206 and display device 208. User inputs for controlling the operation of the computer system 200 may be received via the user-input device adapters 210 from the user-input devices 212.

The described implementations will refer to a node or nodes (or processes or procedures at a node or nodes) performing particular steps or operations. It will be appreciated that in the described implementations these steps or operations are performed by the processor of the node or nodes based on instructions that are stored in memory. Procedures or operations described as being performed by a layer of the conceptual stack model are similarly performed by the processor of the node or nodes based on instructions that are stored in memory.

As a brief overview, in the described implementations when a record from an application in the Application Layer 105 is to be included in the ledger, procedures in the Ledger Layer 103 perform a verification procedure for the record. The verification procedure involves the record being passed along nodes of the network, for example using a gossip protocol, so that the record is rapidly disseminated throughout the nodes of the network of nodes. Nodes in the network are configured to update a unique local event state for the node on receiving a record and to assign the updated event state to the received record. Nodes are also configured to update verification data for the record as they verify the record, as will be described in detail in relation to Figures 5-7 below. Nodes store verified records and associated verification data in their copies of the distributed ledger (or the part of the distributed ledger that they maintain).

When viewed at the network-wide level and using a method in which a node transmits a record and its associated data to a plurality of other nodes of the network which have not yet verified the record, the record and its associated verification data are transmitted through branching paths across the network during the verification procedure. The sequence or branch of nodes along which the record passes during the verification procedure for the record may be considered as a path (or“causality path”) which preserves the sequential order and corresponding event states of each of the nodes which verified the record as it passed through the network to the node. This sequence is recorded in the verification data. If a potential conflict arises between two records such as duplication of a record, the verification data can be used to determine the relative chronological order of the two records and the later record can be rejected. That is, the verification data, and thus the causality paths, of multiple records can be compared in order to determine a relative ordering of records. Also, stored records can be queried later to verify them.

A first implementation will now be described. In the first implementation, the local event state of a node is determined using a logical event clock. In the first implementation the logical event clock is a Lamport clock, although variations use other logical event clocks. The event states assigned by a node to received records in the first implementation are therefore logical event clock count values or, more specifically, Lamport clock values. In the first implementation, a node updates its local event state each time it receives a record as part of a verification procedure.

An aspect of the first implementation provides a way to store records and associated verification data in the distributed ledger. Figure 4 shows data stored in a ledger for the first implementation. The ledger is maintained by a computer node which stores records that have been verified by the node. In this first implementation, each record in the distributed ledger is a record of an email sent from one user to another, for example from user A (the user of user computer A running an email application using the distributed ledger architecture) to user B (the user of user computer B also, although not necessarily, running an email application using the distributed ledger architecture). When user A sends an email using the application, the Application Layer 105 running the email application generates or creates a record containing record data. In this first implementation the record data comprises a payload, which comprises the sender of the email, the receiver of the email, the send time, the email text and the attachments.

In the first implementation, the copy of the ledger stored locally by each node in the network stores records of emails that have been sent and stored in or persisted to the distributed ledger. For each record, the ledger of a node stores a record identifier (ID) for that record, an assigned event state assigned by the node to that record when it received the record, verification data for that record, and the record itself. The ledger entry shown in Figure 4 relates to a record of Email 1001 . The thus entry comprises: the record ID of the record of Email 1001 ; the event state assigned to the record of Email 1001 by the node; verification data for the record; and the record itself, comprising the record data which comprises a payload.

The record ID of a record is a unique identifier which identifies a particular record. In this implementation, the record ID is a number generated by hashing the record (or, more specifically, the record data). This has the advantage of protecting the record against tampering - even a small change to the record will result in a noticeable change to the value generated by hashing the record. The new hash value will not match the record ID, and so the tampering can be detected.

The assigned event state recorded for a record in the ledger is the local event state which the node maintaining the ledger assigned to the record when it received the record. Active nodes typically receive a record during a verification procedure for the record. Nodes which join later, for example a new node or a node which has been inactive or offline, can receive records that have occurred when they have been inactive via an update procedure. An update procedure involves a node querying other nodes for data which it may be lacking in its distributed ledger.

The verification data for a record comprises data added by nodes which have verified the record. This will be described in more detail in relation to Figures 5-7. In this implementation each node which verifies the record updates the verification data when it verifies the record. Thus, as the record passes through the network of nodes, the verification data for the record changes. Each node therefore stores a unique version of the verification data for a record.

The record comprises record data which in this implementation comprises a record payload. The payload contains the details of a deliverable or delivered item. In the first implementation, the record relates to an email. Therefore, the payload comprises the relevant data for the email, as has already been described.

Figure 5 shows a record and verification data for the record. As nodes verify the record, they update the verification data and then transmit the record and updated verification data to a next node so that that node may also verify the record and update the verification data.

As records are transmitted between nodes of the network of nodes for verification, each node which verifies a particular record updates the verification data for that record. In particular, in this implementation, each node updates the verification data to include a new verification coordinate. The verification coordinate added to the verification data by a particular node indicates the identity of that node and the event state assigned to the record by that node. Thus, for a particular record, the verification coordinates assigned to it by various nodes effectively chart a causal history of the record’s verification, namely which nodes verified the record and which event states were assigned to the record by those nodes. By comparing the verification coordinates (in other words the verification data as a whole) of multiple records, a relative chronology or relative ordering of when the various records were processed by respective nodes of the network can be determined, as already mentioned.

The structure of the verification data in the first implementation is shown in Figure 6. The verification data comprises the record ID of the record which, as previously mentioned, is a hash of the record data in this implementation. As described above, the verification data also comprises a number of verification coordinates, one for each node which has verified the record.

With reference to Figure 6, RID is the record ID which, as previously described, is in this implementation a hash of the record data. Other means of identifying the record will be apparent.

V 1 is the verification coordinate added to the verification data by the first node of the network of nodes to verify the record, for example node 102 of Figure 1. Vi in this implementation comprises the ID of the first node 102 and the event state assigned to the record by the first node 102. In other words, verification coordinate V₁ = (N1_ID, N1_ES) where Nl_w is the ID of the first node to verify the record and N1_ES is the event state assigned to the record by this node.

Similarly, V2 is the verification coordinate of the node of the network of nodes, for example node 104 of Figure 1 , which received the record from the first node 102 and subsequently verified the record. In other words, V₂ is the verification coordinate of the second node in this particular sequence or branch of nodes to verify the record. V₂ in this implementation comprises the ID of the second node 104 and the event state assigned to the record by the second node 104. In other words, verification coordinate V₂ = ( N2_ID, N2_es ) where N2_W is the ID of the second node to verify the record and N2_ES is the event state assigned to the record by this node.

As will be described in more detail in relation to Figure 7, in this implementation the record is transmitted between nodes by a gossip protocol so that it is rapidly disseminated throughout and verified by the network of nodes. Each node which receives and verifies the record will, in this implementation, add its own verification coordinate to the verification data for the record. Thus, if n nodes verify the record, the verification data will, in this implementation, comprise n verification coordinates. The verification coordinate added by the last of n nodes to verify the record will accordingly be V_n, where V_n = (Nn_ID, Nn_ES).

It will be apparent from the above that the verification data stored by each node will be unique in this implementation. For example, the verification data stored by the second node to verify the record will contain the verification coordinates of the first and second nodes (Vi and V₂). The verification data stored by the third node will contain the verification coordinates of the first, second and third nodes (Vi, V₂ and V3), and so on. Each node therefore has a unique“view” of the verification of a record and the causal history of the record’s progression through the network and verification by the network. These unique views can be corroborated to determine a consensus about a particular record’s causal history. This can be used to provide relative ordering of multiple records to determine which record was received by the network first. Relative ordering of records (or of the“events” of the network receiving records) can thus be determined without need for recourse to a centralised authority, and without any need for complex and the need for resource-inefficient proof of work systems, such as that employed by block chain. The relative ordering of records can also be used to solve conflicts between records and prevent “double-spends”, as will be described in relation to the second implementation.

In a variation, the verification coordinate added by a node also comprises a check value for the corresponding event state assigned to the record by that node. The check value may be used to verify that the event state assigned by the node is accurate. In this variation the check value can be considered a“commitment”. A commitment is a cryptographically secure, compact representation of event states assigned by a node.

In one variation, a Merkle Tree is constructed and populated with the hashes of all event states assigned by a node since its previous commitment, from which a Merkle Hash can be derived. A commitment of the form C = (h, I, Nn_w, t, s) is then created where; h is the Merkle Hash, / is the event state (logical clock value) assigned to the last record by the node, Nn_w is the ID of the n^th node, t is the node’s wall clock timestamp, and s is a cryptographically secure signature.

The commitments form a linked sequence over time, where the first“leaf” of a commitment’s Merkle Tree references the previous commitment a node has submitted, unless it is the initial commitment to the network.

The commitments a node has produced and submitted to the network may be audited by other nodes at any time. When a node is the subject of an audit, it delivers the leaf hashes in event state (logical clock) order, to the auditing node. The auditing node will then reconstruct the commitment hash and verify its integrity. If a node has tampered with the event states it has assigned, the auditing node will be able to ascertain this. The inevitability of an audit by other nodes, at unknown time intervals, discourages tampering of event state values and commitment sequences, as such tampering is easily and cheaply detectable through the above method.

In a variation, the verification coordinates also comprise a coordinate time value at which the node received the record. The coordinate time value can be helpful for allowing nodes that have been offline to update quickly, because nodes can quickly determine whether a record entered the network during a time that the node was offline or unavailable.

In a variation, the verification coordinates also comprise a digital signature. In other words, the verification data comprises, for each node which has previously verified the record, an associated digital signature for the respective node. In a variation, each node verifying a record digitally signs the data (e.g. the verification coordinate) it produces. This ensures that any tampering with the data will be prevented, or at least will be detectable. A node only signs its own data (e.g. verification coordinate) in one variation. In another variation, it also signs the remaining verification data (e.g. verification coordinates created by other nodes). In the latter case, the digital signature provides additional security by signing not only the data (e.g. verification coordinate) added to the verification by the signing node, but also the verification data (e.g. verification coordinates) provided by the previous nodes that verified the record. This, for example, prevents a malicious node from altering the verification data it receives from other nodes.

Figure 7 shows an overview of the method performed by a node of the network to verify a record as part of a verification procedure. The method shown in Figure 7 applies to all described implementations and variations, though the way in which the node performs the verifying (step 406) will of course vary.

The Application Layer passes a record to the Ledger Layer. A first node of the network, for example node 102 of Figure 1 , receives the record and verification data for the record at step 402. It will be appreciated that, in a variation, node 102 may create the verification data for the record as it is the first node to receive the record.

Node 102 updates its local event state (for example Lamport clock value) upon receiving the record. At step 404, the node 102 assigns the updated event state to the record.

At step 406, the node 102 verifies the record. Verifying the record in the first implementation may comprise checking whether the record satisfies various formal requirements. These formal requirements may include rules like“the record data must comprise a payload indicating: Sender, Receiver, Send time, Email text”. It will be apparent that any number of formal requirements may be checked for at this stage, and the requirements will vary based on the implementation and the network environment. Verifying the record may also comprise checking whether a record already exists in the node’s distributed ledger which conflicts with the newly received record. For example, in simple implementations such as the first implementation, verifying the record may comprise checking that a duplicate record does not already exist in the distributed ledger of the node performing the verification. More complex implementations and variations may comprise more complex verifications at this stage, which will be described in more detail in relation to the second implementation.

Conditional on the node verifying the record (e.g. the record passing whatever checks the node performs and/or the node not objecting to the inclusion of the record in the distributed ledger), the node 102 updates the verification data for the record at step 408. In the first implementation, the updating involves the node 102 adding a verification coordinate to the verification data, as described in relation to Figures 5 and 6.

If the node does not verify the record (for example the record does not pass whatever checks the node performs), the record is rejected by the node 102. This rejection may be notified to, for example, the node that record was received from, or some or all nodes of the network and, ultimately, the relevant user. If the node is rejected at step 406, then steps 408 to 412 are not carried out.

At step 410, the node 102 stores in the part of the distributed ledger maintained by the node 102 the record and the newly updated verification data for the record.

At step 412, the record is transmitted by node 102 by a gossip protocol to other nodes of the network. In other words, in the first implementation node 102 transmits the record and updated verification data to all active (online) neighbouring nodes.

In this variation, node IDs are used to determine which nodes are a particular node’s neighbouring nodes in the network. In this variation, each node’s ID is an integer identifier derived from a public key of the node. These IDs are used to determine which nodes in the network are the node’s neighbouring nodes, by selecting a predefined number of nodes which have the closest integer identifiers to the node’s integer identifier. Active nodes are those that are online. A record of active nodes can be maintained by nodes informing each other of when they are online or can be derived directly from verification data.

In this implementation, the node transmits the record and verification data, via a gossip protocol, to its active neighbouring nodes

Many variations in terms of which nodes the record and updated verification data are transmitted to will be apparent. For example, in a variation, the record and verification data are sent to all nodes that are online and that the transmitting node is aware of. In another variation transmittal does not involve a gossip protocol.

The process described above and shown in Figure 7 is then repeated by each node that receives the record. In the first implementation, the verification procedure of transmitting a record to nodes of the network for verification ends once all active (online) nodes of the network have a copy of the record in their respective ledger. It will be apparent that in other implementations and variations the verification procedure for a record may end at a different time, for example once a pre-determined number or proportion of nodes of the network has received the record.

The record is thereby disseminated throughout the network, and causality paths for the record are built up. It will be apparent that the nature of the causality paths built up for a record will be determined by the method of transmittal. For example, where a gossip protocol is used, the record is sent along branched sequences across the network. For example, Node 102 may transmit the record and verification data to nodes 104 and 106. Node 104 may then transmit to node 108 and 1 10 while node 106 transmits to node 1 12. Each node will perform the process described above in relation to Figure 7, and each node will store a unique set of verification data for the record comprising its own verification coordinate and the verification coordinates of the nodes which verified the record before it. It will be appreciated that the exact order in which the steps of Figure 7 are carried out can be varied, and the order described here is not intended to be limiting.

In some variations, a pre-transmitting step may be included before step 412 of Figure 7. During this pretransmitting step, a node may transmit the record ID of a record it is about to transmit. This enables nodes receiving the record ID to check their ledgers to determine whether they have already received and stored the record (and associated verification data) in question, for example from another node of the network. The record and verification data are then advantageously only transmitted, at step 412, to those nodes which have not previously received the record. Thus, redundant transmission of data is reduced, because the record is only transmitted, at step 412, to those nodes which have not previously received it.

It will be appreciated that the precise manner in which this pre-transmission step is accomplished will vary. For example, a node which receives a record ID and has not yet received the record may request to be included in the list of nodes to which the record and verification data are transmitted to at step 412. Alternatively, a node may be given a pre-determined time period to inform the transmitting node that it does not require the record and verification data. If no objection is sent, the node in question will receive the record and verification data during the transmission at step 412.

It will be appreciated that other means of communicating records and verification data are possible, and the details of how, when and to which nodes records and verification data are transmitted at step 412 will vary depending on the specifics of the implementation environment. The examples described herein are therefore not intended to be limiting.

As mentioned previously, nodes can receive updates from other nodes. This may be used to enable a node which has been offline to update its ledger with records that have been processed by the network while the node has been offline. It will be appreciated that, as in the case for transmitting records during verification procedures, the manner in which records are transmitted during update procedures will also be implementation dependent. For example, typically but not necessarily, nodes which come online can request, via a gossip protocol, information from other nodes indicating which records they have processed while the requesting node was offline. The node may then receive, for example, a list of record IDs from each queried node, indicating the records which that node has processed in the time period indicated. The requesting node can then request the full record and verification data for all those records which are not already stored in its ledger.

While the above described update method is typically an efficient method of updating, it will be apparent that other methods may be used. For example, a node may update its ledger by being sent all record data and verification data in full. The updating node then stores those records which it lacks and discards those records which are already present in its ledger. The updating node may perform a full verification (namely by performing the process described in relation to Figure 7) on records received during updates. Alternatively, nodes may simply add records received during updates to their ledgers without performing any verification (e.g. without performing all steps of Figure 7).

A first implementation has been described in detail and some variations have also been described.

A second implementation will now be described. Whereas the first implementation related to an email- based implementation, the ledger of the second implementation is used to store records relating to transactions of digital currency.

Figure 8 shows data stored in a ledger for the second implementation. In this implementation, records comprise digital currency transactions. Verifying a record may therefore be considered to comprise verifying a transaction against the distributed ledger. Figure 8 is very similar to Figure 4, with the exception that now a“transaction ID” is stored (because the records in this implementation relate to transactions). The assigned event state and verification data are stored for a transaction in this implementation in the same manner as in the first implementation.

In the second implementation, rather than comprising record data relating to an email, the ledger stores transaction data. In particular, the record stores digital currency data which, in this implementation, indicates which digital currency tokens were spent during the transaction.

In the second implementation, the process performed by each node to verify a record is the same as in the first implementation (described in relation to Figure 7 above), with the exception that step 406, where the node verifies the record, now comprises an additional check to ensure that the tokens to which the transaction relates have not already been spent. This can be determined by checking the digital currency data of the transaction and comparing this data with digital currency data of records stored in the node’s ledger. Alternatively, this process may be made more efficient if nodes maintain a table of tokens and associated ownership of those tokens. This can then be updated as new transactions are recorded to the ledger. The table can then be checked every time a new transaction is verified, to ensure the digital currency data conforms with the table of token ownership.

A third implementation will now be described. The third implementation is similar to the second implementation, except it relates to any kind of consumable association whereas a digital currency token associated with particular account can be considered a particular consumable association.

A consumable association is an association that can be consumed or used up in some way. Non-limiting examples of association that can be used up relate to an association associating an entity (e.g. a person, business, legal entity, place or thing) with a particular item (which can include an object or role). The association, for example ownership or allocation of an object or formal assignment of a role could be changed to another entity and would no longer be associated with the former entity. In other words, the association that formerly associated an entity with that particular item, would have been used up or consumed. Importantly, for example if the item was a physical entity being sold, it is important that the same consumable association is not consumed or spent more than once.

In the third implementation, the record comprises a record which consumes a consumable association between an entity and an item (e.g. the ownership by a person of a car). In this implementation, the verifying of the record by a node (step 406 of Figure 7) comprises checking the distributed ledger that the consumable association has not already been consumed by another record. This can be determined by checking the data of the record and comparing this data with data of records stored in the node’s ledger. Alternatively, this process may be made more efficient if nodes maintain a table of items and the association of those items with a current entity. This can then be updated as new records re-associating the item with another entity are recorded to the ledger (e.g. in the way that would happen if a car was sold by one person to another). The table can then be checked every time a new record is verified, to ensure the record data conforms with the table of item association.

If, in the third implementation, it is determined that two records relate to consuming the same consumable association or, in the second implementation, spends the same tokens, (i.e. that there are conflicting records), this conflict can be resolved by determining, from the verification data for each record, which record was received by the network first. This process will be described in greater detail with reference to Figure 9.

In the above-described methods, assuming a gossip protocol is used, records are typically verified by and disseminated throughout substantially the entire network within about 5 seconds of entering the network.

Thus, if a record conflicting with an earlier record (e.g. a“double spend”) is submitted to the network more than 5 seconds after the earlier record, the record will typically be rejected by the first node which receives the later conflicting (double spending) record, because the node will already have the earlier record in its ledger.

In some cases, a malicious actor may instruct one or more nodes under their control to ignore previously verified records in order to verify a record which conflicts with a record already stored by the nodes of the network (e.g. a record which comprises a double spend, or would do if accepted to the ledger by the network). However, such an attempt will be foiled because at some point the conflicting later record will have to be passed to a node not under the control of the malicious actor. This node will then detect a conflict between the two records.

Because in this case the new record has been verified by some nodes (those nodes under the control of the malicious actor, in this example), each of the two conflicting records is effectively being supported by a different group of nodes. In other words, there is a disagreement or lack of consensus about which record to reject. The node which detects the conflict must therefore resolve this conflict.

One method of resolving this conflict according to a variation of each implementation is described with reference to Figure 9. Figure 9 shows sequences of nodes which verified two conflicting records. Record J was verified by nodes 1-5, and Record K was verified by nodes 6-10. Records J and K are conflicting records.

In this case, the conflict is resolved by finding a third record that was received by at least one node in each set of nodes 1-5 and 6-10 during the respective verification procedure for that third record. In Figure 9, Record L was received by a node from each set (nodes 4 and 9 respectively) during its verification procedure. In this situation, the conflict between Records J and K can be resolved if the verification data for the records shows that the following criteria concerning record L is met:

(i) Record J was received by node 4 before Record L and Record L was received by node 9 before Record K; or

(ii) Record J was received by node 4 after Record L and Record L was received by node 9 after Record K.

In case (i), Record K was received by the network later and may be rejected. In case (ii), Record J was received by the network later and may be rejected.

Thus, if the arrangement of Figure 9 is applied to the above scenario, nodes 1-5 may be the nodes belonging to the malicious actor. Thus, in this example, record J is the conflicting (double spending) record. In this example, criteria (ii) will hold and this can be determined by the network once the conflict between records J and K is identified. Thus, the conflicting record J is rejected by the network. It will be appreciated that, if the scenario were the other way around (namely if nodes 6-10 were the malicious nodes), then criteria (i) would be met and record K would be rejected. In either case, the malicious conflicting record is rejected.

It will be apparent that the above-described functionality can be used to resolve non-malicious conflicts as well, such as those resulting from malfunctioning nodes or accidental duplication of records.

In some rare cases it is possible that a conflict between two or more records has been crafted in a manner by a malicious actor so that conflict resolution using the verification data in the manner described above is inefficient. For example, the verification data of too many records may need to be analysed before a record analogous to Record L, which was verified by a node of each“group” (1-5 and 6-10 respectively in the above example), is found. In another example, a record analogous to Record L may not in fact exist, for example if the malicious nodes have been acting in a portion of the network that is split from the remainder of the network for a period of time. To resolve conflicts in these cases, a variation of each implementation uses endorsement weights associated with nodes of the network to resolve conflicts between records. In particular, the endorsement weights of the nodes that took part in the verification procedure for each conflicting record are compared to determine which record should be accepted and stored to the ledger by the nodes of the network. This process will now be described.

Each node has an associated endorsement weight which is increased by verifying records. The particular way in which a node acquires endorsement weight by verifying records will depend on the environment in which the system is operating. Specifically, each network will have its own endorsement weight assignment policy which determines how endorsement weight is assigned to nodes.

For example, in one variation records have an endorsement weight too, which is used to increase the endorsement weight of one or more of the nodes that verify the record. For example, the endorsement weight of a record in the first implementation may derive from the length of the email in question.

In one variation, the endorsement weight of a record is pledged to the node which created the first verification coordinate in the verification data for the record. To prevent spoofing by malicious actors, the record can specify explicitly which node is to receive the endorsement weight, as the creator of the record will have to submit it to the network via a node that is present and active.

Advantageously, but not necessarily, all nodes maintain a set of endorsement weight tables, where each endorsement weight table represents a period known as an endorsement weight period. It will be appreciated that no method of timekeeping is 100% accurate, and errors in record timestamps due to node clock inaccuracies, drift and manipulation can occur. In order to mitigate these errors, endorsement weight periods are typically of a fixed duration which is sufficiently long, such as a day, to mitigate such errors. The endorsement weight tables typically record the known endorsement weight for all nodes allowing for easy retrieval of a node’s endorsement weight at any point in time. Nodes update their endorsement weight tables accordingly as defined by the endorsement weight transfer policy of the network they operate in.

In the case of conflicting records, the use of endorsement weights associated with nodes can be used to determine which of the conflicting records is/are rejected. In particular, the respective endorsement weights of all or some of the nodes involved in the verification procedure of each record respectively is summed in one particular variation. The record whose verifying nodes have the highest combined endorsement weight is maintained in the ledger, while the other is rejected. For example, in the scenario described above in relation to Figure 9, the endorsement weights of nodes 1-5 is summed and compared to the summed endorsement weights of nodes 6-10. The group of nodes with the higher total endorsement weights“wins”, and the record endorsed by that group of nodes is maintained in the ledger. It will be appreciated that, in reality, the group of nodes that represents the malicious actor will likely be very much smaller than the group of nodes representing the rest of the network (unless the malicious actor has been able to co-opt over half of the network, which is very computationally expensive in practice). The malicious actor’s nodes will thus“lose” in terms of endorsement weight when compared with the rest of the network in essentially all real-world scenarios. Malicious double spending is therefore prevented.

It will be apparent that this functionality can be used to determine which record is accepted and which are rejected for any number of conflicting records. It will also be apparent that the network’s specific endorsement weight transfer policy will determine precisely how such conflicts are resolved, and summing the endorsement weights of nodes is just one example of how endorsement weights can be implemented.

In more detail, in the case where records relate to the transfer of value (for example where the records relate to digital token transactions), the amount of endorsement weight associated with a record ( M_c ) may be calculated by summing the token quantity being transferred ( C_q ) and the age (Q) of each token association with the entity (e.g. user) that owns the tokens, such that M_c = C_q Q where M_c is capped to a sufficient value to prevent long range endorsement attacks.

In the described implementations and their variations, because each node updates the verification data before storing and transmitting it, along with the record, the verification data stored in a node’s ledger for a particular record will contain an indication of the event state assigned to the record by that node and all nodes which verified the record prior to that node. Thus, each node has its own unique“view” of the verification procedure, and in particular of the causality path of the record’s transmission through the network of nodes, depending on which and how many nodes received the record before it did. These various unique“views” can be corroborated, for example to determine which of two or more conflicting records was in fact received by the network first. In other words, because the verification data stored by a particular node will contain the event states assigned to the record by the nodes which verified the record before it did, consensus about the order in which nodes received one or more records can be reached. It will be appreciated that this consensus makes it very hard to tamper with the record data - a malicious node which, for example, modifies verification data for a particular record will be at odds with all the other nodes which verified that record. A tamper-proof method of verifying records is thus provided, without any need for a centralised authority or an absolute order of events to be determined. Relative order, created by combining and comparing the various unique“views” of the nodes of the network, is sufficient to enable the ledger to be secured. It will be apparent that at any point in the future, the verification data of the various nodes which verified a record can be used to verify the record in the manner described above.

The described methods enables the network of nodes to build a distributed ledger, in which each record in the distributed ledger is associated with verification data. This verification data can be checked to verify a record in the distributed ledger. For example, the verification data for a particular record can be checked at a later date in response to a user initiated request. A user may query a node to provide the verification data it stores for a particular record. This can be used to verify the integrity of the record, and to corroborate claims about when the record was submitted to the network. The user can query other nodes to corroborate (or not) the verification data provided by a particular node, if this extra level of security is required. In the case of a conflict between verification data provided to the user by certain nodes, multiple nodes can be queried to determine a consensus. Nodes which attempt to tamper with their verification data or provide false verification data can therefore quickly be detected.

From the perspective of each node performing this user-initiated verification, the node receives a request to confirm that a particular part set of verification data is correct (i.e. conforms with the verification data stored by the node receiving the request). The node then checks the verification data stored its distributed ledger and, conditional on the verification data being correct, confirms this to the user. The node may request further verification data from other nodes to help it determine whether the received verification data is correct.

This can be used to verify that an event occurred, for example that an email was sent. Also, and as already mentioned, the verification data can be used to establish the exact order in which records were stored to the ledger. In other words, relative chronology of events can be determined, and a secure distributed ledger is thereby provided, without any need for a centralised authority or objective time order to be agreed on.

In some variations each node stores a complete copy of the distributed ledger, and therefore stores every record. However, this is not necessary and in a variation a node can store any combination of records in its copy of the ledger or even no records at all. This is a departure from prior distributed ledger technologies. In block chain, for example, the linked nature of the chain of blocks comprising the records means that a node needs to receive the block chain ledger in its entirety when updating.

Using the described methods, updating nodes are able to receive data for specific records, without having to receive data for all records. This again is a departure from prior approaches. For example, nodes can elect to receive information about records recently included in the ledgers of other nodes before they receive information about older, potentially less relevant records. Advantageously, this functionality means that, unlike in block chain, nodes using the described methods can operate usefully in the network 100 as soon as they join the network. This is because, for example, they may participate in the verification procedure for records even if they store an incomplete ledger, or store no ledger at all. Systems such as block chain lack this functionality, because they require that every node participating in the network has a full copy of the entire block chain or ledger structure, before that node is allowed to take part in processes using the ledger. A new node joining the block chain must currently receive approximately 250 Gigabytes of data before it can take part. This is hugely resource intensive. Implementations of the present disclosure thus represents a huge potential decrease in bandwidth use and computational burden, by allowing nodes to partake in supporting aspects of the distributed ledger even while holding a partial or no ledger themselves.

As will be apparent from the above description, in the described methods nodes are individually involved in determining a causality path and a relative order of events. Verification/consensus is therefore agreed in an active manner in which all nodes can participate. This is in contrast to existing consensus methods, in which consensus is obtained through, for example, proof-of-work methods, as is the case in block chain. Block chain’s passive method of agreeing consensus utilises provisional verification, known as “0-confirmation”. Nodes are not actively involved in determining consensus. Rather, random chance and proof-of-work are used to determine ordering of events. This not only isolates nodes from the consensus procedure, leading to a potential lack of trust in the network, but the need to use provisional 0- confirmation also leads to a time window of vulnerability, between 0-confirmation and full confirmation through entry to the block chain. In this time window, so-called Finney attacks are possible, in which the network is flooded with malicious duplicate transactions. The active verification/consensus methods described herein remove the requirement for 0-confirmation and therefore remove the window of vulnerability. They also empower nodes to actively take part in the consensus procedure, leading to a more transparent and verifiable ledger and network. Thus, implementations of the present disclosure provide a more secure method of agreeing consensus across a network of nodes maintaining a distributed ledger.

The preceding description has set forth implementations and some variations. Some further variations will now be described. As was mentioned at the beginning of the detailed description, the features of the different implementations and those of the variations (both those described already and those about to be described) are not mutually exclusive. Rather, the features of all implementations and those of the variations can be used with one another.

The described implementations have focussed on certain applications. Other applications include, but are not limited to, administrative procedures such as tax collection, issuing licences, administrating social security benefits and voting procedures, artwork ownership, finance, music and entertainment, diamond and precious assets, the internet of things, and supply chains of various commodities. The described distributed ledger technology is in no way limited in its application. The features of the above implementations can readily be applied to records pertaining to a wide variety of items. These include, but are not limited to, property ownership, financial transactions, contracts and data. The features described herein can be used to prevent double-spends and resolve conflicting ownership claims. They can be used to verify an agreed order of events, and provide a means of providing a tamper-proof ledger of records by virtue of the hashing functionality described above. The use of digital signatures in consumables ensures that only the true owner of the consumable can consent to its consumption.

The ledger may be used to record the transfer of ownership of some good, commodity, right or service, sometimes in exchange for some other good, commodity, right or service.

It is not essential that all nodes in the network maintain a complete copy of the ledger. It is possible for nodes to maintain only a part of the ledger or no copy of the ledger. Nodes can take part in the network maintaining the ledger even if they only maintain a part or no copy of the entire ledger. For example, a node may act as a relay node for a verification procedure. The event state and node identifier for one or more relay nodes may or may not be included in the verification data for a record and may or may not be used in conflict resolution procedures.

The ledger may be split up into partitions. In this variation the partitioning is achieved by taking a truncated 64-bit integer of the 256-bit public key of each account and performing a modulo operation on this truncated number to assign it to one of the partitions of the ledger. As well as users having accounts, each node may be given a public/private key pair and may have an account. It will be apparent that any deterministic method of assigning records to specific partitions may be used. Other identifiers that identify accounts may be used, and public keys and truncations thereof may be of other bit lengths.

It can be seen that by partitioning in this way, each user’s account will reside in one of the partitions. Nodes that maintain the relevant partition can be used to support a user’s account. Nodes can participate in the network by maintaining one or more partitions. This is a huge improvement over existing systems which require nodes to store the entire distributed ledger, as opposed to certain relevant sections.

A node may receive during a verification procedure or an update only those records relevant to its partition.

A node may broadcast to other nodes of the network which partitions it is storing, and therefore which records are relevant to the node and which records can be verified by the node.

In implementations where nodes store partitions, records will be assigned to particular partitions. This assigning may be done through, for example, modulo functionality of the sort already described. Nodes can determine from the data of the record which partition the record relates to. The stack model of Figure 2 is conceptual. It shows how the same architecture can be used for different applications. It is not necessary that this model is used. Dedicated, application specific implementations may be made.

The architecture of the computer node or user computer may vary considerably and the architecture of Figure 3 is only one example. Computers A and/or B of Figure 1 may form part of the network 100 and may play an active role in storing and maintain the distributed ledger.

The described implementations use logical clocks to provide causally complete event states. Other suitable logical clocks may be used. In the case where counters are used, any suitable incremental event counting mechanism could be used. The clocks may not necessarily use incremental counting mechanisms, and instead may use compact state representations such as Merkle trees or a combination of both. In one variation, a variant of a Lamport clock which includes a checksum value representing all of the records that a node has received at that time is used. The checksum is commutative so that adding and/or removing records from it does not destroy the integrity of the checksum itself, in other words the checksum is used like a Merkle Tree hash. The event states assigned by the node to received records in the first implementation are therefore logical event clock count values or, more specifically in one variation, Lamport clock values including a checksum.

Although not necessary, all logical clocks can be initially set to zero. In variations, different initial settings may be used.

There are many alternative ways of identifying records, and using hashing is not essential.

There may be further data associated with the record, and these further data may be included in the verification data.

Procedures in the Application Layer as opposed to the Ledger Layer, may construct the record and initiate the verification procedure.

The coordinate is an implementation specific example of a data structure.

In a variation, a coordinate time value (e.g. a UTC time value) of when the node received the record can also be assigned to the record and stored in the verification data. More particularly, the respective coordinate time value is included in each coordinate. The coordinate time value can be used to ascertain the order in which records were received. If the records relate to documents, such as legal documents, the disclosed methods can clearly provide important advantages, for example in the legal and financial sector, where the determining the order in which documents arrived is important.

In a variation a node may transmit the record and updated verification data to only one node. The overall sequence or path viewed at the network-wide level will be linear if all nodes only transmit the record to only one node or will have linear sections if, for example, more than one node transmits the record to only one node.

While the described implementations generally refer to use of a gossip protocol for communication between nodes, it is not necessary that a gossip protocol is used, and other communication mechanisms will be apparent. For example, the network topology may be a“ring” where nodes pass information around the ring, such as in a round-robin fashion.

In a variation, the verifying by a node is simple acceptance of the record to the ledger.

In a variation, the records may be considered as“events”.

In a variation, the overall sequence or part of the overall sequence may start and end at the same node.

In a variation, a record associates an entity with a one-time use token or coupon.

The endorsement weight for a node may be increased by verifying records. Additionally or alternatively, in a variation the endorsement weight for a node may be increased based on other factors, for example based on the payload of a record it processes.

In the event of a record relating to a non-value transfer (such as a record relating to recording an email) a fee associated with the record can be used to calculate the endorsement weight of the record.

In the event of non-value transfer and no associated fee, then the record may have no endorsement weight.

Any suitable computer programming language may be used in various implementations. Some implementations use the Scala language, which will run on any electronic device supporting a Java Virtual Machine.

In various implementations, power requirements are extremely low when compared to known ledger technologies, both in terms of electrical power and processor speed. An electronic device that is able to act as a node in various implementations includes a computer, a smart phone or even a Raspberry Pi.

Where user accounts are used, the data related to the user can be stored locally on a user device and used to construct records. In a variation, rather than storing the data on a user device the data can be obtained from the ledger, e.g. by a query search. In a variation, old records relating to consumable associations that have been consumed are deleted. Advantageously, this reduces storage requirements.

As noted throughout the preceding disclosure, the exact manner in which nodes of the network communicate will depend on the implementation environment of the network. In a variation, the nodes within the network communicate via messages delivered via User Datagram Protocol (UDP) for non- persistent connections or Transmission Control Protocol (TCP) for persistent connections.

In one variation, each message that a node sends to one or more other nodes may take the form M = (p, c, /, K_pub, POW_d) where; p is the message payload, c is the hash of its last commitment, / is its logical clock value, K_pUb is the node’s public key, and POW_d is a valid Proof-of-Work used to generate an ID. The message may then be signed by the node with the private key used to generate its K_pUb prior to sending, such that

M’ (M, Sign(K_Priv, H(M))) where M’ is the transmitted message.

The described methods may be implemented using computer executable instructions. A computer program product or computer readable medium may comprise or store the computer executable instructions. The computer program product or computer readable medium may comprise a hard disk drive, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). A computer program may comprise the computer executable instructions. The computer readable medium may be a tangible or non-transitory computer readable medium. The term“computer readable” encompasses“machine readable”.

The word“assigning” as used herein includes assigning, allocating, apportioning, allotting, ascribing to or associating in any way. The singular terms“a” and“an” should not be taken to mean“one and only one”. Rather, they should be taken to mean“at least one” or“one or more” unless stated otherwise. The word "comprising" and its derivatives including "comprises" and "comprise" include each of the stated features, but does not exclude the inclusion of one or more further features.

The above implementations have been described by way of example only, and the described implementations are to be considered in all respects only as illustrative and not restrictive. It will be appreciated that variations of the described implementations may be made without departing from the scope of the invention. It will also be apparent that there are many variations that have not been described, but that fall within the scope of the appended claims.

Claims

1. A computer-implemented method for performing by a node of a network of nodes maintaining at least part of a distributed ledger maintained by the network of nodes, the method comprising:

receiving a record intended for the distributed ledger and verification data for the record, wherein the verification data comprises a node identifier and corresponding assigned event state for each node which has previously verified the record;

assigning an event state to the record, wherein the event state is provided by a logical clock for the node;

conditional on the node verifying the record:

updating the verification data to include an identifier for the node and the assigned event state;

storing, in the at least part of the distributed ledger maintained by the node, the record and the updated verification data; and

transmitting the record and the updated verification data to at least one node of the network of nodes which has not previously verified the record.

2. A computer-implemented method according to claim 1 , wherein the transmitting comprises transmitting the record and the updated verification data to a plurality of nodes of the network of nodes which have not yet verified the record.

3. A computer-implemented method according to any preceding claim, wherein the transmitting comprises transmitting using a gossip protocol.

4. A computer-implemented method according to any preceding claim, wherein the verification data comprises, for each node which has previously verified the record, an associated digital signature for the respective node.

5. A computer-implemented method according any preceding claim, wherein the verification data comprises, for each node which has previously verified the record, a check value for the corresponding assigned event state.

6. A computer-implemented method according to any preceding claim, wherein the verification data comprises a hash of the record.

7. A computer-implemented method according to any preceding claim, wherein the record consumes a respective association of a respective item with a respective entity and verifying the record comprises verifying against the distributed ledger that the association has not already been consumed.

8. A computer-implemented method according to any preceding claim, wherein the record comprises a digital currency transaction, and optionally wherein verifying the record comprises verifying the transaction against the distributed ledger.

9. A computer-implemented method according to any preceding claim, wherein the method comprises: conditional on the node not verifying the record:

rejecting the record.

10. A computer-implemented method according to any preceding claim, wherein one or more nodes have a respective endorsement weight, and wherein optionally the record has an endorsement weight which is used to increase the endorsement weight of one or more nodes that verify the record.

1 1. A computer-implemented method according to claim 10, wherein the node has an endorsement weight, and wherein optionally the endorsement weight is increased by verifying the record.

12. A computer-implemented method according to claim 1 1 , wherein the endorsement weight of the record is based on the value of a digital currency consumable transacted by the digital currency transaction and the amount of time since the digital currency consumable was last transacted.

13. A computer-implemented method according to any preceding claim, wherein at least some of the nodes of the network have a respective endorsement weight, wherein the method comprises resolving a conflict between received digital currency transactions attempting to transact the same digital currency consumable by performing a comparison based on endorsement weights for the transactions.

14. A computer-implemented method according to any preceding claim, wherein a respective endorsement weight for at least some of the nodes of the network is stored in a table of endorsement weights.

15. A computer-implemented method comprising configuring at least some of a network of nodes to perform the method of any preceding claim, wherein, in use, records and verification data are transmitted through branching paths across the network.

16. Computer-executable instructions which, when executed on a computer, cause the computer or network to perform the method of any preceding claim.

17. A computer node comprising at least one computer processor and at least one computer memory, wherein the computer memory comprises computer-executable instructions which, when executed, cause the computer node to perform the method of any of claims 1 to 14.