The present disclosure relates to a distributed ledger system, and particularly, but not limited to, a blockchain system.

Background on the invention

As the world becomes increasingly interconnected, it becomes necessary to share ever larger volumes of data between organisations, equipment or people for a plurality of different purposes. For example, financial service providers may be required to send payment instructions back and forth; supply chain systems may require a single consistent view of the end to end supply chain; connected devices share greater volumes of operational data and/or organisations are looking to co-ordinate a digital identity service to provide a way for users to electronically prove their identity or the identity of assets to any party that may request such confirmation.

However, whilst operations requiring data sharing have increased, the security underpinning them has not kept pace accordingly. As such, there is a difficulty in maintaining data integrity, for example, protecting data from corruption and/or tampering, such that it accurately reflects the data as originally stored or transmitted.

Historically, organisations used architectures implementing a “perimeter defence” paradigm (such as firewalls) to protect data. However, this is becoming less practical due to the difficulty in defining a “perimeter” as data is now stored not only on local servers, but also is also distributed on remote devices, such as laptops, mobile phones, and loT devices, and/or through the internet/cloud. As an example, electronic payment card providers utilise vast, private, global networks to support card payments. The vast majority of card payment data is controlled by a small minority of companies, who spend significant resources keeping such networks secure, thus passing on the high cost to the end user. The complexity and scale of the provider’s operation means provides a high barrier to entry for new competitors.

Over the last decade, the concepts of blockchain and zero trust have become prevalent to overcome the lack of “perimeter defences” to protect data. These new technologies allow the data to be stored and shared in a “public space” (e.g. the internet). Such systems may use cryptographic mechanisms to protect and obscure the real contents of the data, whilst allowing any one party to verify that the data has not been tampered. This is often referred to as immutability. Such systems are scalable, allowing competition with conventional electronic card payment providers.

A simplified example of a prior art blockchain in show in figure 1 . Each “block” (“Block 1 “Block 2”...) contains a plurality of data fields (“Record 1.1”; “Record 1.2”...). The data fields may be validated to ensure accuracy and immutability, which will be detailed later. Each block contains a cryptographic hash of the previous block. For example, Block 2 contains a hash of previous block, Block 1 , and so on. The hash comprises an enciphered/encrypted text representative of the contents of the block. Therefore, each block contains information relating to the previous block, thus creating a chain of interconnected blocks. This helps to prevent re-writing of a block, as it would require changing the contents of each block down the chain.

The inventor has found numerous problems with the prior art arrangements. In some arrangements, immutability may be achieved via a consensus voting mechanism. This may be referred to as “proof of stake”. Typically, a set of stakeholder users vote to validate the correct data, with the voter share being determined by the number of tokens/stakes (e.g. currency) a given user in the system possesses.

The number of nodes able to participate in validation is limited to a small subset of voters to prevent the system becoming unwieldy. For example, a given system may have a few thousand voters despite having approximately 20 million coin-holders. The inventor has found numerous problems with this arrangement:

• In some circumstances, bad actors may gain control of sufficient tokens to generate an alternative version of the chain. This may allow removal of their own transactions or data entries, for example, to allow them to double spend a cryptocurrency or modify equipment operation data.

• With a limited number of validation nodes, it is possible for a moderately well- funded attacker (e.g. a large criminal enterprise or state actor) to possess enough nodes and/or tokens to be able to control >50% of the voting rights. This may allow the attacker to insert false transactions and/or remove transactions, thus recording false, but validated, data on the ledger. • Typically, there is little or no reward for voting. This encourages voter apathy, and thus many nodes do not vote. This allows a bad actor to gain a majority voter share more easily, thus the system is compromised more easily.

Alternatively, a “proof of work” arrangement may be used. This requires a node to perform a finite amount of computing power to validate the block, for example, by performing arbitrary hash calculations. A "winner" of a round of validation aggregates and records transactions into the block. The winner is the first node to complete the computational work.

However, a bad actor with sufficient computing power could make themselves the “winner” by providing a sufficiently large proportion of computing power. This may be achieved using a network of infected computers under the control of the bad actor.

Furthermore, “proof of work” systems require significant computing power. This consumes large amounts of energy, which may contribute to excessive CO2 emissions etc. For example, the Bitcoin (RTM) system currently generates nearly 40 million tonnes of CO2, equivalent to the total emissions of New Zealand. Proof of work systems also increase demand for GPUs and other similar components, creating shortages elsewhere.

Additionally, the data for each block is defined/recorded, then validated and then finally voted on in sequential steps (i.e. only one step may begin after the previous has finished). The blocks are then chained together using the hash of the previous block. Thus each block must be completed before the next block. Overall the process is slow. For example, Bitcoin can only perform around 5 transactions per second. This provides a bottleneck in the system, which means the overall transaction rate may be too low to be of practical commercial use and/or limited scalability.

It is an aim of the present invention to overcome or ameliorate one or more of the above problems.

Statement of invention

According to a first aspect of the invention, there is provided: a distributed data record system comprising: one or more computational node forming a data sharing or transacting party; a first block comprising a data record, the record containing data relating to a data exchange or transaction between the one or more node; and a further data block created subsequently to the first data block to form a blockchain, said data record in the respective data block being validated by respective validation processes, and where said data record is distributed across the first and further data block.

The system may comprise two or more further blocks, and the record is distributed over the first block and the two or more further blocks. The record may be partitioned or divided across two or more blocks. The record may be obfuscated or encrypted before the record is partitioned or divided.

The system may comprise one or more previous block created before the first block; and where a second record is distributed between the first block and the previous block.

The system may comprise a plurality of blocks, each block created in sequence, and where each block comprises a record distributed across the previous block and a record distributed across the subsequent block respectively. The record(s) may be interleaved across the blocks.

Each block may comprise a plurality of records, and at least two of the records are distributed across a further block; preferably, at least 10% of the records; preferably, at least 30% of the records; preferably, at least 50% of the records;

Each block may comprise a plurality of records, and at least two of the records are distributed across a different number of blocks.

Each block may comprise a plurality of records, and each and every record is distributed across at least two blocks.

A data sharing party may be able to select or specify the number of blocks over which a given record is distributed.

The block may comprise an audit record relating to an audit procedure, the audit record distributed over two or more blocks.

The system may comprise a terminus block at an end of a data sharing period, the terminus block comprising a dummy block to allow a data transaction to be completed at the end of the data sharing period. The system may comprise an initiation block at the beginning of a subsequent data sharing period. The dummy block may be distributed between the terminus block and the initiation block.

The data sharing party may comprise a transacting party, e.g. for a data transaction and/or financial transaction. The, or each, data sharing period may comprise a transacting period.

The system may comprise a distributed validation mechanism to provide authentication of at least one of the records in the block via a consensus mechanism, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the computational nodes comprising a data record in the data block.

The counterparties may only be selected from the one of the nodes comprising a record in the block.

The system may comprise a plurality of counterparties, the counterparties selected from a plurality of nodes comprising a respective record in the block. At least 10% of the counterparties may be selected from one of the nodes comprising a record in the block; preferably, at least 30%; preferably, at least 50%; preferably, at least 80%. The system may comprise a plurality of counterparties, the counterparties are selected from all of the nodes comprising a respective record in the block.

In order to reach a consensus for the consensus mechanism at least 20% of the cumulative voter share may be required; preferably, at least 30%; preferably, at least 40%.

The data parties may comprise a data sharer/transmitter (e.g. a transactor) and a data recipient or transactee. The transactee may be configured to receive the transacted entity from the transactor, and where the counterparty comprises the transactee.

Each counterparty may comprise an equal voter share (e.g. even when having more than one record in a given block). Each counterparty may comprise a consensus share proportional to the proportion of records relating to the counterparty in the block. The consensus mechanism may comprise an audit voter. The audit voter may comprise a veto. The audit voter and/or audit node may comprise a central banking authority or other central data control authority.

The first data block may contain an indicator indicative of data contained within the further block. The data may be contained within a record in the further block. The indicator may comprise one or more record in the further block.

Data in the further block may be configured to be validated to provide authentication thereof, and the indicator comprises at least a portion of the data before validation thereof (e.g. the indicator comprises raw or pre-validated data).

The further block may comprise one or more record relating to one or more data exchange or transaction between one or more node, and the indicator comprises at least one of the records before validation thereof. The indicator may comprise all of the record in the further block before validation thereof.

Data in the first block may be configured to be validated during a first validation process and data in the further block is configured to be validated during a second validation process, and where at least a portion of the first validation process is performed simultaneously to the second validation process. The first and second validation process may temporally overlap. A plurality of validation process for respective blocks may be performed simultaneously. Three or more validation processes may be performed simultaneously.

Data in the first block may be configured to be validated during a validation process, and where the further block is created before and/or during the validation process (i.e. the further block is created and/or populated before validation is complete). Two or more further blocks may be created before and/or during the validation process.

The indicator may comprise a portion or all of the records before validation thereof. The indicator may comprise a cryptographic hash. The indicator may comprise a digital signature. The indicator may comprise data indicative of a proposer of the further block. The indicator may comprise a digital signature of the proposer of the further block. The further block may comprise data indicative of the first block. The data may comprise data indicative of a proposer of the first block. The data may comprise a digital signature of the proposer of the first block. The data may comprise data indicative of one or more record in the first block. The data may comprise a cryptographic hash of one or more record in the first block.

One or more node may comprise a central banking or data control authority. One or more node comprises a computer or computing system. A monetary, information or asset transaction system may use the distributed ledger system according to any aspect of the invention. A central banking authority transaction system may comprise the monetary transaction system.

According to further aspect of the invention, there is provided: a method of providing a distributed data record system comprising: providing one or more computational node forming a data sharing party; creating a first data block comprising a data record, the record containing data relating to a data exchange between the one or more node; creating a further data block subsequent to the first data block to form a blockchain and distributing said record across the first and further data block; and validating the record in the respective data blocks by respective validation processes.

According to further aspect of the invention, there is provided: a data carrier or data storage medium comprising machine readable instructions for the control of a computational node forming a data sharing party of a distributed ledger system and configured to: create a first data block comprising a data record, the record containing data relating to a data exchange between the one or more node; create a further data block subsequent to the first data block to form a blockchain and distribute said record across the first and further data block; and validate the record in the respective data blocks by respective validation processes.

According to a further aspect of the invention, there is provided: a distributed ledger system comprising: one or more node forming a data sharing party; a first block comprising one or more record, the record relating to one or more data exchange between the one or more node; and a further block created subsequently to the first block, the one or more record in the respective block being validated by a respective validation process, and where the record is distributed across the first and further block. According to a further aspect of the invention, there is provided: a method of providing a distributed ledger system comprising: providing one or more node forming a data exchanging party; creating a first block comprising one or more record, the record relating to one or more data exchange between the one or more node; creating a further block subsequently the first block and distributing the record across the first and further block; and validating the one or more record in the respective blocks by a respective validation process.

According to a further aspect of the invention, there is provided: a distributed ledger system comprising: a plurality of computational nodes forming a data sharing party; a data block comprising a plurality of data records, the records containing data relating to one or more data exchange between the respective nodes; a distributed validation mechanism to provide authentication of at least one of the records in the block via a consensus mechanism, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the computational nodes comprising a data record in the data block.

According to a further aspect of the invention, there is provided: a method of providing a distributed ledger system comprising: providing a plurality of computational nodes forming respective data sharing parties; creating a data block comprising a plurality of data records, the records containing data relating to one or more data exchange between the respective nodes; and validating at least one of the records in the block via a consensus mechanism to provide authentication thereof, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the computational nodes comprising a data record in the data block.

According to a further aspect of the invention, there is provided: a data carrier or data storage medium comprising machine readable instructions for the control of a computational node forming a transacting party of a distributed ledger system and configured to: create a data block comprising a plurality of data records, the records containing data relating to one or more transaction between the respective nodes; and validate at least one of the records in the block via a consensus mechanism to provide authentication thereof, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the computational nodes comprising a data record in the data block. According to a further aspect of the invention, there is provided: a distributed ledger system comprising: a plurality of nodes forming respective data sharing parties; a block comprising a plurality of records, the record relating to one or more data exchange between the respective nodes; and a distributed validation mechanism to provide authentication of at least one of the records in the block via a consensus mechanism, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the nodes comprising a record in the block.

According to a further aspect of the invention, there is provided: a method of providing a distributed ledger system comprising: providing a plurality of nodes forming respective data exchanging parties; creating a block comprising a plurality of records, the record relating to one or more data exchange between the respective nodes; and distributively validating at least one of the records in the block via a consensus mechanism to provide authentication thereof, the consensus mechanism performed by at least one counterparty, where at least one of the counterparty is selected from the one of the nodes comprising a record in the block.

According to a further aspect of the invention, there is provided: a distributed ledger system comprising: one or more computational node forming a data sharing or transacting party; a first data block comprising one or more data record, the record containing data relating to one or more data exchange or transaction between the one or more node; and a further data block created subsequently the first data block to form a blockchain, the one or more data record in the respective data blocks being validated by respective validation processes; and where the first data block contains an indicator indicative of data records contained within the further block.

A method of providing a distributed data record system comprising: providing one or more computational node forming a data sharing party; creating a first data block comprising one or more data record, the record containing data relating to one or more data exchange between the one or more node; and creating a further data block created subsequently to the first data block, and validating the one or more data record in the respective data blocks by respective validation processes; and inserting into the first data block an indicator indicative of data contained within the further block. According to a further aspect of the invention, there is provided: a data carrier or data storage medium comprising machine readable instructions for the control of a computational node forming a data sharing party of a distributed ledger system and configured to: create a first data block comprising one or more data record, the record containing data relating to one or more data exchange between the one or more node; and create a further data block created subsequently the first data block, and validating the one or more data record in the respective data blocks by respective validation processes; and insert into the data first block an indicator indicative of data contained within the further block.

According to a further aspect of the invention, there is provided: a distributed ledger system comprising: one or more node forming a data sharing party; a first block comprising one or more record, the record relating to one or more transaction or data exchange between the one or more node; and a further block created subsequently the first block, the one or more record in the respective block being validated by a respective validation process; and where the first block contains an indicator indicative of data contained within the further block.

According to a further aspect of the invention, there is provided: a method of providing a distributed ledger system comprising: providing one or more node forming a transacting party; creating first block comprising one or more record, the record relating to one or more transaction between the one or more node; and creating further block created subsequently the first block, validating the one or more record in the respective block via a respective validation processes; and inserting an indicator in first block indicative of data contained within the further block.

Any of the optional features of each aspect may be applied to any other aspect where practicable. For example, the system features of one aspect may be applied to the corresponding method/data carrier aspect or vice versa. Similarly, the features of any one aspect (e.g. the system, method or data carrier thereof) may be applied to the system, method or data carrier embodiments of a different aspect.

According to further aspects of the invention, there may be provided a data carrier comprising machine readable instructions for performing the method or implementing the system of any preceding aspects. Any data sharing or exchange may comprise a transaction between parties, e.g. a data/information exchange, an asset transfer/exchange or a financial transaction. Accordingly a ‘ledger’ as referred to herein may comprise a record of any such exchange or sharing of data.

Detailed description

Workable embodiments of the invention are described in further detail below by way of example only with reference to the accompanying drawings, of which:

Figure 1 shows a prior art blockchain system;

Figure 2 shows a schematic view of a distributed ledger system;

Figure 3 shows a schematic view of an interleaved block system of the distributed ledger system;

Figure 4 shows a schematic view of a consensus mechanism of the distributed ledger system;

Figure 5 shows a schematic view of a linking arrangement of the distributed ledger system;

Figure 6 shows a schematic view of a newly created block of the distributed ledger system;

Figure 7 shows a schematic view of a validated block of the distributed ledger system;

Figure 8 shows a schematic view of a completed block of the distributed ledger system;

Figure 9 shows a schematic view of the operation of the distributed ledger system;

Figure 2 shows a distributed ledger system 2. The system 2 comprises a plurality of nodes 4. The nodes 4 may comprise an individual peer 4a. For example, this may comprise any one of: individual person; corporation; enterprise; institution; public body; bank; central bank etc. The nodes 4 may comprise another network, cluster or system 4b. For example, the system may comprise a conventional banking system; electronic payment card system; currency exchange; and/or logistics database etc. The nodes 4 may comprise a server 4c. The server 4c may help to facilitate operation of the ledger system 2. For example, the server 4c may monitor and/or provide analytics to ensure correct operation of the system 2. It can be appreciated the exact form of each node 4 is not pertinent to the invention at hand. The nodes 4 are generally configured to send/receive data or otherwise transact between one or more other node 4. The nodes 4 comprise any suitable hardware and/or software. The nodes 4 comprise a computing device, for example, one or more of: a desktop; laptop; server; mobile phone; tablet computer; interlinked system (e.g. network or super-computer); IOT device; and/or dedicated hardware (e.g. ASIC) etc. The nodes 4 may comprise memory (e.g. volatile and/or non-volatile memory).

The nodes 4 are connected via any suitable technology. Typically, the nodes 4 are connected via a WAN 6. The WAN 6 may utilise the internet and/or cloud technology. The nodes 4 may be connected via a LAN. The LAN may be wired and/or wireless. The nodes may be connected by one or more: Wifi; Bluetooth (RTM); cellular technology (e.g. GSM, 3G, 4G, 5G etc); ethernet and/or other wired technologies. For example, the network may comprise a local peer-to-peer network.

At least some of the nodes 4 may be provided with the same or similar locale (for example, within the same building or site). Additionally, or alternatively, some of the nodes 4 may be geographically distributed. At least some of the nodes 4 may belong to a single institution (e.g. within a single corporation). Additionally, or alternatively, at least some of the nodes 4 may belong to distinct (legally or otherwise) institutions (e.g. different corporations or individuals).

The ledger system 2 is shown schematically in figure 3. The ledger 2 comprises a record 8 relating to one or more transaction between two or more nodes 4. The exact form of the transaction is not pertinent to the invention at hand and may comprise one or more of: currency transfer; stock transfer; foreign currency exchange; distributed tasks; or data transfer (e.g. including operational data for machines, networks and the like), etc. Similarly, the exact form of the data is not pertinent to the invention hand. The data may comprise any suitable means to record the transaction/exchange. Data relating to the transaction is stored in the record 8. Each record comprises a record ID 10.

The ledger 2 is divided into a plurality of discrete portions, referred to herein as blocks 12. The blocks 12 comprise a plurality of records 8. Each block comprises a block ID 13. In general, the blocks 12 are created sequentially (i.e. one after another). For example, Block 1 is created, then Block 2, then Block 3 etc. It can be appreciated that an initial block (e.g. Block 0) may initialise the system. Such a block may be referred to as a “genesis” block. Each of the block 12 is validated and/or stored independently from each of the other block 12, as will be described later. Such a system may provide the basis for a block chain.

Each block comprises a plurality of records 8. The exact number of records 8 per block 12 is not pertinent to the invention at hand, but may comprise tens, hundreds, or thousands of records 8. Typically, the records 8 relate to a plurality of different nodes 4. However, it can be appreciated that where a node 4 completes a plurality of transactions etc. in a given time frame, the node 4 may comprise a plurality of records 8 in each block 12.

The records 8 are distributed across two or more blocks 12. For example, “Record 1.1” spans Block 1 and Block 2, “Record 1 .2” spans Block 1 , Block 2, and Block 3, and so on. The data contained within each record is therefore distributed across two or more blocks accordingly (i.e. the record is divided into a number of parts). As the record 8 is distributed over a plurality of blocks 12, during the validation step described later, each record 8 must be validated over a plurality of blocks 12. This increases the number of nodes 4 that each node 4 shares a block 12 with. For example, in a conventional system, Record 1.1 would only share a block with Record 1 .2. The related node 4 for Record 1.1 thus has a 50% stake of Block 1 . However, in the present system, Record 1.1 now shares a block with Record 0.1 , 0.2 and 0.3 from Block 0 (not shown); Record 1 .2 from Block 1 ; and Record

2.1 and 2.2 from Block 2. The related node 4 for Record 1.1 thus has a 50% stake for Block 1 and a 50% stake for Block two. The node 4 for Record 1.1 also now potentially interacts with six other nodes 4, rather than a single other node 4, in the previous case. This reduces the ability of a single node 4 to gain >50% of the validation votes, by diluting the relative stake of each node for each block and/or increasing the number nodes each node 4 is required to validate with across the plurality of blocks 12, thereby increasing the number of colluders required for an attack.

The records 8 in a given sequential block are further distributed over two or more blocks 12. Thus, every Nth block contains a partial record 8 contained with an N-1 block and an N+1 block. For example. Block 1 shares Records 0.1 , 0.2 and 0.3 with Block 0; Records

1.1 with Block 2; and Record 1 .2 with Block 2 and Block 3.

This creates a “chain” as each block 12 shares a record 8 with the preceding and the subsequent (i.e. following) block 12. This provides an interleaved or “striped” arrangement. As previously described, this increases the number of validation nodes 4 for each block 12 and record 8. The interleaving structure further makes modifying the chain extremely burdensome, as each block would have to be modified going forward and backward in the chain.

Records 8 may be distributed over (i.e. span) any number blocks as required. The records 8 are thus divided into as many parts accordingly. Typically, the records would span two or three blocks 12. Each block 12 may be interleaved with 3-5 blocks accordingly.

Increasing the number of blocks spanned via a given record 4 increases the number of interacting nodes 4, thus increasing security. However, increasing the number of interacting nodes 4 may increase complexity and/or processing time/power required by the system. It can be appreciated that the number of blocks 12 a record spans may be optimised according to the system requirements.

In some embodiments, the number of the blocks 12 spanned may vary between records 8. The records 8 may be divided into any number of parts accordingly. For example, the number of blocks 12 spanned via a record 8 may increase with increasing transaction value and/or importance. This ensures high value/important transactions are less prone to attack. Low value transactions may comprise a low number of record parts accordingly.. Each record 8 may comprise a transaction value and/or importance flag.

In some embodiments, the record 8 may be divided into any number of parts on an ad hoc basis. For example, the transacting node party may be able to select or request the number of parts which a given record 8 is divided.

In some embodiments, the number of the blocks 12 spanned may vary over time. This allows dynamic changing of the interleaving process. For example, if an attack is anticipated or detected, the number of blocks 12 spanned by each record 8 may increase. The system may therefore be proactive/reactive. Alternatively, if a backlog of transactions is anticipated or detected, then the number of blocks 12 spanned by a record 8 could be decreased.

In some embodiments, the number of the blocks 12 spanned by a record 8 may be randomly determined. This makes it more difficult for an attacker to determine the blocks 12 required for an attack. The number of blocks 12 spanned may be determined between a minimum and maximum number. In some embodiments, only a select portion of records 8 may span multiple blocks 12. This may reduce complexity/increase speed. For example, greater than or equal to 50%; preferably, greater than or equal to 30%; preferably, greater than or equal to 10% of records 8 span multiple parts.

The data in each record 8 may be obfuscated. In some embodiments, the record parts are obfuscated such that the data in each record part cannot be determined in isolation. For example, the data in each record may only be determined when all, or at least multiple, record parts are reassembled. This may further help to interleave the blocks 12. The data may be encrypted, obsfucated or disordered, such that the data can only be determined when all record parts are known. For example, if a record 8 comprises 100 bytes, bytes 1 - 10 are provided in record part 1 , bytes 11 -20 in record part 2, bytes 21 -30 in record part 3, and so on. This provides a “striped arrangement”. It can be appreciated that other similar arrangements/algorithms may be provided. In other examples, the data structure of each record 8 might be such that a transaction is impossible or difficult to determine (e.g. the division of the record 8 interrupts crucial data/instructions)

In other embodiments, the data in each block may be merely divided into record parts without obfuscation. In a simple example, the data is divided according to sequential position. For example, if a record 8 comprises 100 bytes, bytes 1 -50 are provided in record part 1 , and bytes 51 -100 in record part 2.

Typically, the interleaved arrangement extends along the block chain ad infinitum (i.e. in a substantially continuous manner). However, in some embodiments, a “break” between chains may be provided. In such a break, an Nth block comprise no overlapping records 8 with an N+1 block. Such an arrangement may be useful where short sequences and/or fixed time period of transactions may be required. This ensures no transactions are left incomplete/unresolved at the end of the sequence/period. For example, this may be useful for a stock exchange system, where the current system 2 is used to record transactions during trading, and then at the end of the trading day, the transactions are finalised. The transactions may then be recorded in a conventional system, if required. However, the “broken” blocks 12 may still be linked using a conventional method, for example using cryptographic hash of a previous block 12. This provides a long term, continuous block chain, whilst allowing a break in transactions for a given period. In some embodiments, a dummy block is created at the start and/or end of a transacting period, allowing the final transactions to be completed without interrupting the blockchain process. The dummy block may comprise any suitable form and may comprise dummy data to allow the validation process to be maintained. This maintains integrity of the system without leaving pending transactions.

In some embodiments, an audit or verification record may be provided. The audit record may be created by an audit node (e.g. a central authority, such as a bank). The audit record may span a plurality or large number of blocks 12. Thus, the audit n node may have a validation stake in all or portion of the blocks 12. This may help to prevent abuse of the system 2. Alternatively, the audit node may sample a small portion of the blocks (e.g. <1%).

In order to verify the contents of each block 12, a consensus mechanism is used to determine (i.e. validate) the “correct” records between a plurality of nodes 4. The nodes 4 required to validate may be referred to as “voters”. In the present embodiment, the voters selected to validate a given block are selected according to whether they provide, own or are otherwise associated with a given record 8 in the block 12. For example, as shown in figure 4, Block 1 contains Records 1.1 , 0.2, 1 .2, 0.4, and 1 .3. The owners Node #3, Node #1 , Node #4, and Node #1 of the respective records are thus selected to participate in the validation. The voters are added to a voter/counterparty list 14.

In such an arrangement, a node 4 associated with a pending transaction in a given block forms part of the consensus mechanism for that block. This may be the transactor (the party configured to send a transacting entity) and/or the transactee (the party configured to receive the transacting entity). For example, this may comprise a node 4 waiting to send/receive a currency transaction. This incentivises voter participation as the node 4 has a direct interest in completing the transaction. This reduces the possibility of attack via voter apathy. Furthermore, as only transacting nodes 4 are permitted to vote, a bad actor would be required to provide transactions for each block 12 they wish to attack. In a system with a large number of transactions, and therefore a large creation of blocks, this may be difficult to achieve.

During the validation stage, the voters vote to validate the correct data. Typically, a simple majority may be required. For example, if >50% of the voters agree the “correct” data, then the data is thus validated. It can be appreciated that such a validation threshold may be determined according to the desired level of certainty. For example, the validation threshold may be greater than or equal to 50%; greater than or equal to 60%; greater than or equal to 70%; greater than or equal to 80% or greater than or equal to 90%.

Each voter may be given a weighting. The weighting may determine each voter’s contribution toward the validation threshold. In some embodiments, each voter gains an equal voter share. Each voter gains a proportion of the voter share equal to the total share divided by the number of voters. For example, in figure 4, Nodes #1-4 (four total voters) get an equal 25% voter share each. The equal voter share ensures that an attacker cannot flood a block with a series of transactions, thereby gaining control of the consensus mechanism.

In some embodiments, each voter gains a share of the votes proportional to the number of records/transactions they own for each block 12. For example, the Nodes #2-4 have one record each, whilst Node #1 has two records. Nodes #2-4 thereby gain a 20% voter share each, whilst Node #1 has a voter share of 40%. This provides more incentive for transacting nodes to validate. However, as discussed above, this may allow an attacker to flood a given block with transactions, thereby gaining greater voter share, and so only be used in certain circumstances.

In some embodiments, an audit/verification voter may be provided. The audit voter may be created by the audit node (e.g. the central authority). The audit may be provided in all or a selected portion of blocks 12. The audit voter may sample a small portion of the blocks (e.g. <1%). The audit voter may comprise a veto power or the like. For example, the audit voter may override/outweigh the other counterparties’ voter share. Thus, in select instances, the validation process may be controlled by the audit voter alone.

In the present embodiment, each voter for a given block is configured to validate every record 8 in the block 12. Accordingly, each record 8 in each block 12 is validated by every voter. Each voter thus provides a “counterparty” for each record 8, ensuring accurate validation of the record.

In other embodiments, each voter may be required to validate a select number of records 8 in each block 12. This may decrease processing time/power. The voters are distributed such that typically each record 8 comprises a different set of voters. The voters may or may not be able to validate their own record 8. In some embodiments, voters not comprising a related record 8 a given block 12 may form a counterparty. For example, the voters may be selected using a conventional “proof of stake” mechanism. The system may therefore comprise a hybrid system. Typically, the voters comprising a related record 8 a given block 12 account for at least a plurality of the counterparties; preferably, at least 10% of the total number of counterparties; preferably, at least 50%; preferably, at least 80%. Alternatively, only voters comprising a related record 8 a given block 10 may be counterparties.

Typically, the consensus mechanism will be incorporated into a distributed ledger system incorporating the aforementioned interleaved block system. As such, a given voter is incorporated in a voter list for multiple blocks in accordance with their record 8. As such, each node 4 validates multiple blocks. For example, Record 1 .1 spans Block 1 and Block 2, and thus Node #3 is in the voter list for Block 1 and Block 2. Accordingly, each block 12 shares at least one voter with the preceding and subsequent block 12. For example, Block 1 shares Node #3 with Block 2 and the Node #1 with Block 0. This provides interleaving of the voter list, thereby providing further difficulty in attacking the system.

The described consensus mechanism may be incorporated into any conventional distributed ledger system. In such arrangements, the voter list would merely comprise the nodes 4 associated with a record 8 contained within the block 12. For example, as shown in figure 1 , the voter list for Block 1 would only include the nodes associated with Records 1.1-4. Whilst not as secure as providing the interleaved arrangement, such an arrangement would still incentivise voting, thereby reducing the likelihood of attack.

A block creation system is described with reference to figure 5. Each block 12 comprises a link to a previous block. Typically, the link comprises cryptographic hash 16 of the previous block 12 and/or contents thereof. The block 12 comprises a record of the unvalidated data 18. This is the raw data received by the system and typically contains a plurality of records 8. Validated data 20 is recorded in the block 12. The validated data 20 comprises a validated record of the unvalidated data 18. As the validation process takes a finite amount of time, the validated data 20 is created/recorded (temporally) after the unvalidated data 18 is received/recorded.

The block 12a comprises a link to the subsequent block 12b. The link provides an indicator relating to the subsequent block 12b. Typically, the indicator comprises a cryptographic hash 22 or the like. The hash 22 is based on the unvalidated/raw data 18b for the subsequent block 12b. The hash 22 thus provides a “backward chain” for the blocks. This increased the difficulty in attacking the chain, as the attacker would have to alter every block forward and backward from the manipulated block.

During creation of the chain, a subsequent block, N+1 , may be created before a given block, N, is completed or finalised. In the present example, Block 2 may be created before Block 1 is finalised. Typically, this will happen during the relatively long validation period. However, it can be appreciated that subsequent N+1 block generation may occur any time after a given N block is created. As the Nth block is not finalised, but the N+1 block has been created, the unvalidated data 18 may be extracted from the N+1 block. A hash 22 for the unvalidated data 18 is created and incorporated into the Nth block.

For example, during validation of the unvalidated data 18a of Block 1 , a new Block 2 is created. Unvalidated data 18b is incorporated into Block 2. A hash 22 of the unvalidated data 18b is created and incorporated into Block 1 . Once validation is complete, the validated data 20 is recorded in Block 1 . Block 1 is now complete/finalised. A hash 16 of Block 1 is then created and recorded in Block 2.

The “previous” hash 16 contains the data from the preceding N-1 block. However, N-1 block contains the unvalidated data 18 from the Nth block. The hash 16 thus circularly links the Nth and N-1 blocks, both linking and providing a cryptographic validator for both the block 12 simultaneously.

It can be appreciated that such a regime may continue ad infinitum. For example, Block 2 comprises a hash 22 for the unvalidated data for Block 3. Once the data is validated, a hash 16 of Block 2 is created and inserted into Block 3, and so on.

As the creation of a subsequent N+1 block is performed before completion of the Nth block, multiple blocks 12 can be both populated and validated simultaneously. This significantly increases the processing capability of the system 2. As such many transactions can be completed in a given time period. For example, the system 2 may allow thousands or millions of transactions per second. The system is thus scalable, allowing transaction rates comparable with conventional electronic card payment systems. Any number of subsequent block N+X may be created before completion of a given Nth block. For example, between 1 and 10 subsequent blocks may be created (i.e. X is between 1 and 10). Once the unvalidated data 18 is populated, the validation process may begin, independently of the other blocks 12. Thus, validation process may be performed simultaneously (i.e. in parallel) across a plurality of blocks 12.

The completion of a given Nth block merely requires that the unvalidated data 18 is completely populated in for the subsequent N+1 block. A given block N may thus otherwise act independently of a subsequent N+1 block. Once the unvalidated data 18 is populated, the hash 22 can be created and the block 12 is finalised. As the hash of the previous N-1 block is required for completion of a given Nth block, completion of the chain of blocks still requires completion of a subsequent N-1 block. This ensures the backward chain of blocks is maintained, ensuring accuracy. The calculation of the hash 16 is typically much quicker than the validation stage, thus completion of the block 12 is not bottlenecked despite the simultaneous/parallel processing of the validation stages of the respective blocks 12.

It can be appreciated that any suitable portion of the subsequent block and/or contents thereof may be used to provide a back-link or indicator to the previous block. In some embodiments, the indicator may comprise data indicative of a proposer of the subsequent block. The indicator may comprise a digital signature or other suitable digital identifier. In some embodiments, the indicator may comprise data indicative of one or more transacting party (i.e. record owner). The indicator may comprise a digital signature of the transacting party.

In some embodiments, only the backward link (i.e. the unvalidated data hash 22) may be provided. This may allow faster completion of blocks, and each block 12 can complete without completion of the previous block.

The data structure of a proposed or newly created block 12 is shown in figure 6. The block comprises header 24. The header 24 generally comprises information relating to the block 12 and/or contents thereof. The header 24 may comprise one or more of:

• A block identifier 26. Typically, this comprises a unique identifier, thus allowing identification of an individual block 12. The identifier may be incremental/index between blocks 12. • A timestamp 28. This allows approximate identification of the creation, validation, and/or completion of a given block 12, thus increasing traceability etc.

• A record index/list 30. The index 30 lists or identifies all the records 8 provided in the block 12. The index 30 may further list nodes 4, transacting parties and/or voters for the block.

The block 12 contains the unvalidated record 18. The record may comprise one or more of:

• A record identifier 32. The identifier 32 may comprise a unique identifier for each record within a block 12 and/or within the system 2 as a whole.

• Data 34. The data typically comprises data relating to one or more transactions between parties. The data 34 is unvalidated at this stage. The data may comprise any suitable form, for example, inter alia: binary; hexadecimal; human-readable code (e.g. ASCII); and/or other machine readable instruction. The exact form or structure of the data is not pertinent to the invention at hand. The data may form part of a ledger or the like.

• A node identifier 36. The identifier 36 identifies/authenticates at least one of the transacting parties and/or verifies the integrity of the data 34 transmitted thereby. The identifier 36 may be implemented using any conventional method. Typically, the identifier 36 comprises a digital signature. The signature may be verified via a public key. The public key may be provided with the identifier 36/data 34. Alternatively, the location of the public key is otherwise indicated.

• A part index 38. This indicates how many parts the record has (e.g. when spanning multiple blocks) and/or the index of each record for the given block. For example, as shown in figure 6, the index 38 indicates the record is the first part of out of two parts. The part index 38 may further identify the block(s) 12 containing the remaining parts of the record 8.

A hash 22 of the unvalidated data 18 is created. The hash 22 may then be incorporated in the previous block as described. The hash 22 may remain in the block 12 indefinitely; or may be deleted once the hash 22 is incorporated in the previous block and/or when the previous block is completed. The hash 22 may therefore be stored in the block temporarily (i.e. only permanently stored in the previous block).

A proposer identifier 40 is provided. The proposer initiates the creation of a new block 12. For example, the proposer may wish to record a transaction, however, the current block 12 has reached its current record capacity. Alternatively, the proposer is selected based on the result of the previous block (i.e. if one or more part of their record are contained with a previous block, and a further part required a new block). The identifier thus identifies the proposer/creator of the new block 12. In some embodiments, the proposed may comprise a central authority or the like. The identifier 40 may comprise a digital signature/public key arrangement as previously described.

A reference identifier 42 for the previous block is included. This provides an initial link to the previous block. In the present embodiment, the identifier comprises the proposer identifier for the previous block. The identifier 42 may comprise a digital signature/public key arrangement as previously described.

In some embodiments, the reference identifier 42 is included in the hash 22. Thus, the back-link/indicator includes data relating to the previous block. Again, a given Nth Block and the subsequent N-1 block are circularly linked.

After validation, the block 12 is updated to record the validation data. The structure of the validated block is shown in figure 7. The validated record 20 is created. The validated record 20 comprises a similar structure to the unvalidated record 18, and may further comprise one or more of:

• A validator ID 44. This comprises an ID of the one or more nodes 4 forming part of the validation system. The identifier may comprise a digital signature/public key arrangement as previously described.

• A validation indicator 46. This may indicate whether the unvalidated data 34 for a given record 8 is valid, not-valid and/or undetermined. In some embodiments, any data included in the validated record 20 may be deemed valid (i.e. implicitly). In other embodiments, the indicator 46 explicitly indicates data, and/or portions thereof, are valid. For example, the indicator 46 may comprise a flag, label or the like. The indicator 46 may comprise a list of non-valid and/or undetermined data.

The data structure of a completed block 12 is shown in figure 8. In this configuration the block 12 is validated and finalised, and therefore confirmed as being authentic. The block 12 comprises a completion footer. The completion footer may comprise one or more:

• A completor identifier 48. The completor comprises a node that ensures validation is complete and the data contained therein is authentic. The identifier may comprise a digital signature/public key arrangement as previously described. • A validation/consensus list 50. The list 50 may include the validation indicator 46 for each of the records 8 and/or a reference thereto. In some embodiments, the list may comprise a list of which records were successfully and/or unsuccessfully validated. Unsuccessfully validated records may be recreated in a subsequent block 12 or discarded, as appropriate. The list 50 may comprise any suitable indicator to indicate a given record 8 in a block is valid and/or invalid.

• A previous block identifier 52. This creates a unique or pseudo-unique indicator of a previous block 12. The identifier is then incorporated into the present block. Typically, this comprises the block hash 16 as previously described.

• The indicator 54 for the subsequent block 12. This comprises the hash 22 of the unvalidated data 18 and/or the proposer ID 40 of the subsequent block. As the validation process is slow, the unvalidated data 18 of the subsequent block has been compiled before the completion of the current block 12.

The process of creating and processing the ledger system 2 is shown schematically in figure 10.

In a first step, a node 4 wishing to record a transaction connects to a messaging service. Typically, the node 4 comprises a node 4 with a record part in a previous block. Further nodes 4 wishing to record a transaction connect accordingly. The messaging service may comprise any suitable communication service and will not be described further. Typically, the messaging service is connectable to nodes 4 via the internet or the like. The messaging service may comprise a centralised system (e.g. internet connected server). Additionally or alternatively, the messaging service may comprise a peer-to-peer system (i.e. the nodes 4 communicate directly). The node 4 then awaits/listens for any messages from the system.

The nodes 4 may be allocated to a queue or ad hoc group etc. The queue/group order may be determined on time of connection to the messaging service (e.g. “first come first serve”). The number of nodes 4 in each queue/group may be determined according to the number of nodes 4 allowed for each block 12. Thus, the nodes 4 may be pre-allocated for a given block 12.

The node 4 creates a record 8 containing data relating to a transaction. The record 8 may then be divided in two or more parts in accordance with the desired regime. The node 4 may divide the record 8 in the respective parts. Additionally or alternatively, the system 2 or other nodes 4 divided the record 8 in the respective parts.

The node 4 sends a message to the messaging system to indicate that a new record 8 is desired to be stored on the system 2. The message is received by the other nodes 4. Each of the nodes 4 then sends a similar message accordingly. Each record part is appended or otherwise linked to the message. Thus each node 4 in the queue/group receives the record part from one or more of the other nodes 4. Where the blocks 12 are interleaved, record parts may be sent to nodes 4 not included in the present block allocation (i.e. nodes 4 that may form the next part of one or more subsequent block).

A node 4 is selected to be a block proposer from the nodes 4 waiting to enter a record on the block. The proposer may be selected according to any suitable algorithm. For example, the proposer may be randomly selected. The proposer creates a new block 12. The new block comprises the reference identifier 42 (e.g. the previous block proposer’s signature). Record parts for the new block and from any subsequent block are incorporated into the block 12. A “proposal” message is sent to the remaining nodes 4 a new block is created.

The block 12 is then validated. Upon reception of the proposal message, the given node 4 then becomes a counterparty (e.g. voter) for the given block 12. Each node 4 then validates the records 8 in the block 12 accordingly. Validation is provided by a known process and will not be described further. Once validation is complete, a validation signature is created by each validation node 4. The validation signature is sent to a block completor and/or the other nodes 4.

When the records 8 are interleaved, it can be appreciated that validation of a plurality of blocks 12 may occur simultaneously. Thus a given node 4 may validate a plurality of blocks 12 simultaneously.

After validation, a completion stage begins. The completor may be selected according to any suitable algorithm (e.g. randomly selection). In some embodiments, the completor may be the proposer. The completor determines when validation is complete and sends a message to the remaining node 4 accordingly. In some embodiments, validation is deemed complete after a predetermined period of time. This ensures transactions are completed quickly. Additionally or alternatively, validation is deemed complete when a predetermined proportions of counterparties have completed validation (e.g. when the completor has received their respective signatures). Typically, the predetermined proportion of validations nodes is 100%. In other embodiments, the predetermined proportion of validations nodes is greater than 50%; preferably, greater than or equal to 75%; greater than or equal to 90%.

The completor identifier 48 (e.g. signature) is recorded onto the block. A hash 16 of the block 12 may be created for inclusion into the subsequent block. The hash 22 of the unvalidated data 18 of the subsequent block 12 is recorded. The block 12 is finalised and stored on the ledger 2 as a completed block.

Once the block 12 is completed, the process can be repeated. However, it can be appreciated, that new blocks 12 can be created and validated before a given block 12 is completed.

In a specific embodiment, the ledger system 2 may be utilised by a central bank, reserve authority, or other monetary authority. Such institutions may manage the currency/monetary policy of a state or formal monetary union and/or may oversee their commercial banking system. Examples include the Bank of England, the European Central Bank, and the US Federal Reserve. The ledger system may therefore be used to transfer money between one or more of, inter alia: the central bank; investment bank; commercial bank; merchant; individual; foreign entity; or other transaction individual. For example, the system 2 may facilitate inter-bank transactions.

The system 2 may be used to transact a conventional fiat currency. The system 2 may incorporate or run in parallel with the fiat currency. In other embodiments, the system 2 may be used to transact a “digital coin” or fungible token. The digital coin may be controlled and/or overseen by the central bank. Creation/distribution (e.g. “minting”) of the digital coins may be performed/authorised by the central bank.

The system 2 may be further used to facilitate consumer electronic payments, for example, using conventional electronic cards, or using purely digital systems.

It can be appreciated the system 2 is versatile and may find use in any number environments, for example, inter alia: inventory/stock management; logistics (i.e. the transfer of goods between different parties); data sharing/distribution (e.g. cloud computing; network monitoring; asset or equipment health monitoring; equipment control/operation management); exchange of stock, equites or other financial products; digital content marketplaces (e.g. NFT marketplaces); cross-border transactions/exchange; identification systems (e.g. digital identities). The system 2 may be used in any situation where a plurality of parties require a secure, distributed transaction system.

In the present embodiment, the present block interleaving arrangement, consensus mechanism, and back-linking arrangement are provided (i.e. all three are provided in a single system). However, it can be appreciated that each of the arrangements is capable of operating in isolation to one another. Thus, in some embodiments, only one or two of the arrangements may be provided. For example, the consensus mechanism may comprise a conventional “proof of work”, “proof of stake” or other conventional mechanism. In some embodiments, only the back-linking arrangement may be provided. The system may then use the conventional hash arrangement shown in figure 1 .

The validation nodes, central authority and/or any other party in the system comprise any suitable hardware/software as previously described.

The present arrangement provides a secure mechanism to transfer data. The interleaving of the records significantly reduces the ability of a bad actor to attack the blockchain, due to exponential overlap of transacting nodes required to perform an attack. The blocks are linked in both a forward and a backward direction. This further increases the difficulty in attacking the system.

The validation system incentivises parties to participate in the validation, thus reduces the likelihood of attack. Allowing simultaneous creation and/or validation of blocks increases parallel processing in the system. This allows a significantly improved effective transaction rate. Due to the improved transaction volume/speed, the present system may be suited for large scale systems, such as those used by central banks or electronic card payment vendors.

Whilst the above description concerns the details of financial transaction records for the most part, the invention has found application in a variety of other applications. In one such application, the invention is used to provide records of operation and control of infrastructure equipment. For example, the record system is used to create logs of sensor data, machine/operational settings and/or control instructions implemented using the equipment. The record system thus provides a secure record system that can validate real records in a manner in which the records cannot be tampered with or added to by another party. The record system can achieve this at high speed such that it can be suitable for the vast volumes of operational data that might need to be captured.

Similarly, the invention may be used for other exchanges of data, information or assets between individuals or operators in a system beyond financial or economic transactions.