GB2549075A

GB2549075A - Device, method and system for a distributed ledger

Info

Publication number: GB2549075A
Application number: GB1605123.7A
Authority: GB
Inventors: Quinn Brendan
Original assignee: Mount Watatic Ltd
Current assignee: Mount Watatic Ltd
Priority date: 2016-03-24
Filing date: 2016-03-24
Publication date: 2017-10-11
Anticipated expiration: 2036-03-24
Also published as: GB201605123D0; WO2017163090A1; GB2549075B

Abstract

A device 100 for providing a node in a distributed ledger, such as a blockchain, has a casing 104 which at least partly encloses a processor 101 configured to match transactions and a memory 103 configured to store transactions received from other nodes. When the casing 104 is compromised, at least a part of the device 100 is rendered non-functional such that the node may be tamper-proofed against a bad actor. Preferably, transaction data or encryption keys stored in the memory 103 are rendered inaccessible or destroyed by a battery powered circuit (figure 10) which applies a voltage to the memory 103 when the casing 104 is opened. The casing 104 may be fitted with radio frequency shielding. All nodes in the distributed ledger may be provided on such a device 100.

Description

Device, Method and System for a Distributed Ledger Field of Invention

The present invention is in the field of distributed ledger systems. More particularly, but not exclusively, the present invention relates to a secure node for a distributed ledger system.

Background

Market trading platforms today have evolved from models based on the physical exchanges they have replaced. In the most common models, transaction flow proceeds as follows: 1) Traders (either individuals or companies) write orders into an incoming order book. 2) A Matcher runs and: a. reads the incoming order book b. matches bids to quotes c. removes matched orders from the incoming order book d. writes matched orders to a matched order ledger

In these models, a Trader who wants current market information must query both the single Incoming Order Book, and the Matched Order Ledger. While there may be a single market interface presented, the interface, Incoming Order Book, and Matched Order ledger are all hosted and maintained by the exchange provider, and a Trader queries a market interface, which queries the Incoming Order Book, and Matched Order Ledger on the Trader’s behalf.

In most implementations of these models, platform throughput (maximum possible volume of orders) is a function of Matcher efficiency. The more quickly orders are removed from the incoming order book, the more orders the platform can handle.

Current implementations also aim to enforce a defined sequence for incoming orders. Several mechanisms are used, which vary by implementation. The most common solution is to use a Single Writer Pattern. In a Single Writer Pattern, all incoming orders are written to a logical queue, usually implemented on a single physical machine. Distributed solutions exist, but can add to the inherent latency of the trading. This is generally deemed to be a negative in trading, as it typically directly affects exchange throughput.

Limitations of distributed solutions has meant that existing implementations are normally only able to operate in a single datacenter, with all parts of the system under the control of a single provider.

There can be no doubt that existing trading exchanges work. However, problems have become apparent, as high frequency trading strategies have emerged. One persistent problem is that of network speeds and switching latency. Networks are not perfect, and latency is governed by fundamental physical laws. The farther in network terms a Trader is from the Single Writer (whether machine or network), the greater their disadvantage in every transaction. In the context of a single trading exchange, this can be (and has been) partly mitigated by exchange providers selling datacenter space in the same datacenter as the Single Writer. This, in effect, creates a two-tier system for Traders. Traders who can afford to purchase datacenter space from the trading exchange provider, can purchase a permanent advantage in the markets provided by that exchange. Traders who cannot, are at a permanent disadvantage. This also forces institutional players to either go through an existing brokerage or invest in establishing full trading teams, in order to execute their large orders.

The problem grows even more complex when multiple trading exchanges are considered. Traders who can purchase private exotic network links between datacenters where trading exchanges are located can (and have) gain significant advantage by shaving milliseconds off of transfer latencies. In 2010, Forbes Magazine estimated the cost of these network links at $700 million, in order to save 3ms.

Another disadvantage of these models is that the requirement for a centralized Incoming Order Book, Matcher, and Matched Order Ledger has meant that Trading Exchange platform providers typically also must provide both fulfilment and market operations services to Traders. The latter includes functions such as opening and closing markets, responding to regulators, and on occasion, unwinding trades. This leads to significant inefficiencies, and presents a barrier to the formation of smaller private markets among Traders.

These problems are a natural consequence of existing trading exchange models, and their implementations around the world.

It is an object of the present invention to provide a device, method and system for a distributed ledger which overcomes the disadvantages of the prior art, or at least provides a useful alternative.

Summary of Invention

According to a first aspect of the invention there is provided a device for providing a node in a distributed ledger, including: A processor configured to match transactions; A communications apparatus configured to receive transactions from a plurality of devices each providing a node in the distributed ledger; A memory configured to store transactions in a transaction memory pool; and A casing configured to enclose, at least in part, the memory and the processor;

Wherein, at least part of, the device is modified into a non-functional state when the casing is compromised.

At least part of the memory may be modified into a non-functional state when the casing is compromised. The at least part of the memory may be modified such that data stored within the at least part of the memory is rendered inaccessible. The transaction memory pool may be rendered inaccessible. At least part of the memory may be destroyed to render it inaccessible. The at least part of the memory may be destroyed via one or more of the following: voltage, heat, acid, cold, explosives, or mechanical force applied to the at least part of the memory.

The casing may include radio frequency shielding to inhibit detection of electrical activity within the casing outside the casing.

The memory may be further configured to store one or more encryption keys and wherein the processor is further configured to decode transactions received from the plurality of devices using the one or more encryption keys. The one or more encryption keys may be rendered inaccessible. The processor may be further configured to encode transactions transmitted to the plurality of devices using the one or more encryption keys.

The device may be further configured to receive transactions from a user of the device. The device may be further configured to validate the transactions received from the user. The device may be further configured to broadcast the transactions received from the user to each other node within the distributed ledger.

The transactions may comprise both bids and quotes for a trading market.

The transactions may comprise both bids and quotes for a plurality of trading markets.

The processor may be configured to match the transactions in accordance with a deterministic matching algorithm.

Each of the plurality of devices providing a node in the distributed ledger may be a device as claimed in the above claim.

The processor may be configured to group valid transactions into a block, to calculate a satisfactory hash for the block based upon a previous consensus block in a chain of blocks, to broadcast the block to the other nodes, and to use the longest chain of blocks to replace the consensus block. The processor may match transactions within the consensus block.

The distributed ledger may be a blockchain.

Transactions within the memory pool may be inaccessible to a user of the device until approval is received from a commit and reveal module executing at the device. The commit and reveal module may utilise a time delay calculated based upon network distances to other nodes.

According to a further aspect of the invention there is provided a system for providing a distributed ledger, including: A plurality of devices, each device as claimed in any one of claims 1 to 22; and A communications system configured to enable each of the plurality of devices to communicate with one another.

According to a further aspect of the invention there is provided a method for providing a node within a distributed ledger, including: a) receiving transactions at a device; b) storing the received transactions in a memory pool at the device; c) matching transactions at the device; and d) rendering at least a part of the device non-functional when a casing of the device is compromised.

The method above may further include the step of determining a consensus block of transactions. The transactions may be matched within the consensus block. The consensus block may be received at the device from one of a plurality of other devices. The device may be as described in relation to the first aspect.

According to a further aspect of the invention there is provided a device for providing a node within a distributed ledger wherein at least a part of the device is modified into a non-functional state when the device is physically compromised.

Other aspects of the invention are described within the claims.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1: shows a block diagram illustrating a device in accordance with an embodiment of the invention;

Figure 2: shows a block diagram illustrating a system in accordance with an embodiment of the invention;

Figure 3: shows a flow diagram illustrating a method in accordance with an embodiment of the invention;

Figure 4: shows a block diagram illustrating shared ledgers in accordance with an embodiment of the invention;

Figure 5: shows a sequence diagram illustrating three verification stages of an embodiment of the invention;

Figure 6: shows a block diagram illustrating matching algorithms used with shared ledgers in accordance with an embodiment of the invention;

Figure 7: shows a block diagram illustrating an exemplary trading sequence in accordance with an embodiment of the invention;

Figure 8: shows a block diagram illustrating multiple trading markets in accordance with an embodiment of the invention;

Figure 9: shows a block diagram illustrating an exemplary communications system in accordance with an embodiment of the invention; and

Figure 10: shows a circuit diagram illustrating a voltage-based memory destruction means in accordance with an embodiment of the invention.

Detailed Description of Preferred Embodiments

The present invention provides a device, method and system for a distributed ledger.

The inventor has determined that a distributed ledger (such as blockchain) can be used to provide a transaction matching system (such as a market trading platform). The advantages of utilising a distributed ledger is greater resilience for the matching system (i.e. greater uptime), increased speed due to distributed processing, more equality for traders, and greater transparency.

However, the inventor has concluded that nodes for distributed ledgers for a transaction matching system may be susceptible to unfair trading practices if in the physical possession of a bad actor.

The inventor has discovered that a node can be suitably configured for use with a distributed ledger such that the node is rendered non-functional, at least in part, when physically compromised or tampered with. With such nodes, the effects of bad actors may be mitigated and/or eliminated in a distributed ledger system.

In Figure 1, a device 100 for providing a node in a distributed ledger in accordance with an embodiment of the invention is shown.

The device 100 comprises a processor 101, a communications apparatus 102, a memory 103, and a casing 104.

The processor 101 is configured to match transactions. The processor 101 may be configured for processing received transactions to reconcile the transactions with each of a plurality of devices providing nodes within the distributed ledger. The process of reconciliation may include sequencing of the transactions. The sequencing may be such that the transactions share the same sequence as each of the plurality of nodes. The processor 101 may reconcile the transactions by grouping valid transactions into a block, calculating a satisfactory hash for the block based upon a previous consensus block in a chain of blocks, broadcasting the block to the other nodes, and using the longest chain of blocks (i.e. either using blocks received from the other nodes or the present device’s block) to replace the consensus block.

The processor 101 may be configured to match the transactions in accordance with one of a plurality of matching algorithms. The matching algorithms may be deterministic and may include “First Match”, “Auction”, “Dutch Auction”, and/or “Volume Weighted”. It will be appreciated that the list of algorithms is exemplary only and that other matching algorithms may be utilised.

The processor 101 may be configured to match transactions within the reconciled transaction (e.g. within the consensus block).

The communications apparatus 102 is configured to receive transactions from the plurality of devices. The communications apparatus 102 may be further configured to transmit transactions to the plurality of devices. The communications apparatus 102 may be further configured to transmit and receive transaction blocks to/from the plurality of devices.

The device 100 may also include an input apparatus 105 configured to receive transactions from one or more traders. The processor 101 may be further configured to validate these received transactions before communicating the received transactions via the communications apparatus to each of the plurality of devices (e.g. broadcasting the transactions).

The memory 103 is configured to store a transaction memory pool. The memory 103 may be further configured to store a reconciled transaction list. In one embodiment, the transaction memory pool may be encrypted by one or more encryption keys and the processor 101 may be further configured to decrypt the memory pool. In this embodiment, the processor 101 may be a FPGA (field-programmable gate array) incorporating the one or more encryption keys in hardware or the encryption keys may be stored in a portion of the memory 103.

The memory 103 may include mutable memory (such as RAM or flash memory) for dynamic data such as transactions and immutable memory (such as ROM) for static data such as encryption keys. It will be appreciated that, in this context, immutable memory also includes difficult to modify memory such as EPROMs.

The device 100 may be configured for encoding and decoding transmission and reception of transactions to and from the plurality of devices using one or more encryption keys. In one embodiment, the processor 101 is further configured for encoding and decoding the transmissions, and the memory is further configured for storing the encryption key(s).

The casing 104 is configured to enclose at least a part of the device 100. In one embodiment, the casing 104 encloses the entire device 100. In another embodiment, the casing 104 encloses the processor 101 and a portion of the memory 103 configured for storing the memory pool and/or the encryption keys. A secondary casing may enclose all portions of the device 100 not enclosed by the casing 104.

In one embodiment, the casing 104 provides RF (Radio Frequency) shielding or otherwise inhibits interception or interference with the electrically functioning of the device 100. In one embodiment, the device 100 further includes an active interference apparatus to prevent or inhibit the interception or interference of the electrically functioning of the device.

The device 100 is configured such that at least a part of the device 100 is modified into a non-functional state when the casing 104 is compromised. In one embodiment, modification into a non-functional state include modifications which prevent accurate analysis of or access to transactions stored in the memory pool. In one embodiment, modification into a non-functional state include modifications which prevent access to one or more, or all the encryption keys. Modifications may include damage or destruction caused to at least part of the hardware such as the memory 103 and/or processor 101 storing transaction and/or encryption data (e.g. damage may be caused to the portion of the memory storing the memory pool). The device 100 may be configured to damage or destroy the hardware via one or more of the following: voltage, heat, acid, cold explosives or mechanical force. In one embodiment where the memory pool is encrypted, only the memory 103 storing the encryption keys may be destroyed or damaged (or the keys rendered otherwise inaccessible).

In one embodiment, the device 100 may be configured to provide access to the transaction memory pool to the one or more traders. Access may be provided in accordance with a commit & reveal algorithm. The commit & reveal algorithm may utilise a time delay calculated based upon network distances to other nodes.

The device 100 may further include an output apparatus 106. The output apparatus 106 may be configured for communicating matched transactions to the one or more traders.

In Figure 2, a system 200 for providing a distributed ledger in accordance with an embodiment of the invention is shown. A plurality of devices 201, 202, 203, and 204, each device as described in relation to Figure 1, are shown. A communications system 205 is also shown. The communications system 205 may include a network such as a private network. The network may be a virtual network overlaid on top of a physical network or internetwork (such as a VPN (virtual private network) overlaid on a LAN, WLAN or the Internet). In one embodiment, the network is an entirely private network (e.g. using the 802.1x protocol) or a physically private network (e.g. using non-public signalling mechanisms).

In one embodiment, the distributed ledger within the system 200 is actuated via the blockchain methodology. However, it will be appreciated that other distributed, append-only data store methods may be used.

Transactions within the distributed ledger may comprise bids and quotes for a single or multiple trading markets. Each trading market may be associated with an entity who provides fulfilment services and an entity who provides market operations. In one embodiment, each trading market is associated with a defined matching algorithm and/or at least one defined encryption key. The system 200 may be configured to utilise the defined encryption key to encode transactions for a market such that only the devices of participants in the market may interact with transactions for that market.

Each of the devices 201 to 204 may be utilised by one or more traders.

One or more of the devices 201 to 204 may be physically located at the premises of a trader (or trading firm) or broker or trader consortium. One or more of the devices 201 to 204 may be physically located within a hosted environment.

Referring to Figure 3, a method 300 for providing a node in a distributed ledger in accordance with an embodiment of the invention will be described.

In this embodiment, the node is being provided by a device. The device may be the device described in relation to Figure 1.

In step 301, transactions are received at the device. Transactions may be received from a plurality of devices within a distributed ledger system (e.g. as described in relation to Figure 2), and/or from one or more traders via an input apparatus (e.g. 105) at the device.

In step 302, received transactions are stored in a memory pool (e.g. in a memory pool at memory 103).

In step 303, transactions are matched (e.g. by processor 101). Transactions may be matched within reconciled transactions. Reconciled transactions may be transactions that have been distributed to each of the plurality of devices (e.g. 201 to 204) and sequenced across the distributed ledger system (e.g. 200), for example, and at least part by a distributed ledger methodology such as blockchain such that the reconciled transactions are those within the consensus block.

In step 304, at least a part of the device may be rendered non-functional when a casing (e.g. 104) is compromised.

Embodiments of the invention will now be described with reference to Figures 4 to 10.

These embodiments relate to secure, distributed network-attached ledger, which provides the means to establish a trade, and thus form the basis of a new type of trading exchange which prevents certain types of unfair trading practices (specifically network-latency-based arbitrage), and which enables new types of market models. It does this providing a distributed, non-repudiable ledger, made up of nodes which communicate with each over a private network (whether physical or virtual). The ledger is provided by means of a block-chain, and the ledger-nodes themselves are contained in secure cases, which cannot be opened without destroying their usefulness.

Model

These embodiments implement an alternative model for a trading exchange, designed to account for conditions existing in wide area networks. Specifically, the embodiments prevents timing and network distance from being exploited in such a way as to privilege a subset of Traders.

This model presented uses a distributed, append-only data store as a Shared Ledger. Transactions can be entered, but once entered can never be removed. Every Trader maintains their own copy of the Shared Ledger (on their own premises), and interacts directly with it, while the Ledgers themselves are constantly being reconciled across the network (see Figure 4).

With reference to Figure 4, note that the Ledger Nodes are not required to be on the physical premises of a Trader; however, it would be the responsibility of the Trader to place the Node in a trusted network, which might be that of a hosting provider.

Note also that a Trader in this context need not be an individual trader. A Trader could be a trading firm, where the Ledger is used by their employees, or a consortium of traders, or indeed a broker who allows their customers to place orders into their Ledger Node. Thus, in this sense, a Trader may be considered any participant in a market who maintains a Ledger Node and takes responsibility for the transactions entered into that Node. Note also that a single Trader may run more than one node. A Trader may even, exchange rules permitting, run more than one node of a single Trading Exchange. Regardless, care must always be taken to ensure that a single Trader does not control the majority of a single Trading Exchange’s processing power.

In order to function as the basis of a trading exchange, there are several constraints placed on the reconciliation process. In one embodiment, reconciliation consists of three stages (see Figure 5):

With reference to Figure 5: 1) Stage 1, Validation: This ensures that all orders are valid. 2) Stage 2, Ensuring Uniformity: All orders which have passed this stage may be considered to have been entered into all instances of the Shared Ledger. 3) Stage 3, Sequencing: This ensures that the sequence of those orders in all instances of the Shared Ledger is the same.

In order to prevent exploitation of network effects and in one embodiment, orders are not made visible to other Traders until they have passed the second reconciliation stage.

Once orders have been fully reconciled, every Trader has an identical copy of the reconciled Ledger. A Matcher can then run over any instance of the Shared Ledger. So long as a deterministic algorithm is used for the Matcher, the same result will be obtained, regardless of instance. This implies that matched orders do not need to be removed from the Shared Ledger, nor do matches need to be written anywhere. The Matcher process can simply be run over the Shared Ledger as needed, to determine market state.

The generic type of algorithm used for the Matcher is not limited by the mechanism used to reconcile the shared Ledger. Algorithms such as ‘First Match’, ‘Auction’, ‘Dutch Auction’, ‘Volume Weighted’, and ‘Value Weighted’, are possible, as well as many others. Even an open outcry auction conducted via video or voice conferencing would be possible, although in the that case the actual matching would be done by the human conducting the sale, who would enter the match as a transaction into the ledger. Any Matcher algorithm implemented in software would be minimal. Matching possibilities are also not limited to price, instrument, etc. Any criteria which is agreed by participating Traders, and can be expressed either entirely in the transactions contained in the Ledger, or in combination with data available to all Traders, is possible. An example of the latter case would be a market where matches were constrained by delivery distance. If the location of origin and delivery were expressed in the relevant transaction (quote or bid), the distance could be determined at match time. Any constraints presented by the choice of Ledger reconciliation mechanisms are likely, however, to have implications for market semantics, and may also influence Trader behaviour.

The full trading sequence will be described with reference to Figure 6: 1) Orders are placed into a local Shared Ledger instance 2) Traders run independent instances of the Matcher against a local Shared Ledger instance: a) Matcher examines only fully reconciled transactions b) matches bids to quotes 3) Reports matched orders to the Trader

Note that in implementations of this model, maximum exchange throughput is a function solely of the efficiency of the reconciliation process, not Matcher efficiency.

The Shared Ledger model also has implications for market operations and fulfilment. An example will be described: consider a group of Traders named Alice, Bob, Carol, and David, who each possess a Shared Ledger Instance. Initially, they use this to trade baseball cards. They agree on a Matcher algorithm to use, and Alice offers to provide fulfilment services, as she sees Bob, Carol, and David regularly, and baseball cards are easily portable. She also agrees to provide market operations, and ensure that the market is closed when she is away on her annual holiday. They all begin to trade (see Figure 7).

With reference to Figure 7: 1. Alice submits a quote to the Shared Ledger to sell 300 assorted 1950s baseball cards at a unit price of $1, and 400 assorted 1960s baseball cards at a unit price of $0.50, with a minimum quantity of 50 cards. 2. Carol submits a bid to the Shared Ledger to buy between 50 and 75 assorted 1950s baseball cards at a unit price of $1. 3. Bob and David both submit bids to the Shared Ledger at roughly the same time. Bob bids to buy a maximum of 300 assorted 1950s baseball cards at a unit price of $1, and a maximum of 50 assorted 1960s baseball cards at a unit price of £0.50. David bids to buy a maximum of 200 assorted 1950s baseball cards at a unit price of £1.05, and a maximum of 300 assorted 1960s baseball cards at a unit price of $0.75. 4. Carol submits a bid to the Shared Ledger to purchase a maximum of 500 assorted 1960s baseball cards at a unit price of $0.50

After the reconciliation process is complete, the sequence of orders in the ledger is as follows: [AliceQuotel, CarolBidl, DavidBidl, BobBidl, CarolBid2]

The Matcher algorithm sees only the sequence in the ledger, and does not handle incoming orders. If using a simple ‘First Match’ algorithm, this sequence would result in: • Carol purchases: o 75 x 1950s baseball cards for $1 each o 150 x 1960s baseball cards for $0.50 each • Bob purchases: o 125 x 1950s baseball cards for $1 each o 50 x 1960s baseball cards for $0.50 each • David purchases: o 100 x 1950s baseball cards for $1.05 each o 200 x 1960s baseball cards for $0.75 each

Note that if the Matcher had used a ‘Best Price and First Match’ criteria instead, this would have resulted in: • Carol purchases: o 75 x 1950s baseball cards for $1 each o 50 x 1960s baseball cards for $0.50 each • Bob purchases: o 25 x 1950s baseball cards for $1 each o 50 x 1960s baseball cards for $0.50 each • David purchases: o 200 x 1950s baseball cards for $1.05 each o 300 x 1960s baseball cards for $0.75 each

After some time has passed, Carol decides to offer a market in bicycles. She approaches Alice, David and Bob and proposes the scheme. Alice and David agree to participate, but Bob declines. Alice, David and Carol agree to use the Shared Ledger, and an algorithm for the Matcher. They also agree that Carol will provide Market Operations and Fulfilment (see Figure 8).

With reference to Figure 8, note that transactions in the bicycle market will be visible to Bob, as they will exist in the Shared Ledger. If the participants in the bicycle market desire privacy, they can include an encoding scheme, which may include forms of cryptography in the Bicycle Market order placement, and Matcher. If this is done, Bob can see that transactions are happening, but not what they are.

For example, consider that the above participants do desire privacy in the bicycle market (as they do not trust Bob). When Alice, David, and Carol meet, they agree on both a Matcher algorithm and a shared key. The key is incorporated into the Matcher algorithm and distributed on USB keys to each of them. Orders into this market are then encrypted with this key, creating a ciphertext. This ciphertext is placed into a Node, where it is tagged with a market ID. The Matcher looks for transactions in the distributed Ledger for orders with its market ID, decrypts the cyphertext, and matches orders in exactly the same way as a non-private market. Note that while this example considers one type of cryptography (symmetrical), and key distribution (physical), most common types of cryptographic and key distribution mechanisms that are agreed by market participants should suffice.

Note that this model means that ensuring the validity of individual transactions in individual markets becomes the responsibility of the Matcher, rather than of the block chain transaction validation rules. The latter can only ensure that the orders themselves follow the rules of the overall exchange. If the transaction themselves are opaque to the Ledger validation process, the Matcher Algorithm must incorporate its own validation mechanism, specific to the market where that Matcher runs.

Further markets can be layered into the Shared Ledger in a similar fashion; market operations and fulfilment services can be distributed between participants in any manner, so long as they all agree.

Implementation

An exemplary implementation for the Shared Ledger based on a block chain, as defined in “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto (https://feitcoin.org/bitcoin.pdf), will now be described: A block chain functions as a distributed, append-only data store that has the following properties: 1) Transactions are entered into the Memory Pool on a node. 2) Those transactions are broadcast to all nodes, and put into the Memory Pool on every node that receives them. 3) Nodes attempt to put transactions in the Memory Pool into blocks, by: a. Verifying that the transactions are valid b. Grouping valid transactions together c. Calculating a mathematical hash of the group, along with a timestamp d. Checking to see if the hash matches a pre-determined “difficulty factor” (Note: The difficulty factor has the property that the number of hash calculations required to successfully create a block increases exponentially as the factor increases, while blocks can be verified by calculating a single hash.) e. If successful, the new block is sent to all other nodes, along with the timestamp of the previous block (thus “chaining” the blocks together). f. Whenever a node receives a new block chain from another node, it always uses the longest chain as the basis for its own verification work. 4) Over time, the chain will converge, as the amount of work required to replace the consensus blocks becomes infeasible. (Note: In the Bitcoin block chain today, this is believed to be six blocks deep.)

Note that ordering in a block chain is a function of the block chain algorithm. The order of transactions in a converged block chain may bear no resemblance to the order they were received. However, the block chain mechanism does guarantee that once the block chain has converged, the transactions are in the only possible sequence. This means that as blocks are immutable, Matcher operation over a converged block chain will be deterministic.

This also implies that from the perspective of the block chain, all transactions in the Memory Pool must be seen as happening simultaneously. Therefore, while the block chain can provide the first and third stages of reconciliation required by the model presented, it does not provide the second.

Specific implementations of embodiments of the invention may incorporate modifications to the above exemplary implementation to optimise the implementation for the specific markets it is expected to handle. For example: changes to the hashing algorithm and difficulty factor to optimise for performance; changes to the structure of the memory pool or verification rules to disincentive specific behaviours in specific participant groups; changes to transaction verification rules, etc.

Network Effects, Bad Actors and the Memory Pool

In order to account for network effects, in some embodiments, transactions in the Memory Pool must not be directly visible to Traders. The obvious solution is to make transactions in the Memory Pool only visible through an interface that maintains a table of network distances to all other nodes, and ensures that no transaction is visible until sufficient time has passed for network propagation to take place. This type of system in exchange platforms is often called a ‘Commit and Reveal’ system, but similar algorithms as used in Internet content distribution networks (CDNs), and other data caching systems may also be suitable. ‘Commit and Reveal’ systems are a common part of many economic systems. One common example in the real world is a sealed bid auction. In this model, a piece of property is put up for sale, with bidders invited to submit bids in sealed envelopes by a specific date and time. At a specified time after the submission deadline, all envelopes are opened and the highest bidder wins the auction. ‘Commit and Reveal’ algorithms are commonly implemented in software in turn-based, multiplayer strategy games. For example: 1) Turn Begins 2) Players are invited to submit their moves. 3) When all player moves have been received: a. All moves are executed on the game board simultaneously b. Conflicting moves are resolved according to the game rules 4) The new state of the game board is revealed to all players 5) Turn Ends A ‘Commit and Reveal’ system alone may not be sufficient to prevent malicious behaviour by Bad Actors who run Ledger Nodes. This is especially true in this model, as Traders may be considered to have physical access to Shared Ledger nodes.

Note that visibility of the memory pool may not necessarily give a Bad Actor an exploitable advantage. However, such visibility may be a necessary precursor to an entire category of theoretical attacks.

Attack Vectors

These are the attack vectors that could be considered: 1) A cheat may attempt to run different software on a Ledger node. 2) A cheat may attempt to read the contents of the Memory Pool off of the network during transfer between nodes. 3) A cheat with access to the underlying operating system of a Ledger node may attempt to read data directly. 4) A cheat with access to the physical machine which runs a Ledger node may attempt to read data: a) by manipulating the hardware directly. b) by passively monitoring the radio spectrum near the physical machine.

Embodiments of the present invention prevent the first two vectors by requiring Ledger nodes to use a virtual private network (VPN) to connect to each other. If only known nodes with encryption keys signed by a trusted authority can connect, the first vector is prevented. The VPN itself encrypts the traffic, thereby preventing the second vector. However, the third and fourth vectors remain. They also imply that any encryption keys could also be read by an attacker, thus bypassing this solution and re-enabling attacks via the first two vectors. However, other implementations are possible, so long as they provide both strong node authentication, and incorporate an encoding scheme which may include forms of encryption for all communications.

One example alternate implementation uses an entirely private network, incorporating the 802.1x (https://en.wlklpedla.org/wik!/IEEE„802.1X ) protocol for node authentication, (see Figure 9).

In the example shown in Figure 9, nodes are issued as a credential, an X.509 certificate signed by the private key of a Trusted Signing Authority(TSA). X.509 certificates incorporate the public key corresponding to a private key generated by the node. This signature may be verified using the corresponding public key. The Authentication Server holds a copy of that public key, and is configured to validate credentials signed by the TSA. When a node attempts to connect to the network: 1) the router demands a credential before the node is allowed to connect 2) the node provides a credential to the router 3) the router forwards the credential to the Authentication Server for validation 4) If the credential is successfully validated by the authentication server, the node is given access to the network

In this example, nodes communicate using Transport Layer Security (TLS) encryption (https://en.wikipedia.org/vviki./Transport....Layer...Security ) using the same certificate as a credential.

Another example might use purely physical means to protect the network. One mechanism by which this could be achieved is to use a private network which depends on non-public signaling mechanisms between switches. So long as access to network hardware could be strictly controlled (i.e. limited manufacture, highly tracked, etc.), access to the network could similarly be controlled. For example: if the only end-point network interfaces in existence were those already in use on a particular network, and no more could ever be made, that network would be secure enough to satisfy both requirements (although there would likely be concerns about that same network’s reliability). Note that this example does not make use of encryption in the mathematical sense (in that there is no ‘key’ as such).

Other examples of an alternative implementation operating entirely across public networks could rely entirely on application-level authentication and point-to-point application level encryption. Again, so long as nodes are authenticated, and traffic is encoded to a degree sufficient to deter eavesdroppers, the network (whether virtual, physical, or application layer) can be made secure enough to guarantee: • that only known Ledger nodes can connect to the network. • that only known Ledger nodes can read the traffic on the network.

However, each alternate implementation will place constraints on network operation in terms of performance, latency, how to provide resilience and redundancy, what level of attack will be deterred, etc. Therefore, the implementation chosen should closely match the constraints of the markets intended to be provided by the network.

How credentials are provided and authenticated can also vary without affecting the intended function of the invention. Above, the central authority ise considered as the credential provider, but other models are possible. For example, consider a model where in order to connect to the network, an aspiring Node Operator must obtain the approval of 30% of the existing Node Operators. Assume a private, physical, wide-area network with access control implemented at the router. Assume the all routers in the network maintain a distributed state table containing the public key of every node connected to the network. When a node attempts to connect: 1) the router demands a credential 2) the node presents a public key, along with all the signatures it has collected for that key 3) the router verifies as many signatures as needed/possible, using the distributed state table 4) If the public key presented has verified signatures of more than 30% of the nodes connected to the network: a. the node is allowed to connect to the network b. the public key for that node is placed into the distributed state table

Although the model chosen may constrain the implementation, any common model for credential provision and verification may be used.

The third vector is prevented by placing the Ledger nodes in a physical device which provides no access to an underlying operating system. The fourth vector may be addressed by using a secure physical case for the device, which has a security system fitted which has the following characteristics: 1) The case itself is fitted with radio frequency (RF) shielding, active interference device, or other means, sufficient to ensure that internal electrical activity cannot be detected outside the case. 2) When the case is opened, the device is selectively or entirely destroyed, permanently erased, or otherwise made inoperable. Typically, this includes: a) working RAM which contains the memory pool. b) static ROM which contains the encryption keys.

However, if the memory pool is encrypted, only the ROM containing the keys would need to be destroyed, permanently erased, or otherwise rendered inoperable. Additionally, if the encryption keys were themselves embedded in a hardware processing unit (FPGA or similar), then only the hardware processing unit would need to be destroyed, permanently erased, or otherwise rendered inoperable.

Note that, in some embodiments, while the underlying Operating System must be inaccessible while the node is in use, in most implementations it would not be necessary to destroy the OS on case open.

In one embodiment, a mechanism to implement the second requirement which is electrically based is used. This mechanism consists of a battery-powered circuit which, when the circuit is completed by opening the case, applies voltage to the memory chips which hold the required memory segments (see Figure 10). Other mechanisms are possible, so long as they destroy, damage or render inoperable the appropriate memory segments.

Note that for systemic exploitation of network effects to be prevented, preferably all the following parts are included within an implementation: 1) Block Chain or similar distributed ledger algorithm; 2) Commit and Reveal System to compensate for network latencies (if traders require access to the memory pool); 3) A Network which is secure enough to ensure: a. only authorized nodes may connect; and b. only authorized nodes may read network traffic; and 4) Secure Physical Case. A number of alternatives for elements of embodiments described above are envisaged by the inventor.

For example, alternative distributed ledger algorithms could be used; such as the algorithms used in Litecoin and HyperLedger. Variations to transaction verification rules, such as minimum order durations, could also be added to the block chain algorithm.

There are also a number of algorithms which could be used either together or separately in the Commit and Reveal system, which use alternative means to determine network propagation timings. In some cases, the Commit and Reveal system could be removed, if Traders are given no access whatsoever to the Memory Pool. This system could also be augmented with latency guarantee algorithms and external monitoring.

In relation to the secure physical case, several possible alternatives are described below: 1) In the simplest case, the case could be rigged to explode when opened. This may be less advantageous than other methods of destruction/damage. 2) The case could be fitted with a mechanical lock which physically destroys the memory as a consequence of allowing the case to be opened. For example: a metal rod could be threaded through the case such that it must be removed for the case to be opened. The rod would also be threaded in such a way that removing it from the case will snap the memory chips in half. 3) The case could be fitted with another device which physically destroys the memory chips by means of acid, heat, cold, or physical force when the case is opened. 4) Should the outer case need to be opened and closed regularly, the case could be fitted with an interior case which only encloses the required components, which itself is fitted with a device to enclose, and shield the critical components, and destroy them should the inner case be opened. However, these variants may also need to be fitted with additional measures to ensure that the device could not be operated while the outer case was open, and care would need to be taken to ensure that no direct electrical access to the components in the inner case was provided. A potential advantage of some embodiments of the present invention is that bad actors are unable to infer with the legitimate functioning of a distributed ledger even if they are in physical possession of a node in the distributed ledger.

While the present invention has been illustrated by the description of the embodiments thereof, and while the embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departure from the spirit or scope of applicant’s general inventive concept.

Claims

1. A device for providing a node in a distributed ledger, including: A processor configured to match transactions; A communications apparatus configured to receive transactions from a plurality of devices each providing a node in the distributed ledger; A memory configured to store transactions in a transaction memory pool; and A casing configured to enclose, at least in part, the memory and the processor; Wherein, at least part of, the device is modified into a nonfunctional state when the casing is compromised.

2. A device as claimed in claim 1, wherein at least part of the memory is modified into a non-functional state when the casing is compromised.

3. A device as claimed in claim 2, wherein the at least part of the memory is modified such that data stored within the at least part of the memory is rendered inaccessible.

4. A device as claimed in claim 3, wherein the transaction memory pool is rendered inaccessible.

5. A device as claimed in any one of claims 3 to 4, wherein the at least part of the memory is destroyed to render it inaccessible.

6. A device as claimed in claim 5, wherein the at least part of the memory is destroyed via one or more of the following: voltage, heat, acid, cold, explosives, or mechanical force applied to the at least part of the memory.

7. A device as claimed in any one of the preceding claims, wherein the casing includes radio frequency shielding to inhibit detection of electrical activity within the casing outside the casing.

8. A device as claimed in any one of the preceding claims, wherein the memory is further configured to store one or more encryption keys and wherein the processor is further configured to decode transactions received from the plurality of devices using the one or more encryption keys.

9. A device as claimed in claim 8, wherein the one or more encryption keys are rendered inaccessible.

10. A device as claimed in any one of claims 8 to 9, wherein the processor is further configured to encode transactions transmitted to the plurality of devices using the one or more encryption keys.

11. A device as claimed in any one of the preceding claims, wherein the device is further configured to receive transactions from a user of the device.

12. A device as claimed in claim 11, wherein the device is further configured to validate the transactions received from the user.

13. A device as claimed in any one of claims 11 to 12, wherein the device is further configured to broadcast the transactions received from the user to each other node within the distributed ledger.

14. A device as claimed in any one of the preceding claims, wherein the transactions comprise both bids and quotes for a trading market.

15. A device as claimed in any one of the preceding claims, wherein the transactions comprise both bids and quotes for a plurality of trading markets.

16. A device as claimed in any one of the preceding claims, wherein the processor is configured to match the transactions in accordance with a deterministic matching algorithm.

17. A device as claimed in any one of the preceding claims, wherein each of the plurality of devices providing a node in the distributed ledger is a device as claimed in the above claim.

18. A device as claimed in any one of the preceding claims, wherein the processor is configured to group valid transactions into a block, to calculate a satisfactory hash for the block based upon a previous consensus block in a chain of blocks, to broadcast the block to the other nodes, and to use the longest chain of blocks to replace the consensus block.

19. A device as claimed in claim 18, wherein the processor matches transactions within the consensus block.

20. A device as claimed in any one of the preceding claims, wherein the distributed ledger is a blockchain.

21. A device as claimed in any one of the preceding claims, wherein transactions within the memory pool are inaccessible to a user of the device until approval is received from a commit and reveal module executing at the device.

22. A device as claimed in claim 21, wherein the commit and reveal module utilises a time delay calculated based upon network distances to other nodes.

23. A system for providing a distributed ledger, including: A plurality of devices, each device as claimed in any one of claims 1 to 22; and A communications system configured to enable each of the plurality of devices to communicate with one another.

24. A method for providing a node within a distributed ledger, including: a) receiving transactions at a device; b) storing the received transactions in a memory pool at the device; c) matching transactions at the device; and d) rendering at least a part of the device non-functional when a casing of the device is compromised.

25. A method as claimed in claim 24, further including the step of determining a consensus block of transactions.

26. A method as claimed in claim 25, wherein the transactions are matched within the consensus block.

27. A method as claimed in any one of claims 25 to 26, wherein the consensus block is received at the device from one of a plurality of other devices.

28. A method as claimed in any one of claims 24 to 27, wherein the device is a device as claimed in any one of claims 1 to 22.

29. A device for providing a node within a distributed ledger wherein at least a part of the device is modified into a non-functional state when the device is physically compromised.

30. A device or method for providing a node in a distributed ledger as herein described with reference to the Figures.

31. A system for providing a distributed ledger as herein described with reference to the Figures.