WO2019081919A1

WO2019081919A1 - Data storage and verification

Info

Publication number: WO2019081919A1
Application number: PCT/GB2018/053066
Authority: WO
Inventors: Alexander GALLAGHER-LYNCH; Matthew Giles DANGERFIELD
Original assignee: Copa Fin Limited
Priority date: 2017-10-24
Filing date: 2018-10-23
Publication date: 2019-05-02

Abstract

A method of processing a data record to generate verification data. A set of data elements is retrieved from the data record, the set of data elements comprising at least a first and second data element from a first and second data field of the data record. A cryptographic algorithm is applied to produce data element verification data from the set of data elements. The cryptographic algorithm is non-deterministic with respect to first input data. Applying the cryptographic algorithm comprises: applying the cryptographic algorithm to at least the first data element as the first input data, to produce first data element verification data representative of the first data element; and applying the cryptographic algorithm to at least the second data element as the first input data, to produce second data element verification data representative of the second data element.

Description

DATA STORAGE AND VERIFICATION

Technical Field

[0001] The present invention relates to methods for storing data securely and for verifying data.

Background

[0002] Malicious parties may wish to change or tamper with data. It is therefore desirable to store data securely, so that the data is resistant to tampering. It is further desirable to be able to verify data, to identify instances of tampering.

[0003] Moreover, malicious parties may wish to attack distributed ledger networks, such as blockchain networks, which if successful could reduce the trust in, and efficiency of, such networks. Even with known private DLNs, which are open to only trusted participants, a malicious party may attempt entry to the distributed ledger network by a variety of techniques. If successful, such an attack could lead to data being added to a network which is from an untrustworthy source. A malicious party may attempt to launch a form of denial-of-service (DoS) attack by bombarding a DLN with requests to store meaningless data, reducing the ability of genuine users to interact with the DLN. It is therefore desirable to improve security in a DLN.

Brief Description of the Drawings

[0004] Further features will become apparent from the following description, given by way of example only, which is made with reference to the accompanying drawings.

[0005] Figure 1 shows schematically an example of a DLN;

[0006] Figure 2 is a schematic diagram showing an example of internal components of a first member node of a DLN according to examples;

[0007] Figure 3 shows schematically an example of the data structure of Figure 2, for storing data at a first member node of a DLN;

[0008] Figure 4 shows schematically a cross-section through the first and second rows of the data structure of Figure 3;

[0009] Figure 5 is a flow diagram illustrating an example of generating a hash value for a first block of a first blockchain; [0010] Figure 6 is a flow diagram illustrating an example of generating a hash value from a set of hash values;

[0011] Figure 7 is a flow diagram illustrating an example of generating a new hashblock based on a new block;

[0012] Figure 8 is a flow diagram illustrating an example of allocating a first node identifier to a first member node of a DLN;

[0013] Figure 9 is a flow diagram illustrating the creation of a first block at a first member node according to examples;

[0014] Figure 10 is a flow diagram illustrating the receipt of a first block at a first member node according to examples;

[0015] Figure 11 is a flow diagram illustrating an example of validation of a block according to examples;

[0016] Figure 12 is a flow diagram illustrating an example of validation of a blockchain according to examples;

[0017] Figure 13 is a flow diagram illustrating an example of receiving a new blockchain at a first member node;

[0018] Figure 14 is a flow diagram illustrating an example of updating a blockchain at a first member node;

[0019] Figure 15 is a flow diagram illustrating an example of updating a blockchain at a second member node;

[0020] Figure 16 is a flow diagram illustrating an example of updating a data structure at a first member node;

[0021] Figure 17 shows schematically an example of internal components of a member node of a DLN according to examples;

[0022] Figure 18 shows schematically an example of broadcasting of data using a UDP broadcaster module;

[0023] Figure 19 shows schematically an example of receiving data using a UDP receiver module;

[0024] Figure 20 is a flow diagram illustrating an example of storing data;

[0025] Figure 21 is a flow diagram illustrating an example of verifying data;

[0026] Figure 22 shows schematically a further example of a DLN;

[0027] Figure 23 shows schematically an example of a data record; [0028] Figure 24 is a flow diagram illustrating an example of generating data element verification data;

[0029] Figure 25 is a flow diagram illustrating an example of generating a secret key for generating data element verification data;

[0030] Figure 26 is a flow diagram illustrating an example of generating data set verification data;

[0031] Figure 27 is a flow diagram illustrating an example of generating additional-level verification data;

[0032] Figure 28 is a flow diagram illustrating an example of verifying a data record;

[0033] Figure 29 is a flow diagram illustrating features of the example of verifying a data record in accordance with Figure 28;

[0034] Figure 30 is a flow diagram illustrating a further example of verifying a data record;

[0035] Figure 31 is a flow diagram illustrating features of the further example of verifying a data record in accordance with Figure 30;

[0036] Figure 32 shows schematically an example system comprising a plurality of DLNs;

[0037] Figure 33 is a flow diagram illustrating a method for storing data according to examples;

[0038] Figure 34 is a flow diagram illustrating additional example features of the method for storing data shown in Figure 33;

[0039] Figure 35 is a flow diagram illustrating a method of processing a request to store verification data according to examples;

[0040] Figure 36 is a flow diagram illustrating example features of the method of processing a request to store verification data shown in Figure 35;

[0041] Figure 37 is a flow diagram illustrating further example features of the method of processing a request to store verification data shown in Figure 35;

[0042] Figure 38 is a flow diagram illustrating a method of processing requests to store verification data according to further examples;

[0043] Figure 39 is a flow diagram illustrating example features of the method of processing requests to store verification data shown in Figure 38;

[0044] Figure 40 is a flow diagram illustrating example features of the method of processing requests to store verification data of Figure 38; [0045] Figure 41 is a flow diagram illustrating a method of processing requests to store verification data according to yet further examples;

[0046] Figure 42 is a flow diagram illustrating a method of processing a request to store verification data according to still further examples;

[0047] Figure 43 is a flow diagram illustrating a method of processing a request to store verification data according to still further examples;

[0048] Figure 44 shows schematically an example of internal components of a client node according to examples;

[0049] Figure 45 shows schematically an example of internal components of a control node according to examples;

[0050] Figure 46 is a flow diagram illustrating a method of verifying verification data according to examples;

[0051] Figure 47 is a flow diagram illustrating a method of verifying verification data according to further examples;

[0052] Figure 48 is a flow diagram illustrating a method of authenticating a computing node according to examples;

[0053] Figure 49 is a flow diagram illustrating a method of determining whether a computing node is entitled to a licence according to examples;

[0054] Figure 50 is a flow diagram illustrating a method of determining whether a computing node is entitled to at least one cryptographic key according to examples;

[0055] Figure 51 is a flow diagram illustrating a method of receiving at least one further cryptographic key according to examples;

[0056] Figure 52 is a flow diagram illustrating a method of transmitting data according to examples;

[0057] Figure 53 is a flow diagram illustrating a method of validating the origin of data according to examples;

[0058] Figure 54 is a flow diagram illustrating a method of validating the origin of data according to further examples;

[0059] Figure 55 is a flow diagram illustrating a method of validating the origin of data according to yet further examples;

[0060] Figure 56 is a flow diagram illustrating a method illustrating example responses to the transmission of a validation request; [0061] Figure 57 shows schematically an example of internal components of a licensing server according to examples; and

[0062] Figure 58 shows schematically an example of internal components of a licensing module according to examples.

Detailed Description

[0063] Details of systems and methods according to examples will become apparent from the following description, with reference to the Figures. In this description, for the purpose of explanation, numerous specific details of certain examples are set forth. Reference in the specification to "an example" or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least that one example, but not necessarily in other examples. It should further be noted that certain examples are described schematically with certain features omitted and/or necessarily simplified for ease of explanation and understanding of the concepts underlying the examples.

[0064] Methods described herein may be used with at least one distributed ledger network (DLN). A blockchain network is an example of a DLN. A blockchain typically includes a continually growing list of records, encoded into blocks, with each block linked to a previous block. Blockchains may be considered to be a cryptographic ally secure chain of records, which includes a chained set of hashes. A hashing algorithm, also referred to as a message digest algorithm, such as the MD5 algorithm, can be applied to a record to produce a unique fingerprint. The hash of a record may be included in a block, and a hash of the block, or of at least the hash included in the block, may be added to a subsequent block. In this way, a chain of records may be generated, in which changes to a data record or sequence of records is readily detectable.

[0065] However, a malicious party wishing to change a record may be able to rewrite an entire chain. For example, with current processors, an entire chain of millions of records may be rewritten in minutes. Thus, if a malicious party wished to alter the millionth record, he or she could branch the chain of records at 999, 999, insert a new record and re-compute the hash values for the rest of the chain. On a centralized system, with one master copy of the data, verification of the data (for example by checking the hash values of the chain) would not detect that the chain of records had been altered. [0066] A blockchain network, which as stated above is an example of a DLN, improves immutability by combining cryptographic hashing with distribution of the blockchain, which is thus stored by multiple nodes. A DLN generally includes a number of member nodes, which each store a copy of the ledger, once it has been synchronized across the network. There is typically no centralized point of failure in a DLN, thus increasing the immutability of data stored in such a network. Known DLNs include public DLNs, to which all users have access (providing they pay the required transaction fees) and private DLNs, to which only a limited set of trusted users have access.

[0067] It is more difficult for a malicious party to tamper with any of the data records in a DLN. Generally, the security of a DLN increases as the number of member nodes connected to the DLN increases. For example, it may be possible to tamper with one copy of the distributed ledger stored at one member node or even all copies owned or stored by member nodes associated with one organization. However, it is more difficult, even virtually impossible, to tamper with copies stored across many organizations, especially if they are stored in various different networks and/or security infrastructures.

[0068] Nevertheless, a DLN may be intended to be a restricted DLN, to which only a set of trusted users have access. This may further increase the security of the DLN. However, in some cases it may be possible for a malicious party to gain access to such a DLN. The malicious party may then be able to access the data of the DLN, which may be undesirable if the data is sensitive. Furthermore, once a malicious party has access to the DLN, the malicious party may be able to write a large quantity of meaningless data to the DLN. This may make it more difficult or less efficient for genuine users to access meaningful data of the DLN. Moreover, this may overload the DLN, reducing the efficiency of the functioning of the DLN.

Examples of a first class

[0069] First examples of a first class described herein provide a method for synchronizing data within a distributed ledger network comprising a plurality of member nodes connected via a data communications system. The method in these examples includes, at a first member node, storing first storage data representing blocks of a first blockchain and second storage data representing blocks of at least a second blockchain. The first blockchain is extended in response to at least one block being created at the first member node and data representing the at least one block is added to the first storage data. Outbound synchronization data is transmitted to at least one other member node of the distributed ledger network, the outbound synchronization data comprising data representative of the at least one block. Inbound synchronization data is received from a second member node of the distributed ledger network, the inbound synchronization data comprising data representative of one or more blocks of the second blockchain. The data representing the one or more blocks of the second blockchain is stored at the first member node. For example, the data representing the one or more blocks of the second blockchain may be added to the second storage data. In examples such as this, the first member node may be configured to be a primary or sole source for blocks of the first blockchain. This may avoid two blocks of the first blockchain being created simultaneously by different member nodes (as one member node can readily control the generation of blocks in sequence order), without the need for a consensus-based algorithm for the publication of a block to the DLN, which can avoid delays which are associated with consensus-based algorithms and can also avoid forking of the first blockchain.

[0070] Second examples of the first class described herein provide a method of adding data to a first member node of a distributed ledger network, the first member node including storage data representing blocks of a plurality of blockchains. The method according to these second examples includes creating a first block at the first member node, receiving a first node identifier associated with the first member node, selecting a first blockchain from the plurality of blockchains based on the first node identifier and extending the first blockchain by storing the first block as part of the first blockchain. This for example allows the first blockchain to be uniquely associated with the first node, which may allow the first node to act as a primary or sole source of blocks for the first blockchain, similarly to the first examples.

[0071] Third examples of the first class described herein provide a first member node for a distributed ledger network. In the third examples, the first node includes storage configured to store first storage data representing a first blockchain, the first blockchain comprising a first continuous sequence of blocks, the first continuous sequence of blocks having been created at the first member node. The storage is also configured to store second storage data representing at least a second blockchain, the second blockchain comprising a second continuous sequence of blocks, the second continuous sequence of blocks having been created at the second member node. In these examples, the first member node may be configured to be a primary or sole source of blocks for the first blockchain and the second member node may be configured to be a primary or sole source of blocks for the second blockchain. [0072] Fourth examples of the first class described herein provide a method of storing data including storing a first blockchain, the first blockchain including a first set of blocks arranged in sequence and storing a second blockchain, the second blockchain including a second set of blocks arranged in sequence. Verification data which links at least some data from a block in the first blockchain and at least some data from a block in the second blockchain is generated and the verification data is stored. In these examples, the first and second blockchains may be independently generated, with the verification data linking the blocks of the first and second blockchains providing immutability for both blockchains. Such improved immutability is for example achieved by synchronizing the first and second blockchains, along with the verification data, within a DLN.

[0073] Fifth examples of the first class described herein provide a method of verifying data including retrieving at least some data from a block in a first blockchain, the first blockchain comprising a first set of blocks arranged in sequence, retrieving at least some data from a block in a second blockchain, the second blockchain comprising a second, different, set of blocks arranged in sequence and retrieving verification data which links the block in the first blockchain and the block in the second blockchain. These examples include performing a cryptographic verification algorithm with the at least some data from the block in a first blockchain, and the at least some data from the block in a second blockchain, as inputs to the cryptographic verification algorithm and comparing the output of the cryptographic verification algorithm with the verification data in order to verify at least one of the block in the first blockchain and the block in the second blockchain. These examples therefore allow data from first and second blockchains that may have been independently generated to be subsequently verified for data integrity. Immutability is improved in situations in which the first and second blockchains, along with the verification data, are distributed across a DLN.

Examples of a second class

[0074] First examples of a second class described herein provide a method of processing a data record to generate verification data for storage. The method in these first examples includes retrieving a set of data elements from the data record, the set of data elements including at least a first data element from a first data field of the data record and a second data element from a second data field of the data record. For example, the data record may have a predetermined structure including a plurality of data fields including the first and second data fields. Each data field may be associated with a particular quantity or characteristic, so that a data element belonging to a particular data field represents a value of the quantity or characteristic associated with that particular data field.

[0075] A cryptographic algorithm is applied to produce data element verification data from the set of data elements from the data record. The cryptographic algorithm is non-deterministic with respect to first input data. For example, for the same value of first input data, the cryptographic algorithm produces different output values. Applying the cryptographic algorithm to produce the data element verification data includes applying the cryptographic algorithm to at least the first data element as the first input data, to produce first data element verification data representative of the first data element and applying the cryptographic algorithm to at least the second data element as the first input data, to produce second data element verification data representative of the second data element. The first and second data element verification data is for verifying the integrity of the first and second data element respectively. The first and second data element verification data are transmitted for storage, for example for use in a subsequent verification process.

[0076] A series of data records that includes data elements that are the same or are repeated between various different data records of the series may be particularly susceptible to dictionary attacks if a deterministic cryptographic algorithm is used. For example, the output of a cryptographic algorithm applied to the same data element will be the same for a deterministic cryptographic algorithm. Hence, a malicious party may be able to identify repeated instances of the same output of such a deterministic cryptographic algorithm if the deterministic cryptographic algorithm is used to generate verification data based on the series of data records. This may aid the malicious party in a dictionary attack, in which a number of different possibilities for the function used by the deterministic cryptographic algorithm is tried to try to identify the correct function. In addition, data elements that are relatively small in size (for example representing a single character or a small number of characters) may also be susceptible to dictionary attacks. However, by using a non-deterministic cryptographic algorithm to generate the first and second data element verification data, such as in the first examples described herein, the first and second data element verification data may be resistant to dictionary attacks. In other words, the first and second data elements represented by the first and second data element verification data may be more secure. In addition, the first and second data element verification data may be used to verify the first and second data elements (as described further below), allowing unexpected changes in the value of the first and second data elements, for example by a malicious party, to be identified.

[0077] Second examples of the second class described herein provide a method of processing a data record to generate verification data for storage. The method of the second examples includes retrieving a set of data elements from the data record. As for the first examples, in the second examples the set of data elements include at least a first data element from a first data field of the data record and a second data element from a second data field of the data record. The method of second examples further includes determining, from presence or absence of an indicator associated with the data record, whether element-level verifiability, of individual data elements of the set of data elements, is requested. This therefore provides flexibility on the level of verifiability to be determined, which can improve the efficiency of a verification check. For example, in circumstances in which it is considered that the data record is relatively secure, which may depend on the security of networks used to transfer or store the data record, it may not be necessary to check the element-level verifiability of individual data elements of the set of data elements. Instead, the set of data elements as a whole may be verified, which may be more straightforward, less complex or more efficient than checking the element-level verifiability of individual data elements of the set of data elements. However, in other circumstances, it may be desired to verify individual data elements. For example, where it has been identified that the set of data elements has failed a verification check, the element-level verifiability of individual data elements may be checked to identify which of the individual data elements has been tampered with or changed.

[0078] In response to determining that element-level verifiability is not requested, a data set hashing algorithm is applied to produce data set verification data from the set of data elements. The data set verification data includes a hash value representative of both the first data element and the second data element, for verifying the integrity of the set of data. The data set verification data is transmitted for storage.

[0079] In response to determining that element- level verifiability is requested a cryptographic algorithm is applied to produce data element verification data from the set of data elements from the data record. The cryptographic algorithm is non-deterministic with respect to first input data. Applying the cryptographic algorithm to produce the data element verification data includes applying the cryptographic algorithm to at least the first data element as the first input data, to produce first data element verification data representative of the first data element and applying the cryptographic algorithm to at least the second data element as the first input data, to produce second data element verification data representative of the second data element. The first and second data element verification data is transmitted for storage. The cryptographic algorithm referred to in the context of the second examples may be similar to or the same as the cryptographic algorithm of the first examples and may therefore provide for further security as described above for the first examples.

[0080] Third examples of the second class described herein provide a method of processing and storing data element verification data. The method of the third examples includes receiving data element verification data. The data element verification data includes first data element verification data representative of a first data element, for verifying the integrity of the first data element, and second data element verification data representative of a second data element, for verifying the integrity of the second data element. The data element verification data is stored and additional-level verification data is produced from the first data element verification data and the second data element verification data and the additional-level verification data is transmitted for storage in a DLN. The additional-level verification data therefore provides for further verification of the first and second data elements. Moreover, by transmitting the additional-level verification data for storing in a DLN, the additional-level verification data may be distributed to or stored at a number of member nodes of the DLN, making it more difficult for the additional-level verification data to be tampered with. This further increases the security of the first and second data elements, as a further cross-check that the values of the first and second data elements haven't been altered.

[0081] Fourth examples of the second class described herein provide a method of verifying a data record. The method of the fourth examples includes receiving a data verification request, the data verification request relating to data representative of the data record. The data representative of the data record is received. The received data includes a received set of data elements from the data record, the received set of data elements including a received first data element from the data record and a received second data element from the data record. A cryptographic algorithm is applied to produce regenerated data element verification data from the received set of data elements from the data record. The cryptographic algorithm is non- deterministic with respect to first input data. Applying the cryptographic algorithm to produce the regenerated data element verification data includes applying the cryptographic algorithm to at least the received first data element as the first input data, to produce regenerated first data element verification data representative of the received first data element and applying the cryptographic algorithm to at least the received second data element as the first input data, to produce regenerated second data element verification data representative of the received second data element. The integrity of the received first data element is verified by checking the regenerated first data element verification data with respect to stored first data element verification data representative of a first data element from the data record. Similarly, the integrity of the received second data element is verified by checking the regenerated second data element verification data with respect to stored second data element verification data representative of a second data element from the data record. Methods in accordance with the fourth examples therefore allow a data record to be verified based on verification data. The verification data in these examples is produced using a cryptographic algorithm which is non- deterministic with respect to first input data, so that the verification data is resistance to dictionary attacks.

[0082] As explained above, methods in accordance with the first, second, third and fourth examples of the second class may be used with a distributed ledger network (DLN).

Examples of a third class

[0083] Examples in accordance with a third class described herein relate to secure storage of data, such as data records, and/or to verification of data. Such examples may be used in conjunction with the other examples described herein, or separately, for example with different methods, networks or systems.

[0084] First examples of the third class described herein provide a method for storing data. The method in these first examples includes transmitting a first data storage request. The first data storage request instructs the storage of first data in a first DLN. The first DLN is for example a private DLN, which is accessible to a particular group of users rather than being freely accessible to all users. Confirmation that the first data has been stored in the first DLN is received. A verification data storage request is transmitted. The verification data storage request instructs storage of verification data in at least one DLN different from the first DLN. The verification data relates to the first data. For example, the first data may include the verification data or vice versa, or the verification data may be derived from the first data. For example, the verification data may include a hash derived from at least a portion of the first data. Confirmation that the verification data has been stored in one or more DLNs of the at least one DLN.

[0085] In methods in accordance with the first examples of the third class, the verification data may be used to verify an integrity of the first data. Typically, the larger the number of DLNs the verification data is stored in, the greater the immutability of the verification data, as a malicious party must alter copies of the verification data in more than 50% of the DLNs the verification is stored in in order to successfully change the verification data without detection. Thus, by storing the verification data in one or more DLNs other than the first DLN, the immutability of the verification data may be increased. Hence, the integrity of the first data (which may be verified using the verification data) may also be verified to a higher degree of confidence. For example, where the first DLN is a private DLN, the number of nodes of the first DLN may be limited to nodes associated with users with access to the first DLN, which may itself be a limited number of users. By storing the verification data in the one or more DLNs other than the first DLN, the verification may be distributed more widely, which may increase the immutability of the verification data.

[0086] Second examples of the third class described herein provide a method of processing a request to store verification data in at least one DLN. The method of the second examples includes receiving a verification data storage request relating to storage of verification data in at least one DLN different from a first DLN. The first DLN is for example a private DLN. The verification data relates to first data stored in the first DLN and may be the same as or similar to the verification data of the first examples. The verification data storage request includes a first data storage transaction identifier identifying a block, within the first DLN, in which the first data has been stored. Data is retrieved from the first DLN on the basis of the first data storage transaction identifier. The verification data is derived from the retrieved data.

[0087] As for the first examples of the third class, methods in accordance with the second examples of the third class described herein allow verification data to be stored in at least one DLN other than the first DLN, allowing the verification data to be distributed more widely than within the first DLN. These second examples of the third class therefore also allow the immutability of the verification data to be increased and the integrity of the first data to be verified to a higher degree of confidence.

[0088] Third examples of the third class described herein provide a method of processing requests to store verification data in at least one DLN. The method of the third examples of the third class includes receiving a first verification data storage request relating to storage of verification data in at least one DLN different from a first DLN and receiving a second verification data storage request relating to storage of verification data in the at least one DLN different from the first DLN. The first verification data storage request relates to first data stored in the first DLN and the second verification data storage request relates to second data stored in the first DLN. The first DLN is for example a private DLN. A hashing algorithm is used to generate the verification data. The hashing algorithm uses both first derived data derived from the first data and second derived data derived from the second data as input data.

[0089] In the third examples of the third class, the verification data is based on both the first data and the second data. For example, the first derived data (derived from the first data) and the second derived data (derived from the second data) may be aggregated and subsequently hashed to generate the verification data. In this way, the amount of data to be stored to verify the first data and the second data (or the first derived data and the second derived data) may be reduced compared with other methods in which separate first and second verification data may be stored for the first and second data (or first and second derived data), respectively. Furthermore, the amount of data transmitted to the at least one DLN may be reduced or the number of data transmissions to the at least one DLN may be reduced by transmitting the verification data derived from the first and second data rather than transmitting, for example, separate first and second verification data in response to the first and second verification data storage requests, respectively. Thus, where the first DLN is a private DLN and the at least one DLN includes a public DLN, methods in accordance with the third examples may reduce the amount of data transferred from a private to a public DLN, which may reduce a network load for transfer of data from the private to the public DLN.

[0090] Fourth examples of the third class described herein provide a method of processing a request to store verification data in at least one DLN. The method of the fourth examples of the third class includes receiving a verification data storage request relating to storage of verification data in at least one DLN different from a first DLN. The verification data relates to first data stored in the first DLN and may be the same as or similar to the verification data of the first, second or third examples. The verification data storage request includes parameter data relating to at least one characteristic requested for the storage of the verification data in the at least one DLN. For example, the at least one characteristic may include a level of immutability requested for the storage of the verification in the at least one DLN or a level of delay within which confirmation of the storage of the verification data in the at least one DLN is requested. One or more DLNs, different from the first DLN, are selected for the storage of the verification data, on the basis of the parameter data and the verification data is stored in the selected one or more DLNs.

[0091] In this way, the verification data may be stored in appropriate DLNs, selected from the at least one DLN, so as to satisfy requirements indicated by the parameter data. For example, a user may request a particular level of immutability for data with a given sensitivity. The method in accordance with the fourth examples may thus allow DLNs to be selected for storage of the data so that the data has a level of immutability that meets or exceeds the requested level of immutability.

[0092] These methods additionally provide for flexibility, which may reduce the amount of data transmitted. For example, if the level of immutability is relatively low, the selected number of DLNs may also be relatively low. This may reduce the data transmitted during the storage of the data in the selected DLNs compared with other cases in which the data may always be transmitted to a fixed or constant number of DLNs, which may be a number of DLNs to provide a maximum level of immutability (which is for example a larger number of DLNs than required for a relatively low requested level of immutability).

[0093] Fifth examples of the third class described herein provide a method of processing a request to store verification data in at least one DLN. The method of the fifth examples includes initiating a DLN transaction. After initiating the DLN transaction, a verification data storage request relating to storage of verification data in at least one DLN is received. The verification data is transmitted to be stored as metadata in association with the DLN transaction, prior to the DLN transaction being confirmed as committed to one or more DLNs of the at least one DLN.

[0094] Methods in accordance with the fifth examples of the third class include pre-emptively initiating a DLN transaction before receiving a verification data storage request. For some DLNs, such as the Ethereum DLN, metadata associated with a DLN transaction may be modified up to a time at which the DLN transaction is confirmed as being committed to the DLN. Thus, the metadata associated with the DLN transaction may be modified to include the verification data up to this time. This allows the verification data to be stored or committed to the one or more DLNs (as part of the metadata associated with the DLN transaction) more rapidly than otherwise. [0095] As explained above, methods in accordance with the first, second, third, fourth and fifth examples of the third class may be used with at least one distributed ledger network (DLN).

Examples of a fourth class

[0096] Examples of a fourth class described herein relate to or provide for validation of an origin of data, for example to determine whether data has originated from a member node of a DLN. Such examples may be used in conjunction with the other examples described herein, or separately, for example with different methods, networks or systems.

[0097] First examples of the fourth class described herein provide a method which includes configuring a computing node with a node identifier. A licence token to be associated with the node identifier is received. A block to be added to a blockchain of a DLN is generated at the computing node. Node validation data for validating an origin of the block is generated based on the block and the licence token. Outbound data comprising the block and the node validation data is transmitted from the computing node, for example for receipt by at least one member node of the DLN.

[0098] By transmitting outbound data including the block and the node validation data, other computing nodes (such as other member nodes of the DLN) can use the node validation data to determine that the block has originated from a computing node which is itself a member node of the DLN. For example, successful validation of the node validation data typically indicates that the computing node that generated the block has a valid licence token and is therefore permitted to interact with the DLN.

[0099] The method of the first examples of the fourth class therefore allows data to be generated and transmitted in a format that allows the origin of the generated data to be validated upon receipt by other computing nodes. These other computing nodes can therefore decide on the appropriate action to take upon receipt of the generated data, depending on whether the origin of the generated data has been successfully validated as being from a member node of the DLN. This may therefore reduce the risk of data originating from malicious sources (which may be meaningless or unwanted data) from being added to the DLN or transmitted widely across member nodes of the DLN. These methods may therefore improve the efficiency of the DLN. [00100] Second examples of the fourth class described herein provide a method of validating an origin of a block generated by a computing node, for storage of the block within a DLN. The method of the second examples includes receiving, at a first member node of the DLN, data derived from the block, a node identifier for identifying the computing node and node validation data for validating that the computing node is a member node of the DLN. A validation request is transmitted from the first member node. The validation request includes the data derived from the block, the node identifier and the node validation data. A validation indication indicative of where the origin of the block is valid is received at the first member node.

[00101] The method of the second examples of the fourth class allows the origin of a block to be validated, for example to check whether the block has been generated or transmitted from a member node of the DLN, which may be a trusted node. By checking the origin of the block, blocks originating from untrusted nodes, such as nodes associated with a malicious party, can be identified. These blocks can then for example be discarded without adding them to the DLN. As for the first examples, this can reduce the chance of a malicious party being able to overload the DLN with meaningless data. Furthermore, if it is determined that a block originates from an untrusted node, the untrusted node can for example be blacklisted or prevented from interacting further with the DLN. This can also improve the security of the DLN, by allowing untrusted nodes to be identified.

[00102] Third examples of the fourth class described herein provide a method of validating an origin of a block generated by a computing node, for storage of the block within a blockchain of a DLN. The method of third examples includes receiving a validation request including data derived from the block, a node identifier for identifying the computing node, and node validation data for validating that the computing node is a member node of the DLN. On the basis of the node identifier, retrieved licence data is obtained based on a stored licence token. The data derived from the block and the retrieved licence data are processed to produce regenerated node validation data. The origin of the block is validated by checking the received node validation data with respect to the regenerated node validation data.

[00103] Similarly to the methods of the first and second examples of the fourth class, the method of the third examples of the fourth class also allows the origin of a block to be validated. As for the second examples, the method of the third examples can improve the integrity and/or security of the DLN, while also allowing untrusted nodes to be identified and dealt with appropriately.

[00104] As explained above, methods in accordance with the first, second and third examples of the fourth class may be used with at least one distributed ledger network (DLN).

Description of examples of the first, second, third and fourth classes, with reference to the Figures

[00105] To put the examples of the first, second, third and fourth classes into context, examples of a DLN 100 will be described, first with reference to Figure 1. Further features of a DLN and of methods for generating and verifying data for storage on such a DLN (or on a plurality of DLNs), for example in accordance with the first class, will then be described with reference to Figures 2 to 21. Further examples relating to generating verification data and/or verifying data, for example in accordance with the second class, will be described with reference to Figures 22 to 31. Yet further examples relating to storing data securely and/or verifying data, for example in accordance with the third class, will be described with reference to Figures 32 to 47. Finally, examples in accordance with the fourth class will be described with reference to Figures 48 to 58.

[00106] The DLN 100 in the example of Figure 1 is a private DLN, to which only a limited set of trusted users have access. The DLN 100 includes a plurality of member nodes 102, in this example a first member node 102a, a second member node 102b, a third member node 102c and a fourth member node 102d. A user is associated with a particular member node 102. The DLN 100 also includes one or more DLN control nodes for controlling access to the DLN, since the DLN in this example is a private network, and for providing various network functions such as data verification. DLN control nodes may be associated with a DLN member node. For example, a DLN control node may have an associated DLN member node, local to the DLN control node, from which the DLN control node can access or retrieve data, without having to request the data from a remote DLN member node. Copies of data held within a distributed ledger associated with the DLN may be stored at, or by, each of the member nodes 102. Both DLN member nodes and DLN control nodes may store copies of the distributed ledger or part of the distributed ledger or DLN control node may instead retrieve copies of all or part of the distributed ledger from one or more DLN member nodes (as described above). [00107] A DLN node (which may be a DLN member node or a DLN control node), which is a computing node, can take a variety of forms, including devices such as a server computer, a desktop computer, a laptop computer, or a smartphone computing device. A DLN node may therefore be any suitable computing device, such as any electronic device with appropriate processing capability for processing or interacting with a distributed ledger, such as a central processing unit (CPU), or dedicated software or hardware such as a suitably programmed field programmable gate array (FPGA) or application specific integrated circuit (ASIC).

[00108] Alternatively, a DLN node may be implemented by a distributed collection of devices interconnected by a network, for example a local area network. Where a DLN node is implemented by different entities, each having a separate corporate network, for example a local area network (LAN) protected by a firewall, at least a part of the DLN node which may be queried by one or more remote DLN nodes, may be located in a demilitarized zone (DMZ) outside the main firewall of the corporate network.

[00109] Each DLN node may be operated by a different user or organization or a user or organization may control or operate a number of different DLN nodes.

[00110] The DLN 100 of Figure 1 is a decentralized, and distributed, system, in which the DLN member nodes 102 can communicate with each other via a data communications network 104. The network 104 may include private network links and/or public network links, and may include a plurality of interconnected networks.

[00111] Each of the member nodes 102 may have integrated or externally-coupled wired networking capabilities. Alternatively, or in addition, each of the member nodes 102 may have integrated or externally-coupled wireless networking capabilities, using wireless telecommunications systems such as those using the Long Term Evolution (LTE) standards. The member nodes may in turn be connected to a series of one or more networks comprising servers, routers and other networking equipment that communicate using the Internet Protocol (IP) protocol. One or more of the member nodes 102 may include virtual devices implemented on underlying physical computing hardware.

[00112] Figure 2 provides an overview of examples of internal components for an example computing device for use as a member node of a DLN, such as the first member node 102a of the DLN 100 of Figure 1.

[00113] The first member node 102a of Figure 2 is a computing device that includes a network interface 106 to communicate with the network 104, such that the first member node 102a may form part of the DLN 100. The network interface 106 of the first member node 102a may include software and/or hardware components, such as a virtual network interface, an Ethernet port, a software driver and/or communications stack interacting with network hardware.

[00114] Storage 108 of the first member node 102a in the example of Figure 2 is configured to store data of the distributed ledger. In this example, the storage 108 stores first storage data 110 representing a first blockchain, the first blockchain comprising a first continuous sequence of blocks of a first blockchain, the first continuous sequence of blocks created at the first member node 102a, and second storage data 112 representing at least a second blockchain, the second blockchain comprising a second continuous sequence of blocks created at a second member node 102b of the DLN. The first blockchain may include solely blocks created at the first member node 102a and the second blockchain may include solely blocks created at the second member node 102b. In such cases, the first and second member nodes 102a, 102b may be considered to be the sole source of blocks for the first and second blockchains, respectively. The second storage data 112 may also represent all other blockchains of the DLN, the other blockchains comprising further continuous sequences of blocks created at all other member nodes of the DLN

[00115] The storage 108 of Figure 2 also stores verification data in the form of hash data 114 (described further below with reference to Figure 3). The first storage data 110, the second storage data 112 and the hash data 114 are stored in a logical data structure 116 as shown in Figure 2, although the first storage data 110, the second storage data 112 and the hash data 114 may be stored in a variety of arrangements of appropriately linked fields in the storage 108.

[00116] The storage 108 may include at least one of volatile memory, such as a Random Access Memory (RAM) and non-volatile memory, such as magnetic, optical or tape media, or a solid state drive (SSD) such as Flash memory. The storage 108 may be local to, or remote from, the member node 108. In examples, the storage 108 may be cloud storage.

[00117] At least one processor 118 is communicatively coupled to the storage 108 in the first member node 102a of Figure 2. The at least one processor 118 in the example of Figure 2 may be a microprocessor, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any suitable combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[00118] The storage 108 in the example of Figure 2 may include computer program code configured to, when processed by the at least one processor 118, implement the methods described herein. This computer program code may be stored in an accessible non-transitory computer-readable medium and loaded into memory, for example the storage 108, to implement the methods described herein.

[00119] The components of the first member node 102a in the example of Figure 2 are interconnected using a systems bus 120. This allows data to be transferred between the various components. For example, the first storage data 110 may be transmitted to other member nodes or control nodes of the DLN 100 by transferring the first storage data 110 from the storage 108, via the systems bus 120, to the network interface 106 for transmission to the network 104.

[00120] Figure 3 shows schematically an example of the data structure 116 of Figure 2, which may be used to store first and second storage data 110, 112 and hash data 114 (although other data structures may be used in other examples). The data structure 116 may be referred to as a blockmatrix structure. A blockmatrix may be considered to be a matrix of independent blockvectors 122a, 122b, 122c, 122d and hashvectors Hi, H₃, H₄, Hs, H₆, H₇ that cross-link the blockvectors; these terms are described further below. A blockmatrix may be represented by an n X k X m matrix, where n, k and m are integers, and n is the length of the longest blockvector, k is the blockvector index number (or the number of blockvectors within the blockmatrix) and m is the hash check depth (which may be considered to correspond with the number of generations of hash checks that are made, as described further below).

[00121] In examples such as that shown in Figure 3, the data structure 116 is a multidimensional data structure, for example a data structure with three or more dimensions. The multidimensional data structure may be arranged in a form including a plurality of columns, a plurality of rows and a plurality of layers. In Figure 3, each column corresponds with a blockvector labelled with the reference numerals 122a, 122b, 122c, 122d. The rows of Figure 3 are labelled with the reference numerals 124a, 124b, 124c, 124d, 124e and the layers of Figure 3 are labelled with the reference numerals 126a, 126b, 126c, 126d.

[00122] The first storage data may include a first column of data of the plurality of columns of data, which is to be found in a first layer of the plurality of layers and in a first number of rows of the plurality of rows corresponding to a number of blocks of the first blockchain. In the illustrative example of Figure 3, the first storage data includes the first blockvector 122a (which corresponds with the first column), in the rows 124a, 124b, 124c, 124d, 124e (as the first blockchain in this example has five blocks) and in the first layer 126a. In such examples, the second storage data may include a second column of data of the plurality of columns of data, which is to be found in the first layer of the plurality of layers and in a second number of rows of the plurality of rows corresponding to a number of blocks of the second blockchain. In Figure 3, the second storage data includes the second blockvector 122b (which corresponds with the second column), in the rows 124a, 124b, 124c, 124d, 124e (as the second blockchain also has five blocks in this example) and in the first layer 126a. Thus, the first storage data may correspond to one column of the multidimensional data structure and the second storage data may correspond to all other columns of the multidimensional data structure. A column index of the multidimensional data structure may correspond to a Vectorlndex associated with the first storage data or the second storage data, which in turn may correspond to a node identifier associated with the first node, and node identifiers associated with all other member nodes (including the second member node) respectively.

[00123] In such examples, hash data (for example in the form of hashvectors Hi, H₃, H₄, Hs, H₆, H₇) may be stored in a second layer of the plurality of layers different from the first layer. This is shown in Figure 3, in which the hashvectors Hi, H₃, Hs are stored in the second layer 126b of the data structure 116. In this example, there are additional hashvectors stored in additional layers of the data structure (in the layers 126c, 126d of Figure 3), with each additional layer corresponding to an additional generation of a hash check. Thus, in the example of Figure 3, as there are three layers 126b, 126c, 126d that store hashvectors, the hash check depth of this example is three.

[00124] This may be generalized for a data structure or blockmatrix represented by an n X k X m matrix. In such cases, the portions of the blockmatrix with m = 1 (corresponding to the first layer 126a of Figure 3) may solely include blockvectors and may not include hashvectors. Conversely, the portions of the blockmatrix with m ≠ 1 (corresponding to the layers 126b, 126c, 126d in Figure 3) may solely include hashvectors and may not include blockvectors.

[00125] A member node such as the first member node 102a may store a current version of the blockmatrix (which may be similar to the data structure 116 shown in Figure 3). Different parts of the blockmatrix may be stored locally, on a local network and/or remotely in cloud storage. As will be appreciated from the above description, herein, the current version of the blockmatrix as stored by a member node is referred to as "storage data" and a version of the blockmatrix as received from another member node, or at least one or more blocks or other elements of the blockmatrix as received from another member node, is referred to as synchronization data. A member node may identify from synchronization data that it receives, data representing a block which is not currently held in its storage data, and add it to its storage data blockmatrix, hence updating the blockmatrix version held by, or on behalf of the member node. This is described further below with reference to FIGS. 13 to 15.

[00126] Referring back to Figure 3, a blockvector such as the blockvectors 122a, 122b, 122c, 122d may be considered to correspond to a single dimensional blockchain, such as a blockchain with no forks. A blockchain is a cryptographically secure chain of data records. Each blockchain (or blockvector) includes a sequence of blocks, which may be considered to be a one-dimensional series of blocks.

[00127] A block of a blockchain, such as the blocks Bn, B 12, B 13, B 14, B 15 of the first blockvector 122a (which may be referred to interchangeably herein as the first blockchain), may comprise a data record and verification data which is associated with the data record in order to provide verification of integrity. The verification data may include a cryptographic hash of the data record of the block.

[00128] Hashing herein refers to cryptographic hashing, the output of which is referred to as a hash, or message digest. A hash may be generated by a one-way cryptographic hashing algorithm, for example MD5 or SHA-256, operating on input data, such as a data record. The output is deterministic, in that application of the hashing algorithm again to exactly the same input data will produce the same hash. The output is one-way in that the original data record cannot be recovered from the hash alone, even with full knowledge of the hashing algorithm. The generated hash may be of a fixed length.

[00129] A further type of hashing algorithm, for example the keyed-hash message authentication code (HMAC) uses a cryptographic key, which may be a random string, in combination with the input data. In this way different, seemingly random, outputs may be generated from the same input data, in order to prevent third parties from detecting the same input data being hashed repeatedly. However, knowledge of the cryptographic key is required to verify the integrity of a data record holding the input data by repeating the hashing procedure and comparing it to the stored hash. [00130] Verification of the integrity of each data record in a blockchain can be performed by re-computing, i.e. regenerating, the hashes of blocks to be checked, beginning with the oldest to be checked, and performing a match with each respective hash stored in the blockchain. Hence, if anywhere in the chain a single data record is changed, or overwritten, after a blockchain has been generated, the hash stored with it in the block will not match the hash that is recomputed. The hash stored with it in the block could also be overwritten with a recomputed hash, however then the hash recalculated for the next block in the blockchain, which takes the hash of the previous block as on input, would then not match the hash stored in the subsequent block. Thus, in order to alter a single record in a blockchain without discoverability, every hash in every block subsequent to that data record would need to be overwritten, otherwise at least one hash in the blockchain would not re-compute correctly, and it can thus be detected that one or more data records have been changed. Adding a block to a blockchain provides a level of immutability to the data, in that it can be checked whether a data record has been altered or not, providing it is difficult to alter all the records in a blockchain. Such immutability can be achieved by storing copies of the blockchain in a distributed ledger, such as that illustrated schematically in Figure 1 and described further below.

[00131] A block may also include other associated metadata, for example a timestamp and a hash pointer which links the block to a previous block in the blockchain (such as the block immediately previous to the block). A block may also include a sequence number which indicates the position of the block in the blockchain.

[00132] In an illustrative example, a block includes the following data fields:

• Blocklndex (Type = Biglnteger)

• Vectorlndex (Type = Biglnteger)

• TimeStamp (Type = TimeStamp)

• PreviousHash (Type = String)

• BlockData (Type = String)

• BlockHash (Type = String).

In this example, the Blocklndex denotes the location of the block in the blockvector (and may therefore correspond with the sequence number of the block) and the Vectorlndex denotes which blockvector each block belongs. The Vectorlndex for blocks generated or created at a given member node of the DLN may be assigned to the member node when the member node is started or initialized, as described further with reference to Figure 8. The TimeStamp is the time at which the block was created, which may be accurate to the picosecond scale. The PreviousHash denotes the hash of the previous block in the sequence. The BlockData denotes the data record stored by the block. There may be no predefined size limit for the BlockData. The BlockHash denotes the hash of the block.

[00133] Thus, in the example of Figure 3, the block B 12 of the first blockvector 122a includes a hash of the data record associated with the block B 12, as well as the hash of the previous block B 11 of the first blockvector 122a. The hash of the previous block B 11 may therefore be considered to be a hash pointer linking the block B 12 to the block B 11.

[00134] An example flow chart illustrating the generation of the BlockHash value is shown in Figure 5. At item 130 of Figure 5, the first block is received. With reference to Figure 3, the first block may for example be the block B 11 of the first blockvector 122a. At item 132 of Figure 5, a hash value is generated. In this example, the hash value is generated by concatenating the Blocklndex, the Vectorlndex, the PreviousHash, the TimeStamp and the BlockData and providing this as an input to the SHA-256 hashing algorithm (although other algorithms may be used in other examples). At item 134, the hash value is returned and at item 136 the hash value is stored in the first block B 11 of the first blockvector 122a (which in this example corresponds to a first blockchain) as the BlockHash value, which is a string in this example.

[00135] To summarise, herein, a set of data referred to as a blockvector is a type of blockchain. Herein, a set of data referred to as a blockmatrix comprises a set of blockchains, or blockvectors, which are additionally cryptographic ally secured by the secure linking of data records across blockchains, This may be achieved by taking as input data, data from each of two corresponding blocks from respective blockchains, to generate verification data which can be used to check the integrity of both blocks. The verification data may include a hash generated from input data including each respective block. The resulting verification data is referred to herein as a hashblock. These hashblocks may be arranged in blockvectors, and may include various levels (or generations) of verification data such that a hashblock can represent validation data for blocks in any number of blockvectors, 2 or above, depending on the level of the hashblock in the blockmatrix, until a final hashblock is reached which represents a "golden hash" of each of the blockvectors in the blockmatrix. The hashblocks may be arranged in a diagonal matrix, which allows an arbitrary number of blockvectors to be validated using a hashblock from a selected level within the blockmatrix. This allows for any number of blockvectors to be represented efficiently in the blockmatrix.

[00136] A hashblock may be considered to be a unit from which hashvectors are built. The purpose of hashblocks is, for example, to join or chain blocks and blockvectors, blocks and blocks and/or blocks and hashblocks to allow blockvectors to be verified. Hashblocks may have a similar structure to blocks. An example of data fields of a hashblock is as follows:

• HashBlocklndex (Type = Biglnteger)

• HashVectorlndex (Type = Biglnteger)

• TimeStamp (Type = TimeStamp)

• HashChildren (Type = String)

• PreviousHashData (Type = String)

• HashData (Type = String).

In this example, the HashBlocklndex denotes the location of the hashblock in the hashvector and the HashVectorlndex denotes which hashvector the hashblock belongs to. The HashVectorlndex may be generated dynamically as new hashvectors are generated, for example based on the HashChildren, HashVectorlndex or BlockVectorlndex. The TimeStamp is the time at which the hashblock was created, which may be accurate to the picosecond scale. The HashChildren includes the hashes that were used to generate the HashData. The PreviousHashData denotes the hash of the previous hashblock in the sequence. The HashData denotes the hash of the previous hashblock, the BlockHash of the block and/or the HashData of the hashblock to be chained.

[00137] The generation of a hash of a hashblock may be generated in the same way as the generation of a hash of a block. For example, a hash of a hashblock may be generated by inputting the concatenation of the HashBlocklndex, the HashVectorlndex, the TimeStamp, the HashChildren and the Previous Hash to a hashing algorithm such as the SHA-256 hashing algorithm and taking the output as the hash of the hashblock.

[00138] Figure 6 is an example flow chart illustrating an example of generating a HashData value. At item 138 of Figure 6, a set of hash values is received. The set of hash values received will depend on where the hashblock is located within the blockmatrix. For example, the set of hash values may include the hash values for immediately neighbouring blocks or hashblocks (as will be described further below with reference to Figure 4). At item 140 of Figure 6, a hash value is generated. In this example, the hash value is generated by supplying the concatenation of the hash values of the set of hash values as an input to the SHA-256 hashing algorithm (although other algorithms may be used in other examples). At item 142 of Figure 6, the hash value is returned and at item 144 of Figure 6, the hash value is stored in the data structure, for example in a hashblock as a BlockHash value, which may be a string. As the method of Figure 6 may receive hashes of both blocks or hashblocks as inputs, this method may therefore be used to chain a hybrid of blocks and hashblocks.

[00139] An illustrative example of chaining blocks and hashblocks together is shown in Figure 4, which illustrates schematically the first and second rows 124a of the data structure 116 of Figure 3. In Figure 4, the first blockvector 122a and the second blockvector 122b have been processed to generate hash data representative of a hash Hi based on a first block Bn of the first blockchain (which in this example corresponds with the first blockvector 122a) and a second block B21 of a second blockchain (which in this example corresponds with the second blockvector 122b). This processing may be performed at the first member node 102a. For example, the first storage data (which may be considered to represent at least the first block Bn) the second storage data (which may be considered to represent at least the second block B21) and the hash data (which may be considered to represent at least the hash Hi) may be stored as part of a data structure at the first member node 102a.

[00140] Referring back to Figure 4, it can be seen in this example that the hash value Hi crosslinks the first block Bn of the first blockchain with the second block B21 of the second blockchain. Other hash values, such as the hash values H3, H5 of Figure 4, may link other blocks of neighbouring blockchains (which in this example correspond with blockvectors). For example, H3 corresponds to a hash of the second block B21 of the second blockchain and a neighboring block B31 of the third blockchain and H5 corresponds to a hash of the block B31 of the third blockchain with the neighbouring B41 of the fourth blockchain, where the third and fourth blockchains correspond to the first and fourth blockvectors 122c, 122d respectively.

[00141] In examples such as Figure 4, the first block B 11 cross-linked by the hash value to the second block B21 is in the same row (the first row 124a) as the second block B21. For example, the first block Bn may be stored at a first position in the first blockchain and the second block B21 may be stored at the first position in the second blockchain. In other words, the first block Bn and the second block B21 may have the same Blocklndex as each other but a different Vectorlndex. [00142] The hash value cross-linking the first block Bn to the second block B21 may be a first hash value representative of a first hash Hi. In cases such as this, the first member node 102a may store a set of hash data representative of a set of hash values including the first hash value and a second hash value representative of a second hash H2 based on the first hash Hi, a third block B 12 of the first blockchain stored at a second position in the first blockchain and a fourth block B22 of the second blockchain stored at the second position in the second blockchain. In the example of Figure 4, the second position corresponds with the second row 124b of the blockmatrix and the first position corresponds with the first row 124a of the blockmatrix. Thus, in examples such as this, the set of hash values may include hash values linking different rows of the blockvectors or blockchains.

[00143] The set of hash values may also include hash values cross-linking hashblocks with other hashblocks. For example, the blockmatrix (or data structure) may include third storage data representing a third continuous sequence of blocks of a third blockchain, the third continuous sequence of blocks created at the third member node 204c of the DLN 100. In FIGS. 3 and 4, the third storage data is representative of the third blockvector 122c, which corresponds with the third column of the data structure 116. A third hash H3 between the second block B21 of the second blockchain and a fifth block B31 of the third blockchain with the first index (for example in the same row as the second block B21 of the second blockchain) may be calculated. In the example of FIGS. 3 and 4, the third hash H3 is also stored as part of the data structure 116, in the third column, the first row 124a and the second layer 126c. However, in other examples, the data structure may not include the third hash. In examples such as FIGS. 3 and 4, the data structure may also store fourth hash data representative of a fourth hash value representative of a fourth hash H₄ between the first hash Hi and the third hash H3. The fourth hash H₄ may be stored in a different layer of the data structure 116 than the hashes used to generate the fourth hash H₄. In FIGS. 3 and 4, the fourth hash H₄ is stored in the third layer 126c whereas the first hash Hi and the third hash H₄ are stored in the second layer 126b. By cross-linking hashblocks with other hashblocks, the data structure 116 may provide additional security and verification than otherwise. For example, each additional layer of the data structure 116 may correspond to an additional hash check, incrementally increasing the security with each additional layer.

[00144] An example of generating a new hashblock upon receipt of a new block at a blockmatrix of the first member node 102a is illustrated in the flow diagram of Figure 7. [00145] At item 146 of Figure 7, the coordinates of a new block within the blockmatrix are received at the first member node 102a. The coordinates may be received in response to the new block being created at the first member node 102a or in response to the new block being received from another member node of the DLN and subsequently added to the blockmatrix. The precise format of the coordinates will depend on the form of the blockmatrix. However, if the blockmatrix is of the form shown in Figure 3, the coordinates will be in the form (n, k, m), where n is the length of the longest blockvector, k is the blockvector index number (or the number of blockvectors within the blockmatrix) and m is the hash check depth.

[00146] Blockchains at a member node of the DLN may be processed in a predetermined order. For example, each member node of the DLN may include a blockmatrix builder that includes a block ordering algorithm that orders the blockvectors in a predetermined order. The block ordering algorithm may be common to each DLN such that, when corresponding blocks, from adjacent blockvectors in the blockmatrix, are chained together, the same resulting hashblock is created. Hence, each member node is able to verify the integrity of a blockmatrix that it has stored against a blockmatrix that may be received from a remote member node of the DLN. The blockchains may be ordered for example according to a member node identifier (described further below with reference to Figure 8), which may be considered to correspond to a second dimension. As shown in Figure 4, blocks from blockchains having a predetermined relationship in the array of blockchains (such as adjacent blockchains) may also be chained together, with the hashblocks generated corresponding to a third dimension of a multi-dimensional data structure for example.

[00147] Hence, the method of Figure 7 involves, at item 148 of Figure 7, checking whether the blockchains (or blockvectors) of the blockmatrix are arranged in a predetermined order at the first member node 102a. The predetermined order is for example based on the node identifier (or Vectorlndex) associated with the member node at which the respective blockvector was created. As node identifiers may be generated based on a synchronous time source (e.g. an atomic clock) identifying a time corresponding to when the corresponding member node joined the DLN, each subsequent node identifier (for each subsequent member node that joins the DLN) may be larger than previous node identifiers for member nodes that have previously joined the DLN. As each blockvector may be associated with a node identifier (which for example corresponds with the member node at which the blockvector was created), the blockvectors may be arranged based on node identifier, from the smallest to the largest (i.e. representing the oldest to the youngest member node). As there will have been more time to add new blocks to the oldest blockvectors, the longest blockvectors (i.e. the longest blockchains) will tend to be located in the first positions of the blockmatrix, for example in the leftmost column of the blockmatrix for a blockmatrix with a structure similar to that of Figure 3. If the blockchains are not arranged in the predetermined order, the blockchains are reordered at item 150, for example using the block ordering algorithm.

[00148] Once the blockchains are arranged in order, the method of Figure 7 involves, at items 151 and 152 checking whether there are valid blocks in predetermined locations or positions within the data structure 116 for generating a hashblock at a particular position within the data structure 116 relative to the blocks. For example, methods such as Figure 7 may involve checking for valid blocks in positions neighbouring or adjacent to the position of a hashblock to be generated, for example with indices that are previous or subsequent to indices corresponding to or representing coordinates of the position of the hashblock to be generated.

[00149] In the example of Figure 7, in which the data structure is a three-dimensional blockmatrix, arranged in columns, rows and layers such as the blockmatrix of Figure 3, item 151 involves checking whether there is a valid block or hashblock to the front of the position of the hashblock to be generated. Such a check may involve identifying whether the block or hashblock includes valid data or merely null or unknown values. The coordinates of the current hashblock may be calculated based on the coordinates of the new block or hashblock, for example upon receipt of the new block. For example, the current hashblock to be generated may be located in the same row and column as the new block or hashblock but in an adjacent layer (for example in the second layer 126b rather than the first layer 126a as shown in Figure 4).

[00150] At item 152, the method of Figure 7 involves checking whether there is a valid block or hashblock in a different neighbouring position than that checked at item 151. In this example, the check at item 152 involves determining whether there is a valid block or hashblock to the front left of the position of the current hashblock in the blockmatrix. For example, referring back to Figure 4, upon receipt of the fourth block of the second blockchain (B22), the checks at item 151 and 152 of Figure 7 may involve checking whether there is indeed a block to the front of the current hashblock to be generated (H2), and thus whether the blocks B 12 and B22 of Figure 7 are present and include valid data rather than null values. [00151] If one or both of these blocks or hashblocks are not present or are not valid, hashblock generation is ceased at item 154. At this stage, the first member node 102a may wait to receive an update from other member nodes of the DLN to fill in any missing blocks or hashblocks at the first member node 102a, before subsequently attempting to perform the hashblock generation again.

[00152] If blocks or hashblocks in the predetermined positions relative to the current hashblock to be generated (in this example, to the front and front left of the current hashblock to be generated) are present and valid, the method of Figure 7 involves, at item 156, checking whether there is a valid hashblock in a predetermined position or location relative to the position or location of the current hashblock within the data structure. In the example of Figure 7, item 156 includes checking whether there is a valid hashblock above the position of the current hashblock within the blockmatrix. If not, the blocks or hashblocks to the front and left of the current hashblock are hashed at item 158. In contrast, if there is a valid hashblock above the position of the current hashblock within the blockmatrix, the blocks or hashblocks to the front, left and above the current hashblock are hashed at item 160.

[00153] As will be appreciated, in other examples in which the method involves checking for blocks and/or hashblocks in other predetermined positions relative to the position of the current hashblock within the data structure, the hashes generated (for example corresponding to items 158 and 160 of Figure 7) may be generated using valid blocks and/or valid hashblocks at these other predetermined positions relative to the position of the current hashblock within the data structure.

[00154] Subsequently, at item 162 of Figure 7, a new hashblock is generated at the position of the current hashblock, thereby updating the data structure. The new hashblock for example includes the HashBlocklndex, HashVectorlndex, TimeStamp, HashChildren, PreviousHashData and HashData as described above. The HashBlocklndex is equal to the HashBlocklndex of the upper hashblock (the hashblock above the current hashblock in the blockmatrix) plus one (or 1 if there is no upper hashblock). The HashVectorlndex is equal to the HashVectorlndex of the upper hashblock (as they are both in the same column of the blockmatrix) or the Vectorlndex of the new block (if there is no upper hashblock). The TimeStamp is the current time and the HashChildren are the front block or hashblock, the front left block or hashblock (and the upper hashblock if present). The PreviousHash is the HashData of the upper hashblock (or a random number if there is no upper hashblock). The HashData is equal to a hash of the hashes calculated at items 158 or 160 and the hash of (HashBlocklndex + HashVectorlndex + TimeStamp + HashChildren + PreviousHash) of the current hashblock, where the + symbol for example refers to a concatenation. This may be similar to the generated of the second hash H₂ shown in Figure 4.

[00155] A similar method may be used to generate further hash checks, which may be stored in additional layers of the blockmatrix (such as the fourth, sixth and seventh hashes H₄, ¾, H₇ illustrated in Figure 4). However, instead of taking front and front left blocks as an input, a current hashblock may be generated based on front and front left hashblocks as an input (as well as an upper hashblock if it exists).

[00156] As explained above, examples may involve creating a first block at the first member node 102a, receiving a first node identifier associated with the first member node 102a, selecting a first blockchain from a plurality of blockchains based on the first node identifier and extending the first blockchain by storing the first block as part of the first blockchain. Figure 8 illustrates an example of allocation of a first node identifier to the first member node 102a.

[00157] At item 164 of Figure 8, the first member node starts up, i.e. initializes. At item 166, the first member node generates a random number, such as a random universally unique identifier (UUID). At item 168, the first member node receives a timestamp from a server, such as an atomic timestamp server accessible to the first member node (which may also be accessible to other member nodes of the DLN). The timestamp for example represents a time associated with initializing the first member node and may be accurate to nanoseconds or picoseconds. The time represented by the timestamp may be measured using a synchronous time source, e.g. an atomic clock, at, or accessible to each member node, which provides a highly accurate time measurement, so that the node identifiers are unique. The atomic clock may for example be located in a control node accessible to member nodes of the DLN, which may be queried by the first member node during the initialization process. At item 170 of Figure 8, the first node identifier is generated based on an exact time associated with initializing the first member node, for example a point at which a specific routine is conducted during initialization. In this example, the first node identifier also includes a random number generated by the member node in order to decrease the chance of any two member nodes having the same node identifier (although the first node identifier may be generated based on the time of initializing without using the random number in other examples, providing time is measured using a sufficiently granular clock to ensure that two nodes are highly unlikely to receive the same node identifier). The first node identifier in Figure 8 is generated by concatenating the timestamp and the random number and is then allocated to the first member node at item 172. Thus, Figure 8 is an example of generating the first node identifier upon initialization of the first member node and, subsequently, allocating the first node identifier to the first member node based on time of initialization. Thus, when the node identifiers are ordered lowest- highest, the order is in a time-order.

[00158] There may be a plurality of control nodes, geographically spread, to provide service to member nodes which are in each respective geographic area. For example, a control node may supply a timestamp indicative of a time of initialization of a member node in the geographic area associated with the control node. By receiving a timestamp from clocks that are accurate and synchronous, such as atomic clocks, each member node may be able to generate an accurate, consistent node identifier based on time of initialization, which is consistent across the DLN, for example across different control nodes of the DLN. In other examples, though, a member node may retrieve or receive a node identifier from the control node rather than retrieving or receiving a timestamp from the control node.

[00159] Each member node is the sole source of blocks for a given blockvector within the blockmatrix, and each different member node is the respective sole source of blocks for a different blockvector within the matrix. For example, the first member node may be the sole source of all blocks in the first blockchain. A member node includes a module for accepting incoming requests for data to be published to the DLN. These requests may be sent locally at the DLN node, or may be sent from remote computing devices securely connected to the DLN node. For example, in a financial institution, such requests may comprise records of trades which can be originated in trade management systems connected to the member node via a corporate network administered by the financial institution, or another party on behalf of the financial institution. When the incoming request is accepted, the member node originates a block, including the data record and the hash performed on the data record and the hash stored in the previous block of the blockvector which the member node uses to add blocks to the blockmatrix. It subsequently transmits the newly-added block in synchronization data to other member nodes, hence publishing it to the network.

[00160] Thus, a member node may be responsible for originating all blocks in a single blockchain within the blockmatrix, and this is referred to herein as the member node's primary blockvector. Blockvectors originated by other member nodes, and received in synchronization data from the network, are referred to herein as a member node's secondary blockvectors. A member node's primary blockvector may be stored by the member node itself in its storage data.

[00161] By allowing a member node to be the sole source of blocks within the member node's primary blockvector (which may be considered to correspond to a member node's primary blockchain), blocks can be added to the DLN without delay and without the danger of collisions between blocks created on a different member nodes. Methods of controlling publication to a blockchain network involving competition between nodes, such as proof-of-work or other methods of cooperative publication of a single block or multiple blocks, are therefore not required. Furthermore, methods described herein also avoid the chance of forking and the complexities and delays associated with forking. These methods therefore provide a low- latency publication method, which may be useful if users require quick confirmation of a data record having been added to the DLN.

[00162] For example, a first continuous sequence of blocks created at the first member node may include a first block created at a first time and a subsequent block created at a subsequent time, the subsequent block positioned immediately subsequent to the first block in the first continuous sequence of blocks. A second continuous sequence of blocks created at the second member node may include a second block created at a second time between the first time and the subsequent time. In other words, blocks may be added to the first and second blockchains (which originate at the first and second member nodes) at different times from each other or at the same time as each other, without requiring a consensus-based algorithm for publication of blocks and still without risking sequence number collision, as each member node is the sole source for blocks of the member node's primary blockvector.

[00163] As described above, each member node 102 has a unique identity within the network, which is referred to herein as a Vectorlndex. The primary blockvector of a member node may be associated with its network identity, in this case the Vectorlndex, in order to uniquely identify the blockvector within the blockmatrix. A block within a blockvector may be identified by a sequence number, representing its position within the blockchain formed by the blockvector. Herein, the sequence number of a block within a blockvector is referred to as the Blocklndex. [00164] Transactions, i.e. data records, may be identified in the distributed ledger either directly or indirectly, by lookup. Herein, a transaction identifier or transaction ID, which may be used to directly identify a block within the blockmatrix, and which is unique network-wide, is formed by concatenating the Blocklndex and the Vectorlndex in a predetermined order. The transaction ID may be returned to the user as part of a receipt when a block is committed to the blockmatrix.

[00165] Figure 9 shows an example of extending a first blockchain in a DLN. The method of Figure 9 may be performed when a user attempts to create a new block at a member node of the DLN (in this example the first member node 102a). The method of Figure 9 involves checking the validity of the existing blockvector on the member node, which is for example the blockvector with a Vectorlndex corresponding to the member node, i.e. with a node identifier associated with the member node. In this example, the method therefore involves checking the validity of the first blockvector, which corresponds to the first blockchain, on the first member node 102a. Providing the blockvector is valid, the first block is generated and the first blockchain is extended by adding the first block to the first blockchain. The first block, the updated first blockchain or the updated blockmatrix may then be broadcast to the DLN.

[00166] At item 174 of Figure 9, incoming data for a first block is received. The incoming data may be received within the first member node 102a, for example where the data is created at the first member node 102a and subsequently processed as shown in Figure 9. Alternatively, the incoming data may be received from another node of the DLN, for example as part of inbound synchronization data (as discussed further below).

[00167] At item 176 of Figure 9, a first node identifier is received from the first member node 102a. The first node identifier may be generated as described with reference to Figure 8. For example, the first node identifier may be generated based on first member node parameters as shown at item 178, such as a random number generated by the first member node 102a.

[00168] At item 180 of Figure 9, the validity of the first block and the first blockchain are checked. For example, the method of Figure 9 may involve, before extending the first blockchain, determining that the first block satisfies at least one block validity condition. Similarly, the method of Figure 9 may also or alternatively involve, before extending the first blockchain, determining that the first blockchain satisfies at least one blockchain validity condition. This is described further below with reference to Figure 11. Determining that a block satisfies at least one block validity condition as referred to herein may involve determining that the block satisfies all of a set of block validity conditions, where there may be one or more block validity conditions in the set of block validity conditions. For example, the set of block validity conditions may correspond to the minimum set of conditions for the block to be considered valid. Similarly, determining that a blockchain satisfies at least one blockchain validity condition as referred to herein may involve determining that the blockchain satisfies all of a set of blockchain validity conditions, where there may be one or more blockchain validity conditions in the set of blockchain validity conditions. The set of blockchain validity conditions may thus correspond to the minimum set of conditions for the blockchain to be considered valid.

[00169] If the first block (the data for which was received at item 174) or the first blockchain are not found to be valid, the method of Figure 9 involves, at item 182, waiting for new data to be received or restarting the first member node. In other words, if the first block or the first blockchain are invalid, the first block is not added to the first blockchain as this would destroy the validity of the first blockchain at the first member node 102a.

[00170] In contrast, if the first block and the first blockchain are determined to be valid, the first block may be added to the first blockchain. In the example method of Figure 9, this involves, at item 184, obtaining the next sequence number for the first block from the first blockchain. The next sequence number may be obtained from the first blockchain by incrementing the sequence number of the block at the end of the first blockchain (i.e. the most recently added block) by one.

[00171] At item 186 of Figure 9 a hash of the previous block (which in this example is the block at the end of the first blockchain) is obtained, for example using the method of Figure 5. The method of Figure 5 may also be used to generate the hash of the first block at item 188 of Figure 5. As will be appreciated, the other of the items of Figure 9 is merely illustrative and may differ in other examples. For example, item 186 may be performed after item 188.

[00172] After generating the hash of the previous block and the first block, various actions may be performed. For example, the first blockchain at the first member node 102a may be extended in response to the first block being created (item 190 of Figure 9), and data representing the first block may be added to the first storage data at item 192. In this way, the first storage data may be updated to represent the first blockchain after being extended.

[00173] The first block is then transmitted for synchronization with data stored at other member nodes of the DLN (item 194 of Figure 9). Note, that whilst synchronization is described in relation to one member node transmitting outbound synchronization data, and other nodes of the network receiving corresponding inbound synchronization data, it should be understood that each member node of the DLN performs similar methods of synchronization with respect to other member nodes of the DLN. Thus, each member node transmits outbound synchronization data to other nodes of the DLN, and each member node receives inbound synchronization data from other nodes of the DLN.

[00174] The first block may be transmitted as outbound synchronization data for receipt by at least one other member node of the DLN. According to a first method of synchronization, the outbound synchronization data in examples may include a first type of outbound synchronization data transmitted from a member node to other nodes, and a corresponding first type of inbound synchronization data received at a member node from other nodes. The first type of outbound synchronization data is transmitted at irregular intervals, synchronously with respect to the creation at blocks at the first member node, i.e. in response to each block being created at the first member node 102a. For example, the first type of outbound synchronization data may correspond to data representative of one new blocks, which may be transmitted to the other member nodes of the DLN upon creation of the new block. Thus, the first type of outbound synchronization data may be transmitted without delay to the other member nodes, so that data held at the other member nodes may be synchronized with the data held at the first member node 102a rapidly. This may help to improve the consistency between different member nodes of the DLN so that, at any given time, most or all of the member nodes store an up to date copy of the data structure.

[00175] According to a second method of synchronization, the outbound synchronization data in examples may include a second type of outbound synchronization data transmitted from a member node to other nodes, and a corresponding second type of inbound synchronization data received at a member node from other nodes. The second type of outbound synchronization data is transmitted at regular intervals, or at least at timings which are generally well-spaced, asynchronously with respect to the creation at blocks at the first member node. For example, item 196 of Figure 9 involves, after adding the data representing the first block to the first storage data, compressing the outbound synchronization data before transmitting the outbound synchronization data to the at least one other member node. Subsequently, at item 198 of Figure 9, the compressed outbound synchronization data may be transmitted to the at least one other member node. The second type of outbound synchronization data includes more information than the first type of outbound synchronization data, for example more than newly created blocks. For example, the second type of outbound synchronization data may include the entirety of the first blockchain or a continuous sequence of blocks of the first blockchain, or some or all of the blockmatrix or data structure including the first blockchain and the second blockchain, and verification data associated therewith, or only the first blockchain and verification data associated therewith. If for example at least every generation of hashblock data derived at least in part from the first blockchain is included, the integrity of the first blockchain can be verified at other nodes receiving the second type of synchronization data by recomputing the hashes in the hashblocks based on the first blockchain and blockchain data received from other nodes, and then comparing one or more of the computed values to the received values. The second type of outbound synchronization data may include all of the first storage data and the second storage data, or parts thereof. Transmission of the second type of outbound synchronization data may be performed at regular intervals, or at least at timings which are generally well- spaced, to allow the other member nodes of the DLN to allow data stored at the member nodes to be supplemented regularly, or at least at timings which are generally well-spaced by the second type of outbound synchronization data. Since the first type of outbound synchronization data may not arrive safely at any given member node (as any given transmission is not guaranteed to arrive if a connectionless protocol is used), the data stored at the given member node may become out of date, and it may not include newly created blocks represented by the first type of inbound synchronization data. However, the data stored at the given member node may then be updated upon receipt of the second type of inbound synchronization data.

[00176] Methods such as that of Figure 9 may involve detecting a synchronization trigger event, and in response to detecting the synchronization trigger event, transmitting the second type of outbound synchronization data to the at least one other member of the DLN. The synchronization trigger event may be associated with a regular time interval or a varying time interval which is asynchronous with respect to the creation of blocks on a member node (e.g. it may be a random time interval). The synchronization trigger may be associated with a command received from a control node of the DLN for the second type of outbound synchronization data to be transmitted.

[00177] The points in time at which the synchronization trigger event occurs may depend on the node identifier associated with the member node from which the second type of outbound synchronization data is transmitted (in this case, the first node identifier). As each member node has a different node identifier (which may be pseudo-random, for example based on a timestamp and a random number), transmitting the second type of outbound synchronization data at times depending on the node identifier may allow the second type of outbound synchronization data from various different member nodes to be spread across time, for example pseudo-randomly. This may help even out or balance the network load.

[00178] Examples may include transmission of only one of the first type of outbound synchronization data and the second type of outbound synchronization data. For example, the first type of outbound synchronization data may be transmitted upon the creation of a new block at a member node and the first type of outbound synchronization data may be retransmitted at regular intervals, or at least at timings which are generally well-spaced. Alternatively, the second type of outbound synchronization data may be transmitted at regular intervals, or at least at timings which are generally well-spaced, and the first method of synchronization may be omitted.

[00179] In the second method of synchronization, during a time interval between one outbound synchronization data transmission, and an immediately subsequent (i.e. next) outbound synchronization data transmission, a plurality of blocks of the first blockchain may be created. Thus, the second type of outbound synchronization data may not be transmitted each time a block is created at the first member node. In such cases, the subsequent outbound synchronization data may include data representing the plurality of blocks that have been created between one outbound synchronization data transmission and the subsequent outbound synchronization data transmission. For example, the second type of outbound synchronization data may include a blockmatrix (taken from the most recently updated first and second storage data) including the plurality of blocks that have been created between one second type of outbound synchronization data transmission and the subsequent second type of outbound synchronization data transmission.

[00180] In some examples, the first blockchain may be extended by adding a continuous sequence of blocks to the first blockchain during the time interval between one outbound synchronization data transmission and the subsequent outbound synchronization data transmission. The continuous sequence of blocks may be added to the first block in response to receiving a plurality of data records to be added to the DLN. As explained above with reference to Figure 9, the plurality of data records are typically created at the first member node 102a but may be received from an alternative source in some examples.

[00181] Transmission of both, or either of the first and second types of outbound synchronization data may include multicasting the outbound synchronization data to a plurality of member nodes of the DLN. For example, a member node which multicasts data such as the outbound synchronization data may broadcast the data to all member nodes of the DLN that are listening for multicast transmissions. Multicasting for example involves transmitting data to a group of destination computing devices (such as the member nodes of the DLN) using known multicasting protocols. Multicasting of the outbound synchronization data is performed using a connectionless protocol, such as the User Datagram Protocol (UDP). Multicasting therefore differs from peer-to-peer transmissions in which a member node transmitting outbound synchronization data must have a direct connection with each other peer (such as another member node of the DLN) in order to transmit the outbound synchronization data to that peer. The method of these examples thus provides much lower network overhead and utilization compared to existing DLN networks, in which significant overhead and utilization is required in the setting up and maintenance of peer-to-peer connections across the network. For example, UDP involves a so-called "fire and forget" method that occurs once. In contrast, a connection-oriented protocol such as the Transmission Control Protocol (TCP) requires a three stage handshake for a connection to be opened. Connection-oriented protocols therefore unicast data (and may thus be considered to involve injective or one-to-one transmissions) whereas a connectionless protocol such as UDP multicasts data, and may thus be considered one-to-many, with one member node transmitting data to a set of other member nodes. For example, UDP typically involves one broadcast whereas TCP generally involves multiple nodes connecting and disconnecting with each other and the same data being sent multiple times around a network.

[00182] Figure 10 is a flow diagram illustrating the receipt of a first block at a first member node 102a according to examples. The method of Figure 10 may be performed when a new block (such as the first block) is received by a member node (such as the first member node) as inbound synchronization data from a different member node of the DLN or when the new block is created at the member node and received internally within the member node. In summary, the method of Figure 10 involves obtaining the parent blockvector (i.e. blockchain) for the new block from the member node (if it exists) and processing the new block to ensure it is valid before committing the new block to the blockvector. If the new block is found to be invalid or if the parent blockvector for the block is not stored at the member node, the new block is discarded.

[00183] At item 200 of Figure 10, the first block is received at the first member node 102a. At item 202, the blockchains stored at the first member node 102a are obtained (for example by obtaining the blockvectors of the first member node 102a). A check is performed at item 204 to determine whether the parent blockchain of the first block (in this example the first blockchain) is stored at the first member node 102a. If not, the first block is discarded at item 206.

[00184] If the first blockchain in this example is stored at the first member node 102a, the method of Figure 10 involves obtaining the last block of the first blockchain at item 208. For example, the last block of the first blockchain may be obtained by retrieving the block of the first blockchain with the largest Blocklndex. At item 210, it is determined whether the first block satisfies at least one validity condition. This is explained further below with reference to Figure 11. If the first block is found to be invalid, the first block is discarded at item 206. If, however, the first block is found to be valid, the first block is stored as part of the first blockchain at item 212. For example, the first blockchain may be extended by adding the first block to the end of the first blockchain. The first block, the updated first blockchain or the updated blockmatrix may then be broadcast or transmitted to at least one other member node of the DLN as described with reference to Figure 9. Finally, at item 214, at least one hash value is generated based on the updated first blockchain. The at least one hash value may be generated for example using the method of Figure 7.

[00185] An example of validation of a block will now be described with reference to Figure 11. The method of Figure 11 may be used to check whether two sequential blocks are valid and pass at least one validity condition for the two sequential blocks to be chained, for example to form a continuous sequence of two blocks as part of blockchain. In the example of Figure 11, the validity conditions for block a and block b to be valid (where block b comes after block a in a sequence of blocks) may be summarized as follows:

1. The Blocklndex of block b must equal the Blocklndex of block a + 1.

2. The PreviousHash stored in block b must equal the BlockHash of block a.

3. The hash of block b (generated by the method of Figure 5, for example) must equal the BlockHash of block b. [00186] This can be seen from Figure 11, which involves receiving block a at item 216 and receiving block b at item 218. Item 220 involves checking criterion 1, item 222 involves checking criterion 2 and item 224 of Figure 11 involves checking criterion 4. If any of these criteria are failed, it is determined at item 226 of Figure 11 that the validation of block b has failed. Block b will therefore not be added to the blockchain including block a. Conversely, if these criteria are passed, at item 228 of Figure 11 it is determined that the validation of block b has succeeded. Block b may then be added to the blockchain including block a.

[00187] It is to be noted that the validation example of Figure 11 is merely illustrative. In some cases some of the validity conditions may be omitted or other validity conditions may be used instead. For example, in some cases methods described herein may include receiving a request to validate data on the first member node and, in response, processing the hash data to check whether the hash satisfies at least one hash validity condition. For example, this may involve checking criterion 3 without checking criteria 1 and 2.

[00188] A similar method to that of Figure 11 may be used to check the validity of a hashblock, for example to check that two sequential hashblocks in a hashvector are valid. For example, the validity conditions for hashblock a and hashblock b to be valid (where hashblock b comes after hashblock a in a sequence of hashblocks) may be summarized as follows:

1. The HashBlocklndex of hashblock b must equal the HashBlocklndex of block a + 1.

2. The PreviousHashData stored in hashblock b must equal the HashData of hashblock a.

3. The hash of hashblock b (generated by the method of Figure 6, for example) must equal the HashData of hashblock b.

[00189] As explained above for checking the validity of a block, though, in some cases some of these validity conditions may not be checked or different validity conditions may be used.

[00190] Figure 12 is a flow diagram illustrating an example of validation of a blockchain according to examples. The method of Figure 12 may be used to check the consistency and contents of a blockvector or blockchain based on the blocks of that blockchain independently of validating other blockvectors or hashvectors of a blockmatrix.

[00191] At item 230 of Figure 12, the Vectorlndex of the blockvector to validate is received. In this instance, the first node identifier is received, as the first node identifier corresponds to the Vectorlndex in this example. At item 232 of Figure 12, the first blockchain is obtained from the first member node 102a. At item 234 of Figure 12, the validity of individual blocks is checked, for example using the method of Figure 11 with two consecutive blocks of the first blockchain as inputs. If all of the blocks of the first blockchain satisfy the at least one block validity condition, the first blockchain is considered to satisfy the at least one blockchain validity condition and the first blockchain is validated at item 236 of Figure 12. If, however, one of the blocks of the first blockchain fails to satisfy the at least one block validity condition, the validation of the first blockchain fails at item 238. At item 240, all blocks in the first blockchain are then deleted after the last validated block. The first member node 102a may update the first blockchain at a later time, if the first member node 102a receives a copy of the first blockchain from another member node of the DLN that is validated according to the method of Figure 12.

[00192] The method of Figure 12 may be performed separately for some or all of the blockvectors or blockchains stored at a member node. For example, in response to receiving a request to validate data at the first member node 102a, the first storage data may be processed to check whether the first blockchain satisfies at least one blockchain validity condition and the second storage data may be processed to check whether the second blockchain satisfies the at least one blockchain validity condition.

[00193] Figure 13 is a flow diagram illustrating an example of receiving a new blockchain at a first member node, which may involve the validation methods described with reference to FIGS. 11 and 12. The method of Figure 13 may be performed when a new blockmatrix is received at a member node of the DLN that includes blockvectors that do not exist or that are not currently stored at the member node. First, the method of Figure 13 confirms that a blockvector of the blockmatrix is not present at the member node. Subsequently, the contents of the blockvector are validated as each block of the blockvector is saved to the member node.

[00194] Item 242 of Figure 13 represents a data structure stored on the first member node 102a of the DLN. The data structure for example stores a blockmatrix such as the blockmatrix of Figure 3. Item 244 represents a second blockchain, which may for example be represented by inbound synchronization data transmitted from the second member node 102b to the first member node 102a.

[00195] As described above for the outbound synchronization data, the inbound synchronization data may be a first type of inbound synchronization data or a second type of inbound synchronization data. The first type of inbound synchronization data for example represents one or more blocks of a blockchain created at a member node other than the member node receiving the inbound synchronization data. In the example in which the inbound synchronization data is received from the second member node 102b, the first type of inbound synchronization data may represent one or more blocks of the second blockchain that have been newly created at the second member node 102b. The first type of inbound synchronization data may be received at irregular intervals, for example when one or more new blocks of the second blockchain are created at the second member node 102b and transmitted to the first member node 102a (for example as the first type of outbound synchronization data). The second type of inbound synchronization data for example represents all or part of an entire set of the member nodes' blockchains, i.e. the blockmatrix. Where the first member node 102a includes a first version of the second storage data representing blocks of a first version of the second blockchain before receiving the inbound synchronization data, the second type of inbound synchronization data may include a second version of the second storage data representing blocks of a second version of the second blockchain. The second version of the second blockchain may be an updated version of the second blockchain compared with the first version of the second blockchain. In some cases, each member node of the blockchain includes a copy of all the blockchains within the DLN. In such cases, the second type of inbound synchronization data may include data representative of a copy of the blockchains of the DLN stored at a member node other than the member node receiving the second type of inbound synchronization data. As for second type of inbound synchronization data, the second type of inbound synchronization data may be received at regular intervals, or at least at timings which are generally well- spaced, by the first member node 102a, in response to regular or at least generally well-spaced transmissions of the second type of outbound synchronization data by the second member node 102b.

[00196] Item 246 of Figure 13 involves checking whether the second blockchain is stored on the first member node 102a. If the second blockchain is already stored on the first member node 102a, the process of Figure 13 is exited at item 248. In cases such as this, a different method can be used to update the data stored at the first member node 102a using the inbound synchronization data. For example, new blocks of the second blockchain that are not already present on the second blockchain of the first member node 102a may be added sequentially to the second blockchain of the first member node 102a as described further below with reference to Figure 14.

[00197] If the second blockchain is not stored on the first member node 102a, a new blockchain is created at item 250 of the method of Figure 13. The new blockchain may be created as a new blockvector in the blockmatrix with a Vectorlndex equal to the Vectorlndex associated with the second blockchain. The first block of the second blockchain (for example the block of the second blockchain with the lowest Blocklndex, which is for example positioned in the first row of the blockmatrix) is stored to the new blockchain at item 252 of Figure 13.

[00198] Subsequently, the validity of each subsequent block of the second blockchain is checked at item 254. Item 254 may involve checking whether each subsequent block of the second blockchain satisfies at least one validity condition, for example using the method of Figure 11. For each subsequent block, if the subsequent block of the second blockchain satisfies the at least one validity condition, the subsequent block is stored as part of the new blockchain at item 256 of Figure 11. This method may therefore involve creating or generating second storage data representing the blocks of the new blockchain (which in this example corresponds to the second blockchain received from the second member node 102b). If, however, a block of the second blockchain is found not to be valid, the process is exited at item 248.

[00199] Figure 14 is a flow diagram illustrating an example of updating a blockchain at a first member node. Before receiving inbound synchronization data in the example of Figure 14, the first member node 102a includes a first version of the second storage data representing blocks of a first version of a second blockchain (item 258 of Figure 14). The first member node 102a receives the inbound synchronization data from the second member node 102b at item 260 of Figure 14, which in this example is representative of blocks of a second version of the second blockchain. At item 262 of Figure 14 it is determined that the second version of the second blockchain is longer than the first version of the second blockchain. This may be performed by calculating the length of the first and second versions of the second blockvectors (which in this example correspond to the first and second versions of the second blockchain respectively) and comparing the respective lengths to ascertain that the second version of the second blockchain is longer than the first version of the second blockchain.

[00200] In examples such as Figure 14, the first version of the second blockchain may be updated based on the inbound synchronization data such that the second storage data is representative of the second version of the second blockchain, and similarly updated based on the inbound synchronization data such that the second storage data is representative of up-to- date, or near-up-to-date, versions of the primary blockchains of all other member nodes. The first version of the second blockchain may be updated without checking the validity of the inbound synchronization data. However, typically the validity of the inbound synchronization data is checked before the first version of the second blockchain is updated. Figure 14 shows such an example.

[00201] At item 264 of Figure 14, the index of the last block of the first version of the second blockchain is obtained. This index may be obtained by obtaining the largest Blocklndex of the first version of the second blockvector. At item 266 of Figure 14, the block with the index of the last block of the first version of the second blockchain incremented by one is obtained from the second version of the second blockchain. Then, at item 268, it is determined whether the block obtained at item 266 satisfies at least one validity condition, for example by using the block at item 266 and the block at item 264 as inputs to the method of Figure 11. If the block obtained at item 266 does not satisfy the at least one validity condition, the process is exited at block 270. If, however, the block obtained at item 266 does satisfy the at least one validity condition, this block is added to the first version of the second blockchain, for example at the end of the first version of the second blockchain, at item 272. The first version of the second blockchain may thus be updated, which may involve updating the second storage data. This method may be performed multiple times for each block of the second version of the second blockchain that isn't present in the first version of the second blockchain.

[00202] After updating the first version of the second blockchain for consistency with the second version of the second blockchain, the method of Figure 14 involves, at item 274, generating at least one hash value, for example using the method of Figure 7. However, in some examples, the generation of the at least one hash value may be omitted or may not be performed immediately after updating the first version of the second blockvector. For example, the generation of the at least one hash value may be performed intermittently, for example once a day, rather than each time the blockchains stored at the first member node 102a are updated or altered.

[00203] Figure 15 is a flow diagram illustrating an example of updating a blockchain at a second member node 102b of the DLN, for example to generate the inbound synchronization data that may be received by the first member node 102a.

[00204] The second member node 102b in Figure 15 includes a second blockchain (item 276), which in this example includes a continuous sequence of blocks created at the second member node 102b. Thus, in Figure 15, the second member node 102b is the sole source for blocks of the second blockchain. [00205] In the method of Figure 15, a second block is created at the second member node 102b at item 278. At item 280, it is determined that the second block is to be stored as part of the second blockchain based on the second node identifier (as described above for storage of the first block as part of the first blockchain). At item 282, it is determined that the second blockchain does not include the second block. In other words, it is determined that the second block is a new block. At item 284, the last block of the second blockchain is obtained and is determined whether the second block satisfies at least one validity condition at item 286. For example, the determination of the validity of the second block may be performed by supplying the second block and the last block as inputs to the method of Figure 11.

[00206] If the second block does not satisfy the at least one validity condition, the process is exited at item 290. Thus, the second block is not stored as part of the second blockchain. If, however, the second block does satisfy the at least one validity condition, the second blockchain is extended by adding the second block to the second blockchain at item 292. Subsequently, at item 294, at least one hash value may be generated, for example using the method of Figure 7 (although this item may be omitted in some cases). The updated second blockchain (or solely the second block that has been added to the second blockchain) may then be transmitted to at least one other member node of the DLN as outbound synchronization data in order to synchronize data stored at the at least one other member node with that of the second member node 102b. The outbound synchronization data may be transmitted as described above and may therefore include other blockchains than the second blockchain, for example the entire blockmatrix including the second blockchain.

[00207] Figure 16 is a flow diagram illustrating an example of updating a data structure at a first member node. The method of Figure 16 may be used when a member node of the DLN receives a blockmatrix (or other data structure) from another member node of the DLN. The method of Figure 16 involves checking the validity of the new blockmatrix using the hashvectors and comparing the new blockmatrix to the blockmatrix on the member node, updating or adding new blockvectors or blocks as necessary.

[00208] At item 296 of Figure 16 a second data structure is received at the first member node 102a. In this example, the second data structure represents a second blockmatrix, whereas the first member node stores a first blockmatrix represented by storage data. At item 298 of Figure 16, a second set of hash values stored within the second data structure is checked to determine whether the second set of hash values satisfy at least one hash validity condition. For example, the second set of hash values may represent some or all of the hashblocks or hashvectors of the second blockmatrix (such as layers of the second blockmatrix other than the first layer, in examples in which the second blockmatrix has a structure similar to that of Figure 3). The validity of the second set of hash values may be checked by copying the blockvectors of the second blockmatrix to a temporary blockmatrix. The hashblocks of the second blockmatrix may then be re-generated using the blockvectors of the temporary blockmatrix (for example using the method of Figure 7). The re-generated hashblocks may then be compared with the hashblocks of the second blockmatrix. If they match, the second blockmatrix may be considered to be valid. Otherwise, the second blockmatrix may be considered to be invalid. Although in this case, the validity of the hashblocks of the second blockmatrix are checked when the second blockmatrix is newly received at the first member node of the DLN, in other cases the validity of hashblocks of a blockmatrix may be checked before a full blockmatrix is transmitted or broadcast to other member nodes of the DLN.

[00209] If the second set of hash values do not satisfy the at least one hash validity condition, the second data structure (in this example, the second blockmatrix) is discarded at item 300 of Figure 16. However, if the second set of hash values do satisfy the at least one hash validity condition, further validity checks are carried out including, at item 302, checking whether the first member node includes versions of all the blockchains of the second data structure. If not, new blockchains are added at item 304, for example using the method of Figure 13.

[00210] If the first member node does include versions of all of the blockchains of the second data structure, the method of Figure 16 involves checking, at item 306, whether the blockchains of the second data structure satisfy at least one validity condition, for example using the method of Figure 12. If the blockchains do satisfy the at least one validity condition, the first data structure (for example the first blockmatrix) is updated based on the second data structure at item 308. Otherwise, invalid blockchains are discarded at item 310.

[00211] Figure 17 shows schematically an example of internal components of a member node 312 of a DLN according to examples. The member node includes a controller 314, a data structure builder 316 and a hash generation module 318. The data structure builder 316 and the hash generation module 318 of Figure 17 are shown as separate components to the controller 314. However, typically, the data structure builder 316 and the hash generation module 318 may be sub-components or sub-modules of the controller 314. The controller 314 may be configured or arranged to perform any of the methods described herein, and may select the appropriate method to perform based on requests received and the data type received.

[00212] The member node 312 of Figure 17 also includes a UDP broadcaster 320 for broadcasting data to other member nodes of the DLN using UDP and a UDP receiver 322 for receiving data from other member nodes of the DLN that has been broadcast using UDP. The UDP broadcaster 320 may include a compression module (not shown) for compressing data before transmission to the other member nodes and the UDP receiver 322 may include a decompression module (not shown) for decompressing compressed data received from the other member nodes.

[00213] Typically, the UDP broadcaster 320 is capable of multicasting data in compressed or uncompressed formats, for example depending on the size of the data to be multicast. The UDP broadcaster 320 may additionally be capable of determining whether compression is to be applied dynamically, for example depending on the network capacity and the data size. The UDP broadcaster 320 may use a communications protocol such as Datagram Transport Layer Security (DTLS) for security and network layer consistency checking. A flow diagram illustrating broadcasting of data by the UDP broadcaster 320 is shown in Figure 18.

[00214] The UDP broadcaster 320 receives a request for data to be broadcast at item 400. The data to be broadcast is for example a block of a blockmatrix, a blockvector of a blockmatrix or a blockmatrix. Within the UDP broadcaster 320, the input data to be broadcast is obtained at item 402. At item 404, the input data is encoded into an appropriate format for broadcasting, such as the JavaScript Object Notation (JSON) format. The JSON format is converted to a byte array at item 406 and at item 408 the size of the byte array is determined. If the size of the byte array is larger than a size limit, the byte array is compressed at item 410. Finally, at item 412, the byte array is packaged into one or more datagram packets and broadcast by the UDP broadcaster 322.

[00215] Figure 19 illustrates a flow diagram showing receipt of data using the UDP receiver 322. The UDP receiver 322 may be constantly or continuously listening for incoming messages. For example, when the member node 312 starts or initializes, the member node 312 may be predefined to listen to broadcasts on certain ports by default. Various network address translator (NAT) traversal techniques may be used to establish and maintain connections with member nodes of the DLN via gateways or routers that implement network address translation, for example for users of the DLN who are unable to open a router port. When a message is received, the message is decompressed if the message had previously been compressed, and converted into an appropriate format for further processing. Similarly to the UDP broadcaster 320, the UDP receiver 322 may use a communications protocol such as Datagram Transport Layer Security (DTLS) for security and network layer consistency checking.

[00216] At item 412 of Figure 19, the UDP receiver 322 receives an incoming message 414. At item 416, the datagram packet or datagram packets are converted into a byte array. At item 418, the byte array is converted to the JSON format. At item 420, it is determined if the incoming message includes a block or a blockmatrix and item 422 the incoming message is converted either to a block object or to a blockmatrix object depending on whether the incoming message includes a block or a blockmatrix. Finally, the block or blockmatrix object is transmitted to the controller 314, where it may be further processed. Thus, the UDP receiver 322 operates to reverse the processing applied by the UDP broadcaster 320, so that the received data is an appropriate format for the controller 314 to process. For example, if the incoming message includes a new block, the new block may be added one of the blockchains of a blockmatrix to extend the blockchain. Subsequently, the new block may be transmitted to other member nodes of the DLN (for example as a first type of outbound synchronization data) or the updated blockmatrix may be transmitted to the other member nodes (for example as a second type of outbound synchronization data), to synchronize the other member nodes with the member node 312, for example via the UDP broadcaster 320.

[00217] Referring back to Figure 17, the member node 312 includes a new request module 324. The new request module 324 is for example arranged to accept incoming data storage requests for data to be published to the DLN from a user associated with the member node 312. A data storage request is sent from the user's terminal, or a data processing system connected to the user's terminal, via a data communications link to the member node 312. The new request module 324 typically accepts data in a variety of formats, including raw text. However, where the original data is sensitive, the original data may be hashed (for example on a private network, which may be protected by a firewall outside which the member node 312 is located) and the hash of the data is sent to the new request module 324 in the data storage request. After receiving a data storage request, the new request module 324 generates a transaction ID as explained above. The data to be published to the DLN (typically along with the transaction ID) is transferred to the controller 314. The transaction ID is also sent back to the user who requested the publishing of the data to the DLN, for storage against the original data such that the original data can subsequently be verified by the submission of a verification request including the transaction ID, as will be explained below.

[00218] The member node 312 includes a verification check module 326, which may be used to handle requests from a user to verify data that has previously been committed to the DLN. A verification request is sent from the user's terminal, or a data processing system connected to the user's terminal, via a data communications link to the member node 312 associated with the user, and upon receipt, the verification request is passed to the verification check module 326. The verification check module 326 for example receives an incoming request for verification, which typically includes a transaction ID (for a transaction to be verified) and data to be verified. Again, where the original data is sensitive, the original data may have been hashed before storage on the DLN, thus a hash of the original data is generated before the verification request is sent, and the hash is sent to the verification check module 326 in the verification request. The request is then transferred to the controller 314 to retrieve the storage data for a given transaction ID. The retrieved data may then be compared against the data submitted in the request for verification and a result may be returned to the user which indicates whether the data to be verified has matched the data retrieved from the DLN.

[00219] The member node 312 also includes a node data store for storing local copies of the data structure, which may be shared with other member nodes of the DLN. For example, the node data store may include first storage for storing the first storage data for storing the primary blockvector (or blockchain) associated with that specific member node of the DLN, and second storage for storing the second storage data for storing blockvectors (or blockchains) associated with each of the other member nodes of the DLN. The first and second storage may be separate, or may be combined storage for storing the storage data representing all of the blockvectors (or blockchains), for example for storing the entire blockmatrix.

[00220] The components of the member node 312 may be interconnected using a systems bus such as the systems bus 120 described with reference to Figure 2. Instructions to implement the modules of the member node 312 may be stored in storage of the member node 312, which may be similar to or the same as the storage 108 described with reference to Figure 2. The node data store 328 may also form part of the storage 108. As noted above with reference to Figure 2, the instructions to implement these modules may be processed by at least one processor 118 so as to perform the methods of these modules. Any of the modules described herein may be implemented in software or in hardware or in a combination of software or hardware. [00221] Figures 20 and 21 are flow diagrams illustrating features and aspects of the above- described examples. In particular, Figure 20 shows features and aspects of storing data according to these examples, and Figure 20 shows features and aspects of verifying data according to these examples. These features and aspects may be used in conjunction with all, or some, features and aspects of the above-described examples, or may be used independently or in other conjunction with other DLN methods and systems.

[00222] Referring now to Figure 20, at item 500, a first blockchain stored. The first blockchain includes a first set of blocks arranged in sequence. For example, the first set of blocks may be first consecutive series of blocks. At item 502 of Figure 20, a second blockchain is stored, which includes a second, different, set of blocks arranged in sequence. The first and second blockchains may be similar to the first and second blockchains described above, and may be generated independently, for example by different member nodes of the DLN.

[00223] At item 504 of Figure 20, verification data which links at least some data from a block in the first blockchain and at least some data from a block in the second blockchain is generated, and item 506 the verification data is stored, for example as part of a data structure such as the blockmatrix structure described above. The verification data may include a hash of at least some data from the block in the first blockchain and at least some data from the block in the second blockchain. The hash may for example be generated by supplying the data from the block in the first and second blockchains, respectively, as inputs to a hashing algorithm such as the MD5, SHA-256 or HMAC cryptographic hashing algorithms. In such example, the verification data may include a hash of at least a hash from the block in the first blockchain and at least a hash from the block in the second blockchain. For example, the respective blocks in the first and second blockchains may be hashed using the method of Figure. 5, and the verification data may then be generated by hashing the hashes of the blocks in the first and second blockchains using the method of Figure 6 (with the hashes of the blocks in the first and second blockchains used as the set of hash values received as input at item 138 of the method of Figure 6).

[00224] In order to generate the verification data, methods in accordance with Figure 20 may include selecting the block in the first blockchain and selecting the block in the second blockchain, wherein selecting the blocks in the first and second blockchains is performed on the basis of the blocks being in the same location in each respective sequence. As an illustrative example, if the first blockchain and the second blockchain correspond to the first and second blockvectors 122a, 122b of Figure 3, these methods may include selecting blocks of the first and second blockvectors 122a, 122b that have the same Blocklndex as each other.

[00225] In this way, methods in accordance with Figure 20 allow blocks of the same row, or at the same position of location within a sequence of blocks, of two different blockchains to be linked together. This can improve the immutability of the data stored within the blockchains. This is further improved by synchronizing the two blockchains, and the verification data, within a DLN, using for example the methods described above.

[00226] Referring now to Figure 21, at item 600, at least some data is retrieved from a block in a first blockchain and at least some data is retrieved from a block in a second blockchain. The first blockchain includes a first set of blocks arranged in sequence and the second blockchain includes a second, different, set of blocks arranged in sequence. Although Figure 21 shows the data being retrieved from the first and second blockchains as part of the same item, in other examples the data may be retrieved from the first and second blockchains separately, or at different points in time.

[00227] At item 602 of Figure 21 , verification data which links the block in the first blockchain and the block in the second blockchain is retrieved. The verification data may be similar to the verification data described with reference to Figure 20.

[00228] At item 604 of Figure 21, a cryptographic verification algorithm is performed, with the at least some data from the block in the first blockchain and the at least some data from the block in the second blockchain as inputs to the cryptographic verification algorithm.

[00229] At item 606 of Figure 21, the output of the cryptographic verification algorithm is compared with the verification data in order to verify at least one of the block in the first blockchain and the block in the second blockchain.

[00230] The performing of the cryptographic verification algorithm may include performing a hashing algorithm with the at least some data from the block in the first blockchain and the at least some data from the block in the second blockchain as inputs to the hashing algorithm. For example, at least a hash from the block in the first blockchain and at least a hash from the block in the second blockchain may be used as inputs to the hashing algorithm. The cryptographic verification algorithm may therefore include generating a hash based on the at least some data from the block in the first blockchain and the at least some data from the block in the second blockchain and comparing this with a hash represented by the verification data. The verification data may for example correspond with a hashblock as described with reference to Figures 3 and 4, and the performing the cryptographic verification algorithm may correspond with regenerating the hashblock (for example using the method of Figure 7) and comparing the regenerated hashblock value with a hashblock value retrieved from the DLN. The cryptographic verification algorithm may be performed by the verification check module 326 illustrated in Figure 17.

[00231] Similarly to the method of Figure 20, methods in accordance with Figure 21 may include selecting the block in the first blockchain and selecting the block in the second blockchain, wherein selecting the blocks in the first and second blockchains is performed on the basis of the blocks being in the same location in each respective sequence. As an illustrative example, if the first blockchain and the second blockchain correspond to the first and second blockvectors 122a, 122b of Figure 3, these methods may include selecting blocks of the first and second blockvectors 122a, 122b that have the same Blocklndex as each other, and then verifying that the data in one or both of the blocks of the first and second blockvectors 122a, 122b have not been tampered with. This is for example for consistency with the generation of the verification data: the method of Figure 21 may aim to reproduce the verification data that may be generated using the method of Figure 20. If the output of the cryptographic verification algorithm of Figure 21 and the verification data of Figure 20 match, then at least one of the block in the first and second blockchains may be considered to be verified. In order to do this, the cryptographic verification algorithm may receive predetermined inputs that have been used to generate the verification data, for example on the basis of their positions in their respective sequences of blocks in the first and second blockchains.

[00232] Methods in accordance with Figure 21 therefore mean that data from first and second blockchains can be verified, with a higher level of immutability than if the first and second blockchains were not linked by the verification data.

[00233] The above examples are to be understood as illustrative examples. Further examples are envisaged. Although the example of Figure 3 illustrates the blockmatrix as being rectangular, this need not be the case in other examples. For example, some or all of the blockvectors and/or hashvectors may have different lengths. Furthermore, the number of layers may be different from the number of rows and/or number of columns.

[00234] In examples described above, a member node may be the sole source for blocks of a primary blockvector (or primary blockchain) associated with the member node. However, in other examples, there may be a plurality of member nodes of the DLN that act as a primary source for blocks of a primary blockvector or blockchain associated with the plurality of nodes of the DLN. In such cases, the data structure (such as a blockmatrix) may include a plurality of blockvectors, with each blockvector associated with a different subgroup of member nodes, with each subgroup of member nodes including one or more than one member node of the DLN. For example, a subgroup of member nodes may include a pair of member nodes. A subgroup of member nodes may communicate cooperatively to reserve sequence numbers in a blockchain (which may correspond with Blocklndex values for a blockvector) for records to be published to the DLN. For example, an organization may deploy such a subgroup of member nodes in order to improve the resilience of their member nodes.

[00235] Although examples described above refer to using a hashing algorithm to generate the verification data linking blocks of a blockchain together, in other examples other cryptographic algorithms may be used to generate the verification data. For example, blocks may be linked together by taking a hash value from a block of one blockchain, a hash value from a block in another blockchain and performing an encryption algorithm using the two hash values as inputs. The verification data may thus include an encrypted version of the two hash values, which may be decrypted and compared to the hash values stored in the blocks to verify the hash values. The hash values may then be compared to hash values regenerated from other data in the blocks to verify the respective blocks.

[00236] Further examples relate to generation of verification data or to verifying data. Features of these examples will now be described, with reference to Figures 22 to 31. These methods may be used with the methods described above. For example, these example methods may be used with the DLN 100 of Figure 1.

[00237] An alternative DLN 700 for use with these examples is illustrated schematically in Figure 22. Similarly to the DLN 100 of Figure 1, the DLN 700 of Figure 22 includes a network 704 and a first, second, third and fourth member node 702a, 702b, 702c, 702d in communication with the network 704. The third member node 702c is associated with a first organization 706a, which may correspond with a first location or premises, and the fourth member node 702d is associated with a second organization 706b. The components shown within the boxes labelled as corresponding to the first and second organizations 706a, 706b in Figure 22 may be considered to be located on a network associated with the first and second organizations 706a, 706b respectively. The first and second member nodes 702a, 702b are located external to the first and second organizations 706a, 706b but may be associated with other organizations, individuals or users.

[00238] Each of the first and second organizations 706a, 706b has a similar security system in the example of Figure 22, which includes respective external firewalls 708a, 708b and internal firewalls 710a, 710b. The external firewalls 708a, 708b may be considered to establish a barrier between internal networks associated with the first and second organizations 706a, 706b respectively (which may be trusted or secure and may be located behind the internal firewalls 710a, 710b), and the network 704, which is an external network that may not be secure. The internal firewalls 710a, 710b may provide a further layer of security. For example, sensitive or private components may be located behind the internal firewalls 710a, 710b. For each of the first and second organizations 706a, 706b, the region of the network between the respective external firewalls 708a, 708b and internal firewalls 710a, 710b may be considered to be a demilitarized zone (DMZ), which may operate as an isolated network positioned between the network 704 and the private or internal network of the organization, behind the internal firewalls 710a, 710b. The external and internal firewalls 708a, 708b, 710a, 710b may filter or monitor incoming and outgoing traffic passing between the network associated with the first and second organizations 706a, 706b and the network 704, for example based on security rules that may be determined by the first and second organizations 706a, 706b respectively. In the example of Figure 22, the third and fourth member nodes 702c, 702d are located in the DMZ associated with the first and second organizations 706a, 706b respectively, although, in other examples, member nodes associated with an organization may be located differently.

[00239] In the example of Figure 22, the first organization 706a includes a first client node 712a, which may be considered to be a node of the DLN for interfacing with other nodes of the DLN, such as member nodes and control nodes. In other words, the first client node 712a may be used by a user, such as a user of the first organization 706a, to access the DLN (where a user may be considered to refer broadly to a computing device operated by or associated with an operator). The first client node 712a may include routines, such as hardware or software, for operating on or interfacing with sensitive or private data stored within the private network of the first organization 706a. In Figure 22, the first client node 712a interfaces to a first trade processing system 714a, for example for processing trades involving the transfer of an asset or financial instrument for a price. Such assets or instruments may include cash instruments, such as stocks, bonds, bills, foreign exchange or derivative instruments such as swaps or options. Such a trade processing system 714a may be used to keep a record of trades, which may be considered to be an example of data records, for example keeping a record of the date at which a trade was executed, the rate, the volume, the asset and so forth. In the example of Figure 22, the first trade processing system 714a includes a first trade storage system 716a for storing data records (in this case trade data records), which in this example is a database although other storage systems are possible. These data records or other data generated by the first trade storage system 716a may be transmitted for storage on the DLN, for example via the first client node 712a.

[00240] The first client node 712a in the example of Figure 22 also interfaces to a second trade processing system 714b, which includes a second trade storage system 716b. The second trade processing system 714b and the second trade storage system 716b may be similar to or the same as the first trade processing system 714a and the first trade storage system 716a, respectively. Alternatively, the first and second trade processing systems 714a, 714b may be differently configured. For example, the first and second trade processing systems 714a, 714b may be predetermined to store generated trade records differently, for example using a different level of granularity. This may then affect the level of verifiability of the trade records, as will be discussed further below.

[00241] In Figure 22, the second organization 706b includes a third trade processing system 714c, which includes a third trade storage system 716c. The third trade processing system 714c and the third trade storage system 716c may be similar to, the same as or different from the first and second trade processing systems 714a, 714b and the first and second trade storage systems 716a, 716b, respectively. The third trade processing system 714c in this example interfaces to the DLN via a second client node 712b.

[00242] The first, second and third trade processing systems 714a, 714b, 714c may communicate directly with the network 704 (via the first and second client nodes 712a, 712b and the firewalls 708a, 708b, 710a, 710b) or the first, second and third trade processing systems 714a, 714b, 714c may communicate with the network 704 via the third or fourth member nodes 702c, 702d in addition to the first and second client nodes 712a, 712b and the firewalls 708a, 708b, 710a, 710b.

[00243] In the example of Figure 22, the DLN 700 also includes a control node 718. As explained above, the control node 718 may be used to control access to the DLN and/or to provide various network functions such as data verification, as will be detailed further below. [00244] It is to be understood that the DLN 700 of Figure 22 is merely an illustrative example. Other DLNs for use with the methods described herein may be configured differently and may include different components. Although the DLN 700 of Figure 22 includes first, second and third trade processing systems 714a, 714b, 714c for processing trade data records, other DLNs may not include such systems. For example, the methods described herein may be used with various other types of data that is representative of various other quantities, characteristics or values, such as data that is representative of measurements of physical quantities.

[00245] However, Figure 23 provides an example of a data record 720 for example for storage as part of a DLN or using components of a DLN such as the DLN 700 of Figure 22. The data record 720 in this example, which is merely illustrative, is an example of a data record for a foreign exchange trade. In examples such as Figure 23, the data record 720 includes a set of data elements. The set of data elements are arranged as a series or sequence of data fields, with each data field including a corresponding entry, which may be referred to as a data element. In the example of Figure 23, data field number 1 includes a date, which is the date the trade occurred. The date is therefore the first data element in this example. Data field number 2 includes a rate, which is the exchange rate at which this foreign exchange trade occurred. The rate is the second data element in this example. Data field number 3 includes the volume, which is the amount or quantity of one currency that was exchanged as part of the foreign exchange trade and data field number 4 includes the pair of currencies that were exchanged as part of the foreign exchange trade, which may be given as a concatenation of the three-letter currency codes associated with each currency. The volume and pair of currencies are third and fourth data elements in this example. In other examples, the data record may also include a data element representative of the full data set or an entire set of data elements, for example as a concatenation of each of the individual data elements.

[00246] There may be a predetermined order or sequence of data fields. In other words, data field number 1 may always correspond to a first characteristic (in this case, the date of a trade) and data field number 2 may always correspond to a second characteristic (in this case, the rate at which a trade occurred). In this way, the first characteristic and the second characteristic may be obtained simply by looking up or locating the data elements associated with the appropriate data fields. For example, where the data elements are stored as elements of a vector or array, each data field may correspond with a particular element of the array. Hence, it may not be necessary to store an identifier or index to retrieve a particular data element from the set of data elements. Instead, the data element may be retrieved on the basis of its location in the set of data elements.

[00247] Data records such as the data record 720 of Figure 23 may also be stored alongside or with a transaction identifier and a receipt. By associating a transaction identifier and a receipt with a particular data record, the data record may be located or retrieved on the basis of the transaction identifier or the receipt. For example, the transaction identifier and/or receipt may be stored as a separate entry in a database storing the data record 720, which separate entry is nevertheless associated with the data record 720, or as metadata associated with the data record 720.

[00248] The example data record 720 of Figure 23 is a simple example. In other examples, a data record for a foreign exchange trade, such as a foreign exchange options order, may include further data elements. For example, a foreign exchange options order may include a data element representing an identifier of the order as assigned by an organization or institution, such as the financial institution submitting the order. Such an order may also include a data element indicating whether the trade is to be executed automatically, without broker intervention and a data element indicative of an option symbol allowing the option to be identified on an options exchange. Such an order may also include data elements indicating, respectively, the side of the order (i.e. buy or sell), the quantity of the order, the order type (indicating how the order is to be executed), the price, the client ID (allowing a firm executing the trade to be identified) and the broker to be used (for example, whether a default or other broker should be used).

[00249] In an example, a trade processing system such as the first trade processing system 714a of Figure 22 may generate a data record 720 that includes a trading record. Such a trading record may be similar to or different from the data record 720 of Figure 23. For example, the first and second data elements of the data record 720 (which may correspond with data field numbers 1 and 2 as illustrated in Figure 23) may include only one of: trading party identifier data, financial instrument identifier data, currency identifier data, and transaction value data. The trading party identifier data for example indicates the parties involved in the transaction and the financial instrument identifier data for example indicates which financial instrument the trade relates to. The currency identifier data may indicate the currency in which a trade is executed or may indicate a pair of currencies in examples in which the trade is a foreign exchange trade, in which a quantity of one currency is exchanged to a quantity of a different currency. The transaction value data for example represents the value of the trade, such as the monetary value in a particular currency or the volume of a particular transaction, where the transaction has a fixed value. Each data element may include solely one form of data, which represents solely one characteristic, measurement or value. Alternatively, one or more data elements may include a combination of multiple characteristics, measurements and/or values. As will be appreciated though, this is not be taken as limiting; this is merely an illustrative example of a data record 720 that may be suitable for processing with the methods described herein.

[00250] Figure 24 is a flow diagram illustrating an example of processing a data record, such as the data record 720 of Figure 23, for storage. The method of Figure 24 involves, at item 728, retrieving a set of data elements from a data record. As explained above, the set of data elements may be retrieved on the basis of their location or position within the data record. For example, each data element may be extracted from a corresponding data field, with each data field having a particular, predetermined, position within the data record. As a simple example, noted above, if the data of a data record is considered to correspond to a one dimensional vector or array, it may be predetermined that the first element of the vector corresponds to data field number 1, which stores data element 1 (as in Figure 23). Thus, data element 1 can be retrieved from the data record by retrieving the first element of the vector corresponding to the data of the data record.

[00251] The data record 720 may be stored in storage of a client node. In such cases, the set of data elements may be retrieved from the storage of the client node, from the data record 720 and the items of Figure 24 may be performed at the client node.

[00252] In cases in which the data record 720 includes sensitive or private data, some or all of the data elements of the set of data elements may be cryptographically secured or disguised, for example by applying a cryptographic hashing algorithm to the data elements of the set of data elements before storing the data elements in the storage.

[00253] At item 730 of Figure 24, an indicator indicative that element-level verifiability is requested is received. Element-level verifiability for example refers to the ability to independently check or verify whether data elements of the set of data elements have been tampered with, changed or altered. The indicator may for example be generated on the basis of the data type of the data record 720 or in dependence on a configuration of the client node or a system for generating the data record 720. For example, referring to Figure 23, the first trade processing system 714a may generate sensitive data relating to trades, for which it may be desirable to facilitate element- level verifiability to satisfy future regulatory requirements. Thus, generation of data records by the first trade processing system 714a may involve the generation of an indicator indicative that element-level verifiability is requested. Conversely, the second trade processing system 714b may generate less sensitive data, for which element- level verifiability is not needed. In such cases, the second trade processing system 714b may generated data records without generating an indicator indicative that element-level verifiability is requested, or with generating a different indicator indicative that element-level verifiability is not requested. For example, the method of Figure 24 may include determining, from presence or absence of an indicator associated with the data record, whether element-level verifiability of individual data elements of the set of data elements is requested, and applying a cryptographic algorithm to produce data element verification data (as described below) on the basis that element-level verifiability is requested.

[00254] At item 732 of Figure 24, a check may be performed to determine whether the number of data elements in the set of data elements equals an expected number of data elements, for example based on a predetermined expectation of the data a data record is to store. The number of data elements in the set may for example be determined by calculating the size of a vector storing the set of data elements. Alternatively, the data record may itself have a data field which stores a value indicating the total number of data fields of the data record.

[00255] If the number of data elements in the set differs from the expected number it can be determined that the structure of the data record differs from an expected structure and that the data record may therefore have been altered. If this is the case, a message or indicator may be sent to the client node indicating that verification of the set of data elements has failed and the method may cease. Conversely, if the number of data elements in the set equals the expected number, the method may continue. It is to be noted that the check of item 732 of Figure 24 is merely optional and in some cases may be omitted.

[00256] At item 734 of Figure 24 a cryptographic algorithm is applied to produce data element verification data from the set of data elements. The cryptographic algorithm is non- deterministic with respect to first input data. For example, there may be a one to many mapping between the first input data and an output of the cryptographic algorithm. The output may differ, seemingly randomly, when the first input data is supplied as an input to the cryptographic algorithm. [00257] For example, the cryptographic algorithm may include a hashing algorithm. The hashing algorithm may be hashing algorithm that receives, in addition to the first input data, second input data. The second input data is typically a random string (sometimes referred to as a "salt"). The first and second input data may be combined in any suitable way. As the second input data is a random string, even for the same first input data the combination of the first and second input data will differ. Accordingly, the output of the cryptographic algorithm will also differ, so that the cryptographic algorithm is non-deterministic with respect to the first input data. The hashing algorithm may for example be a keyed-hash message authentication code (HMAC) algorithm, which may use a secret key as second input data, as will be explained further below. The HMAC algorithm may be a SHA-256- HMAC algorithm, which is for example the HMAC algorithm in conjunction with the SHA-256 hashing algorithm.

[00258] Applying the cryptographic algorithm includes applying the cryptographic algorithm to at least the first data element as the first input data to produce first data element verification data representative of the first data element and applying the cryptographic algorithm to at least the second data element as the first input data to produce second data element verification data representative of the second data element. The first and second data element verification data are for verifying the integrity of the first and second data element respectively. In other words, the first data element verification data may be generated by hashing a combination of the first data element and the secret key using the HMAC algorithm. Similarly, the second data element verification data may be generated by hashing a combination of the second data element and the secret key using the HMAC algorithm.

[00259] As explained above, certain sets of data elements may include data elements that are small in size or that are repeated in different data records, which may be susceptible to dictionary attacks. In an example in which the data record is a trade data record, an organization involved in a trade may always include its own identifier in the data field associated with trading party identifier data (for example if the organization is trading on its own behalf). In such cases, that data field may always include the same data. If a malicious party who is knowledgeable about the trade processing system record format and contents is able to intercept trade data records, the malicious party may be able to guess the initial input data and may therefore be able to defeat deterministic cryptographic hashing of the data record. However, by using a cryptographic algorithm that is non-deterministic with respect to the first input data, the data elements may be more cryptographically secure than otherwise. [00260] At item 736 of Figure 24, the first and second data element verification data is transmitted for storage. The first and second data element verification data, for example as part of data element verification data that may include other verification data, may be transmitted for storage in a DLN, such as the DLN 700 of Figure 22. By storing the data element verification data in the DLN, the data element verification data may be duplicated across numerous nodes of the DLN, which may further increase the security of the data element verification data. The data element verification data in such cases may be added to a first blockchain at a first member node of the DLN as described above and may subsequently be synchronized with the first blockchain at a second member node of the DLN.

[00261] As explained above, the DLN may include member nodes and at least one control. In such cases, the data element verification data may be transmitted to a control node of the DLN. The control node of the DLN may store the data element verification data for subsequent use in verification of data, for example if it is desired at a later date to verify the data record. If the data element verification data is stored solely at the control node, no data derived from the data element verification data need be stored in other nodes of the DLN. However, in other examples, immutability of the data element verification data may be improved by storing at least some additional-level verification data in the DLN, as will be described further below.

[00262] Figure 25 illustrates an example of generation of a secret key for example for use with a cryptographic algorithm which is non-deterministic with respect to first input data, such as the HMAC algorithm. At item 740 of Figure 25, a request for a secret key is received. The request may for example be transmitted by a client node, for example as part of the method of Figure 24, such as prior to transmitting the data element verification data (or prior to receipt of the data element verification data by the control node). For example, the request for the secret key may be sent after checking that the number of data elements in the set equals the expected number at item 732. The request may be for example for a key pair, such as a private key and a public key (where the private key for example corresponds with the secret key). The private key may be a 4096-bit private key.

[00263] In examples, the request is received by the control node, for example by a hardware security module (HSM) of the control node. The secret key is generated at item 742, for example by the HSM. The HSM may therefore be considered to be a random string generator, as the secret key is a random string. The request for the secret key may therefore be considered to be a request for a random string, such as a random string of a fixed or predetermined length. [00264] At item 744 of Figure 25, the secret key is transmitted for use in generating the data element verification data, for example for use as the salt by the HMAC algorithm. The secret key may thus be received by a client node of a DLN. The secret key in examples is not used for encryption but is instead used as a source of a securely generated random string. Hence, in other examples, other sources of a random string may be used instead of a secret key.

[00265] The secret key may be discarded after generation of the data element verification data, for example to avoid storing the secret key along with the data verified with use of the secret key. This may improve the security of the data element verification data as, otherwise, the data element verification data would be vulnerable in the case of unauthorized access to the client node.

[00266] Figure 26 is a flow diagram illustrating an example of generating data set verification data. At item 746, a set of data elements is retrieved from a data record, for example similarly to item 728 of Figure 24. For example, it may be sufficient to retrieve the set of data elements once, and then perform both the methods of Figure 24 and Figure 26, in any order. At item 748, an indicator indicative that element- level verifiability is not requested. At item 750, in response to determining that element-level verifiability is not requested, a data set hashing algorithm is applied to produce data set verification data from the set of data elements. The data set verification data includes a hash value representative of both the first data element and the second data element, for verifying the integrity of the set of data. For example, the first data element and the second data element may be combined (for example by concatenation) before applying the data set hashing algorithm to the combination of the first data element and the second data element. In examples, the data set hashing algorithm may be applied to a data element that is representative of the set of data elements, for example where a data record includes a data element representative of a concatenation or other combination of the set of data elements. The data set hashing algorithm is for example deterministic with respect to the set of data elements (although in other examples the data set hashing algorithm may be non- deterministic, but in those other examples, access to a private or secret key will be required in order to regenerate the hash for checking). For example, the data set hashing algorithm may be the SHA-256 hashing algorithm or another deterministic hashing algorithm. At item 752 of Figure 26, the data set verification data is transmitted for storage. For example, the data set verification data may be transmitted to a member node of a DLN such as the DLN 700 of Figure 22, to further increase the security of the data set verification data. [00267] As noted above, examples may include performing one or both of the methods of Figures 24 and 26. For example, methods may involve determining, from presence or absence of an indicator associated with the data record, whether element- level verifiability of individual data elements of the set of data elements is requested and performing the method of Figure 24 if element-level verifiability is requested or performing the method of Figure 26 is it is determined that element-level verifiability is not requested. In such examples and other examples, data set verification data may be generated in accordance with Figure 26 even in cases in which element-level verifiability is requested. This provides for a first-level check to be made to verify the integrity of an entire data record. If it is found that the entire data record has been tampered with, a second, element-level, check may be carried out to determine exactly which data field(s) has or have been tampered with.

[00268] Figure 27 is a flow diagram illustrating an example of processing and storing data element verification data. The method of Figure 27 may for example be performed at a control node of a DLN or at a client node or member node of a DLN.

[00269] At item 754, data element verification data including first data element verification data and second data element verification data is received. The first and second data element verification data may be generated as described above, for example. The data element verification data is stored at item 756. Where the method of Figure 27 is performed at a control node of DLN, the data element verification data may be stored in storage of the control node, such as a control node data store.

[00270] At item 758 of Figure 27, additional-level verification data is produced from the first data element verification data and the second data element verification data. The additional- level verification data may be considered to represent a further layer of verification for verifying a combination of the first and second data elements and may be generated in any suitable manner. For example, immutability of the first and second data elements may be improved by generating the additional-level verification data.

[00271] Generation of the additional-level verification data may include applying a hashing algorithm to produce at least part of the additional-level verification data from the first data element verification data and the second data element verification data. In such cases, the additional-level verification data includes a hash value representative of both the first data element verification data and the second data element verification data. For example, the first data element verification data and the second data element verification data may be combined into a concatenated data string before applying the hashing algorithm to the concatenated data string to produce the additional-level verification data. Concatenating the first and second data element verification data may involve appending a predetermined series of characters indicating a separator between different data elements (such as a series of hash symbols or other symbols) to the string represented by the first data element verification data and subsequently appending the string represented by the second data element verification data. This allows the first and second data element verification data to be combined (although other ways of combining the first and second data element verification data are possible in other examples). Then, the hashing algorithm for example allows a size of the concatenated data string to be reduced to a size that is suitable for storage on a DLN, which may also reduce storage requirements for the additional-level verification data.

[00272] At item 760, the additional-level verification data is transmitted for storage on a DLN such as the DLN 700 of Figure 22. As explained above, this allows the additional-level verification data to be duplicated across the DLN, increasing the immutability (and hence the security) of the additional-level verification data.

[00273] At item 762, a transaction identifier is received from the DLN in response to transmitting the additional-level verification data for storage in the DLN. The transaction identifier for example allows a block of a blockchain of the DLN storing the additional-level verification data to be identified. For example, if the additional-level verification data is stored as a first block of a first blockchain such as the first blockchain described above, the transaction identifier may include the Blocklndex and the Vectorlndex of the first block (for example a concatenation of the Blocklndex and the Vectorlndex in a predetermined order, as described above) or sufficient data to allow the Blocklndex and the Vectorlndex of the first block to be identified.

[00274] At item 764 of Figure 27, the transaction identifier is stored with the data element verification data. For example, the transaction identifier and the data element verification data may be stored in storage of the control node. In examples, the additional-level verification data may also be stored in the storage of the control node. The transaction identifier, the data element verification data and the additional-level verification data may subsequently be retrieved from the storage for example for use in verification of data records, as will be explained.

[00275] At item 766 of Figure 27, receipt data is transmitted in response to receiving the data element verification data (for example for generation of the additional-level verification data as in Figure 27, or otherwise). The receipt data for example includes a transaction identifier for use in a subsequent data element verification request relating to the data element verification data, such as the transaction identifier received from the DLN in item 762 of Figure 27. The receipt data may be transmitted from a control node to the client node that transmitted the data element verification data to the control data, indicating to the client node that the data element verification data has been successfully received. The transaction identifier and the receipt data may be stored as part of or associated with the data record as shown in Figure 23. The receipt data may also include the secret key, which may be sent back to the client node that generated the data element verification data. The secret key may be stored in storage of the client node for subsequent use in verification of a data record, for example as described below with reference to Figures 28 to 31.

[00276] Figure 28 illustrates an example of verifying a data record, which may be used in conjunction with any of the methods described herein. The method of verifying the data record may be performed in a control node of a DLN. At item 768 a data verification request is received, for example by the control node of the DLN. At item 770, data representative of a data record to be verified is received. The received data includes a received set of data elements from the data record. The received set of data elements includes a received first data element from the data record and a received second data element from the data record. The received set of data elements are for example received in the same order or are arranged in the same order as the set of data elements that were used to generate the data element verification data described above. In this way, the set of data elements may be verified without requiring further rearranging, for example based on an index or other identifier. Furthermore, this allows changes in the structure of the data record, such as changes to the order of the data elements, to be detected.

[00277] The data is for example received from a client node, such as a client node that originally transmitted the data element verification data to the control node for storage. For example, the data may be retrieved from internal or secure storage of the client node, such as storage of the client node that lies within the internal or private network associated with an organization that includes the client node. A secret key may be received from the requesting party, such as the client node, in association with the data verification request. The secret key may be received as part of a receipt from the client node. In other words, the data verification request may include receipt data that includes the secret key. [00278] At item 772, a cryptographic algorithm is applied to produce regenerated data element verification data from the received set of data elements. The cryptographic algorithm is for example non-deterministic with respect to first input data. Applying the cryptographic algorithm to produce the regenerated data element verification data for example includes applying the cryptographic algorithm to at least the received first data element as the first input data, to produce regenerated first data element verification data representative of the received first data element and applying the cryptographic algorithm to at least the received second data element as the first input data, to produce regenerated second data element verification data representative of the received second data element.

[00279] At item 774 of Figure 28, the integrity of the received first data element is verified by checking the regenerated first data element verification data with respect to stored first data element verification data representative of a first data element from the data record.

[00280] At item 776 of Figure 28, the integrity of the received second data element is verified by checking the regenerated second data element verification data with respect to stored second data element verification data representative of a second data element from the data record.

[00281] The cryptographic algorithm applied during the verification is for example the same cryptographic algorithm applied to generate the first and second data element verification data and typically uses the same random string or secret key in examples involving a hashing algorithm that takes a random string or secret key as an input. In other words, if the stored first and second data element verification data has not been altered, the first and second data element verification data should match the regenerated first and second data element verification data. For example, the regeneration of the first and second data element verification data should involve reproducing the first and second data element verification data, provided the first and second data element verification data has not been tampered with and thus that the first and second data elements are also unchanged.

[00282] Figure 29 provides an illustrative example of verifying the integrity of the received first data element. The method of Figure 29 involves, at item 778, retrieving the stored first data element verification data. In examples in which the first data element verification data is stored in the storage of the control node, the stored first data element verification data may be retrieved from this storage, for example based on a transaction identifier or a receipt associated with the data record that includes the first data element. For example, a receipt (represented by receipt data), may be transmitted along with the data verification request. For example, where a data record is stored in the format shown in Figure 23, the position of receipt data within the data structure may be used to identify a row of the data structure that is associated with a particular data record. Various data elements may then be retrieved based on their positional relationship to the receipt within the data structure the data record is stored in (which is for example a predetermined structure). In other examples, a transaction identifier or receipt may be stored as metadata associated with data elements of a set of data elements, allowing these data elements to be identified and retrieved.

[00283] At item 780 of Figure 29, the integrity of the received first data element is verified by comparing the regenerated first data element verification data to the stored first data element verification data. As explained above, if the regenerated and stored first data element verification data match or are equal, the first data element may be considered to be verified. A similar method may be performed for each of data element of a set of data elements to be verified, in order to identify data elements that are not verified. Upon identifying that a data element is not verified, a message or indicator can be sent to a requesting user (such as the client) to indicate that the data element has not been verified and may therefore have been tampered with.

[00284] The additional-level verification data may be verified similarly to verification of the received first and second data elements. Figures 30 and 31 provide examples of verifying additional-level verification data.

[00285] Items 782, 784 and 786 of Figure 30 are similar to corresponding items 768, 770 and 772 of Figure 28; corresponding descriptions should be taken to apply. At item 788, regenerated additional-level verification data is produced from the regenerated first data element verification data and the regenerated second data element verification data. The regenerated additional-level verification data may be produced using the same method as that used for generation of the additional-level verification data, as described above. For example, a hashing algorithm may be applied to produce at least part of the regenerated additional-level verification data. In such cases, the regenerated additional-level verification data includes a hash value representative of both the regenerated first data element verification data and the regenerated second data element verification data. For example, the regenerated first data element verification data and the regenerated second data element verification data may be combined into a concatenated data string before applying the hashing algorithm to the concatenated data string to produce the regenerated additional-level verification data. [00286] At item 790 of Figure 30, the integrity of the regenerated additional-level verification data is verified by checking the regenerated additional-level verification data with respect to stored additional-level verification data.

[00287] As illustrated in Figure 31, the verification of the integrity of the regenerated additional-level verification data may include (at item 792) retrieving the stored additional- level verification data (for example from storage of a control node of a DLN or from a member node of the DLN) and (at item 794) comparing the regenerated additional-level verification data to the stored additional-level verification data. The verification of the integrity of the regenerated additional-level verification data may be performed by a control node of a DLN or a member node of a DLN for example. For example, where the verification is performed by a member node of a DLN, the regenerated additional-level verification data may be transmitted to the member node for verification by the member node with respect to additional-level verification data stored in the DLN, either at the member node or at another member node of the DLN.

[00288] While the verification methods of Figures 28 to 31 have been described in the context of a method of verifying a data record performed in a control node of a DLN, it will be appreciated that, in other examples, these methods may be performed in other nodes or components of a DLN. For example, these methods may be implemented by a combination of a client node and a control node of a DLN or a combination of a control node and a member node of a DLN. For example, where the data element verification data or the additional-level verification data are stored in the DLN and in storage of the control node, the methods of Figures 28 to 31 may involve transmission of data to be verified from the control node to a member node of the DLN, for comparison with stored data element verification data or stored additional-level verification data stored at the member node of the DLN. For example, the data to be verified may be transmitted along with a receipt or transaction identifier, so that the appropriate data may be located at the member node of the DLN (for example by identifying a block of a blockchain stored at the member node that corresponds with a transaction or data record to be verified).

[00289] In other examples, these methods may be implemented using other systems that do not involve or include a DLN.

[00290] The verification methods of Figures 28 to 31 may also include checking to see that the number of data elements received as part of the received set of data elements equals or matches the stored set of data elements of the stored data record. If not, the received set of data elements may be considered to be incomplete or altered with respect to the stored set of data elements.

[00291] The methods of Figures 28 and 29 may be used in conjunction with those of Figures 30 and 31, or separately. For example, the method of Figures 30 and 31 may be used initially, where additional-level verification data is stored for a particular data record. If the verification of the received additional-level verification data fails, the methods of Figures 28 and 29 may subsequently be performed to identify which of the data elements has been altered. Alternatively, the methods of Figures 28 and 29 may be performed without first performing the methods of Figures 30 and 31.

[00292] In the examples described above, there is a one-to-one correspondence between data fields and data elements. All data fields may be included. However, in other examples, the set of data elements may represent or be associated with only a subset of data fields in a data record, which are chosen to have element-level verifiability.

[00293] Examples described above include the use of a cryptographic hashing algorithm. However, in other examples, the cryptographic algorithm that is non-deterministic with respect to first input data may be a non-deterministic encryption algorithm instead.

[00294] Examples above describe transmission of data element verification data to a control node. However, in other examples, the data element verification data may be transmitted to a member node of a DLN for storage instead of a control node. In such cases, the member node of the DLN may have the appropriate functionality to perform verification of data elements, which may be similar to the functionality described above for the control node. In these cases, the control node may therefore not include this verification functionality.

[00295] Further examples relate to storage of data. Features of such examples will now be described, with reference to Figures 32 to 47. The methods of these examples may be used with the methods described above or as part of other methods or systems.

[00296] Figure 32 shows schematically an example system 800 comprising a plurality of DLNs 802, in this example a first, second, third and fourth DLN 802a, 802b, 802c, 802d. The second, third and fourth DLNs 802b, 802c, 802d are different from the first DLN 802a and in this example may be referred to collectively as at least one DLN 802e different from the first DLN 802a. Each of the plurality of DLNs 802 may be the same as or different from each other. For example, various DLNs of the plurality of DLNs 802 may be the same as or similar to the example DLNs 100, 700 illustrated in Figures 1 and 22 respectively. For example, the first DLN 802a and/or the at least one DLN 802e may include a client node and/or a control node and may also or alternatively include a member node. In the example of Figure 32, the plurality of DLNs 802 are connected to a network 804, which allows the DLNs to communicate with each other.

[00297] In the example of Figure 32, the first DLN 802a is a private DLN, which is accessible to a limited set of trusted users. A private DLN is for example a DLN that is accessible to a group or subset of users rather than all users. For example, a private DLN may be accessible to users that satisfy particular requirements or that have elected to subscribe to access the private DLN. A user may, for example, obtain a digital certificate indicating that the user has access to the private DLN. Continued access to the private DLN may be contingent on the user having an up to date version of the digital certificate. This is not to be taken as limiting though; limiting access to a private DLN to a particular group of users may be performed in various different ways. In contrast, a public DLN may be freely accessible or accessible to all users, without the users having to satisfy particular requirements.

[00298] The first DLN 802a may be similar to the DLN 700 of Figure 22 and may include member and/or client nodes associated with various organizations, which may be located behind one or more firewalls of these various organizations to provide additional security. A client node of the first DLN 802a may communicate directly with other nodes of the first DLN 802a, over the network 804, or may communicate indirectly with other nodes of the first DLN 802a, for example via a member node of the first DLN 802a, such as the member nodes 702c, 702d illustrated in Figure 22. The first DLN 802a may also include at least one control node (such as the control node 718 described above) which may interface with other nodes of the first DLN 802a to control access to the first DLN 802a. The control node may also be used to control transmission of data stored in the first DLN 802a outside the first DLN 802a, such as to the at least one DLN 802e different from the first DLN 802a. For example, the control node may act as a member node of both the first DLN 802a and the at least one DLN 802e.

[00299] The at least one DLN 802e of Figure 32 are public DLNs, which are freely accessible or accessible to all users rather than a limited set of trusted users. Examples of public DLNs include the Bitcoin DLN and the Ethereum DLN. The at least one DLN 802e, similar to the first DLN 802a, may include number of member nodes, which may be similar to the member nodes described above. Typically, the number of member nodes in a DLN of the at least one DLN 802e is larger than the number of member nodes of the first DLN 802a, as DLNs of the at least one DLN 802e are generally accessible to a larger number of users than the first DLN 802a. In other words, the first DLN 802a may include fewer node than one or more DLNs of the at least one DLN 802e. Alternatively, the first DLN 802a may include a first number of nodes and a combination of one or more DLNs of the at least one DLN 802e may include a second number nodes, larger than the first number of nodes.

[00300] As will be appreciated, though, the configuration of Figure 32 is merely an example. In other examples, the first DLN 802a and/or the at least one DLN 802e may have different features than those described above with reference to Figure 32. For example, in some cases, the at least one DLN 802e may include one or more private DLNs (which may be accessible to the first DLN 802a) or both the first DLN 802a and DLNs of the at least one DLN 802e may be public DLNs.

[00301] Figure 33 is an example of a method for storing data in accordance with the first examples described above. The method of Figure 33 may for example be used with the system 800 shown in Figure 32. For example, the method of Figure 33 may be performed in a client node of a plurality of client nodes of a first DLN such as the first DLN 802a of Figure 32. Such a client node which may be similar to or the same as one of the client nodes 712a, 712b of Figure 22. In other examples, though, the method of Figure 33 may be used in different systems or in different components of the system 800 of Figure 32 or with different DLNs than the DLNs 100, 700 of Figures 1 and 22.

[00302] At item 806 of Figure 33, a first data storage request is transmitted. In examples in which the method of Figure 33 is performed in a client node of the first DLN 802a, the first data storage request may be transmitted to other nodes of the first DLN 802a, such as other client nodes, member nodes or control nodes of the first DLN 802a.

[00303] The first data storage request instructs the storage of first data in the first DLN 802a. The first data storage request may be in any suitable format, such as the JSON format or other formats such as binary if desired for performance purposes. The first data storage request may include the first data to be stored in the first DLN 802a or an identifier allowing the first data to be retrieved. In examples in which the first data includes private or sensitive data, the first data may be cryptographically secured or disguised, for example by applying a cryptographic hashing algorithm to the first data before transmission of the first data outside a trusted or private network in which the first data was generated or received. For example, the first data may be hashed within an internal or private network of an organization and then transmitted to a control node of the first DLN 802a or to a member node of the first DLN 802a, via a client node of the organization, for storage in the first DLN 802a.

[00304] The first data may be stored in the first DLN 802a for example as or as part of a block of a first blockchain. The first blockchain may for example be part of a blockmatrix, such as that described above. The first data may be considered to be the entirety of a block (which may include a number of data fields, such as a Blocklndex, Vectorlndex, TimeStamp, PreviousHash, BlockData and BlockHash, as described above). Alternatively, the first data may be considered to be a subset or part of a block, such as the BlockData component of a block, which, as explained above, may itself include one or a plurality of data elements. In yet further examples, the first data may be considered to be a portion of a data component of a block such as a subset of data elements where the BlockData component of a block includes a plurality of data elements.

[00305] By storing the first data in the first DLN 802a, the immutability of the first data may be improved, for example due to the distributed and decentralized nature of the first DLN 802a.

[00306] In examples where the method of Figure 33 is performed in a client node of the first DLN 802a, the client node may include a copy of the blockmatrix (as new data added to the blockmatrix or the blockmatrix itself is generally broadcast among nodes of the first DLN 802a periodically or at various time intervals so that each node has an up to date copy of the blockmatrix). In such cases, the first data may be added to a local copy of the blockmatrix stored at the client node and subsequently the block including the first data or the updated local copy of the blockmatrix may be transmitted to other nodes of the first DLN 802a so that the other nodes may synchronize their copies of the blockmatrix with that of the first DLN 802a.

[00307] At item 808 of Figure 33, confirmation that the first data has been stored in the first DLN 802a is received. Methods in accordance with Figure 33 may therefore include receiving a first data storage identifier in response to the first data storage request. The first data storage identifier may be considered to correspond to a receipt allowing a location of the first data within the first DLN 802a to be determined, for example so that the first data may be subsequently retrieved from the first DLN 802a. For example, the first data storage transaction identifier may identify a block, within the first DLN 802a, in which the first data has been stored. The first data storage transaction identifier may for example include a Blocklndex and a Vectorlndex in cases where the first data is stored within a blockmatrix. This allows the position of the first data within the blockmatrix to be determined. Alternatively, the first data storage transaction identifier may include or be a transaction ID, which may be used to identify a block storing the first data. For example, where the first data is stored in a blockmatrix, the transaction ID may correspond to a concatenation of the Blocklndex and the Vectorlndex in a predetermined order.

[00308] At item 810 of Figure 33, a verification data storage request is transmitted. In examples in which the method of Figure 33 is performed in a client node of the first DLN 802a, the first data storage request may be transmitted to a control node of the first DLN 802a, which may control transmission of data from the first DLN 802a to the at least one DLN 802e different from the first DLN 802a. In other examples, though, the first data storage request may be transmitted to a different component of the first DLN 802a or to a component of a different DLN than the first DLN 802a.

[00309] The verification data storage request instructs the storage of verification data relating to the first data in the at least one DLN 802e different from the first DLN 802a. As for the first data storage request, the verification data storage request may be in any suitable format, such as JSON or binary. The verification data storage request may include the verification data to be stored in the at least one DLN 802e or may alternatively include data allowing the verification data to be retrieved or generated before storage in the at least one DLN 802e (as will be described further below with reference to Figure 35).

[00310] The verification data storage request may not explicitly identify which DLNs the verification data is to be stored in or how many DLNs the verification data is to be stored in. Instead, the verification data storage request may be processed to determine which DLNs of the at least one DLN 802e the verification data is to be stored in, as discussed further below with reference to Figure 41.

[00311] The verification data relates to the first data, for example is based on, generated using, derived from or otherwise representative of all or some of the first data. For example, the first data may include the verification data or vice versa, or the verification data may include a hash derived from at least the first data. For example, the verification data may correspond to a BlockHash of the first data, which may be generated from the first data by concatenating data elements of the first data and hashing the concatenated data elements, for example as shown in Figure 5. Alternatively, where the first data includes at least the BlockHash (for example, where the first data represents a block of a blockmatrix of the first DLN 802a), the BlockHash may be retrieved from the block of the blockmatrix as the verification data. Such cases for example allow for additional verification of the verification data, as the BlockHash is itself verified in the next block of the blockchain or across different blockchains where the blockmatrix structure is used.

[00312] In further examples, the first data may be retrieved from the first DLN 802a (for example by retrieving a block of the first DLN 802a including or representing the first data) and a hashing algorithm or other cryptographic algorithm may be applied to the first data to generate the verification data. For example, by applying a hashing algorithm to the first data, the verification data generated from the first data may be a fixed or predetermined size, which may allow for more efficient storage of the verification data, for example by generating verification data with a reduced size than would be generated otherwise. Using these further examples in cases where the first data is raw data or data that has not previously been hashed before storage in the first DLN 802a for example allows the verification data to be secured cryptographically, improving the security of the verification data.

[00313] For example, the first data storage identifier may be transmitted in the verification data storage request. The first data storage identifier may be used to retrieve the first data from the first DLN 802a. The retrieved first data may then be processed (for example hashed) to generate the verification data or all or part of the retrieved first data may be used as the verification data itself, as explained above. For example, the BlockHash may be extracted from the first data and used as the verification data in examples where the first data is stored as a block of a blockmatrix. The first data storage identifier may then be stored in storage (for example storage of a control node of the first DLN 802a where the verification data storage request is transmitted to the control node), so that it may be used subsequently to retrieve the first data from the first DLN 802a.

[00314] At item 812 of Figure 33, confirmation that the verification data has been stored in one or more DLNs of the at least one DLN 802e is received. For example, the confirmation may be received from a control node of the first DLN 802a, where the control node is used to control transmission of the verification data to the one or more DLNs of the at least one DLN 802e.

[00315] The confirmation received at item 812 of Figure 33 may be similar to the confirmation received at item 808 of Figure 33, but confirming that the verification data has been stored in the one or more DLNs rather than confirming that the first data has been stored in the first DLN 802a. For example, the confirmation of item 812 may be a receipt indicating that the verification data has been successfully committed to the one or more DLNs.

[00316] In these examples, a verification data storage transaction identifier may be received in response to the verification data storage request, which may be received as part of the confirmation or separately. The verification data storage transaction identifier allows the verification data to be located within the one or more DLNs, for example so that the verification data may be retrieved from the one or more DLNs. The verification data storage transaction identifier for example identifies a block (or one or more blocks), within the one or more DLNs, in which the verification data has been stored. As for the first data storage transaction identifier, the verification data storage transaction identifier may include a block index or a transaction ID allowing a block of a blockchain of the one or more DLNs in which the verification data is stored to be identified. In examples, the one or more DLNs may each include a one-dimensional blockchain, whereas the first DLN may include a multidimensional blockmatrix such as that described above. In other examples, though, the one or more DLNs may include a distributed ledger stored in other formats, such as a multidimensional blockmatrix, a plurality of one- dimensional blockchains or a one-dimensional blockchain with one or more forks (which may be hard or soft forks).

[00317] In some cases, a hashed verification data storage identifier may be received in response to the verification data storage request. The hashed verification data storage transaction identifier in these cases represents a hash derived from a block identifier identifying a block, within the one or more DLNs, in which the verification data has been stored. For example, the hashed verification data storage transaction identifier may be a hash of the block index or transaction ID. In cases such as this, the verification data storage identifier may be stored in storage of a control node of the first DLN 802a before hashing, for example so that the verification data storage identifier can be retrieved from the storage upon receipt of a request to verify storage of verification data corresponding to the hashed verification data storage identifier.

[00318] Transmitting the hashed verification data storage identifier, for example to the node from which the verification data storage request was sent initially, may improve security compared with transmission of the verification data storage identifier. For example, even if a malicious party intercepts the hashed verification data storage identifier during transmission, the malicious party will not be able to identify where the verification data is stored in the one or more DLNs without performing a dictionary attack on the hashed verification data storage identifier. In examples, further measures to counter dictionary attacks may also be employed. For example, the verification data storage identifier may be hashed using a cryptographic algorithm which is non-deterministic with respect to the verification data storage identifier as first input data (such as using the HMAC algorithm). Such measures may also be used in other examples described herein in which hashing is used.

[00319] Methods in accordance with Figure 33 therefore allow first data to be stored in a first DLN 802a (which may be a private DLN) and verification data related to the first data to be stored in one or more DLNs different from the first DLN 802a (which may be public DLNs). The one or more DLNs may have a relatively high level of immutability compared with the first DLN 802a. The one or more DLNs may therefore be more resistant to manipulation or tampering by a malicious party. For example, where the one or more DLNs are public DLNs, without a central authority and with a large number of member nodes, and the first DLN 802a is a private DLN, with a relatively small number of member nodes, the one or more DLNs may be notably more resistant to attacks by a malicious party.

[00320] To combat or reduce the susceptibility of first data stored in such a first DLN 802a to tampering, verification data related to the first data (which for example allows a level of immutability to be verified) may be stored in the one or more DLNs, for example in accordance with Figure 33. This process may be used to increase the immutability of the verification data (and hence confidence in the immutability of the first data) to a higher level than achievable with a single DLN such as the first DLN 802a. In other words, users of the first DLN 802a may benefit from features of the one or more DLNs, which may be large-scale public DLNs with a high resistance to tampering.

[00321] Figure 34 is a flow diagram illustrating additional example features of the method for storing data shown in Figure 33. In examples in accordance with Figure 34, parameter data is transmitted in the verification data storage request at item 814. The parameter data relates to at least one characteristic requested for the storage of the verification data in the at least one DLN 802e. For example, the parameter data may include one or more requirements for storage of the verification data in the at least one DLN 802e, which typically affect the number of DLNs the verification data is stored in, the identity of the DLNs the verification data is stored in or a format in which the verification data is stored. [00322] The at least one characteristic may include a level of immutability requested for the storage of the verification data in the at least one DLN. Generally, the level of immutability increases as the verification data is stored in an increasing number of DLNs of the at least one DLN. For example, the probability of error associated with storing the first data in the first DLN 802a and the verification data in n DLNs may be calculated as:

[00323] where P is the probability of error, Pk is the probability of error associated with storage of the verification data in a DLN of the n DLNs and PDLNI is the probability of error associated with storage of the first data in the first DLN 802a.

[00324] The level of immutability may be determined by user input or based on processing of the first data. For example, where the first data is identified to be sensitive data a higher level of immutability may be requested compared with public data. A sensitivity of the first data may be identified based on metadata associated with the first data, which may indicate that the first data is sensitive or that the first data is of a type that is considered to be sensitive (although other ways of identifying a sensitive of first data may be used in other examples).

[00325] In other examples, the at least one characteristic includes a level of delay within which confirmation of the storage of the verification data in the at least one DLN is requested. For example, the level of delay may indicate a request that the verification data is confirmed as committed to the at least one DLN within a predetermined time period, such as within a given time period from receipt of the verification data storage request or by a particular time in absolute terms (for example relative to an atomic clock). The method may then involve identifying suitable DLNs to which the verification data can be confirmed as committed to within the requested level of delay. For example, some DLNs of the at least one DLN may take a relatively long time to commit new data to the DLN. Such DLNs may therefore not be appropriate for storage of verification data with a short requested level of delay.

[00326] The at least one characteristic may include a plurality of characteristics such as a requested level of immutability and a requested level of delay, each of which may be used to identify DLNs for storage of the verification data. In other examples, the at least one characteristic may include blacklisted DLNs, which the verification data is not to be stored in, or preferred DLNs, which the verification data is to be stored in preferentially (for example in preference to other DLNs) or a requested minimum or maximum number of DLNs in which the verification data is to be stored.

[00327] The example method of Figure 34 includes, at item 816, receiving calculated parameter data. The calculated parameter data may for example represent a calculated value of at least one characteristic requested for storage of the verification data in the at least one DLN 802e. For example, the calculated parameter data may include receiving immutability data representative of a calculated level of immutability associated with the storage of the verification data in the one or more distributed ledger networks. This may be used to compare the calculated level of immutability to the requested level of immutability (in cases in which the verification data storage requested includes a requested level of immutability), for example to assess whether the requested level of immutability is met or exceeded. In other examples, in which the at least one characteristic includes a requested level of delay, the calculated parameter data may represent a calculated delay, which is for example the length of time taken for confirmation of the storage of the verification data in the at least one DLN 802e (which may be taken as a length of time between receipt of the verification data storage request and committal of the verification data to the at least one DLN 802e).

[00328] Figure 35 is an example of a method for processing a request to store verification data in at least one DLN in accordance with the second examples described above. Features of the method of Figure 35 may be the same as or similar to corresponding features of the methods of Figures 33 or 34. For example, the first data, the verification data, the verification data storage request, the first DLN 802a and the at least one DLN 802e may be the same as or similar to that described above with reference to Figures 33 and 34.

[00329] The method of Figure 35 includes, at item 818, receiving a verification data storage request relating to storage of verification data in at least one DLN 802e different from the first DLN 802a. The verification data relates to first data stored in the first DLN 802a. The verification data storage request includes a first data storage transaction identifier identifying a block, within the first DLN 802a, in which the first data has been stored. The first data storage transaction identifier maybe similar to or the same as that described above with reference to Figure 33.

[00330] The method of Figure 35 may be performed by a control node of the first DLN 802a. For example, the verification data storage request may be received at the control node, from a client node of the first DLN 802 for example. [00331] At item 820 of Figure 35, data is retrieved from the first DLN 802a on the basis of the first data storage transaction identifier. For example, the first data itself may be retrieved from the first DLN 802a by locating a block of the first DLN 802a corresponding to the first data storage transaction identifier, for example with a transaction ID corresponding to the first data storage transaction identifier or with a Blocklndex and Vectorlndex corresponding to a Blocklndex and Vectorlndex of or derived from the first data storage transaction identifier.

[00332] At item 822 of Figure 35, the verification data is derived from the retrieved data. For example, the verification data may be derived from the first data (where the retrieved data corresponds to or includes the first data) by hashing the first data, for example to generate a BlockHash of a block including the first data. Thus, in the example of Figure 35, the verification data itself need not be transmitted. Instead, the verification data may be generated from data retrieved from the first DLN 802a. Methods in accordance with Figure 35 may therefore be more efficient, with a smaller amount of data transferred from a client node to a control node or stored in storage of the client node, than otherwise.

[00333] At item 824 of Figure 35, the verification data is transmitted to one or more DLNs of the at least one DLN 802e. In this way, as explained above with reference to Figures 33 and 34, the immutability of the verification data may be increased.

[00334] The verification data may be transmitted to be stored as metadata associated with at least one of: a transaction or a block of the one or more DLNs. The verification data may be transmitted as metadata when a DLN transaction is initiated. For example, the metadata may be transmitted as part of or associated with the DLN transaction, for committal to the one or more DLNs. For example, metadata may be added to a DLN transaction or edited using the OP_RETURN instruction (where the DLN is the Bitcoin network), which is a part of the Bitcoin scripting language. Similar instructions may exist for other DLNs to which the verification data may be committed, such as other public DLNs. A DLN transaction may be incorporated in a block of the one or more DLNs with a plurality of other DLN transactions, which may be transactions involving other users than users associated with the first DLN. In such cases, the verification data may be stored as metadata associated with a transaction of a block of the one or more DLNs. In other examples, the verification data may be stored as metadata associated with a block of the one or more DLNs itself.

[00335] In other examples where a DLN transaction has already been initiated, the metadata associated with the DLN transaction may be added to the metadata associated with the DLN transaction. For example, the verification data may be transmitted to be added to pre-existing metadata associated with a block to be committed to the one or more DLNs, so as to store the verification data as the metadata associated with the block. It is to be noted, though, that the data of the block itself cannot be edited or rewritten, as blocks are intended to be immutable. This allows the verification data to be stored in the one or more DLNs efficiently, without having to initiate an additional transaction or write an additional block to the one or more DLNs. Further examples in which verification data may be stored as metadata will be described below with reference to Figures 42 and 43.

[00336] Figure 36 is a flow diagram illustrating example features of the method of processing a request to store verification data shown in Figure 35. At item 826 of Figure 36, a verification data storage request is received. The verification data storage request of Figure 36 relates to storage of verification data in a plurality of DLNs different from the first DLN 802a. Otherwise, the verification data storage request of Figure 36 may be the same as that of Figure 35.

[00337] At item 828 of Figure 36, a plurality of network verification data storage identifiers are received in response to the verification data storage request. For example, the verification data storage requested may be received by a control node of the first DLN 802a and subsequently the verification data may be stored in the plurality of DLNs. After storing the verification data in the plurality of DLNs, the plurality of network verification data storage identifiers may be received at the control node of the first DLN 802a, indicating that the verification data has been stored in the plurality of DLNs. For example, each of the plurality of network verification data storage identifiers may be received from a respective DLN of the plurality of DLNs.

[00338] Each of the plurality of network verification data storage transaction identifiers in Figure 36 identifies a respective block, within a corresponding distributed DLN of the plurality of DLNs, in which the verification data has been stored. For example, a network verification data storage transaction identifier may be similar to or the same as a verification data storage transaction identifier and may therefore include a block index or transaction ID allowing a block within which the verification data has been stored to be identified.

[00339] In some examples, each of the plurality of network verification data storage transaction identifiers may be transmitted to the client node of the first DLN 802a or stored within storage of the control node of the first DLN 802a so that the verification data may subsequently be requested by the client node from the plurality of DLNs, for example if a request to check an immutability the verification data is submitted.

[00340] However, the example method of Figure 36, the plurality of network verification data storage identifiers are combined at item 830 to generate a combined verification data storage identifier. At item 832 of Figure 36, a hashing algorithm is applied to the combined verification data storage identifier to generate a hashed verification data storage identifier. In this way, the various receipts received from each of the plurality of DLNs (which each correspond to a network verification data storage transaction identifier respectively) may be combined to a single receipt (in this case the hashed verification data storage identifier), which may be stored and transferred more efficiently than a plurality of separate receipts. For example, the hashed verification data storage identifier may be transmitted to the client node of the first DLN 802a that initially requested storage of the verification data in the plurality of DLNs and the plurality of network verification data storage identifiers may be stored within storage of a control node which receives the network verification data storage identifiers from the plurality of DLNs.

[00341] Figure 37 is a flow diagram illustrating further example features of the method for storing data shown in Figure 35. At item 834 of Figure 37, parameter data is received in the verification data storage request (which may be similar to or the same as that of Figures 35 or 36). At item 836 of Figure 37 calculated parameter data is generated and the calculated parameter data is transmitted at item 838 of Figure 37. The parameter data for example relates to at least one characteristic requested for the storage of the verification data in the at least one DLN, for example as described above with reference to Figure 34, and may be generated as described with reference to Figure 34. For example, the calculated parameter data may be generated at a control node of the first DLN 802a and transmitted to a client node of the first DLN 802a. For example, methods in accordance with Figure 37 (which may additionally be in accordance with Figures 35 and 36) may involve generating immutability data indicative of a calculated level of immutability associated with the storage of the verification in the one or more DLNs.

[00342] Figure 38 is a flow diagram illustrating a method of processing requests to store verification data according to further examples. Figure 38 is for example a method of aggregating a plurality of requests to store verification data, for more efficient storage within at least one DLN. The method of Figure 38 may be performed in a control node of at least one control node of a first DLN 802a, which may be used to control data transfer between a first DLN 802a and at least one DLN different from the first DLN 802a.

[00343] At item 840 of Figure 38, a first verification data storage request relating to storage of verification data in the at least one DLN different from the first DLN 802a is received and at item 842 of Figure 38, a second verification data storage request relating to storage of verification data in the at least one DLN different from the first DLN 802a is received. The first verification data storage request relates to first data stored in the first DLN 802a and the second verification data storage request relates to second data stored in the first DLN 802a.

[00344] The first verification data storage request is for example received from a first client node of a plurality of client nodes of the first DLN 802a and the second verification data storage request is for example received from a second client node of the plurality of client nodes, although in other examples, both the first and second verification data storage requests may be received from the same node of the first DLN 802a, which may be a client node, member node or control node.

[00345] At item 844 of Figure 38, a hashing algorithm is used to generate the verification data. The hashing algorithm in the example of Figure 38 uses both first derived data derived from the first data and second derived data derived from the second data as input data. For example, the first derived data and the second derived data may be derived from the first and second data, respectively, by applying a hashing algorithm to the first and second data or the first and second derived data may represent a hash of at least a portion of the first and second data respectively. The first and second derived data may represent a portion of the first and second data respectively, For example, where the first and second data represent a block of a blockmatrix, which includes a BlockHash data field, the first and second derived data may represent a BlockHash of the first and second data, which may be considered to correspond to a portion of the first and second data respectively. In other examples, the first and second derived data may be derived differently from the first and second data. For example, the first and second data may be processed (for example using a hashing or other cryptographic algorithm) to generate the first and second derived data respectively.

[00346] In this way, two separate requests to store verification data may be combined or aggregated and a single piece of verification data may be generated to represent the two separate requests. The generated verification data may then be transferred or stored more efficiently than separate storage of data relating to the two requests. [00347] The verification data may be generated on the basis that the first verification data storage request and the second verification data storage request are received within a predetermined time period. The predetermined time period may relate to or depend on an expected, predicted or predetermined time period for committal of new blocks to blockchains of the at least one DLN 802e. For example, if the first and second verification data storage request are received within such an expected time period, the generated verification may be transmitted to the at least one DLN 802e for storage within the same block or associated with the same block, without delaying committal of data to the at least one DLN 802e. In such cases a plurality of verification storage requests may be aggregated in situations where it is determined that such aggregation can be performed before the next block is committed to the at least one DLN 802e, i.e. where it is determined that the aggregation can be performed without reducing the rate of committing data to the at least one DLN 802e.

[00348] A determination such as this may be made in conjunction with a current time, an expected or predicted time for committal of the next block in a blockchain of a DLN of the at least one DLN 802e, or a time difference between the current time and the expected or predicted time for next block committal. This determination may be made separately for each or each of a subset of DLNs of the at least one DLN 802e. For example, for a particular DLN, it may be determined that there is an expected time period before committal of the next block in the blockchain of that DLN. Any verification data storage requests that are received within this time period may then be aggregated and the verification data generated using the aggregation procedure may then be transmitted for storage as part of or associated with the next block of the blockchain of that DLN.

[00349] Such a determination may be carried out in conjunction with other checks of a suitability of a DLN for storage of particular verification data. For example, a DLN may be assessed to determine whether it satisfies the at least one characteristic requested for storage of the verification data. If not, the derived data associated with that particular verification data storage request may not be aggregated with other derived data for storage in that DLN and may instead be stored in or aggregated with other derived data for storage in a different DLN.

[00350] After generating the verification data, the verification data may be transmitted for storage in one or more DLNs of the at least one DLN 802e, for example to increase the immutability of the verification data. As explained above with reference to other examples, the verification data may be transmitted to be stored as metadata associated with at least one of: a transaction or a block of the one or more DLNs.

[00351] Figure 39 is a flow diagram illustrating example features of the method of processing requests to store verification data shown in Figure 38. At items 848 and 850 of Figure 39, the first and second derived data are retrieved from the first DLN 802a. For example, the first verification data storage request may include a first data storage transaction identifier identifying a first block, within the first DLN 802a, in which the first data has been stored and the second verification data storage request may include a second data storage transaction identifier identifying a second block, within the first DLN 802a, in which the second data has been stored. In such cases, the first and second derived data may be retrieved from the first DLN 802a on the basis of the first and second data storage transaction identifiers, respectively. For example, the first and second data storage transaction identifiers may be similar to the first data storage transaction identifier described above with reference to Figure 33.

[00352] The first derived data and the second derived data may be stored in storage of a control node of the first DLN 802a, for example, so that the first and second derived data may be used subsequently for verification of the first and second data, as will be explained further below. Similarly, the verification data generated using the first and second derived data may also be stored in the storage of the control node of the first DLN 802a.

[00353] Referring back to Figure 39, at item 852, the first derived data and the second derived data are combined into a concatenated data string. For example, the first derived data and the second derived data may be concatenated, for example without intervening characters or with one or a plurality of predetermined spacer characters between the first and second derived data. For example, concatenating the first and second derived data may involve appending a predetermined series of characters indicating a separator (such as a series of hash symbols or other symbols) to the string represented by the first derived data and subsequently appending the string represented by the second derived data, although other methods of combining or concatenating the first and second derived data are possible in other examples. At item 854 of Figure 39, the hashing algorithm is applied to the concatenated data string to generate the verification data. As explained above for generation of the additional-level verification data (which may use a similar procedure), this for example allows a size of the concatenated data string to be reduced to a size that is suitable for storage on a DLN, which may also reduce storage requirements for the verification data. [00354] Figure 40 is a flow diagram illustrating example features of the method of processing requests to store verification data of Figure 38, which may for example occur after the items shown in Figure 38. At item 856 of Figure 40, a network verification data storage identifier is received in response to transmitting the verification data for storage in the one or more DLNs of the at least one DLN 802e different from the first DLN 802a. The network verification data storage transaction identifier identifies a block, within the one or more DLNs, in which the verification data has been stored. For example, the network verification data storage transaction identifier may be similar to or the same as the verification data storage identifier and may therefore include a block index or transaction ID allowing a block of a blockchain of the one or more DLNs in which the verification data is stored to be identified.

[00355] Typically one network verification data storage transaction identifier will be received for each DLN the verification data is stored in. Thus, if the verification data is stored in a plurality of different DLNs, a plurality of network verification data storage transaction identifiers may be received. The one more network verification data storage transaction identifiers may for example be received by a component that generated the verification data (such as a control node of the first DLN 802a), and may be received from the DLNs in which the verification data was stored.

[00356] In the example of Figure 40, the verification data is stored in solely on DLN of the at least one DLN 802e, for simplicity and ease of explanation. It is to be appreciated, though, that typically the verification data may be stored in more than one different DLN of the at least one DLN 802e.

[00357] At items 858 and 860 of Figure 40, a first confirmation indicative that the first derived data has been stored in the one or more DLNs and a second confirmation indicative that the second derived data has been stored in the one or more DLNs are transmitted. The first and second confirmation each include data derived from the network verification data storage identifier. For example, the first and second confirmation may each include one or more of the network verification data storage identifier or a hash of the verification data storage identifier. The first and second confirmations may be transmitted to the components from which the first and second verification data storage requests originated, such as first and second client nodes of the first DLN 802a. The first and second confirmations may thus each correspond to the confirmation referred to with reference to Figure 33. [00358] Figure 41 is a flow diagram illustrating a method of processing requests to store verification data according to yet further examples. Features of the method of Figure 41 may be similar to or the same as corresponding features of other examples described herein. For example, the verification data storage request, the first data, the verification data, the first DLN 802a, the at least one DLN 802e different from the first DLN 802a and the parameter data may be the same as those described above with reference to Figures 32 to 40. The method of Figure 41 may for example be performed in a client node of a first DLN 802a, or in other nodes in other examples.

[00359] At item 862 of Figure 41, a verification data storage request relating to storage of verification data in at least one DLN 802e different from a first DLN 802a is received. The verification data relates to first data stored in the first DLN 802a. In the example of Figure 41, the verification data storage request includes parameter data relating to at least one characteristic requested for the storage of the verification data in the at least one DLN 802e. The at least one characteristic may be for example a requested level of immutability or a level of delay as explained above.

[00360] At item 864 of Figure 41, one or more DLNs different from the first DLN 802a are selected for storage of the verification data, on the basis of the parameter data. At item 866 of Figure 41, the verification data is stored in the one or more DLNs selected at item 864. For example, the one or more DLNs may be selected so as to store the verification data in accordance with the at least one characteristic represented by the parameter data.

[00361] As an example, if the at least one characteristic includes a requested level of immutability, a sufficient number of DLNs may be selected for storage of the verification to store the verification data in the selected DLNs with a level of immutability that meets or exceeds the requested level of immutability.

[00362] Similarly, if the at least one characteristic includes a requested level of delay, a DLN may be selected from the at least one DLN 802e for storage of the verification data based on an expected or predicted time for committal of a next or subsequent block to the DLN which is within a requested level of delay. For example, if it is determined that a new block is to be committed to the DLN within a time period corresponding to the requested level of delay, that DLN may be selected for storage of the verification data. In other words, the DLNs may be selected so that the verification data may be committed to these DLNs sufficiently quickly to be within the requested level of delay. [00363] Figure 42 is a flow diagram illustrating a method of processing a request to store verification data according to still further examples. At item 868 of Figure 42, a DLN transaction may be initiated. A DLN transaction may be considered to be any operation that involves interaction with the distributed ledger of the DLN, for example that involves modifying or updating the distributed ledger. For example, operations that involve the writing, committing or storing of new data to the DLN, such as operations that involve adding a new block to a blockchain of the DLN, may be considered to be a DLN transaction.

[00364] The DLN transaction may for example be a cryptocurrency transaction, although other transactions are possible in other examples. A cryptocurrency is for example a digital asset that may be exchanged or transferred between parties in cryptocurrency transactions. Cryptocurrencies are generally secured cryptographically. In such cases, a DLN transaction may represent a transaction or transfer of a cryptocurrency between a first digital wallet and a second digital wallet. For example, the method of Figure 42 may be performed in a node including the first digital wallet and the second digital wallet, such as a control node of the first DLN 802a.

[00365] Bitcoin is an example of a cryptocurrency; other cryptocurrencies may be exchanged or transferred similarly. Using Bitcoin as an example, a Bitcoin address may represent a possible destination for a Bitcoin payment or a destination already associated with Bitcoins. For example, to perform a Bitcoin transaction, a first user with Bitcoins at a first Bitcoin address may transfer some or all of their Bitcoins to a second Bitcoin address (which may initially include some or no Bitcoins), which may be associated with a second user.

[00366] Bitcoin addresses can be created using a public key, which may be shared publicly. A Bitcoin address may therefore be considered to correspond to a public key. In this example, the second user may supply the public key associated with the second Bitcoin address to the first user, so the first user can transfer the Bitcoins to the second Bitcoin address. However, a private key is generally required to access the Bitcoins associated with a Bitcoin address, which should be kept secret in order to protect the security of the Bitcoins at that Bitcoin address. In this example, the first user has a first private key allowing the first user to access the first Bitcoin address, and hence the Bitcoins associated with the first Bitcoin address. Similarly, the second user has a second private key allowing the second user to access the second Bitcoin address. A private key and a public key in this scenario may therefore be considered to be a key pair: typically the public key can be generated from the private key but the private key cannot be generated from the public key or the Bitcoin address. A new key pair may be generated for each transaction, so that each transaction corresponds with a different Bitcoin address.

[00367] A digital wallet is for example an electronic wallet for storing data related to or representative of digital assets or digital transactions. Such a digital wallet may be a cryptocurrency wallet. Cryptocurrency wallets may support multiple different types of cryptocurrency so that the user can use the same wallet to participate in transactions involving these multiple different types of cryptocurrency. A cryptocurrency wallet may be considered to be a digital location for storage of information relating to cryptocurrency assets or transactions of a user. For example, a Bitcoin wallet may store key pairs. As explained above, each key pair may include a private key (which the user should keep private and secure to maintain the security of their Bitcoin wallet), and a public key which corresponds to a Bitcoin address. Other cryptocurrency wallets may store similar information. For example, an Ethereum wallet may also store key pairs similarly to a Bitcoin wallet.

[00368] A transaction identifier (sometimes referred to as a transaction ID) may be generated in response to a cryptocurrency transaction. A transaction ID representing a transaction between the first and second digital wallets is for example associated with a block of the blockchain which includes transaction data representative of that transaction. For example, the transaction identifier may allow the block associated with that transaction to be located within the blockchain and retrieved. Typically, the transaction data includes data representative of an amount of cryptocurrency transferred, the date, the address of the first digital wallet (or the sender of the cryptocurrency), the address of the second digital wallet (or the receiver of the cryptocurrency) and the size of the transaction. As explained above, each block generally also includes a hash of that block (which may be referred to as a current block hash) and a hash of the previous block in the blockchain, in order to chain the block to the blockchain. Each block generally includes transaction data for a plurality of different transactions.

[00369] Typically, there is a delay between a DLN transaction being initiated and a new block being created and added to the blockchain that records that DLN transaction. For example, new blocks may be created and added to the Bitcoin network approximately every ten minutes, by Bitcoin miners who compete to solve a computational problem in exchange for new-created Bitcoins and transaction fees (other DLNs such as Ethereum may work similarly). Until a DLN transaction is recorded and included in a block of the blockchain, the DLN transaction is considered to be unconfirmed or uncommitted to the DLN. However, after a DLN transaction is included in a block of the blockchain, the DLN transaction may be considered to be confirmed or committed to the DLN. There may therefore be a delay of up to around ten minutes for a DLN transaction to be committed to a given DLN.

[00370] Referring back to Figure 42, item 870 involves receiving a verification data storage request relating to storage of verification data in at least one DLN 802e. The verification data storage request and the verification data may be for example be the same as or similar to the verification data storage request and the verification data described in other examples herein. For example, the verification data storage request may be received from a client node of the first DLN 802a, which may be a private DLN (whereas the at least one DLN 802e different from the first DLN 802a may include at least one public DLN). The verification data storage request in examples such as Figure 42 is received after initiating the DLN transaction.

[00371] At item 872 of Figure 42, the verification data is transmitted to be stored as metadata in association with the DLN transaction, prior to the DLN transaction being confirmed as committed to one or more DLNs of the at least one DLN 802e. In some DLNs, after initiation of a DLN transaction but before committal of the DLN transaction to the DLN, the metadata associated with the DLN transaction (which may be stored as metadata associated with a transaction after the transaction is recorded in a block of a blockchain) may be altered (although it is not possible to alter the transaction itself, such as the quantity of cryptocurrency transferred). This may be exploited by altering or adding to the metadata associated with the DLN transaction to include or to represent the verification data, which may allow the verification data to be stored more rapidly within the DLN than otherwise.

[00372] Figure 43 is a flow diagram illustrating a method of processing a request to store verification data according to still further examples. Features of Figure 43 are similar to those of other examples described herein; corresponding descriptions should be taken to apply. At item 874 of Figure 43, a plurality of DLN transactions are initiated before receiving a verification data storage request (which may be similar to the verification data storage request of Figure 42). Each of the plurality of DLN transactions are unconfirmed as committed to the one or more DLNs when the verification data storage request is received. The plurality of DLN transactions may be initiated at pre-determined time intervals, respectively, so that there is a ready or relatively steady supply of DLN transactions for storage of the verification data. For example, there may be a plurality of verification data storage requests each requesting storage of different verification data. The different verification data may than be stored, for example as metadata, along with different respective DLN transactions. Thus, the rate of initiation of the plurality of DLN transactions may be selected to match an expected rate of receipt of incoming verification data storage requests. The pre-determined time intervals may be regular or irregular and may vary over time, for example in dependence on the rate or the expected rate of receipt of incoming verification data storage requests.

[00373] At item 876 of Figure 43, a DLN transaction is selected from the plurality of DLN transactions from the plurality of DLNs for the storage of the verification data, on the basis of at least one characteristic of the verification data storage request. For example, the at least one characteristic of the verification data storage request may be used to select an appropriate DLN transaction for storage of the verification data, such as a DLN transaction with metadata capacity for storage of the verification data or a DLN transaction that does not already include metadata representative of other verification data. In examples, the at least one characteristic of the verification data storage request includes a time of receiving the verification data storage request. For example, the verification data may be stored as metadata associated with the DLN transaction that was initiated at a closest point in time to receipt of the verification data storage request or a DLN transaction that was initiated at a closest point in time to receipt of the verification data storage request and that also satisfies other requirements, such as data capacity. In other examples, the at least one characteristic may include a level of delay within which confirmation of the storage of the verification data in the at least one DLN 802e is requested. For example, if a relatively long level of delay is tolerable, the verification data may not be immediately associated with a DLN transaction. Instead the verification data may be held for a period of time and subsequently included as metadata of a later DLN transaction, thereby leaving earlier DLN transactions free to receive verification data that is requested to be stored in the at least one DLN 802e more urgently.

[00374] Figure 44 shows schematically an example of internal components of a client node 1312 according to examples, which is for example a client node of the first DLN 802a referred to above. The example client node 1312 of Figure 44 may be similar to the member node 312 of Figure 17. Features of Figure 44 that are similar to corresponding features of Figure 17 are labelled with the same reference numeral incremented by 1000; corresponding descriptions are to be taken to apply. The client node 1312 of Figure 44 may be used with any of the examples described herein. [00375] In addition to the components that are similar to the client node 312 of Figure 17 (which will not be described again here, for brevity), the client node 1312 of Figure 44 also includes a communication module 878 for communicating with a control node of the first DLN 802a. For example, the communication module 878 may transmit verification data storage requests to the control node and may receive confirmation of storage of the verification in the one or more DLNs of the at least one DLN 802e. The client node 1312 also includes a verification data storage module 880 for generating the verification data storage requests.

[00376] Figure 45 shows schematically an example of internal components of a control node 882 according to examples. The control node 882 of Figure 45 may be similar to or used in a similar way to the control node 718 of Figure 22. In this example, the control node 882 includes a communication module 884 which may for example be configured to handle incoming communications received from client nodes (such as the client node 1312 of Figure 44) or member nodes of the first DLN 802a or to handle incoming communications from nodes of the at least one DLN 802e different from the first DLN 802a. The communication module 884 may also be used to transmit outgoing communications to the client node or member nodes of the first DLN 802a or to nodes of the at least one DLN 802e. The control node 882 includes a verification data storage module 886, which may be used to derive, generate or retrieve the verification data and to instruct storage of the verification data in the at least one DLN 802e. The control node 882 in this example also includes an aggregation module 888, which may be used to aggregate a plurality of verification data storage requests into one verification data storage request. In such cases, the aggregation module 888 and the verification data storage module 886 may act together to generate the verification data. In this example, the control node 882 also includes a first digital wallet 890 and a second digital wallet 892, although this is not to be taken as limiting. For example, other control nodes may not include a digital wallet. Although not shown in Figure 45, it is to be appreciated that the control node 882 of Figure 45 may also include other components or modules (such as similar modules to those of the client node 1312 of Figure 44). The modules of the control node may be connected via a systems bus for example.

[00377] Figure 46 is a flow diagram illustrating a method of verifying verification data according to examples. The verification data may be stored in one or more DLNs as described above, which may be different from a first DLN 802a in which first data related to the verification data is stored. In the example of Figure 46, the verification data to be verified relates to first data. Thus, the example of Figure 46 is a relatively simple example, in which the verification data has not been generated via aggregation. Features of Figure 46 are nevertheless similar to corresponding features of other examples and corresponding descriptions should be taken to apply. In the example of Figure 46, this method is performed by a control node of the first DLN 802a, but in other examples this method may be performed by other components or by components of other DLNs.

[00378] At item 894 of Figure 46, a data verification request is received. The data verification request includes verification data to be verified and confirmation of storage of the verification data in at least one DLN 802e different from the first DLN 802a. At item 896, at least one verification data storage transaction identifier is retrieved, in this example from storage of the control node of the first DLN 802a. For example, one verification data storage transaction identifier may be retrieved in examples in which the verification data is stored in solely one DLN different from the first DLN 802a or in other examples in which the verification data is stored in a plurality of DLNs different from the first DLN 802a but the verification data storage transaction identifier nevertheless allows the location of the verification in the plurality of DLNs to be identified. The verification data storage transaction identifier may be retrieved on the basis of the confirmation, which may for example be a receipt or other identifier allowing the verification data storage transaction identifier to be located and retrieved.

[00379] At item 898 of Figure 46, the verification data is retrieved from the at least one DLN 802e based on the at last one verification data storage transaction identifier. At item 900, the retrieved verification data and the received verification data (received at item 894) are compared to calculate the immutability data. For example a degree of match between the retrieved and the received verification data may be calculated and may be multiplied with a level of error in the at least one DLN 802e in which the verification data was stored (which may be predetermined or calculated on-the-fly), to generate the immutability data. The immutability data in this example may be considered to represent the level to which the verification data can be verified, which may be expressed as percentage. Finally, at item 902, the immutability data is transmitted, for example to the node that initially transmitted the data verification request, which may be the client node from which the initial verification data storage request was transmitted or a different node.

[00380] Figure 47 is a flow diagram illustrating a method of verifying verification data according to further examples. The method of Figure 47 is similar to that of Figure 46 but relates to a more complex example in which the data to be verified has been aggregated before storage on the at least one DLN.

[00381] At item 904 of Figure 47, a data verification request is received. The data verification request in this example includes first derived data to be verified (such as the first derived data described above) and confirmation of storage of verification data generated using the first derived data in at least one DLN 802e different from the first DLN 802a in which first data from which the first derived data is derived has been stored.

[00382] At item 906, the first derived data is retrieved on the basis of the confirmation. For example, the first derived data may be retrieved from storage of a control node of the first DLN 802a in examples in which the method of Figure 47 is performed by a control node of the first DLN 802a. At item 908, a first comparison is performed between the received first derived data and the retrieved first derived data, for example to assess whether the received first derived data has been altered compared with the retrieved first derived data.

[00383] At item 910 of Figure 47, at least one verification data storage transaction identifier is retrieved. As for the retrieval of the first derived data, the at least one verification data storage transaction identifier may be retrieved from storage of a control node of the first DLN 802a. The at least one verification data storage transaction identifier may be retrieved on the basis of the confirmation received at item 904, as explained with reference to Figure 46. At item 912, the verification data is retrieved from the at least one DLN 802e on the basis of the at least one verification data storage transaction identifier and at item 914 the verification data is regenerated using the received first derived data. The verification data may be regenerated using the same process as was used originally to generate the verification data. Thus, where the verification data was originally produced by hashing first derived data and second derived data, the second derived data may also be retrieved (for example from storage of the control node of the DLN 802a) and subsequently hashed with the received first derived data to regenerate the verification data.

[00384] At item 916 of Figure 47, a second comparison between the retrieved verification data and the regenerated verification data may be performed, for example to assess whether the regenerated verification data (based on the received derived first data) differs from the retrieved verification data.

[00385] At items 918 and 920 of Figure 47, immutability data is calculated based on at least one of the first comparison or the second comparison and the immutability data is transmitted, for example to a node that transmitted the data verification request. The immutability data may be calculated as described above for Figure 46. For example, the first and second comparisons may each involve the generation of a degree of match, respectively, which may be multiplied together and with the level of error in the at least one DLN 802e the verification data was stored in to calculate the immutability data in examples in which both the first and second comparisons are used to generate the immutability data.

[00386] As will be appreciated, the verification methods of Figures 46 and 47 are merely examples and various other verification methods may be used in other examples. Typically, though, verification methods involve a comparison between verification data (either as received or as generated using received data) and stored verification data or retrieved verification data, which may be retrieved for example from at least one DLN 802e or from the first DLN 802a.

[00387] Further examples, such as the first, second and third examples referred to above, relate to authenticating a computing node and/or validating an origin of a block. Features of the first, second and third examples will now be described, with reference to Figures 48 to 58. The methods of the first, second and third examples may be used with the methods described above or as part of other methods or systems.

[00388] Figure 48 is a flow diagram illustrating a method of authenticating a computing node according to examples. The items of Figure 48 may for example be performed by the computing node that is to be authenticated. At item 922 of Figure 48, a computing node is configured with a node identifier. The node identifier may be a fixed or constant identifier or a pseudo-random identifier. An identifier may be considered to be pseudo-random for example where the identifier appears to be random, such as exhibiting statistical randomness, while being generated based on a deterministic process. The computing node may be configured with the node identifier as exampled above with reference to Figure 8. For example, the node identifier may be generated upon initialization of the computing node and, subsequently, the computing node may be configured with the node identifier. The node identifier may be generated based on a time associated with initializing the computing node, which may be measured using a synchronous time source such as an atomic clock. For example, the node identifier may correspond to a concatenation of a timestamp representative of a time of initializing the computing node and a random number (although other node identifiers are possible in other examples). [00389] At item 924 of Figure 48, the node identifier and a licence entitlement data are transmitted from the computing node. The licence entitlement data is typically any data that can be processed to determine whether the computing node has access to a licence. For example, the licence entitlement data may be in the form of text data representative of string, which is for example a series of characters, such as a series of letters and/or numbers.

[00390] In examples, the computing node is associated with an entity, such as a user or a collection or users. In such examples, the licence entitlement data may be or include an entity identifier associated with the entity. For example, the licence entitlement data may be a unique identifier that uniquely identifies the entity, such as a unique string.

[00391] The node identifier and the licence entitlement data may be transmitted from the computing node to a further node, such as a licensing server. Such a licensing server may then process the node identifier and the licence entitlement data to determine whether the computing node is entitled to a licence. An example of processing that may be performed by a licensing server in response to receiving a node identifier and licence entitlement data is illustrated in the flow diagram of Figure 49. At item 926 of Figure 49, the node identifier and the licence entitlement data are received. At item 928 of Figure 49, a determination is made as to whether the computing node is entitled to receive a licence. In examples such as Figure 49, this determination is bade based on the node identifier and the licence entitlement data. For example, the licensing server may include storage, such as a licensing database, which includes a record of nodes that are entitled to receive a licence and/or valid licence entitlement data. For example, where the licence entitlement data represents an entity identifier, item 928 of Figure 49 may include querying the licensing database to determine whether the entity identifier is listed as belonging to a trusted entity, which is entitled to receive a licence. This is merely an example, though, and in other examples item 928 may be performed differently. For example, item 928 may instead include determining whether a licence entitlement identifier represented by the licence entitlement datan matches one of a list or table of valid licence entitlement identifiers.

[00392] If it is determined at item 928 that the computing node is entitled to a licence, item 930 of Figure 49 involves generating a licence token. Similarly to the licence entitlement data, the licence token may be any data that can be processed to determine whether the computing node has access to secure data. The licence token may act as a password or electronic key to access the licence, and may be in any suitable format, such as text data representative of a string. Both the licence entitlement data and the licence token may be valid indefinitely or one or both of the licence entitlement data and/or the licence token may be valid for a limited period of time. Outside this period of time, the licence entitlement data and/or the licence token may be considered to be invalid.

[00393] The licence token may include string, which may be a random string or a pseudorandom string. For example, a random string may be retrieved from a module accessible to the licensing server (which may be integral to or separate from the licensing server), such as the hardware security module (HSM) referred to above, which is typically configured to generate random strings. Alternatively, the random string may be generated by the licensing server, for example by hardware of the licensing server such as a field-programmable gate array (FPGA). A size of the random string may depend on the desired security of the DLN. For a typical DLN, the random string may be a 4096 bit random string.

[00394] The licence token may also include other data for use in future validation of the licence token. For example, the licence token may include licence expiry data representative of an expiry time of the licence token. The expiry time may represent both a point in time, as measured in hours and minutes for example, and a date at which the licence token expires, but may instead include merely one of a point in time or a date, for example depending on the timescale over which a licence token is intended to remain valid. For example, the licence expiry data may merely represent an expiry date (which in this context is to be considered to correspond to an expiry time) in a system in which it is preconfigured that licence tokens expire at a given point in time on the expiry date corresponding to the licence expiry data.

[00395] In addition to the random string and, optionally, the licence expiry data, the licence token may also or alternatively include the node identifier received by the licensing server. In this way, it may be determined from the licence token itself that the licence token is associated with the computing node corresponding to the node identifier. For example, the licence token may be associated with a particular node identifier such that different node identifiers correspond to different licence tokens. As the node identifier associated with a particular computing node may be regenerated upon restarting the computing node (as described above), this means that the licence token may also be regenerated each time the computing node is restarted, for example to reflect the change in node identifier. A user may wish to avoid the startup process of configuring a computing node with a node identifier and retrieving a new licence token, as this startup process may lead to a delay in accessing the DLN. This may therefore reduce the number of times the user restarts the computing node, which may help to reduce the number of separate blockchains of a blockmatrix, as each blockchain is typically associated with a different node identifier. This may improve the efficiency of processing the blockmatrix, as it is typically more efficient to process a smaller number of longer blockchains of a blockmatrix rather than a larger number of shorter blockchains.

[00396] The licence token may also or alternatively include a checksum, which may be obtained by applying a checksum algorithm to the remainder of the data of the licence token. A checksum is typically a piece of data derived from other data for the purpose of detecting errors in the other data, which may have been introduced during transmission or storage of the other data. Any suitable checksum algorithm may be used. As an example, a one-way cryptographic hashing algorithm such as MD5 or SHA-256 may be used as the checksum algorithm. For example, the random string, expiry data and node identifier may be received as an input to the cryptographic hashing algorithm to generate the checksum as an output.

[00397] The generated licence token may be stored in the licensing database, for example associated with the licence entitlement data or the node identifier (for example in cases in which the licence token does not include the node identifier). In this way, it can be determined by querying the licensing database whether there is a licence token associated with a given node identifier. For example, the licensing database may include a column of node identifiers and a column of licence tokens. A node identifier may be considered to be associated with the licence token that is located in the same row of the licensing database (although this is merely an example and other arrangements may be used in other examples to indicate an association between licence tokens and respective node identifiers).

[00398] At item 932 of Figure 49, the licence token is transmitted to the computing node from which the node identifier and the licence entitlement data were received. In examples, the licence token transmitted may be solely the random string (or other licence identifier) or the transmitted licence token may also include the expiry data and/or other data. For example, the licence token may include the random string, the node identifier, the expiry data and the checksum.

[00399] Figure 49 illustrates an example of actions that may be performed by the licensing server upon a determination at item 928 that the computing node from which the node identifier and the licence entitlement data were received is not entitled to a licence. At item 934 of Figure 49, a message is transmitted to the computing node indicating that the licence is denied. Although not shown in Figure 49, in other examples other actions may be performed instead of or as well as item 934. For example, where the licence entitlement data includes an entity identifier associated with an entity, a message or other communication may be sent to the entity to notify the entity that there was a failed attempt to obtain a licence. Such a communication may be sent via any suitable communication means, for example via an email or telephone call. There may be such a failed attempt in examples in which the DLN has particular resource allocation rules, which may restrict the maximum number of member nodes any one entity can have. In cases such as this, where an entity already has the maximum number of member nodes, an attempt to obtain a licence for an additional computing node to be a member node of the DLN may result in failure. However, in other examples, an attempt to obtain a licence for an additional computing node may result in removing access for one of the existing member nodes associated with the entity (for example by removing the licence token associated with the node identifier corresponding to the existing member node from the record of valid licence tokens). In such examples, removal of access for an existing member node may also result in the sending of a message to the existing member node or to the entity. In yet further examples, a network address associated with the computing node may be blacklisted. Blacklisting of a network address typically prevents a computing node associated with that network address from accessing the DLN, for a limited time period or indefinitely.

[00400] Referring back to Figure 48, at item 936, the licence token, which is to be associated with the node identifier, is received at the computing node. In this example, the licence token includes the random string and the expiry data.

[00401] At item 938 of Figure 48, licence data is derived from the licence token by applying a checksum algorithm to the licence token. The checksum algorithm is for example the same checksum algorithm as is performed on the licensing server. For example, the checksum algorithm may receive the random string, the expiry data and the node identifier (which the computing node already has access to) as inputs to generate the checksum as an output. The checksum for example corresponds to the licence data derived from the licence token.

[00402] As will be appreciated, in other examples in which the licence token received by the computing node includes the checksum, the licence data may be derived from the licence token merely by obtaining the checksum from the licence token, for example from an appropriate field of the licence token (in examples in which the licence token includes a field or data storage area for storage of the checksum). In yet further examples, the licence data derived from the licence token may be different from the checksum. For example, the licence data may be any suitable data to represent the licence token, and may correspond to the licence token itself.

[00403] At item 940 of Figure 48, a request for at least one cryptographic key is transmitted. The request for example includes the licence data and the node identifier. It is to be understood that transmission of the licence data itself (with or without the node identifier) may be considered to correspond to transmission of a request for the at least one cryptographic key, regardless of whether the transmission explicitly indicates that the at least one cryptographic key is being requested. In other examples, rather than transmitting the licence data and the node identifier, the licence data may be transmitted without the node identifier as, for example, the licence data may be sufficient to determine whether the computing node is licensed to participate in the DLN.

[00404] The request of item 940 of Figure 48 is for example received by a licensing server, which may be the same licensing server as that used to generate and issue the licence token or a different licensing server that may nevertheless have access to or a copy of the licensing database. An example of processing that may be performed by the licensing server in response to receiving the request for the at least one cryptographic key from the computing node is illustrated in the flow diagram of Figure 50.

[00405] At item 942 of Figure 50, the request for the at least one cryptographic key is received, at the licensing server, from the computing node. At item 944 of Figure 50, a determination is made as to whether the computing node is entitled to the at least one cryptographic key. The determination of item 944 of Figure 50 may for example include querying the licensing database to determine whether the licence data is included in the licensing database as corresponding to a valid licence. In examples in which the request includes the licence data and the node identifier, the determination of item 944 may further include checking whether the node identifier is also included in the licensing database as belonging to a computing node that is entitled to receive a licence. Furthermore, a cross-check may be performed to check that the licence data is associated with the correct node identifier, and thus with the correct computing node. This can improve security by making it more difficult for a malicious party to satisfy this check, as the malicious party must not only have the licence data but also the correct node identifier associated with the licence data.

[00406] If the computing node is determined to be entitled to the at least one cryptographic key, Figure 50 involves, at item 946, transmitting the at least one cryptographic key and expiry data indicative of an expiry time of the at least one cryptographic key (in examples in which the at least one cryptographic key has a limited validity period). Similarly to the licence expiry data, the expiry time represented by the expiry data for example includes both a point in time, as measured in hours and minutes for example, and a date at which the at least one cryptographic key expires, but may instead include merely one of a point in time or a date, for example depending on the timescale over which the at least one cryptographic key is intended to remain valid. The expiry time of the at least one cryptographic key may be synchronized across member nodes of the DLN.

[00407] If, however, the computing node is determined not to be entitled to the at least one cryptographic key, Figure 50 involves, at item 948, transmitting a message to the computing node indicating that access to the DLN has been denied. As described above with reference to Figure 49, in other examples other actions may be performed instead of or as well as item 948 such as notifying an entity that there was a failed attempt to access the DLN or blacklisting of a network address associated with the computing node.

[00408] Referring back to Figure 48, at item 950, the at least one cryptographic key for data transmitted in the DLN is received at the computing node. The at least one cryptographic key for example includes a decryption key for decrypting encrypted data of the DLN. The decryption key is for example a secret key (sometimes referred to as a private key), such as the secret key described above with reference to Figure 25. It is to be appreciated, though, that while the decryption key may be referred to as a secret key or a private key (as it may perform the function of a private key in asymmetric cryptography), the decryption key may not strictly be secret or private as the same decryption key may be provided to each of the member nodes of the DLN, so that each of the member nodes can decrypt the encrypted data of the DLN. Nevertheless, the decryption key may be kept secret from users outside the DLN, who are not entitled to access the DLN, to prevent those users from decrypting the encrypted data of the DLN. Therefore, by supplying the decryption key solely to those users who have been determined to be entitled to licence entitlement data and entitled to a licence token, decryption of the encrypted data of the DLN may be restricted solely to trusted users (who do have such an entitlement to the licence entitlement data and licence token). This may improve the security of the encrypted data of the DLN.

[00409] For example, the encrypted data may be undecryptable using the licence token. In such cases, the encrypted data may not be decrypted until the at least one cryptographic key is received, thereby enforcing a multi-factor authentication process. For example, in such cases, the at least one cryptographic key must additionally be requested even after the licence token is received by a computing node for the computing node to decrypt the encrypted data. This may improve the security of the encrypted data.

[00410] The at least one cryptographic key may also or instead include an encryption key, which may be a public key. A computing node that receives the encryption key can therefore encrypt data for storage on the DLN, allowing the computing node to participate as a member node of the DLN. Typically, item 950 of Figure 950 involves receiving both the decryption key and the encryption key, so the computing node can both decrypt encrypted data of the DLN and encrypt data for storage on the DLN, as a member node of the DLN.

[00411] Methods in accordance with Figure 48 may be performed upon initializing a computing node. Alternatively, methods in accordance with Figure 48 may be performed when a new node identifier is configured for a computing node, which may be periodically or upon initialization of the computing node. Furthermore, parts of the method of Figure 48 may be performed at other times. For example, the request for the at least one cryptographic key may be performed periodically, or each time the at least one cryptographic key expires (which may be at regular or irregular time intervals). In such cases, methods such as that of Figure 51 may be used to obtain a further at least one cryptographic key after the expiry of a previously- received at least one cryptographic key. By using cryptographic keys that expire after a limited time period, the maximum length of time a malicious user can decrypt the data of the DLN (for example if the malicious user somehow manages to obtain the at least one cryptographic key) can also be restricted. This may further improve the security of the data of the DLN. For example, the at least one cryptographic key may expire every 24 hours (although other expiry times are possible).

[00412] At item 952 of Figure 51, a determination is made that the at least one cryptographic key has expired. For example, the expiry time represented by the expiry data may be compared against a current time to assess whether the current time is after the expiry time. Alternatively, it may be inferred that the at least one cryptographic key has expired by determining that the at least one cryptographic key has failed to decrypt the encrypted data.

[00413] At item 954 of Figure 51, subsequently to item 952, the licence data is transmitted from the computing node. For example the licence data may be transmitted to the licensing server and checked against the records of the licensing server as described with reference to Figure 50 to determine that the computing node is entitled to participate in the DLN.

[00414] At item 956 of Figure 51 , at least one further cryptographic key for the data transmitted in the DLN is received at the computing node. The at least one further cryptographic key may be received with further expiry data indicative of an expiry time of the at least one further cryptographic key.

[00415] Methods in accordance with Figures 48 to 51 for example provide multi-factor authentication of a computing node. For example, each computing node must be identified as being entitled to receive a licence token before receiving the licence token. Subsequently, the licence token may be validated to determine whether the licence is valid. If so, at least one cryptographic key is issued to the computing node, which for example allows the computing node to decrypt data of the DLN or to encrypt data for storage on the DLN. In this way, the computing node can act as a member node of the DLN.

[00416] Methods in accordance with Figures 48 to 51 are typically more secure than single- factor authentication methods, as any malicious party wishing to gain access to the DLN must spoof or otherwise simulate a number of different elements (in this case, the node identifier, the licence entitlement token and the licence token). This may reduce the possibility of a malicious party accessing a DLN that is intended to be inaccessible to the malicious party. This can reduce the chance of the malicious party accessing private data of the DLN and reduce the chance of such a malicious party overwhelming the DLN, for example by adding an excessive amount of meaningless data to the DLN

[00417] Moreover, as the DLN includes encrypted data that may only be decrypted using the at least one cryptographic key, which is generally issued solely to member nodes of the DLN, the data may be transmitted in the DLN more securely. For example, even if a malicious party accesses the encrypted data, the malicious party will be unable to decrypt the encrypted data as the malicious party generally won't have the at least one cryptographic key.

[00418] Figure 52 is a flow diagram illustrating a method of transmitting data according to examples, which involves the use of an encryption key such as that which may be received at item 950 of Figure 48. It is to be understood, though, that methods similar to that of Figure 52 may not include the use of such an encryption key. For example, the outbound data described below may be transmitted without first being encrypted, in examples in which the security requirements of the DLN are relatively relaxed or where the outbound data is not considered to be particularly sensitive.

[00419] At item 958 of Figure 52,a block to be added to a blockchain of the DLN is generated at a computing node. In examples such as this, the computing node has typically been configured with a node identifier, for example as described above with reference to Figure 48. The computing node has for example received a licence token associated with the node identifier, for example as described with reference to Figure 48. The computing node may also have received at least one cryptographic key in some examples.

[00420] At item 960 of Figure 52, node validation data is generated based on the block and the licence token. Generation of the node validation data based on the block and the licence token may involve using some or all of the block and/or the licence token. For example, a BlockHash of a block may be received as an input to the node validation data generation process rather than all the data fields of a block (such as the Blocklndex, Vectorlndex, TimeStamp, PreviousHash, BlockData and BlockHash, as described above). Similarly, a checksum of the licence token may be receive as an input to the node validation data generation process rather than all the data fields of a licence token (such as a random string, licence expiry data, a node identifier and the checksum).

[00421] The generation of the node validation data may include combining data derived from the block and licence data derived from the licence token to allow both the block itself and the licence token to be validated. For example, a hashing algorithm may be applied to data derived from the block and licence data derived from the licence token. The hashing algorithm may for example be a keyed-hash message authentication code (HMAC) algorithm, which is non- deterministic with respect to first input data. For example, the data derived from the block may be input to the HMAC algorithm as the first input data and the licence data may be input to the HMAC algorithm as second input data. The licence data may therefore be used as a salt of the HMAC algorithm, to securely generate the node validation data, which is representative of a random string.

[00422] The node validation data may be used subsequently by other member nodes of the DLN upon receipt of data (such as encrypted outbound data as described further below) generated by the computing node. For example, upon receipt of the encrypted outbound data, an other member node of the DLN may transmit a validation request to determine whether the encrypted outbound data received has originated from a member node of the DLN, for example with a valid licence token. In other words, the other member node may transmit the validation request to determine whether the computing node that generated the encrypted outbound data is a member node of the DLN. To facilitate this validation process, the data derived from the block and the licence data may be transmitted to a licensing server for storage. At least one of the data derived from the block and the licence data may subsequently be retrieved from the licensing server upon receipt of a validation request at the licensing server, as described further with reference to Figure 54. In other examples, though, the node validation data may be transmitted to the licensing server instead of or as well as the data derived from the block and the licence data. Figure 53 illustrates an example of transmitting a validation request, for example to a licensing server.

[00423] At item 962 of Figure 53, a validation request is transmitted, for example from the other member node upon receipt of the encrypted outbound data from the computing node. The encrypted outbound data for example includes the block and the node validation data, thus allowing the computing node which generated the encrypted outbound data to be validated. The validation request typically includes sufficient data to validate the block, for example to check that the block has been generated by a member node of the DLN, which has a valid licence token. The validation request in Figure 53 includes the data derived from the block, the node identifier identifying the computing node which generated the block and the node validation data. Where the data derived from the block is a BlockHash of the block, the BlockHash may be obtained by reading the BlockHash field or entry of the block or by applying a hashing algorithm to the other components of the block. The node identifier identifying the computing node may for example also be received as part of the encrypted outbound data, allowing the computing node from which the encrypted outbound data originated to be identifier. Alternatively, the node identifier may be determined from the block based on the Vectorlndex of a blockchain including the block (as the Vectorlndex of the blockchain may correspond with the node identifier of the computing node which generated the block).

[00424] The validation request is for example transmitted to a licensing server, which may be the same licensing server as that used to generate and issue the licence token or a different licensing server that may nevertheless have access to or a copy of the licensing database. An example of processing that may be performed by the licensing server in response to receiving the validation request from the computing node is illustrated in the flow diagram of Figure 54. [00425] At item 964 of Figure 54, the validation request is received from the other computing node upon receipt of the encrypted outbound data from the computing node. The processing of Figure 54 may be considered to correspond to a method of validating an origin of a block generated by a computing node, such as the block generated in accordance with Figure 52. Similarly to Figure 53, in Figure 54 the validation request includes data derived from the block for which the origin is to be validated, a node identifier for identifying the computing node that generated the block and node validation data for validating that the computing node is a member node of the DLN.

[00426] Item 966 of Figure 54 includes retrieving a stored licence token from storage. For example, the stored licence token may be retrieved from the licensing database on the basis of the node identifier received as part of the validation request. For example, the stored licence token may be retrieved by querying the licensing database to obtain the licence token stored in the licensing database which is associated with the node identifier.

[00427] At item 968 of Figure 54, retrieved licence data is derived from the stored licence token by applying a checksum algorithm to the licence token. For example, the checksum algorithm may be the same checksum algorithm used to generate the checksum of licence tokens generated by the licensing server, in order to regenerate the checksum associated with the licence token. In such cases, the retrieved licence data may correspond with a checksum associated with the licence token.

[00428] Items 966 and 968 of Figure 54 may be considered to correspond to obtaining, on the basis of the node identifier, retrieved licence data based on a stored licence token. However, in other examples, the retrieved licence data may be obtained differently than as shown in items 966 and 968. For example, it may be possible to retrieve the checksum of the licence token associated with node identifier, rather than retrieving other elements of licence data (such as the random string, licence expiry data and/or node identifier, as described above) and regenerating the checksum.

[00429] At item 970 of Figure 54, the data derived from the block and the retrieved licence data are processed to produce regenerated node validation data. For example, the processing of item 970 may be the same processing that is used to generate the node validation data received at the licensing server at item 964. For example, the processing at item 970 may include applying a hashing algorithm to the data derived from the block and the retrieved licence data. As described above with reference to Figure 52, the hashing algorithm may be a keyed-hash message authentication code (HMAC) algorithm, for example with the retrieved licence data as the salt.

[00430] At item 972 of Figure 54, the received node validation data is checked with respect to the regenerated node validation data to validate the origin of the block. At item 974 of Figure 54, it is determined whether the origin of the block has been validated. This for example corresponds to determining whether the block has originated from a member node of the DLN which is permitted to access or interact with the DLN, for example by virtue of having a valid licence token. A block may be considered to originate from a computing node for example where that block is generated by that computing node or where that block is transmitted to other nodes, such as member nodes of the DLN, by that computing node.

[00431] If it is determined that the origin of the block has been successfully validated, the method of Figure 54 includes, at item 976, updating a record of blocks of the blockchain of the DLN to include a block index indicative of a position of the block within the blockchain. This may be used subsequently to improve the efficiency of validating blockchains, as will be described further with reference to Figure 55. In some cases, though, item 976 may be omitted, for example where the block is generated by a computing node which does not yet include a blockchain, such as where the block is to be the first block of a new blockchain or where the block has been received at the computing node from another computing node.

[00432] At item 978 of Figure 54, a validation indication indicative that the origin of the block has been validated is transmitted to the other computing node. The validation indication may therefore indicate that the computing node which generated the block is a valid member node of the DLN.

[00433] However, in some cases, the determination at item 974 of Figure 54 may identify that the origin of the block has not been validated. This may for example indicate that the block has not originated from a member node of the DLN, which is for example a computing node of the DLN with a valid licence token. In such cases, the process of Figure 54 includes, at item 980, transmitting a validation indication indicating that the origin of the block has not been validated. This may correspond to indicating that the computing node from which the block originated is not a valid member node of the DLN.

[00434] Referring back to Figure 53, at item 964 of Figure 53 a validation indication is received at the other computing node, which is indicative of whether the computing node is a member node of the DLN. In response to receiving the validation indication, the other computing node may perform various actions as described further with reference to Figure 56. For example, if the validation indication indicates that a block or a blockchain including the block originates from a computing node which is a member node of the DLN, the received block may be added to a blockchain of the DLN or the received blockchain may be added to a blockmatrix of the DLN. In this way, data may not be added to the blockchain or blockmatrix unless it has been identified as having been generated by a member node of the DLN, for example with a valid licence token. This may reduce the chance of malicious parties adding unwanted data to the blockchain, which can improve the efficiency of the DLN. The updated blockchain or blockmatrix may then be broadcast to other member nodes of the DLN. Conversely, if the validation indication indicates that the block or blockchain originates from a computing note which is not a member node of the DLN, the block or blockchain may be discarded and/or a network address associated with the computing node may be blacklisted.

[00435] Referring now to Figure 52, at item 984 of Figure 52, outbound data is generated at the computing node. The outbound data is for example data to be included within a blockchain of the DLN and for example includes the block and the node validation data and may also include the node identifier (although this is not necessary, as the node identifier may be derived from the block itself, based on the Vectorlndex, which typically corresponds to the node identifier).

[00436] At item 986 of Figure 52, the outbound data is encrypted at the computing node, using an encryption key, to generate encrypted outbound data. The encryption key is for example received as part of the at least one cryptographic key that is received by the computing node in response to a determination that the computing node has a valid licence token and is thus permitted to be a member node of the DLN. By encrypting the outbound data using the encryption data, the encrypted data may be decrypted straightforwardly by other member nodes of the DLN, which typically include the decryption key for decrypting the encrypted outbound data, which is for example also received as part of the at least one cryptographic key.

[00437] At item 988 of Figure 52, the encrypted outbound data is transmitted, for example for receipt by at least one other member node of the DLN (such as the other member node of the DLN referred to with reference to Figure 53). The at least one other member node can then decrypt the encrypted outbound data. However, if other computing nodes intercept the encrypted outbound data, these computing nodes will typically be unable to decrypt the encrypted outbound data as they generally will not include the correct decryption key. The encrypted outbound data may therefore be transmitted between member nodes of the DLN securely.

[00438] For example, the encrypted outbound data may be transmitted by multicasting the encrypted outbound data to the at least one other member node. For example, the encrypted data may be transmitted using the User Datagram Protocol (UDP). This may therefore reduce the network overhead compared to transmission of data within other DLN networks, in which significant overhead may be incurred in setting up and maintaining peer-to-peer connections. Furthermore, this may reduce the risk of denial of service attacks on member nodes of the DLN, which are inherent in peer-to-peer connections to the nature of the underlying TCP communication protocol used for such connections.

[00439] In general, the encrypted outbound data generated by the computing node may be transmitted to other member nodes of the DLN without validating the origin of the encrypted outbound data. The encrypted outbound data may therefore be transmitted from the computing node without waiting for a validation response from the licensing server, improving the efficiency of data transmission within the DLN. Instead, the other member nodes may validate the origin of received data upon receipt of the data, for example as described with reference to Figures 53 and 54.

[00440] Turning to Figure 55, Figure 55 is a flow diagram illustrating a method of validating the origin of data according to further examples. In Figure 55, the data to be validated is a blockchain. A blockchain may be validated for example by individually validating each of the blocks of the blockchain, for example using a similar method to that described with reference to Figure 54. However, this may be relatively slow. It may therefore be more efficient to perform the process of Figure 55.

[00441] At item 992 of Figure 55, a blockchain validation request is received. The blockchain validation request for example includes a last block index indicative of a position of a last block of the blockchain. The last block is for example the block of the blockchain that was added most recently and that for example has the largest block index (assuming that the block index for blocks of the blockchain is incremented sequentially as new blocks are added to the blockchain). For example, the last block index may correspond to the number of blocks of the blockchain minus 1 (where the blocks of the blockchain receive an index from 0 upwards, with the first block having an index of 0, the second block having an index of 1 and the nth block having an index of n-1). The blockchain validation request is for example received by a licensing server, which may be the same licensing server as that used to generate and issue the licence token or a different licensing server that may nevertheless have access to or a copy of the licensing database.

[00442] At item 994 of Figure 55, the block index for the last published block of the blockchain is retrieved from the licensing server, for example from the licensing database or other storage accessible to the licensing server. This block index may for example be retrieved from the record of blocks of the blockchain, which may be updated as described at item 976 of Figure 54. For example, the record of blocks may include a list, table or other record of the blocks of the blockchain, which indicates a time at which the blocks were added to the blockchain and from which the block index of the last (or most recently added) block can be retrieved. Alternatively, this record may simply include the block index for the last block of the blockchain, without including details of other blocks of the blockchain. For example, this record may be simply incremented to correspond to the block index for the last block as new blocks are added to the blockchain.

[00443] At item 996 of Figure 55, the block index retrieved from the storage of the licensing server is compared with the last block index received as part of the blockchain validation request. In other words, the process of Figure 55 for example includes validating the blockchain by processing a record of blocks of the blockchain to determine that the last block index is less than or equal to the block index indicative of the most recently added block of the blockchain (for example as updated at, and retrieved from, the licensing server using the method of Figure 54). If it is determined that the last block index is less than or equal to the retrieved block index, it can be ascertained that the block has been generated by a computing node which is a member node of the DLN. This is for example because blocks generated by a member node will be generated with sequential indices (which may be referred to as sequence numbers) for a given blockchain. However, as in examples solely one member node may be a source for blocks of a blockchain, a blockchain received at a computing node from a particular member node should have a size which does not exceed the stored size of the blockchain for that computing node (which is for example updated at the licensing server each time a new block is added to that blockchain and broadcast to other member nodes of the computing node, i.e. before the blockchain is received at the computing node and before the blockchain validation request can be transmitted to the licensing server from the computing node). Conversely, if a blockchain that is purportedly from a particular member node has a size which is larger than the size of the blockchain as reported by that member node (for example using the method of Figure 54 to update the record of blocks of the blockchain as new blocks are added), this indicates that blockchain may not actually be from that member node and may instead originate from an insecure node, for example associated with a malicious party.

[00444] Thus, at item 998 of Figure 55, if it is determined that the last block index is less than or equal to the retrieved block index, a validation indication is transmitted to the computing node indicating that the blockchain has been generated by a member node of the DLN, which for example includes a valid licence token. Conversely, at item 1000 of Figure 55, if it is determined that the last block index is greater than the retrieved block index, a validation indication is transmitted to the computing node to indicate that the blockchain has been generated by a computing node which is not a member node of the DLN, for example which does not have a valid licence token.

[00445] Figure 56 is a flow diagram illustrating a method illustrating example responses to the transmission of a validation request. Methods in accordance with Figure 56 may be used to validate an origin of a block generated by a computing node, for storage of the block within a DLN.

[00446] At item 1002 of Figure 56, a first member node of the DLN receives: data derived from the block to be validated, a node identifier for identifying the computing node that generated the block, and node validation data for validating that the computing node is a member node of the DLN. The node validation data may be generated for example as described above with respect to Figure 52.

[00447] At item 1004 of Figure 56, a validation request is transmitted from the first member node. The validation request includes the data derived from the block, the node identifier and the node validation data.

[00448] At item 1006 of Figure 56, it is determined whether the origin of the block is valid, for example using the method of Figure 54. Based on this, a validation indication indicative of whether the origin of the block is valid may be received at the first member node.

[00449] If the block is determined to originate from a valid origin, in other words, if it is determined that the computing node that generated the block is a member node of the DLN, the method of Figure 56 involves, at item 1008, adding the block to a blockchain of the DLN. If, for example, the block is part of a blockchain that is newly received at the first member node, the blockchain may be added to a blockmatrix of the DLN. [00450] If, however, the validation indication indicates that the origin of the block is invalid, the method of Figure 56 includes, at item 1010, and in response to receiving the validation indication, at least one of: discarding the block or blacklisting a network address associated with the computing node that generated the block. This may therefore prevent data originating from sources that are not licensed or permitted to access the DLN from writing data to the blockchain.

[00451] It is to be appreciated that a method similar to that of Figure 56 may be performed upon receipt of either a new block or a new blockchain at the first member node. For example, receiving the data derived from the block may include receiving a blockchain including the data derived from the block. In such cases, methods similar to Figure 56 may include transmitting, from the first member node, a respective validation request for each of a plurality of blocks of the blockchain. Each of the validation requests may be similar to the validation requests described with reference to Figure 53 and 54. In examples such as this, a first validation indication for a first block of the plurality of blocks may be received at the first member node. If the first validation indication indicates that the origin of the first block is invalid, at least one of: the blockchain may be discarded or the network address associated with the computing node may be blacklisted. In other words, as soon as a first validation indication indicative that an origin of one of the blocks of the blockchain is invalid, the validation process may cease and the actions of item 1010 of Figure 56 may instead be performed. For example, a validation request may be transmitted initially for a first or genesis block of the blockchain (such as the block with index 0) and if it is determined that the first block is not of a valid origin, the entire blockchain may be discarded without checking subsequent blocks of the blockchain. In other examples in which a new blockchain is received at the first member node, the validity of the origin of the blockchain may be checked using a process similar to that of Figure 54, in which the last block index of the blockchain is checked rather than checking individual blocks of the blockchain.

[00452] Figure 57 shows schematically an example of internal components of a licensing server 1012 according to examples. The licensing server 1012 may for example be integrated with other computing nodes, such as a control node. Alternatively, the licensing server 1012 may be a separate node.

[00453] The licensing server 1012 includes a licence issuance module 1014 for example for issuing licence tokens. For example, the licence issuance module 1014 may be configured to perform the method of Figure 49. The licensing server 1012 also includes storage 1016, which may for example include a licensing database or other storage for storing records relating to licensing data. The licensing server 1012 includes a node startup module 1018. The node startup module 1018 for example communicates with each computing node upon initialization, if the computing node attempts to be included as a member node of the DLN. The node startup module 1018 for example receives and handles requests for the at least one cryptographic key, as described with reference to Figure 50. Such requests may be received upon initialization of a computing node or if the at least one cryptographic key of a computing node has expired.

[00454] A data validation module 1020 of the licensing server 1012 for example interacts with or controls a block validation module 1022 for validating the origin of blocks and a blockchain validation module 1024 for validating the origin of blockchains. The data validation module 1020 may therefore be used to determine whether blocks or blockchains have originated from a member node of the DLN, with a valid licence token. For example, the data validation module 1020 may perform the methods of Figures 54 and 55.

[00455] As will be appreciated, the licensing server 1012 illustrated in Figure 57 has been simplified for ease of explanation. The licensing server 1012 may include other components or modules that are not illustrated. For example, the licensing server 1012 may include at least one processor and at least one memory and a bus for interconnecting components of the licensing server 1012. Furthermore, the licensing server 1012 may include a communications module for communicating with other nodes such as the computing node referred to herein with reference to Figures 48 to 56 or to member nodes of the DLN.

[00456] Figure 58 shows schematically an example of internal components of a licensing module 1026 according to examples. A licensing module such as the licensing module 1026 of Figure 58 may for example be included in a computing node, such as a member node of a DLN, which may be similar to or the same as the member node 312 of Figure 17.

[00457] The licensing module 1026 includes a node startup module 1028, which for example handles actions that may be performed upon initialization of the computing node. For example, the node startup module 1028 may be used to retrieve a licence token (if the computing node does not already include a valid licence token) and/or to retrieve the at least one cryptographic key pair. For example, the node startup module 1028 may be used to implement the method of Figure 48. [00458] The licensing module 1026 also includes a packet signer module 1030 to sign outbound data, such as a block to be added to a blockchain or a blockchain to be added to a blockmatrix of the DLN, using the licence data. For example, the packet signer module 1030 may be used to generate the node validation data and to broadcast outbound data with the node validation data. This allows other member nodes of the DLN to validate that the outbound data has been generated by a member node of the DLN, which has a valid licence token. For example, the packet signer module 1030 may be integrated with a UDP broadcaster of the computing node in examples in which the outbound data is multicast or broadcast using the UDP.

[00459] The licensing module 1026 includes a packet signature validation module 1032, which may be used to verify that data (which may be in the form of packets of data and may represent blocks of a blockchain or blockchains of a blockmatrix) received by the computing node has originated from a valid member node of the DLN. The packet signature validation module 1032 may interact with the data validation module 1020 of the licensing server 1012 to validate the received data.

[00460] A licence renewal module 1034 of the licensing module 1026 is for example configured to renew keypairs that have expired. For example, the licence renewal module 1034 may be configured to request a further at least one cryptographic key pair as described with reference to Figure 51.

[00461] In examples in which the computing node comprising the licensing module 1026 includes a UDP broadcaster module and a UDP receiver module, a decryption key may be loaded into the UDP receiver module for decrypting received encrypted data. Similarly, an encryption key may be loaded into the UDP broadcaster module to encrypt outbound data.

[00462] Yet further examples relate to systems and apparatus for implementing the methods described herein. For example, as described above, a computing system for implementing the methods described herein may include storage configured to store any of the data described above and at least one processor communicatively coupled to the storage. Such a computing system may for example include appropriate instructions, stored in the storage, which, when processed by the at least one processor, implement the methods described herein. The computing system may include one computing device or multiple computing devices such as a distributed series or network of computing devices, such as a DLN. For example, the computing system may include one or more of a control node, a client node or a member node of a DLN, as described herein.

[00463] References herein to identifying a block of a DLN are to be understood as also encompassing identification of a transaction of a block of a DLN. In other words, if a transaction of a block of a DLN is identified, the block of the DLN in which the transaction is stored is also to be understood as identified (by virtue of identifying the transaction). For example, methods herein may include receiving or transmitting transaction identifiers such as transaction IDs. Receipt or transmittal of such a transaction ID is to be considered to correspond to or be analogous to receipt or transmittal of an identifier identifying a block within which the transaction is stored.

[00464] As an illustrative example, examples described herein involve a first data storage transaction identifier identifying a block, within the first DLN, in which first data has been stored. However, as a block may include a plurality of different transactions, the first data storage transaction identifier may identify a transaction of a block in which the first data has been stored (for example, as metadata). In such cases, the first data storage transaction identifier may be a transaction ID of a transaction in which the first data has been stored, as part of a block of a DLN (rather than a block ID of a block storing the transaction in which the first data has been stored). Similarly, the verification data storage transaction identifier may be a transaction ID of a transaction in which the verification data has been stored (which itself may be stored in a block of a DLN). Furthermore, each of the plurality of network verification data storage transaction identifiers may correspond to a transaction ID of a respective transaction in which the verification data has been stored (which may each be stored in a respective block within a corresponding DLN). In each of these cases (and other examples herein involving an identifier for identifying a block within a DLN in which particular data has been stored), the identifier corresponding to a transaction ID may be taken as identifying a block within a DLN within which data of the transaction corresponding to the transaction ID is stored.

[00465] In examples described above, a determination may be made as to whether a computing node is entitled to at least one cryptographic key, for example based on licence data transmitted to a licensing server from the computing node. It is to be appreciated that, in general, the validity of a licence token from which the licence data is derived may be checked as required or as desired by a user. For example, the licence data may be transmitted to the licensing server. The licensing server may subsequently query the licensing database to check whether the licence data is listed as being associated with a valid licence or whether licence expiry data associated with the licence data (either transmitted to the licensing server with the licence data or retrieved from the licensing database based on the licence data) indicates that the licence is currently valid (or has expired). A message or other response may subsequently be transmitted to the computing node to indicate whether the licence token is valid or not.

[00466] Further examples are given in the later clauses section.

[00467] It is to be understood that any feature described in relation to any one example may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the examples, or any combination of any other of the examples. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the accompanying claims.

CLAUSES

Al. A method for synchronizing data within a distributed ledger network comprising a plurality of member nodes connected via a data communications system, the method comprising, at a first member node:

storing first storage data representing blocks of a first blockchain and second storage data representing blocks of at least a second blockchain;

extending the first blockchain in response to at least one block being created at said first member node,

adding data representing said at least one block to said first storage data;

transmitting outbound synchronization data to at least one other member node of the distributed ledger network, the outbound synchronization data comprising data representative of said at least one block;

receiving inbound synchronization data from a second member node of the distributed ledger network, the inbound synchronization data comprising data representative of one or more blocks of the second blockchain; and

adding the data representing said one or more blocks of the second blockchain to the second storage data.

A2. The method according to clause Al, comprising transmitting at least a given type of outbound synchronization data, transmissions of the given type of outbound synchronization data being separated by respective time intervals, wherein during a time interval between one, and the next transmission of the given type of outbound synchronization data, a plurality of blocks of said first blockchain are created, and wherein said next transmission comprises data representing said plurality of blocks.

A3. The method according to clause A2, wherein extending the first blockchain comprises adding a continuous sequence of blocks to the first blockchain during said time interval in response to receiving a plurality of data records to be added to the distributed ledger network. A4. The method according to any one of clauses Al to A3, wherein:

the outbound synchronization data includes a first type of outbound synchronization data; and

the method comprises transmitting the first type of outbound synchronization data in response to the at least one block being created at said first member node. A5. The method according to any one of clauses Al to A4, wherein:

the outbound synchronization data includes a second type of outbound synchronization data, the second type of outbound synchronization data comprising the first storage data and the second storage data; and

the method comprises:

detecting a synchronization trigger event; and

in response to detecting the synchronization event, transmitting the second type of outbound synchronization data.

A6. The method according to clause A5, wherein the synchronization trigger event is asynchronous with respect to creation of blocks at the first member node.

A7. The method according to any one of clauses Al to A6, wherein:

the inbound synchronization data includes a first type of inbound synchronization data; and

the method comprises receiving the first type of inbound synchronization data at irregular intervals.

A8. The method according to any one of clauses Al to A7, wherein:

before receiving the inbound synchronization data, the first member node comprises a first version of the second storage data representing blocks of a first version of the second blockchain; and

the inbound synchronization data includes a second type of inbound synchronization data comprising a second version of the second storage data representing blocks of a second version of the second blockchain.

A9. The method according to clause A8, comprising receiving the second type of inbound synchronization data from the second member node at regular intervals.

A10. The method according to any one of clauses Al to A9, wherein transmitting the outbound synchronization data to the at least one other member node comprises multicasting the outbound synchronization data to a plurality of member nodes of the distributed ledger network.

Al l. The method according to any one of clauses Al to A10, wherein transmitting the outbound synchronization data to the at least one other member node comprises transmitting the outbound synchronization data using the User Datagram Protocol (UDP). A12. The method according to any one of clauses Al to Al l, comprising compressing the outbound synchronization data before transmitting the outbound synchronization data to the at least one other member node.

A13. The method according to any one of clauses Al to A12, comprising, before extending the first blockchain, determining that the at least one block created at said first member node satisfies at least one block validity condition.

A14. The method according to any one of clauses Al to A13, comprising, before extending the first blockchain, determining that the first blockchain satisfies at least one blockchain validity condition.

A15. The method according to any one of clauses Al to A14, wherein:

before receiving the inbound synchronization data, the first member node comprises a first version of the second storage data representing blocks of a first version of the second blockchain;

the inbound synchronization data is representative of blocks of a second version of the second blockchain; and

the method comprises:

determining that the second version of the second blockchain is longer than the first version of the second blockchain; and

updating the first version of the second blockchain based on the inbound synchronization data such that the second storage data is representative of the second version of the second blockchain.

A16. The method according to any one of clauses Al to A15, comprising, at the first member node:

processing the first storage data and the second storage data to generate hash data representative of a hash based on a first block of the first blockchain and a second block of the second blockchain.

A17. The method according to clause A16, wherein storing, at the first member node, the first storage data, and storing, at the first member node, the second storage data, comprises storing the first storage data, the second storage data and the hash data as part of a multidimensional data structure.

A18. The method according to clause A17, wherein: the multidimensional data structure comprises a plurality of columns, a plurality of rows and a plurality of layers;

the first storage data includes a first column of the plurality of columns, which is to be found in a first layer of the plurality of layers and in a first number of rows of the plurality of rows corresponding to a number of blocks of the first blockchain; and

the second storage data includes at least a second column of the plurality of columns, which is to be found in the first layer of the plurality of layers and in a second number of rows of the plurality of rows corresponding to a number of blocks of the second blockchain.

A19. The method according to clause A18, wherein the hash data is stored in a second layer of the plurality of layers different from the first layer.

A20. The method according to any one of clauses A16 to A19, comprising:

receiving a request to verify data on the first member node; and, in response, processing the hash data to check whether the hash satisfies at least one hash validity condition.

A21. The method according to clause A20, comprising, in response to receiving the request: processing the first storage data to check whether the first blockchain satisfies at least one blockchain validity condition; and

processing the second storage data to check whether the second blockchain satisfies the at least one blockchain validity condition.

A22. A method of adding data to a first member node of a distributed ledger network, the first member node comprising storage data representing blocks of a plurality of blockchains, the method comprising:

creating a first block at the first member node;

receiving a first node identifier associated with the first member node;

selecting a first blockchain from the plurality of blockchains based on the first node identifier; and

extending the first blockchain by storing the first block as part of the first blockchain. A23. The method according to clause A22, comprising:

generating the first node identifier upon initialization of the first member node; and, subsequently,

allocating the first node identifier to the first member node. A24. The method according to clause A23, wherein the generating the first node identifier comprises generating the first node identifier based on a time associated with initializing the first member node.

A25. The method according to clause A24, wherein the time is measured using an atomic clock.

A26. The method according to any one of clauses A22 to A25, wherein the first member node is the sole source of all blocks in the first blockchain.

A27. A first member node for a distributed ledger network, wherein the first member node comprises:

storage configured to store:

first storage data representing a first blockchain, the first blockchain comprising a first continuous sequence of blocks, the first continuous sequence of blocks created at the first member node; and

second storage data representing at least a second blockchain, the second blockchain comprising a second continuous sequence of blocks, the second continuous sequence of blocks created at a second member node of the distributed ledger network; and

at least one processor communicatively coupled to the storage.

A28. The first member node according to clause A27, wherein:

the first continuous sequence of blocks comprises:

a first block created at a first time; and

a subsequent block created at a subsequent time, the subsequent block positioned immediately subsequent to the first block in the first continuous sequence of blocks; and

the second continuous sequence of blocks comprises;

a second block created at a second time between the first time and the subsequent time.

A29. The first member node according to clause A27 or clause A28, wherein the storage is configured to store hash data representing a hash value cross-linking a first block of the first blockchain with a second block of the second blockchain. A30. The first member node according to clause A29, wherein the first block is stored at a first position in the first blockchain and the second block is stored at the first position in the second blockchain.

A31. The first member node according to clause A30, wherein:

the hash value is a first hash value representative of a first hash between the first block and the second block; and

the storage is configured to store a set of hash data representative of a set of hash values comprising the first hash value and a second hash value representative of a second hash based on the first hash, a third block of the first blockchain stored at a second position in the first blockchain and a fourth block of the second blockchain stored at the second position in the second blockchain.

A32. The first member node according to clause A30 or clause A31, wherein:

the storage is configured to store:

third storage data representing a third continuous sequence of blocks of a third blockchain, the third continuous sequence of blocks created at a third member node of the distributed ledger network; and

fourth hash data representative of a fourth hash value representative of a fourth hash between the first hash and a third hash between the second block of the second blockchain and a fifth block of the third blockchain with the first index.

A33. The first member node according to any one of clauses A29 to A32, wherein the storage is configured to store a data structure comprising the first storage data, the second storage data and a set of hash data comprising the hash data.

A34. The first member node according to clause A33, wherein the data structure is a multidimensional data structure.

A35. A method of storing data comprising:

storing a first blockchain, the first blockchain comprising a first set of blocks arranged in sequence;

storing a second blockchain, the second blockchain comprising a second, different, set of blocks arranged in sequence; using a cryptographic algorithm to generate verification data which links at least some data from a block in the first blockchain and at least some data from a block in the second blockchain; and

storing the verification data.

A36. The method according to clause A35, wherein the cryptographic algorithm comprises a hashing algorithm and the verification data comprises a hash of at least some data from the block in the first blockchain and at least some data from the block in the second blockchain. A37. The method according to clause A36, wherein the verification data comprises a hash of at least a hash from the block in the first blockchain and at least a hash from the block in the second blockchain.

A38. The method according to any one of clauses A35 to A37, wherein the method comprises selecting the block in the first blockchain and selecting the block in the second blockchain, wherein selecting the blocks in the first and second blockchains is performed on the basis of the blocks being in the same location in each respective sequence.

A39. The method according to any one of clauses A35 to A38, wherein the method comprises synchronizing the first block chain, the second blockchain and the verification data within a distributed ledger network.

A40. A method of verifying data, comprising:

retrieving at least some data from a block in a first blockchain, the first blockchain comprising a first set of blocks arranged in sequence;

retrieving at least some data from a block in a second blockchain, the second blockchain comprising a second, different, set of blocks arranged in sequence;

retrieving verification data which links the block in the first blockchain and the block in the second blockchain;

performing a cryptographic verification algorithm with the at least some data from the block in the first blockchain, and the at least some data from the block in the second blockchain, as inputs to the cryptographic verification algorithm;

comparing the output of the cryptographic verification algorithm with the verification data in order to verify at least one of the block in the first blockchain and the block in the second blockchain.

A41. The method according to clause A40, wherein performing the cryptographic verification algorithm comprises performing a hashing algorithm with the at least some data from the block in the first blockchain, and the at least some data from the block in the second blockchain, as inputs to the hashing algorithm.

A42. The method according to clause A41, wherein performing the cryptographic verification algorithm comprises performing a hashing algorithm with at least a hash from the block in the first blockchain, and at least a hash from the block in the second blockchain, as inputs to the hashing algorithm.

A43. The method according to any of clauses A40 to A42, wherein the method comprises selecting the block in the first blockchain and selecting the block in the second blockchain, wherein selecting the blocks in the first and second blockchains is performed on the basis of the blocks being in the same location in each respective sequence.

B 1. A method for storing data, the method comprising:

transmitting a first data storage request, the first data storage request instructing storage of first data in a first distributed ledger network, the first distributed ledger network being a private distributed ledger network;

receiving confirmation that the first data has been stored in the first distributed ledger network;

transmitting a verification data storage request, the verification data storage request instructing storage of verification data in at least one distributed ledger network, different from the first distributed ledger network, the verification data relating to the first data;

receiving confirmation that the verification data has been stored in one or more distributed ledger networks of the at least one distributed ledger network.

B2. The method according to clause B 1, comprising:

receiving a first data storage transaction identifier in response to the first data storage request, the first data storage transaction identifier identifying a block, within the first distributed ledger network, in which the first data has been stored; and

transmitting the first data storage transaction identifier in the verification data storage request.

B3. The method according to clause B l or clause B2, comprising receiving a verification data storage transaction identifier in response to the verification data storage request, the verification data storage transaction identifier identifying a block, within the one or more distributed ledger networks, in which the verification data has been stored. B4. The method according to clause B l or clause B2, comprising receiving a hashed verification data storage identifier in response to the verification data storage request, the hashed verification data storage transaction identifier representing a hash derived from a block identifier identifying a block, within the one or more distributed ledger networks, in which the verification data has been stored.

B5. The method according to any one of clauses B 1 to B4, wherein the first data comprises the verification data.

B6. The method according to any one of clauses B l to B4, wherein the verification data comprises a hash derived from at least a portion of the first data.

B7. The method according to any one of clauses B l to B6, wherein the at least one distributed ledger network comprises a public distributed ledger network.

B8. The method according to any one of clauses B l to B7, comprising transmitting parameter data in the verification data storage request, the parameter data relating to at least one characteristic requested for the storage of the verification data in the at least one distributed ledger network.

B9. The method according to clause B8, wherein the at least one characteristic comprises a level of immutability requested for the storage of the verification data in the at least one distributed ledger network.

B 10. The method according to clause B8 or clause B9, wherein the at least one characteristic comprises a level of delay within which confirmation of the storage of the verification data in the at least one distributed ledger network is requested.

B l l. The method according to any one of clauses B l to B IO, comprising receiving immutability data representative of a calculated level of immutability associated with the storage of the verification data in the one or more distributed ledger networks.

B 12. The method according to any one of clauses B l to B l l, wherein the first distributed ledger network comprises a plurality of client nodes and at least one control node, wherein the method is performed in a client node of the plurality of client nodes of the first distributed ledger network.

B 13. The method according to clause B 12, wherein the verification data storage request is transmitted to a control node of the first distributed ledger network. B 14. The method according to any one of clauses B l to B 13, wherein the verification data storage request comprises a first data storage transaction identifier identifying a block, within the first distributed ledger network, in which the first data has been stored.

B 15. The method according to any one of clauses B l to B 14, wherein the first distributed ledger network comprises fewer nodes than one or more distributed ledger networks of the at least one distributed ledger network.

B 16. A method of processing a request to store verification data in at least one distributed ledger network, the method comprising:

receiving a verification data storage request relating to storage of verification data in at least one distributed ledger network, different from a first distributed ledger network, the verification data relating to first data stored in the first distributed ledger network, the first distributed ledger network being a private distributed ledger network,

wherein the verification data storage request comprises a first data storage transaction identifier identifying a block, within the first distributed ledger network, in which the first data has been stored;

retrieving data from the first distributed ledger network on the basis of the first data storage transaction identifier; and

deriving said verification data from the retrieved data.

B 17. The method according to clause B 16, comprising transmitting the verification data to one or more distributed ledger networks of the at least one distributed ledger network.

B 18. The method according to clause B 17, comprising transmitting the verification data to be stored as metadata associated with at least one of: a block or a transaction of the one or more distributed ledger networks.

B 19. The method according to clause B 18, comprising transmitting the verification data to replace pre-existing metadata associated with the at least one of: the block or the transaction so as to store the verification data as the metadata associated with the at least one of the: block or the transaction, respectively.

B20. The method according to any one of clauses B 16 to B 19, comprising generating immutability data indicative of a calculated level of immutability associated with the storage of the verification data in the one or more distributed ledger networks.

B21. The method according to any one of clauses B 16 to B20, wherein the verification data storage request relates to the storage of the verification data in a plurality of distributed ledger networks, and the method comprises receiving a plurality of network verification data storage identifiers in response to the verification data storage request, each of the plurality of network verification data storage transaction identifiers identifying a respective block, within a corresponding distributed ledger network of the plurality of distributed ledger networks, in which the verification data has been stored.

B22. The method according to clause B21, comprising:

combining the plurality of network verification data storage identifiers to generate a combined verification data storage identifier; and

applying a hashing algorithm to the combined verification data storage identifier to generate a hashed verification data storage identifier.

B23. The method according to clause B21 or clause B22, comprising receiving each of the plurality of network verification data storage identifiers from a respective distributed ledger network of the plurality of distributed ledger networks.

B24. The method according to any one of clauses B 16 to B23, wherein the first distributed ledger network comprises a plurality of client nodes and at least one control node, wherein the method is performed in a control node of the at least one control node of the first distributed ledger network.

B25. The method according to any one of clauses B 16 to B24, wherein the verification data storage request is received from a client node of the plurality of client nodes.

B26. The method according to any one of clauses B 16 to B25, wherein the at least one distributed ledger network comprises a public distributed ledger network.

B27. A method of processing requests to store verification data in at least one distributed ledger network, the method comprising:

receiving a first verification data storage request relating to storage of verification data in at least one distributed ledger network, different from a first distributed ledger network, the first verification data storage request relating to first data stored in the first distributed ledger network, the first distributed ledger network being a private distributed ledger network;

receiving a second verification data storage request relating to storage of verification data in the at least one distributed ledger network, the second verification data storage request relating to second data stored in the first distributed ledger network; using a hashing algorithm to generate said verification data, wherein said hashing algorithm uses both first derived data derived from said first data and second derived data derived from said second data as input data.

B28. The method according to clause B27, comprising:

retrieving the first derived data from the first distributed ledger network;

retrieving the second derived data from the first distributed ledger network;

combining the first derived data and the second derived data into a concatenated data string; and

applying the hashing algorithm to the concatenated data string to generate the verification data.

B29. The method according to clause B27 or clause B28, wherein:

the first verification data storage request comprises a first data storage transaction identifier identifying a first block, within the first distributed ledger network, in which the first data has been stored;

the second verification data storage request comprises a second data storage transaction identifier identifying a second block, within the first distributed ledger network, in which the second data has been stored; and the method comprises:

retrieving the first derived data from the first distributed ledger network on the basis of the first data storage transaction identifier; and

retrieving the second derived data from the first distributed ledger network on the basis of the second data storage transaction identifier.

B30. The method according to any one of clauses B27 to B29, comprising generating the verification data and, subsequently, transmitting the verification data for storage in one or more distributed ledger networks of the at least one distributed ledger network.

B31. The method according to any one of clauses B27 to B30, comprising generating the verification data on the basis that the first verification data storage request and the second verification data storage request are received within a predetermined time period.

B32. The method according to any one of clauses B27 to B31, wherein the first distributed ledger network comprises a plurality of client nodes and at least one control node, wherein the method is performed in a control node of the at least one control node of the first distributed ledger network.

B33. The method according to clause B32, comprising: retrieving the first derived data from the first distributed ledger network; retrieving the second derived data from the first distributed ledger network;

storing the first derived data in storage of the control node;

storing the second derived data in the storage of the control node;

storing the verification data in the storage of the control node; and

transmitting the verification data for storage in one or more distributed ledger networks of the at least one distributed ledger network.

B34. The method according to any one of clauses B27 to B33, comprising receiving a network verification data storage identifier in response to transmitting the verification data for storage in one or more distributed ledger networks of the at least one distributed ledger network, the network verification data storage transaction identifier identifying a block, within the one or more distributed ledger networks, in which the verification data has been stored.

B35. The method according to clause B34, comprising:

transmitting a first confirmation indicative that the first derived data has been stored in the one or more distributed ledger networks, the first confirmation comprising data derived from the network verification data storage identifier; and

transmitting a second confirmation indicative that the second derived data has been stored in the one or more distributed ledger networks, the second confirmation comprising data derived from the network verification data storage identifier.

B36. The method according to clause B35, wherein

the first confirmation comprises at least one of: the network verification data storage identifier or a hash of the verification data storage identifier; and

the second confirmation comprises at least one of: the network verification data storage identifier or a hash of the verification data storage identifier.

B37. The method according to any one of clauses B27 to B36, wherein:

the first verification data storage request is received from a first client node of a plurality of client nodes of the first distributed ledger network; and

the second verification data storage request is received from a second client node of the plurality of client nodes.

B38. The method according to any one of clauses B27 to B37, comprising transmitting the verification data to be stored as metadata associated with at least one of: a block or a transaction of one or more distributed ledger networks of the at least one distributed ledger network. B39. The method according to clause B38, comprising transmitting the verification data to replace pre-existing metadata associated with the at least one of: the block or the transaction so as to store the verification data as the metadata associated with the at least one of: the block or the transaction, respectively.

B40. The method according to any one of clauses B27 to B39, wherein the at least one distributed ledger network comprises a public distributed ledger network.

B41. A method of processing a request to store verification data in at least one distributed ledger network, the method comprising:

receiving a verification data storage request relating to storage of verification data in at least one distributed ledger network, different from a first distributed ledger network, the verification data relating to first data stored in the first distributed ledger network,

wherein the verification data storage request comprises parameter data, the parameter data relating to at least one characteristic requested for the storage of the verification data in the at least one distributed ledger network;

selecting one or more distributed ledger networks, different from the first distributed ledger network, for the storage of the verification data, on the basis of the parameter data; and storing the verification data in the selected one or more distributed ledger networks. B42. The method according to clause B41, wherein the at least one characteristic comprises a level of immutability requested for the storage of the verification data in the at least one distributed ledger network.

B43. The method according to clause B41 or clause B42, wherein the at least one characteristic comprises a level of delay within which confirmation of the storage of the verification data in the at least one distributed ledger network is requested.

B44. The method according to any one of clauses B41 to B43, wherein the first distributed ledger network is a private distributed ledger network, and the at least one distributed ledger network comprises a public distributed ledger network.

B45. The method according to any one of clauses B41 to B44, wherein the first distributed ledger network comprises a first number of nodes and a combination of the selected one or more distributed ledger networks comprises a second number of nodes, larger than the first number of nodes.

B46. The method according to any one of clauses B41 to B45, wherein the first distributed ledger network comprises a plurality of client nodes and at least one control node, wherein the method is performed in a client node of the plurality of client nodes of the first distributed ledger network.

B47. A method of processing a request to store verification data in at least one distributed ledger network, the method comprising:

initiating a distributed ledger network transaction;

after initiating the distributed ledger network transaction, receiving a verification data storage request relating to storage of verification data in at least one distributed ledger network; and

transmitting said verification data to be stored as metadata in association with said distributed ledger network transaction, prior to said distributed ledger network transaction being confirmed as committed to one or more distributed ledger networks of the at least one distributed ledger network.

B48. The method according to clause B47, comprising:

initiating a plurality of distributed ledger network transactions before receiving said verification data storage request, each of said plurality distributed ledger network transactions remaining unconfirmed as committed to the one or more distributed ledger networks when said verification data storage request is received; and

selecting a distributed ledger network transaction, from said plurality of distributed ledger network transactions, for the storage of said verification data, on the basis of at least one characteristic of the verification data storage request.

B49. The method according to clause B48, wherein the at least one characteristic comprises a time of receiving the verification data storage request.

B50. The method according to clause B48 or clause B49, wherein the at least one characteristic comprises a level of delay within which confirmation of the storage of the verification data in the at least one distributed ledger network is requested.

B51. The method according to any one of clauses B48 to B50, wherein the plurality of distributed ledger network transactions are initiated at pre-determined time intervals, respectively.

B52. The method according to any one of clauses B47 to B51, wherein the distributed ledger network transaction is a cryptocurrency transaction.

B53. The method according to any one of clauses B47 to B52, wherein the at least one distributed ledger network comprises a public distributed ledger network. B54. The method according to any one of clauses B47 to B53, wherein the distributed ledger network transaction represents a transaction between a first digital wallet and a second digital wallet.

B55. The method according to clause B54, wherein the method is performed in a node comprising the first digital wallet and the second digital wallet.

B56. The method according to clause B55, wherein the node is a control node of a first distributed ledger network, different from the at least one distributed ledger network.

B57. The method according to any one of clauses B47 to B56, comprising receiving the verification data storage request from a client node of a first distributed ledger network different from the at least one distributed ledger network.

B58. The method according to clause B57, wherein the first distributed ledger network is a private distributed ledger network.

CI. A method comprising :

configuring a computing node with a node identifier;

receiving a licence token to be associated with the node identifier;

generating, at the computing node, a block to be added to a blockchain of a distributed ledger network;

generating node validation data, based on the block and the licence token, for validating an origin of the block; and

transmitting, from the computing node, outbound data comprising the block and the node validation data.

C2. The method according to clause CI, wherein transmitting outbound data comprises: encrypting the outbound data to generate encrypted outbound data; and

transmitting the encrypted outbound data.

C3. The method according to clause CI or clause C2, wherein transmitting outbound data comprises multicasting the outbound data.

C4. The method according to any one of clauses CI to C3, wherein transmitting the outbound data comprise transmitting the outbound data using the User Datagram Protocol (UDP). C5. The method according to any one of clauses CI to C4, wherein generating node validation data comprises applying a hashing algorithm to data derived from the block and licence data derived from the licence token.

C6. The method according to clause C5, wherein the hashing algorithm is a keyed-hash message authentication code (HMAC) algorithm.

C7. The method according to any one of clauses CI to C6, wherein the node identifier is a pseudo-random node identifier.

C8. The method according to any one of clauses CI to C7, comprising:

transmitting licence data derived from the licence token; and

receiving at least one cryptographic key for data transmitted in the distributed ledger network.

C9. The method according to clause C8, comprising deriving the licence data from the licence token by applying a checksum algorithm to the licence token.

CIO. The method according to clause C8 or clause C9, wherein the at least one cryptographic key comprises a decryption key for decrypting encrypted data of the distributed ledger network. Cl l. The method according to any one of clauses C8 to CIO, wherein the at least one cryptographic key comprises an encryption key for encrypting the outbound data.

C 12. The method according to any one of clauses C8 to C 11 , wherein transmitting the licence data comprises transmitting a request for the at least one cryptographic key, the request comprising the licence data and the node identifier.

C13. The method according to any one of clauses C8 to C12, comprising, after transmitting the licence data, receiving expiry data indicative of an expiry time of the at least one cryptographic key.

C14. The method according to any one of clauses CI to C13, comprising:

determining that the at least one cryptographic key has expired;

subsequently transmitting, from the computing node, the licence data; and

receiving, at the computing node, at least one further cryptographic key for the data transmitted in the distributed ledger network.

C15. The method according to any one of clauses CI to C14, comprising, before receiving the licence token, transmitting licence entitlement data to a licensing server.

C16. The method according to clause C15, wherein:

the computing node is associated with an entity; and the licence entitlement data comprises an entity identifier associated with the entity. C17. The method according to any one of clauses CI to C16, wherein configuring the computing node with the node identifier comprises:

generating the node identifier upon initialization of the computing node; and, subsequently,

configuring the computing node with the node identifier.

C18. The method according to clause C17, wherein generating the node identifier comprises generating the node identifier based on a time associated with initializing the computing node. C19. The method according to any one of clauses CI to C18, comprising:

receiving a further block generated by a further computing node;

transmitting, from the computing node, a validation request comprising:

data derived from the further block;

a further node identifier for identifying the further computing node; and further node validation data for validating that the further computing node is a member node of the distributed ledger network; and

receiving, at the computing node, a validation indication indicative of whether the further computing node is a member node of the distributed ledger network.

C20. A method of validating an origin of a block generated by a computing node, for storage of the block within a distributed ledger network, the method comprising:

receiving, at a first member node of the distributed ledger network:

data derived from the block;

a node identifier for identifying the computing node; and

node validation data for validating that the computing node is a member node of the distributed ledger network;

transmitting, from the first member node, a validation request comprising:

the data derived from the block;

the node identifier; and

the node validation data; and

receiving, at the first member node, a validation indication indicative of whether the origin of the block is valid. C21. The method according to clause C20, wherein the validation indication indicates that the origin of the block is valid and the method comprises, in response to receiving the validation indication, adding the block to a blockchain of the distributed ledger network.

C22. The method according to clause C20, wherein the validation indication indicates that the origin of the block is invalid and the method comprises, in response to receiving the validation indication, at least one of: discarding the block or blacklisting a network address associated with the computing node.

C23. The method according to any one of clauses C20 to C22, wherein receiving the data derived from the block comprises receiving a blockchain comprising the data derived from the block.

C24. The method according to clause C23, comprising transmitting, from the first member node, a respective validation request for each of a plurality of blocks of the blockchain.

C25. The method according to clause C24, comprising:

receiving, at the first member node, a first validation indication for a first block of the plurality of blocks which indicates that the origin of the first block is invalid; and

in response, at least one of:

discarding the blockchain; or

blacklisting a network address associated with the computing node.

C26. A method of validating an origin of a block generated by a computing node, for storage of the block within a blockchain of a distributed ledger network, the method comprising: receiving a validation request comprising:

data derived from the block;

a node identifier for identifying the computing node; and

obtaining, on the basis of the node identifier, retrieved licence data based on a stored licence token;

processing the data derived from the block and the retrieved licence data to produce regenerated node validation data; and

validating the origin of the block by checking the received node validation data with respect to the regenerated node validation data. C27. The method according to clause C26, comprising, in response to validating the origin of the block, updating a record of blocks of the blockchain to include a block index indicative of a position of the block within the blockchain.

C28. The method according to clause C27, comprising:

receiving a blockchain validation request comprising a last block index indicative of a position of a last block of the blockchain; and

validating the blockchain by processing the record of blocks of the blockchain to determine that the last block index is less than or equal to the block index.

C29. The method according to any one of clauses C26 to C28, wherein obtaining the retrieved licence data comprises:

retrieving the stored licence token from storage; and

deriving the retrieved licence data from the stored licence token by applying a checksum algorithm to the licence token.

C30. The method according to any one of clauses C26 to C29, wherein processing the data derived from the block and the retrieved licence data comprises applying a hashing algorithm to the data derived from the block and the retrieved licence data.

C31. The method according to clause C30, wherein the hashing algorithm is a keyed-hash message authentication code (HMAC) algorithm.

Claims

1. A method of processing a data record to generate verification data for storage, the method comprising:

retrieving a set of data elements from the data record, the set of data elements comprising at least a first data element from a first data field of the data record and a second data element from a second data field of the data record;

applying a cryptographic algorithm to produce data element verification data from the set of data elements from the data record, wherein the cryptographic algorithm is non- deterministic with respect to first input data, wherein applying the cryptographic algorithm to produce said data element verification data comprises:

applying the cryptographic algorithm to at least said first data element as said first input data, to produce first data element verification data representative of said first data element, the first data element verification data being for verifying the integrity of said first data element; and

applying the cryptographic algorithm to at least said second data element as said first input data, to produce second data element verification data representative of said second data element, the second data element verification data being for verifying the integrity of said second data element; and

transmitting said first and second data element verification data for storage.

2. The method according to claim 1, wherein the cryptographic algorithm comprises a hashing algorithm.

3. The method according to claim 2, wherein the hashing algorithm is a keyed-hash message authentication code (HMAC) algorithm, the HMAC algorithm using a secret key as second input data.

4. The method according to any preceding claim, comprising transmitting said data element verification data for storage in a distributed ledger network.

5. The method according to claim 4, wherein the distributed ledger network comprises member nodes and at least one control node, and wherein transmitting said data element verification data for storage comprises transmitting said data element verification data to a control node of the distributed ledger network.

6. The method according to any preceding claim, comprising:

applying a data set hashing algorithm to produce data set verification data from the set of data elements, said data set verification data comprising a hash value representative of both said first data element and said second data element, the data set verification data being for verifying the integrity of the set of data;

transmitting said data set verification data for storage.

7. The method according to claim 6, wherein the data set hashing algorithm is deterministic with respect to the set of data elements.

8. The method according to claim 6 or claim 7, wherein transmitting said data set verification data for storage comprises transmitting said data set verification data to a member node of a distributed ledger network.

9. The method according to claim 6, 7 or 8, comprising determining, from presence or absence of an indicator associated with the data record, whether element-level verif lability, of individual data elements of the set of data elements, is requested, and applying the cryptographic algorithm to produce data element verification data on the basis that element- level verifiability is requested.

10. The method according to any preceding claim, wherein said data record comprises a trading record, and wherein the first and second data elements each comprise only one of: trading party identifier data;

financial instrument identifier data;

currency identifier data; and

transaction value data.

11. A method of processing a data record to generate verification data for storage, the method comprising:

determining, from presence or absence of an indicator associated with the data record, whether element-level verif lability, of individual data elements of the set of data elements, is requested;

in response to determining that element-level verifiability is not requested:

applying a data set hashing algorithm to produce data set verification data from the set of data elements, said data set verification data comprising a hash value representative of both said first data element and said second data element, for verifying the integrity of the set of data; and

transmitting said data set verification data for storage; and

in response to determining that element-level verifiability is requested:

applying the cryptographic algorithm to at least said first data element as said first input data, to produce first data element verification data representative of said first data element, for verifying the integrity of said first data element; and

applying the cryptographic algorithm to at least said second data element as said first input data, to produce second data element verification data representative of said second data element, for verifying the integrity of said second data element; and transmitting said first and second data element verification data for storage.

12. The method according to claim 11, further comprising, in response to determining that element-level verifiability is requested:

transmitting said data set verification data for storage.

13. A method of processing and storing data element verification data, the method comprising:

receiving data element verification data, the data element verification data comprising: first data element verification data representative of a first data element, for verifying the integrity of said first data element; and

second data element verification data representative of a second data element, for verifying the integrity of said second data element;

storing said data element verification data;

producing additional-level verification data from the first data element verification data and the second data element verification data; and

transmitting said additional-level verification data for storage in a distributed ledger network.

14. The method according to claim 13, comprising applying a hashing algorithm to produce at least part of the additional-level verification data from the first data element verification data and the second data element verification data, wherein the additional-level verification data comprises a hash value representative of both the first data element verification data and the second data element verification data.

15. The method according to claim 14, comprising combining the first data element verification data and the second data element verification data into a concatenated data string before applying the hashing algorithm to the concatenated data string to produce the additional- level verification data.

16. The method according to any one of claims 13 to 15, comprising transmitting receipt data in response to receiving the data element verification data, the receipt data including a transaction identifier for use in a subsequent data element verification request relating to said data element verification data.

17. The method according to claim 16, comprising:

receiving the transaction identifier from the distributed ledger network in response to transmitting the additional-level verification data for storage in the distributed ledger network; and

storing the transaction identifier with the stored data element verification data.

18. The method according any one of claims 13 to 17, comprising, prior to receiving the data element verification data:

receiving a request for a secret key;

generating the secret key in response to the request; and

transmitting the secret key for use in generating the data element verification data.

19. A method of verifying a data record, comprising:

receiving a data verification request, the data verification request relating to data representative of the data record;

receiving the data representative of the data record, the received data comprising a received set of data elements from the data record, the received set of data elements comprising a received first data element from the data record and a received second data element from the data record;

applying a cryptographic algorithm to produce regenerated data element verification data from the received set of data elements from the data record, wherein the cryptographic algorithm is non-deterministic with respect to first input data, wherein applying the cryptographic algorithm to produce said regenerated data element verification data comprises:

applying the cryptographic algorithm to at least said received first data element as said first input data, to produce regenerated first data element verification data representative of said received first data element; and

applying the cryptographic algorithm to at least said received second data element as said first input data, to produce regenerated second data element verification data representative of said received second data element; verifying the integrity of said received first data element by checking said regenerated first data element verification data with respect to stored first data element verification data representative of a first data element from the data record; and

verifying the integrity of said received second data element by checking said regenerated second data element verification data with respect to stored second data element verification data representative of a second data element from the data record.

20. The method according to claim 19, wherein verifying the integrity of said received first data element comprises:

retrieving the stored first data element verification data; and

verifying the integrity of said received first data element by comparing said regenerated first data element verification data to said stored first data element verification data, and

wherein verifying the integrity of said received second data element comprises:

retrieving the stored second data element verification data; and

verifying the integrity of said received second data element by comparing said regenerated second data element verification data to said stored second data element verification data.

21. The method according to claim 19 or 20, wherein the cryptographic algorithm uses a secret key as second input data.

22. The method according to claim 21, comprising receiving said secret key from a requesting party in association with said data verification request.

23. The method according to any one of claims 19 to 22, wherein the method of verifying the data record is performed in a distributed ledger network.

24. The method according to claim 23, wherein the distributed ledger network comprises member nodes and at least one control node, and wherein the method of verifying the data record is performed in a control node of the distributed ledger network.

25. The method according to any one of claims 19 to 24, comprising producing regenerated additional-level verification data from the regenerated first data element verification data and the regenerated second data element verification data, and verifying the integrity of the regenerated additional-level verification data by checking the regenerated additional-level verification data with respect to stored additional-level verification data.

26. The method according to claim 25, comprising verifying the integrity of the regenerated additional-level verification data by:

retrieving the stored additional-level verification data; and

comparing the regenerated additional-level verification data to the stored additional- level verification data.

27. The method according to claim 25 or 26, comprising verifying the integrity of the regenerated additional-level verification data by:

transmitting the regenerated additional-level verification data to a member node of a distributed ledger network for verification by the member node of the additional-level verification data with respect to additional-level verification data stored in the distributed ledger network.

28. The method according to claim 25, 26 or 27, comprising applying a hashing algorithm to produce at least part of the regenerated additional-level verification data, wherein the regenerated additional-level verification data comprises a hash value representative of both the regenerated first data element verification data and the regenerated second data element verification data.

29. The method according to claim 28, comprising combining the regenerated first data element verification data and the regenerated second data element verification data into a concatenated data string before applying the hashing algorithm to the concatenated data string to produce the regenerated additional-level verification data.