GB2572627A

GB2572627A - Hybrid blockchain transaction system

Info

Publication number: GB2572627A
Application number: GB1805708.3A
Authority: GB
Inventors: Ells Richard
Original assignee: Electroneum Ltd
Current assignee: Electroneum Ltd
Priority date: 2018-04-05
Filing date: 2018-04-05
Publication date: 2019-10-09
Also published as: WO2019193363A1; GB201805708D0

Abstract

A cryptocurrency blockchain transaction system comprises an interface database system (IDS) 102 having a plurality of user and vendor cryptocurrency wallets and one or more transaction queues 110 which receive transactions between users 106 and vendors 108. Wallet worker units 112 of the IDS verify the queued transactions against the corresponding user wallets. IDS controlled blockchain nodes 114 are configured to blockchain process the verified transactions and submit them for addition to a master blockchain 105 maintained by a distributed blockchain network 104 comprising the IDS controlled nodes and a plurality of other blockchain nodes 116. Preferably, the worker units ring-fence a payment in the wallet associated with a queued transaction and confirm this to the vendor prior to blockchain processing by the IDS controlled nodes. Instantaneous-type transactions may be held in a second transaction queue and released for blockchain processing at times of off-peak system load. The system may enable cryptocurrency payments to be instantly confirmed, reducing delays associated with maintaining consensus of the blockchain. More generally, a blockchain transaction system comprising an IDS configured to receive and blockchain process transactions using one or more blockchains synchronized to a master blockchain is disclosed.

Description

HYBRID BLOCKCHAIN TRANSACTION SYSTEM [0001] The present application relates to a system, apparatus, methods for a hybrid blockchain transaction system including an interface database system for receiving transactions from users and/or vendors coupled to a distributed blockchain network for maintaining a master blockchain in relation to the transactions.

Background [0002] Decentralised or distributed blockchain systems and networks, hereinafter referred to as distributed blockchain networks, use blockchain nodes to perform computational processing to determine what the next block of the master blockchain will be given a set of transactions. Each node may have a full copy of the master blockchain and have to come to algorithmic consensus of what should be added to the next block on the master blockchain. Each of the nodes apply quite a few mathematical tests and look for consensus to the tests to make sure no-one is adding spoofed, erroneous or fraudulent transactions to the master blockchain. Forming consensus and adding a block to the master blockchain takes a lot of time and processing power.

[0003] In order to encourage nodes to contribute time and processing power to form each block, the nodes may get rewarded for their time, hardware and electricity etc. with something that is emitted from the blockchain. For example, entities such as miners may receive a reward such as a virtual coin, which is a by-product of a cryptocurrency blockchain to reward entities for contributing their computational power.

[0004] A consensus event occurs when each node produces a confirmation and when a majority of nodes agree on a particular block. Once this occurs, the master blockchain is updated with the new block in which a majority of nodes agreed consensus on. Consensus can depend upon the number of nodes communicating with each other, the percentage of market the node controls, position of node within hierarchy, level of satisfaction etc.

[0005] Most distributed blockchains from hyperledger through to cryptocurrencies rely on blockchain consensus to confirm a transaction has taken place and is legitimate. Due to the de-centralised nature of such blockchains there is a transaction delay of minutes or hours or even days before receiving confirmation that the transaction may proceed. Transaction delay is not the only problem of distributed blockchain systems.

[0006] Distributed blockchain systems also have difficulty scaling as the number of transactions and/or users increase. Most distributed blockchain systems have fixed block sizes, which means that as the number of transactions increase the blockchain system eventually has too many transactions that do not fit into the current block and so have to wait in a memory pool (mempool). The mempool is where transactions wait before being “picked up” by a miner for inclusion in a block. Miners will automatically choose the most profitable transactions. This leads to secondary problems, typically the less valuable a transaction is to miners, the longer the transaction stays in the mempool. For example, in a crypto currency blockchain, the nodes of miners typically process the most valuable transactions that currently have the highest fees. If the market moves forwards and is busy then a transaction with a low fee might be ignored in preference for one with a higher fee. This is especially true if the transaction size in kilobytes is large due it being made up of a number of smaller units of virtual coins (also known as dust). However, smaller transactions sizes are becoming common places as users and vendors start using the blockchain for small everyday transactions. Thus, these smaller sized less valuable transactions may be delayed in the mempool in favour of higher valued larger sized transactions, which introduces further delay in the transaction being confirmed. Typically, vendors will wait until a transaction is confirmed before releasing the product/services to a user.

[0007] Most distributed blockchains have this problem and are unsuitable for scaling with the number of transactions. This is also particularly troublesome for time sensitive applications in which any delay in confirming a transaction may be unacceptable or result in a penalty (e.g. monetary penalty, time penalty, etc.) to one of the parties to the transaction.

[0008] There is a desire to substantially minimise or eliminate the transaction confirmation delay in receiving confirmation that a transaction may proceed and a further desire for a blockchain transaction system that truly scales with a growth in transactions.

[0009] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of the known approaches described above.

Summary [0010] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter; variants and alternative features which facilitate the working of the invention and/or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention disclosed herein.

[0011] The present disclosure provides various system(s), apparatus, method(s) for a hybrid blockchain transaction system including an interface database system (IDS) for receiving transactions from users and/or vendors coupled to a distributed blockchain network for maintaining a master blockchain in relation to the transactions. For certain transactions of a particular type (e.g. instant type transactions), the IDS may have access to the necessary portions of the transaction on behalf of the user and/or vendor and act as a trusted third party between the user(s) and/or vendor(s) associated with these transactions. These transactions are so-called instant transactions, which are perceived to be completed by the user and vendor once the transaction is submitted to the IDS. Instant type transactions may include PUSH transactions (e.g. purchase transactions initiated by a user) and PULL transactions (e.g. subscription transactions initiated by a vendor in respect of a user and/or automatically by the IDS). This allows the IDS to process and complete the transaction prior to the transaction being added to the master blockchain of the distributed blockchain network. This provides the advantage that the transaction may be blockchain processed within the IDS at a time that is convenient to the IDS and/or the distributed blockchain network minimising blockchain processing load and also perceived delay in the transaction being completed between the user(s) and/or vendor(s). This system may be applicable to cryptocurrency systems, smart-contract systems, auction systems and any other blockchain transaction system that would benefit from instant transactions.

[0012] In a first aspect, the present disclosure provides a cryptocurrency blockchain transaction system comprising: an interface database system (IDS) including: a plurality of user and vendor cryptocurrency wallets; one or more transaction queues for receiving cryptocurrency transactions between users and vendors; a plurality of wallet worker units configured to retrieve cryptocurrency transactions from the one or more transaction queues, and verifying the cryptocurrency transactions in relation to the corresponding user cryptocurrency wallets; a plurality of IDS controlled nodes configured to blockchain process one or more verified cryptocurrency transactions and submit the blockchain processed cryptocurrency transactions for addition to a master blockchain in relation to the transactions; and the cryptocurrency blockchain transaction system further including a distributed blockchain network coupled to the IDS, the distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, wherein the distributed blockchain network is configured to maintain consensus of the master blockchain in relation to the transactions.

[0013] Preferably, one or more worker units are configured to: maintain a second transaction queue for cryptocurrency transactions identified to be of an instantaneous type, wherein the cryptocurrency transactions are kept in the second queue during detected transaction peak loads; release one or more cryptocurrency transactions of the instantaneous type from the second transaction queue to one or more of the plurality of IDS controlled nodes for blockchain processing and addition to the master blockchain during detected transaction offpeak loads.

[0014] Preferably, one or more worker units are configured, prior to placing a cryptocurrency transaction of the instantaneous type in the second transaction queue, to: determine whether a user cryptocurrency wallet is capable of handling a cryptocurrency payment associated with the cryptocurrency transaction; ring-fence the cryptocurrency payment in the user cryptocurrency wallet when the cryptocurrency wallet is capable of handling a cryptocurrency payment; confirm instant transaction success to the user and vendor associated with the cryptocurrency transaction.

[0015] Preferably, one or more worker units are configured to: receive confirmation from the master blockchain of the distributed blockchain network that the cryptocurrency transaction has been added to the master blockchain; and update the user cryptocurrency wallet by transferring the ring-fenced cryptocurrency payment to the vendor cryptocurrency wallet.

[0016] Preferably, the cryptocurrency transaction is a PUSH cryptocurrency transaction, the PUSH cryptocurrency transaction is submitted to the IDS by the user for transferring a cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with a vendor, the cryptocurrency transaction includes data representative of an authorisation by the user for the vendor to request transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with functionality of the IDS, the cryptocurrency transaction includes data representative of a transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

[0017] In a second aspect, the present disclosure provides an interface database system comprising: a plurality of user and vendor cryptocurrency wallets; one or more transaction queues for receiving cryptocurrency transactions between users and vendors; a plurality of wallet worker units configured to retrieve cryptocurrency transactions from the one or more transaction queues, and verifying the cryptocurrency transactions in relation to the corresponding user cryptocurrency wallets; a plurality of IDS controlled nodes configured to blockchain process one or more verified cryptocurrency transactions and submit the blockchain processed cryptocurrency transactions for addition to a master blockchain in relation to the transactions; and wherein the blockchain processed cryptocurrency transactions are submitted to a distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

[0018] Preferably, one or more worker units are configured to: maintain a second transaction queue for cryptocurrency transactions identified to be of an instantaneous type, wherein the cryptocurrency transactions are kept in the second queue during detected transaction peak loads; release one or more cryptocurrency transactions of the instantaneous type from the second transaction queue to one or more of the plurality of IDS controlled nodes for blockchain processing and addition to the master blockchain during detected transaction offpeak loads.

[0019] Preferably, one or more worker units are configured, prior to placing a cryptocurrency transaction of the instantaneous type in the second transaction queue, to: determine whether a user cryptocurrency wallet is capable of handling a cryptocurrency payment associated with the cryptocurrency transaction; ring-fence the cryptocurrency payment in the user cryptocurrency wallet when the cryptocurrency wallet is capable of handling a cryptocurrency payment; confirm instant transaction success to the user and vendor associated with the cryptocurrency transaction.

[0020] Preferably, one or more worker units are configured to: receive confirmation from the master blockchain of the distributed blockchain network that the cryptocurrency transaction has been added to the master blockchain; and update the user cryptocurrency wallet by transferring the ring-fenced cryptocurrency payment to the vendor cryptocurrency wallet.

[0021] Preferably, the cryptocurrency transaction is a PUSH cryptocurrency transaction, the PUSH cryptocurrency transaction is submitted to the IDS by the user for transferring a cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with a vendor, the cryptocurrency transaction includes data representative of an authorisation by the user for the vendor to request transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with functionality of the IDS, the cryptocurrency transaction includes data representative of a transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

[0022] In a third aspect, the present disclosure provides computer-implemented method for processing a cryptocurrency transaction of an instant type received by an interface database system according to the first or second aspects, modifications thereof and/or as described herein, the method comprising: determining whether a user cryptocurrency wallet associated with the user is capable of handling a cryptocurrency payment associated with a cryptocurrency transaction between a user and a vendor of the plurality of users and vendors; ring-fencing the cryptocurrency payment in the user cryptocurrency wallet associated with the user when the user cryptocurrency wallet is capable of handling a cryptocurrency payment; confirming an instant transaction success to the user and vendor associated with the cryptocurrency transaction and indicating the cryptocurrency payment will be transferred from the user cryptocurrency wallet to the vendor; maintaining a second transaction queue for cryptocurrency transactions identified to be of an instantaneous type, wherein the cryptocurrency transactions are kept in the second queue during detected transaction peak loads; and releasing one or more cryptocurrency transactions of the instantaneous type from the second transaction queue to one or more of the plurality of IDS controlled nodes for addition to the master blockchain of the distributed blockchain network during detected transaction off-peak loads.

[0023] Preferably, the computer-implemented method further including receiving confirmation from the master blockchain of the distributed blockchain network that the cryptocurrency transaction has been added to the master blockchain; and updating the user cryptocurrency wallet by transferring the ring-fenced cryptocurrency payment to the vendor cryptocurrency wallet.

[0024] Preferably, the cryptocurrency transaction is a PUSH cryptocurrency transaction, and the cryptocurrency transaction is submitted to the IDS by the user.

[0025] Preferably, the cryptocurrency transaction is a PULL cryptocurrency transaction associated with a vendor, wherein the cryptocurrency transaction includes data representative of an authorisation by the user for the vendor to request transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

[0026] Preferably, the PULL cryptocurrency transaction is associated with a subscription to a product or a service from the vendor, the method further comprising: allocating a vendor token to the subscription, the vendor token representative of an authorisation from the user to the vendor in relation to transferring a cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

[0027] In a fourth aspect, the present disclosure provides computer-implemented method for creating an automated subscription in an IDS according to the first or second aspects, modifications thereof, and/or as described herein, the method comprising: receiving a selected subscription associated with a vendor from a user; generating the rules of the subscription; receiving authorisation from the user for a cryptocurrency payment to be transferred from the crypto currency wallet of the user to that of the vendor in relation to the subscription; creating a PULL transaction in relation to the subscription and crypto currency payment; and storing the subscription rules, cryptocurrency payment, subscription details, and a vendor token linked to the user in a database of the IDS, wherein the vendor token represents the user authorisation.

[0028] In a fifth aspect, the present disclosure provides computer-implemented method for automatically processing a subscription associated with a vendor in an IDS according to the first or second aspects, modifications thereof and/or as described herein, where the subscription is created according to the fourth aspect, modifications thereof, and/or as described herein, the method comprising: reprocessing a selected subscription linked to a userand stored in the database of the IDS; determining whether the subscription is valid or invalid; transmitting a success confirmation to the vendor and user when the subscription is valid; and transferring the cryptographic payment from the user to the vendor in accordance with the method according to claim 7 for processing a cryptocurrency transaction of an instant type.

[0029] In a sixth aspect, the present disclosure provides computer-implemented method for terminating a subscription with a vendor in an IDS, wherein the subscription is created according to the fourth aspect, modifications thereof, and/or as described herein, the method comprising: receiving a request from a user to cancel the subscription; notifying the vendor and user that the subscription is cancelled; and removing the subscription rules, details and vendor token associated with the user from the database of the IDS.

[0030] In a seventh aspect, the present disclosure provides computer-implemented method for reconciling an IDS, controlled node in an IDS according to the first or second aspects, modifications thereof and/or as described herein, the method comprising: receiving status reports from IDS controlled nodes of the IDS, wherein each status report includes data representative of a block height of the blockchain of the corresponding IDS controlled node; restarting an IDS controlled node when it reports a block height differing from consensus of the master blockchain of the distributed blockchain network; prior to restarting the IDS controlled node, retrieving recent transactions added to the blockchain of the IDS controlled node; adding the retrieved recent transactions to a transaction verification queue of the IDS for blockchain reprocessing as required.

[0031] In an eighth aspect, the present disclosure provides computer-implemented method for spawning IDS controlled nodes in an IDS according to the first or second aspects, modifications thereof and/or as described herein, the method comprising: maintaining a trusted IDS blockchain node configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network; estimating the required number of IDS controlled nodes; in response to the estimated number of IDS controlled nodes being greater than the current number of IDS controlled nodes, spawning one or more IDS controlled nodes to meet the required number of IDS controlled nodes; pausing maintenance of the trusted copy of the master blockchain on the trusted blockchain node; storing a copy of the trusted master blockchain on each of the spawned IDS controlled nodes; synchronising the spawned IDS controlled nodes and the trusted IDS blockchain node with the master blockchain of the distributed blockchain network.

[0032] Preferably, the computer-implemented method further including estimating the required number of IDS controlled nodes further comprises when a transaction queue size reaches a factor of a predetermined number of IDS controlled nodes, and setting the estimated required number of IDS controlled nodes to the current number of IDS controlled nodes combined with the predetermined number of IDS controlled nodes.

[0033] Preferably, estimating the required number of IDS controlled nodes further comprises: determining the number of cryptocurrency wallets that worker units are concurrently required to open; determining the numberof cryptocurrency wallets an IDS controlled node can handle; and estimating the required number of IDS controlled nodes based on dividing the number of cryptocurrency wallets that worker units are concurrently required to open by the numberof cryptocurrency wallets an IDS controlled node can handle.

[0034] In an ninth aspect, the present disclosure provides computer-implemented method for spawning worker units in an IDS according to the first or second aspects, modifications thereof and/or as described herein, the method comprising: estimating the required number of worker units to process one or more transaction queues; in response to the estimated number of worker units being greater than the current number of worker units, spawning one or more worker units to meet the required number of worker units; assigning the spawned worker units to one or more of the transaction queues; in response to the estimated number of worker units being less than the current number of worker units, removing one or more worker units to meet the required number of worker units.

[0035] Preferably, estimating the required number of worker units further comprises: determining the transaction queue size; determining the number of transactions each worker unit can concurrently handle; receiving an operator selected time target; estimating the number of worker units to be the transaction queue size divided by the number of transactions each worker unit can concurrently handle divided by the time target.

[0036] In a tenth aspect, the present disclosure provides a blockchain transaction system comprising: an IDS configured to receive transactions from a plurality of users and blockchain process the transactions using one or more blockchains synchronised to a master blockchain;

and a distributed blockchain network coupled to the IDS, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

[0037] Preferably, the IDS further comprising: a plurality of IDS controlled nodes, each IDS controlled node configured to perform blockchain processing for adding transactions to the master blockchain, wherein each IDS controlled node operates on a blockchain synchronised to the master blockchain; and a transaction queue configured to queue transactions prior to blockchain processing depending on blockchain load.

[0038] Preferably, the IDS comprising: a transaction queue configured to receive transactions from a plurality of users; and a plurality of IDS controlled nodes coupled to the transaction queue, where each of the IDS controlled nodes are configured to blockchain process one or more of the transactions using a blockchain synchronised to a master blockchain; and where the IDS is coupled to a distributed blockchain network, the distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

[0039] Preferably, the IDS further comprising: a transaction module configured to receive the transactions from the plurality of users; a transaction processing module configured to perform the blockchain processing to add transactions to one or more copies of the master blockchain; a resource module configured to maintain scalable blockchain processing resources in relation to the transaction processing module and the transaction module; wherein the transaction processing module is configured to submit one or more blocks to the distributed blockchain network for consensus with the master blockchain.

[0040] Preferably, the transaction module is configured to: maintain a second transaction queue for transactions identified to be of an instantaneous type, wherein the transactions are kept in the second queue when a dynamic sizing of the blockchain is detected to expand; release one or more transactions of the instantaneous type from the second transaction queue to the transaction processing module for addition to the master blockchain when a dynamic sizing of the blockchain is detected to contract.

[0041] Preferably, the transaction module is configured to: maintain a second transaction queue for transactions in the transaction queue identified to be of an instantaneous type, wherein the transactions are kept in the second queue when the blockchain processing load has reached a blockchain transaction load limit or blockchain interaction threshold; or release one or more transactions of the instantaneous type from the second queue to the transaction processing module for addition to the master blockchain when the blockchain processing load is below the blockchain transaction load limit or the blockchain interaction threshold.

[0042] Preferably, the transaction processing module is further configured to: monitor the blockchain transaction load; store transactions to the mempool for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

[0043] Preferably, the transaction processing module is further configured to: monitor the blockchain transaction load; receive transactions from the transaction queue(s) for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

[0044] Preferably, the transaction processing module is further configured to: receive status reports from IDS controlled nodes of the IDS, wherein each status report includes a block height of the blockchain controlled by the corresponding IDS controlled node; restart an IDS controlled node when it reports a block height differing from consensus of the master blockchain; prior to restarting the IDS controlled node, retrieve recent transactions added to the blockchain of the IDS controlled node and add the recent transactions to a transaction verification queue for blockchain reprocessing as required.

[0045] Preferably, the resource module is further configured to: monitor transaction blockchain load; spawn one or more IDS controlled nodes when the transaction blockchain load reaches or exceeds a current transaction load limit of the blockchain nodes and/or IDS controlled nodes; and remove one or more IDS controlled nodes when the transaction blockchain load falls below a current transaction load limit of the blockchain nodes and/or IDS controlled nodes.

[0046] Preferably, the IDS further comprising a synchronisation module configured to: maintain a trusted blockchain node configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network; receive a request to spawn one or more IDS controlled nodes from the resource module; allocate the one or more requested IDS controlled nodes; pause maintenance of the trusted copy of the master blockchain on the trusted blockchain node; store a copy of the trusted master blockchain on each of the allocated IDS controlled nodes; synchronise the allocated IDS controlled nodes and the trusted blockchain node with the master blockchain of the distributed blockchain network.

[0047] Preferably, the IDS further comprises a plurality of worker units for processing the transaction queue(s), and the resource module is further configured to: monitor the number of worker units required to meet a transaction queue load; spawn one or more worker units when the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

[0048] Preferably, the resource module further configured to: maintain an estimate of average queue transaction processing time for a worker unit to complete processing a transaction; determine a required number of worker units based on the number of transactions in the transaction queue, the number of transactions handled by each worker unit, and the average queue transaction processing time estimate; allocate or deallocate one or more worker units to meet the determined required number of worker units.

[0049] Preferably, the resource module is further configured to: monitor the number of worker units required to meet a transaction queue load; spawn one or more worker units when more the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

[0050] Preferably, the transaction comprises a PUSH transaction from a user to a vendor, or a PULL transaction from a vendor to a user.

[0051] Preferably, the master blockchain is a cryptocurrency master blockchain; the IDS further comprises a database including a plurality of user wallets associated with one or more of the plurality of users for storing data representative of cryptocurrency units, and wherein the transactions are crypto currency transactions.

[0052] In an eleventh aspect, the present disclosure provides an IDS comprising: a transaction queue configured to receive transactions from a plurality of users; and a plurality of IDS controlled nodes coupled to the transaction queue, wherein each of the IDS controlled nodes are configured to blockchain process one or more of the transactions using a blockchain synchronised to a master blockchain; and wherein the IDS is coupled to a distributed blockchain network, the distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

[0053] Preferably, the IDS further comprising: a transaction module or device configured to receive the transactions from the plurality of users; a transaction processing module configured to perform the blockchain processing to add transactions to one or more copies of the master blockchain; a resource module or device configured to maintain scalable blockchain processing resources in relation to the transaction processing module or device and the transaction module; wherein the transaction processing module or device is configured to submit one or more blocks to the distributed blockchain network for consensus with the master blockchain.

[0054] Preferably, the transaction module or device is configured to: maintain a second transaction queue for transactions identified to be of an instantaneous type, wherein the transactions are kept in the second queue when a dynamic sizing of the blockchain is detected to expand; release one or more transactions of the instantaneous type from the second transaction queue to the transaction processing module for addition to the master blockchain when a dynamic sizing of the blockchain is detected to contract.

[0055] Preferably, the transaction module or device is configured to: maintain a second transaction queue for transactions in the transaction queue identified to be of an instantaneous type, wherein the transactions are kept in the second queue when the blockchain processing load has reached a blockchain transaction load limit or blockchain interaction threshold; or release one or more transactions of the instantaneous type from the second queue to the transaction processing module for addition to the master blockchain when the blockchain processing load is below the blockchain transaction load limit or the blockchain interaction threshold.

[0056] Preferably, the transaction processing module or device is further configured to: monitor the blockchain transaction load; store transactions to the mempool for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

[0057] Preferably, the transaction processing module or device is further configured to: monitor the blockchain transaction load; receive transactions from the transaction queue(s) for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

[0058] Preferably, the transaction processing module or device is further configured to: receive status reports from IDS controlled nodes of the IDS, wherein each status report includes a block height of the blockchain controlled by the corresponding IDS controlled node; restart an IDS controlled node when it reports a block height differing from consensus of the master blockchain; prior to restarting the IDS controlled node, retrieve recent transactions added to the blockchain of the IDS controlled node and add the recent transactions to a transaction verification queue for blockchain reprocessing as required.

[0059] Preferably, the resource module or device is further configured to: monitor transaction blockchain load; spawn one or more IDS controlled nodes when the transaction blockchain load reaches or exceeds a current transaction load limit of the blockchain nodes and/or IDS controlled nodes; and remove one or more IDS controlled nodes when the transaction blockchain load falls below a current transaction load limit of the blockchain nodes and/or IDS controlled nodes.

[0060] Preferably, the IDS further comprising a synchronisation module or device configured to: maintain a trusted blockchain node configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network; receive a request to spawn one or more IDS controlled nodes from the resource module; allocate the one or more requested IDS controlled nodes; pause maintenance of the trusted copy of the master blockchain on the trusted blockchain node; store a copy of the trusted master blockchain on each of the allocated IDS controlled nodes; synchronise the allocated IDS controlled nodes and the trusted blockchain node with the master blockchain of the distributed blockchain network.

[0061] Preferably, the IDS further comprises a plurality of worker units for processing the transaction queue(s), and the resource module or device is further configured to: monitor the number of worker units required to meet a transaction queue load; spawn one or more worker units when the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

[0062] Preferably, the resource module or device may be further configured to: maintain an estimate of average queue transaction processing time for a worker unit to complete processing a transaction; determine a required number of worker units based on the number of transactions in the transaction queue, the number of transactions handled by each worker unit, and the average queue transaction processing time estimate; allocate or deallocate one or more worker units to meet the determined required number of worker units.

[0063] Preferably, the resource module or device is further configured to: monitor the number of worker units required to meet a transaction queue load; spawn one or more worker units when more the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

[0064] Preferably, the transaction comprises a PUSH transaction from a user to a vendor, or a PULL transaction from a vendor to a user.

[0065] Preferably, the master blockchain is a cryptocurrency master blockchain; the IDS further comprises a database including a plurality of user wallets associated with one or more of the plurality of users for storing data representative of cryptocurrency units, and wherein the transactions are crypto currency transactions.

[0066] In a twelfth aspect, the present disclosure provides a computer-readable medium comprising data or instruction code, which when executed on a processor, causes the processor to implement one or more of the computer-implemented method(s) according to one or more of the third, fourth, fifth, sixth, seventh, eighth, and/or ninth aspects, modifications thereto, and/or as described herein.

[0067] In an thirteenth aspect, the present disclosure provides a tangible (or non-transitory) computer-readable medium comprising data or instruction code, which when executed on one or more processor(s), causes at least one of the one or more processor(s) to perform at least one of the steps of the one or more computer-implemented method(s) of the third, fourth, fifth, sixth, seventh, eighth, and/or ninth aspects, modifications thereto, and/or as described herein.

[0068] In a fourteenth aspect, the present disclosure provides one or more apparatus, each apparatus comprising a processor unit, a memory unit and/or a communication interface, the processor unit is connected to the memory unit and/or the communication interface, the memory unit comprises data or instruction code, which when executed on the processor unit (or one or more processors)), causes the processor unit to perform at least one of the steps of one or more of the computer-implemented method(s) of the third, fourth, fifth, sixth, seventh, eighth, and/or ninth aspects, modifications thereto, and/or as described herein.

[0069] The methods, process(es) and/or computer-implemented methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0070] This application acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0071] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Brief Description of the Drawings [0072] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0073] Figure 1a is a schematic diagram illustrating an example hybrid blockchain system according to the invention;

[0074] Figure 1 b is a schematic diagram illustrating an example interface database system (IDS) for the hybrid blockchain system of figure 1a according to the invention;

[0075] Figure 1c is a flow diagram illustrating an example process for the IDS of figures 1a and 1b according to the invention;

[0076] Figure 1d is a flow diagram illustrating an example transaction process for use by the IDS of figures 1 a and 1 b according to the invention;

[0077] Figure 1e is a schematic diagram illustrating an example cryptocurrency hybrid blockchain system according to the invention;

[0078] Figure 2a is a schematic diagram illustrating an example transaction load graph for an example blockchain transaction system;

[0079] Figure 2b is a flow diagram illustrating an example instant transaction process that minimises the transaction load for use by the IDS according to the invention;

[0080] Figure 2c is a schematic flow diagram illustrating an example instant transaction process for PUSH and PULL transactions in relation to the example cryptocurrency hybrid blockchain transaction system of figure 1e according to the invention;

[0081] Figure 2d is a further flow diagram illustrating an example instant transaction process for use with the IDS according to the invention;

[0082] Figure 3a is a flow diagram illustrating an example IDS controlled node spawning process for use with the IDS according to the invention;

[0083] Figure 3b is a flow diagram illustrating another example IDS controlled node spawning process for use with the IDS according to the invention;

[0084] Figure 3c is a flow diagram illustrating an example worker unit spawning process for supporting transaction queue processing for use with the IDS according to the invention;

[0085] Figure 3d is a flow diagram illustrating an example reconciliation process for out-ofsync IDS controlled nodes for use by the IDS according to the invention;

[0086] Figure 4a is a schematic and flow diagram illustrating an example subscription set-up process for performing PULL subscription transactions for the IDS according to the invention;

[0087] Figure 4b is a schematic and flow diagram illustrating an example subscription-retry process for performing further PULL subscription transactions for the IDS according to the invention;

[0088] Figure 4c is a schematic and flow diagram illustrating an example subscriptiontermination process in relation to cancelling PULL subscription transactions for the IDS according to the invention; and [0089] Figure 5 is a schematic diagram illustrating an example computing device according to the invention.

[0090] Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description [0091] Embodiments of the present invention are described below by way of example only. These examples represent the best mode of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0092] The inventors propose a hybrid blockchain transaction system that advantageously retains the benefits of centralised type systems in providing practically instantaneous transactions whilst retaining the benefits of decentralised or distributed blockchain networks in relation to immutability of transactions as they are added to a master blockchain for which consensus is maintained by the decentralised or distributed blockchain network; hereinafter referred to as a distributed blockchain network. The hybrid blockchain transaction system includes an interface database system (IDS) for receiving a plurality of transactions from users and/or vendors, and acting as a trusted proxy, may process the transactions allowing users and vendors to complete their transactions prior to the transaction being submitted to the master blockchain of the distributed blockchain network.

[0093] A transaction may comprise or represent an exchange of information between pairs and groups of parties such as, by way of example but not limited to, pairs and/or groups of users, pairs and/or groups of vendors, and/or pairs and/or groups of users and vendors. For example, a transaction may be between two or more users 106a-106n, between two or more vendors 108a-108m, and/or between one or more users 106a-106n and one or more vendors 108a-108m. Examples of transactions according to the invention may include, byway of example only but is not limited to, cryptocurrency payments/transactions; smart-contract transactions; electronic auction transactions; back-office settlement systems to process trades, transfers and other financial transactions; and/or transactions involving a sale, swap, auction, bid, exchange, distribution of information or other transaction which requires supervision and trust between parties to occur, a transaction that requires authorisation or validation, or any other transaction between parties (e.g. users and/or vendors) or the like.

[0094] For example, the hybrid blockchain transaction system may be applied to cryptocurrency transactions (e.g. cryptocurrency payments) between user(s) (e.g. buyer of a product or service) and/or vendors (e.g. seller of a product or service). The cryptocurrency transaction may be of an instant type, which allows the transaction to be performed by the IDS prior to blockchain processing and/or addition of the transaction to the master blockchain of the distributed blockchain network. Instant type transactions may include PUSH transactions (e.g. purchase transactions initiated by a user) and/or PULL transactions (e.g. subscription transactions initiated by a vendor in respect of a user). Instant transactions may be performed when the IDS acts as a trusted third party and has secure access to the necessary cryptocurrency accounts/wallets of the user and/or vendor. Permission may be given by the user and/or vendor allowing the use of instant transactions. Once provided the user may submit an instant PUSH transaction and the vendor may submit an instant PULL transaction to the IDS.

[0095] Each user of the IDS may have a wallet or account stored in the IDS. The IDS may store each user's cryptocurrency balance in, by way of example only but not limited to, a secure database when the user registers or opens a cryptocurrency wallet or account with virtual currency funds with the IDS. At the same time, the IDS may submit a transaction representing the virtual currency funds deposited by the user for addition to the blockchain, thus the user's cryptocurrency balance may also be determined from the blockchain. The IDS may also keep track of each user's cryptocurrency balance using the secure database; and thus may immediately ring fence an amount of cryptocurrency and prevent the user from spending this amount to avoid double spend. The IDS may use and/or maintain the stored user's cryptocurrency balance using the secure database based on transactions associated with the user (e.g. adding or removing funds from the user's cryptocurrency balance stored in the secure database). On occasion, the IDS may also include, when computational resources are available, maintenance or verification of a user's cryptocurrency balance using the blockchain of the distributed network. This is to ensure the user's cryptocurrency balance stored in the secure database matches that recorded by the blockchain. The user's cryptocurrency balance in the stored database may be compared with the user's cryptocurrency balance as recorded by the blockchain, where updates to the user's cryptocurrency balance stored in the secure database are made using the user's cryptocurrency balance as recorded by the blockchain.

[0096] When a user wishes to purchase a product/service from a vendor, the user may submit an instant PUSH transaction to the IDS for pushing the required cryptocurrency payment amount to the vendor in relation to the product/service. An instant PUSH transaction may be executed and the transaction enacted by the IDS prior to the transaction being blockchain processed and/or added to the master blockchain of the distributed blockchain network that maintains the master blockchain. For example, when a user has a wallet or account stored in the IDS, a user may submit a crypto currency transaction to purchase a product/service form a vendor. The IDS identifies the transaction as an instant PUSH transaction because it has secure access to the user and vendor accounts/wallets as trusted third party. The IDS verifies that the users cryptocurrency balance can handle the cryptocurrency payment, then it ring fences the cryptocurrency payment amount in the users cryptocurrency account preventing the user from over-spending in future transactions. The cryptocurrency payment may also be transferred to the vendor as the user account has been ring fenced in relation to this payment. The vendor may then release product or service to the user on receipt of notification payment has been or is to be transferred, which may occur a very short time (e.g. almost instantly) after the user submits the cryptocurrency payment transaction. The transaction may be blockchain processed a later time that is advantageous to the processing load on the IDS and/or distributed blockchain network.

[0097] Prior to and during the time that the transaction is blockchain processed, the cryptocurrency payment has been ring fenced in the users account or held in escrow by the IDS. Once confirmation of the transaction being added to the master blockchain by the distributed blockchain network has been received, the IDS completes the transaction, i.e. removes the cryptocurrency payment (the ring fenced cryptocurrency payment) from the user's account, notifies the user(s) and/or vendor(s) that payment process is complete and other transaction completion processes.

[0098] In another scenario, a user may want to subscribe to a digital product/content, product and/or service from a vendor. On accepting the subscription terms, rules and conditions, the user may provide the vendor with permission to submit an instant PULL transaction to the IDS for pulling the required cryptocurrency payment amount from the user's cryptocurrency account at regular and/or agreed intervals (e.g. monthly, quarterly, or annual subscription payments) to the vendor's cryptocurrency account in relation to the subscription.

[0099] This permission may be in the form of a unique token (e.g. a user token or a vendor token) that allows the particular subscription and also the user to be identified by the vendor and/or the IDS. The user is linked to the unique token, the subscription details and rules of the particular subscription, which is stored by the IDS. This allows either the vendor or the IDS to pull the required cryptocurrency payment amount from the user's cryptocurrency account to the vendor's cryptocurrency account. There is one unique token that is generated for each subscription of each user. Thus, a single vendor may supply a single user with multiple subscriptions and each subscription would still be identifiable to the IDS. Alternatively or additionally, multiple vendors may supply a single user with multiple corresponding subscriptions, each of which would be identifiable to the IDS. The IDS may process each transaction associated with a subscription and identified by the unique token as belonging to a particular user and present the unique token back to the vendor with success or fail. The vendor's system may match the unique token to the user and the correct subscription, and can mark it as success or fail and action it accordingly.

[00100] In another example, once a unique token has been generated and the subscription set-up and stored by the IDS, a vendor may submit an instant PULL transaction to the IDS including data representative of the unique token in relation to the user, the IDS checks the unique token against the subscriptions of all users, and, given each unique token is different, can identify the subscription associated with the correct user. If there is a match and the IDS has identified a user, the IDS may check that the subscription is still valid (e.g. the user may have cancelled the subscription) and if still valid, it authorises the required cryptocurrency payment amount in relation to the subscription to be made from the user's cryptocurrency account to the vendor's cryptocurrency account. Alternatively or additionally, the IDS may store a list of subscriptions linked to user tokens for each user of the IDS. The IDS may check the list of subscriptions of each user, determine that a payment is due, and automatically pull the required cryptocurrency payment amount from the user's cryptocurrency account to the vendor's cryptocurrency account. The IDS may confirm the payment has been made to the user and/or the vendor, in which the confirmation includes the unique token associated with the subscription, which allows the vendor and/or user to identify the subscription payment has been made and to continue the subscription.

[00101] In one example, the unique token may be generated when a user subscribes to the vendor's subscription via the vendor's website and/or payment system, in which the unique token may be submitted by the user and/or the vendor to the IDS. Alternatively, the IDS generates a unique token linking it to the user and the subscription of the vendor, the IDS may then supply the unique token to the vendor and/or user. The IDS links the unique token to the user, the subscription details, rules etc. and securely stores the subscription associated with the user. This allows the IDS to identify any future PULL transactions from the vendor in relation to the subscription are legitimate, authorised by the user, and can proceed with the transaction. The unique token is linked with the user and the subscription, which also allows the vendor to identify the payments etc.

[00102] In another example, when the user subscribes to the vendor's subscription, the vendor may supply a unique token to identify the user and the subscription on the IDS. The unique token, subscription details and/or rules (e.g. payment schedule and the like), are linked to the user and stored by the IDS. This allows the IDS to check and authorise each transaction in relation to the subscription. This also allows future subscription payments to made (automatically by the IDS) in which the unique token associated with the subscription and user are sent in a confirmation notification to the vendor with success or fail. This enables the vendor to track the user's subscription on their system.

[00103] In another example, when an instant PULL transaction is received from a vendor, it may be executed based on the vendor's instant PULL transaction providing data representative of the unique token in relation to the subscription in the transaction. Based on this unique token from the vendor matching a unique token stored in the IDS in relation to the subscription, the IDS can identify the user, verify the transaction is legitimate or in accordance with the subscription rules/details etc. and, if verified, may authorise and enact the cryptocurrency payment from the identified user account to the vendor account prior to the transaction being blockchain processed and/or added to the master block.

[00104] In essence, the PULL transactions are token and permission based in which the vendor may present a unique token in relation to a subscription by a user and the IDS processes the transaction by checking the identities/permissions/authorisations of the vendor/user in relation to the unique token such that, on successful verification, the cryptocurrency payment may be authorised and made to the vendor. For example, when a vendor submits a PULL transaction including a unique token that the IDS has linked to a user and a subscription in relation to the vendor, the IDS checks that the vendor has permission to make the transaction from the user cryptocurrency account based on the stored unique token and the subscription details/rules etc. This may also involve identifying the user linked to the unique token, verifying the subscription linked to the unique token is associated with the vendor, and identifying the payment is in agreement with the subscription payment terms/conditions/ payment periods etc., determining the PULL transaction is of the required cryptocurrency amount. The user may have various permissions set up in relation to the unique token and/or the linked subscription that allow the minimum payment, a required constant subscription payment, a maximum payment, capped payment, and/or an unlimited payment, or any type of payment to be pulled by the vendor.

[00105] In another example, the IDS may identify that a vendor cryptocurrency transaction in relation to the user having subscribed to a product/digital product/service from the vendor can be implemented as an instant PULL transaction. This may occur when the transactions includes data representative of the unique token associated with the subscription provided by the vendor and linked to the user. The IDS may identify the transaction can be implemented as an instant PULL transaction when the received unique token matches a unique token linked to a user and a subscription, and when the vendor and user have cryptocurrency accounts with the IDS. This means the user and vendor may authorise the IDS to act as a trusted third parry and have secure access to the user and vendor accounts. When these conditions are satisfied, the IDS may perform an instant PULL transaction along the following lines.

[00106] The IDS may verify that the users cryptocurrency balance can handle the cryptocurrency payment. The IDS may store the user's cryptocurrency balance in a secure database, which means that the IDS does not need to verify the user's cryptocurrency balance using the blockchain of the distributed blockchain network. If the IDS establishes that the user's account has enough cryptocurrency in their account in relation to the transaction, using the user's cryptocurrency balance stored in the secure database, then the IDS may be configured to ring fence the cryptocurrency payment amount in the users cryptocurrency account stored in the secure database. This prevents the user from over-spending on future transactions prior to confirmation of the current transaction being blockchain processed and added to a master blockchain of a distributed blockchain network. The IDS may notify that vendor that the cryptocurrency payment has been ring fenced in the user's account.. Once the vendor receives this notification, the vendor may then release product/digital products/service in relation to the subscription to the user, which may occur a very short time (e.g. almost instantly) after the vendor submits the cryptocurrency payment transaction. The transaction may be blockchain processed at a later time that is advantageous to the processing load on the IDS and/or distributed blockchain network.

[00107] During the blockchain processing of the transaction, the cryptocurrency payment has been ring fenced in the user's account or held in escrow by the IDS. Once confirmation of the transaction being added to the master blockchain by the distributed blockchain network has been received, the IDS completes the transaction, i.e. removes the cryptocurrency payment (the ring fenced cryptocurrency payment) from the user's account, notifies the user(s) and/or vendor(s) that payment process is complete and/or other transaction completion processes such as, by way of example only but not limited to, transferring the ring-fenced cryptocurrency amount from the user's account to the vendor's account.

[00108] Although the vendor may be notified by the IDS that the cryptocurrency payment is ring-fenced in the user's account, it is to be appreciated by the skilled person that modifications may be made to the process in which the IDS may, prior to blockchain processing the transaction and submitting for addition to the blockchain, also transfer the ringfenced cryptocurrency amount from the user's account to the vendor's account and notify the vendor accordingly. After which the vendor may then release product/digital products/service in relation to the subscription to the user, which would occur a very short time (e.g. almost instantly) after the vendor submits the cryptocurrency payment transaction.

[00109] In another example, the IDS may check, based on the unique token linked to the user and/or subscription details/rules, for user permission and timing and identify when or that a cryptocurrency payment is due in relation to the subscription. Should all these criteria be met and a cryptocurrency payment is due in relation to a user's subscription, the IDS may then automatically perform a transaction (e.g. an instant PUSH/PULL transaction on behalf of the user/vendor) to push/puII the cryptocurrency payment in relation to a user's subscription to the vendor. This means that neither the vendor or the user need to do anything in relation to making the subscription payment on time. The IDS automatically makes the cryptocurrency payment in a similar manner as described above in relation to the instant PUSH/PULL transactions (e.g. checking for cryptocurrency balance, ring fencing funds, notifying vendor transaction is being made prior to blockchain processing the transaction etc.). Prior to blockchain processing, the IDS may send a success or fail notification to the vendor depending on the user's cryptocurrency balance, and/or whether the subscription is still valid in relation to the user etc. Once the transaction is complete and added to the master blockchain of the distributed blockchain network the IDS may send a final confirmation that the transaction has been successful.

[00110] In another example, the hybrid blockchain transaction system may be applied to smart contract / hyperledger type transactions (e.g. execution of smart contract clauses) between one or more party(ies) such as user(s) and/or vendor(s) (e.g. contractors, legal persons, corporations, banks and the like) in which the smart contract clauses may need to be executed within a limited period of time or almost instantly, otherwise a penalty or delay may be incurred by one of the party(ies) to the smart contract. On receipt of a smart contract clause transaction, the responsible user(s) may immediately perform the transaction whilst the IDS acts as a trusted third party confirming the smart contract clause transaction is being stored and/or added to the master blockchain of the distributed blockchain network representing the smart contract/hyperledger etc. Given that the IDS acts as a trusted third party, the smart contract transaction may be blockchain processed a later time that is advantageous to the processing load on the IDS and/or distributed blockchain network. During this time, the smart contract transaction may be queued and the responsible users and/or IDS being required to execute one or more portions of the smart contract transaction. Once confirmation of the transaction being added to the master blockchain by the distributed blockchain network has been received, the IDS completes the transaction, notifies to user(s) and/or vendor(s) of completion of the transaction and the like.

[00111] Figure 1a is a schematic diagram illustrating an example hybrid blockchain transaction system 100 according to the invention. The blockchain transaction system 100 includes an interface database system (IDS) 102 communicatively coupled or connected to a distributed blockchain network 104. The distributed blockchain network 104 may be configured, by way of example only but is not limited to, a peer-to-peer network. The IDS 102 connects with a plurality of users 106a-106n and/or a plurality of vendors 108n-108m, and is configured to receive transactions (or transaction requests) from the plurality of users and/or the plurality of vendors.

[00112] The distributed blockchain network 104 includes a plurality of IDS controlled nodes 114a-114r and a plurality of blockchain nodes 116a-116z. The distributed blockchain network 104 is illustrated as being partitioned into an IDS distributed network 114 that is communicatively coupled to a first distributed network 116. The IDS 102 is connected to the IDS distributed network 114, which includes the plurality of IDS controlled nodes 114a-114r, which are controlled and/or operated by the IDS 102. The first distributed network 116 includes the plurality of blockchain nodes 116a-116z. The distributed blockchain network 104 maintains ajnaster blockchain 105 via the plurality of blockchain nodes 116a-116z and the plurality of IDS controlled nodes 114a-114r, which are in communication with each other for maintaining consensus of the master blockchain 105. Each of the blockchain nodes 116a116z and IDS controlled nodes 114a-114r have a full and/or partial copy of the master blockchain 105 stored thereon and include functionality for performing blockchain processing on one or more transaction(s). It is assumed that the first distributed network 116 has enough or the majority of blockchain nodes 116a-116z that are required for maintaining consensus of the master blockchain of the distributed blockchain network 104.

[00113] The plurality of blockchain nodes 116a-116z may be, byway of example only but are not limited to, full and/or partial blockchain nodes, miner nodes, mobile blockchain nodes, and the like etc. The IDS controlled nodes 114a-114r that are coupled to and controlled by the

IDS 102 may include, by way of example only but are not limited to, functionality associated with full blockchain node(s) and other functionality for processing transactions as the IDS 102 demands. The IDS 102 may include resource and control functionality for, by way of example only but is not limited to, allocating/deallocating (e.g. spawn/de-spawn) one or more IDS controlled nodes 114a-114r, resynchronising IDS controlled nodes 114a-114r to the master blockchain 105 of the distributed blockchain network 104, and/or control the allocation of transactions to the IDS controlled nodes 114a-114r for efficiently blockchain processing transactions forsubmission/addition to the master blockchain 105 of the distributed blockchain network 104.

[00114] The IDS 102 further includes transaction queue functionality 110 that may include one or more transaction queue(s) 110a-110q into which the received transactions are placed, worker unit network 112 that includes multiple worker units 112a-112w (e.g. wallet servers etc.) for processing the transactions, database/server storage 109 for storing user/vendor information etc. (e.g. tokens, wallets and the like), and functionality for controlling and/or operating the IDS controlled nodes 114a-114r for, when required, blockchain processing one or more of the transactions.

[00115] In essence, each worker unit 112a-112w retrieves transactions from one or more of the queues 110a-110q, verifies and confirms the transactions are legitimate (e.g. opens wallets associated with each transaction and verifies the transaction can be made etc.), and sends verified transactions to one of the IDS controlled nodes 114a-114r of the distributed blockchain network 104. Each of the IDS controlled nodes 114a-114r receives verified transaction(s) from the worker units 112a-112w, and performs, so-called blockchain processing to generate a block of transactions (using their copies of the master blockchain 105). Each generated block of transactions may be submitted by an IDS controlled node 114a-114r to at least a portion of the plurality of nodes 116a-116z of the distributed blockchain network 104 for consensus and subsequent addition to the master blockchain 105.

[00116] The IDS is further configured to control the IDS controlled nodes 114a-114r to blockchain process the transactions using one or more blockchains synchronised to the master blockchain 105, and submit the blockchain processed transactions to the master blockchain 105, which, once consensus is achieved, stores data representative of one or more of the transactions within its blocks. The distributed blockchain network 104 is configured to maintain consensus of the master blockchain 105 in relation to the transactions that have been blockchain processed and submitted to it for storage in the master blockchain 105.

[00117] The IDS 102 is configured to control the manner in which the users 106a-106n and/or the vendors 108a-108m interact and transact with each other. The IDS 102 is configured to act as a trusted third party between the users 106a-106n and/or the vendors 108a-108m allowing them to transact, whilst at the same time providing the benefits of distributed blockchain network 104. The hybrid blockchain transaction system 100, which includes the IDS 102 that is in communication with the distributed blockchain network 104, is a hybridisation between a centralised type of system and a distributed type of blockchain system. This allows many features and benefits that may be applied to transactions between parties whilst retaining the advantages of both the centralised type of and decentralised/distributed type of systems such as, byway of example but not limited to, immutability of transactions, speed of transactions such as, byway of example only but not limited to, providing so-called instantaneous transactions between users and/or vendors, whilst providing trust between the transacting parties in relation to a transaction.

[00118] Although a distributed blockchain network 104 is used to securely store the transactions in a master blockchain 105, which controls the overall consensus in relation the submission of transactions to the master blockchain 105, it is the IDS 102 that acts as a trusted third party and can control the blockchain processing, verification and/or authorisation of the transactions, and submissions of transactions between users 106a-106n and/or the vendors 108a-108m connected to the IDS 102. This allows the users 106a-106n and/or the vendors 108a-108m to trust that they can transact between each other accordingly and in an instantaneous manner. The IDS 102 includes functionality that is configured to efficiently blockchain process received transactions, and also scale to any growth in numbers of users 106a-106n and/or the number of vendors 108a-108m that may be party to the transactions.

[00119] The IDS 102 further includes transaction queue functionality 110, worker unit functionality 112 that connects with IDS distributed network 114, which provides IDS blockchain functionality. These interoperate together to efficiently manage the received transactions whilst scaling as the number of users 106a-106n and/or vendors 108a-108m increase. The transaction queue functionality 110 may be configured to manage one or more transaction queues 110a-110q, which may be used to manage and/or prioritise the transaction workload, verification and/or blockchain processing. A transaction queue may be configured to queue transactions prior to blockchain processing depending on blockchain load. The worker unit functionality 112 may be configured to manage a plurality of worker units 112a-112w, each of which may retrieve transactions from one or more of the transaction queues 110a-110q, process and/or verify the retrieved transactions, and send the verified transactions for blockchain processing by IDS blockchain functionality of the IDS distributed network 114. The IDS distributed network 114 includes a plurality of IDS controlled nodes 114a-114r in which each IDS controlled node 116a is configured to perform blockchain processing on transactions for adding the processed transactions to the master blockchain 105. Each IDS controlled node operates on a blockchain synchronised to the master blockchain 105 of the distributed blockchain network 104.

[00120] Blockchain processing comprises or represents the processing and preparation of a transaction for inclusion or addition into a block of a blockchain. Examples of blockchain processing as used herein may include, by way of example only but are not limited to, downloading every block and transaction and check them against the distributed blockchain network 104 core consensus rules; parse and verify the blockchain, its transactions and everything related; any other form of block processing or blockchain processing required to enable one or more transactions to be submitted for addition to a master blockchain.

[00121] A blockchain node comprises or represents a process, computing apparatus or device and/or server configured to perform blockchain processing on a transaction or one or more transactions for submission to the distributed blockchain network 104 for addition onto the master blockchain 105. Examples of blockchain nodes as used herein may include, by way of example only but is not limited to, full and/or partial blockchain nodes, miner nodes, mobile blockchain nodes and the like.

[00122] A worker unit comprises or represents one or more application(s), one or more process(es), one or more computing device(s) or apparatus and/or server(s) for performing various transactional computations/processing in relation to one or more transactions. Examples of a worker unit according to the invention may include, by way of example only but is not limited to, processing cryptocurrency transactions, and verifying cryptocurrency wallets, verifying cryptocurrency wallet balances and transactions; verifying a transaction; any other processing, transaction queueing/retrieval operation or function, or verification process and the like for operating/queuing/processing a transaction prior to blockchain processing of the transaction.

[00123] In particular, there may be several transaction queues 110a-110q such as, byway of example only but not limited to, a primary transaction queue 110a, an instant transaction queue 110b, and/or a confirmation transaction queue 110q. The primary transaction queue may be configured for receiving and queuing transactions that may require, by way of example only but not limited to, conventional blockchain processing and submission for addition to the master blockchain 105. Although conventional transactions may be blockchain processed and submitted for addition to the master blockchain in a similar manner as distributed blockchain system transactions, the front-end to the IDS 102 may be configured to receive and queue, via the primary transaction queue 110a, the transaction (e.g. cryptocurrency payment transaction) from a user 106a and allow a worker unit 112a to retrieve the transaction for worker unit processing and subsequent blockchain processing by an IDS controlled node 114a. The worker unit 112a and IDS controlled node 114a are controlled to carry out the transaction on the blockchain as fast as possible. The instant transaction queue 110b may be configured for storing transactions that have been identified to be of an instantaneous (instant) type, so-called instantaneous transactions (instant transactions). Various worker units 112b may process the instant transaction queue 110b to implement instant type transactions as described herein. The confirmation queue 110q may be configured to receiving confirmations or full confirmations from the distributed blockchain network 104 of transactions that have been added to the master blockchain 105. Various worker units 112w may process the confirmation queue 110q for receiving confirmations or full confirmations that transactions have been added to the master blockchain and perform any final transaction processing such as, by way of example only but not limited to, notifications to the vendor(s) and/or user(s) involved in the transaction, transferring payment and updating the user and/or vendor accounts accordingly etc.

[00124] A transaction of the instant type or instant transactions may be allowed, once feasibility of the transaction has been verified, by the IDS 102 to proceed prior to blockchain processing and/or without full confirmation the transaction has been added to the master blockchain 105 of the distributed blockchain network 104. Feasibility of whether the transaction is to be identified as an instant type transaction includes, but is not limited to, whether the parties (e.g. user(s) and/or vendor(s)) to the transaction have an account or details with the IDS 102. This allows the IDS 102 to have the parties to any transaction agree, typically beforehand or on registration to the IDS 102, that the IDS may act as a trusted third party. Thus, the parties to the transaction may trust the IDS 102 to allow the transaction to proceed without full confirmation that the transaction has been added to the master blockchain 105. Typically, the IDS 102 will ensure the main parts of the transaction are proceeded with and send notification to the parties (e.g. user(s) and/or vendor(s)) that they should proceed with finalising the transaction. It is the IDS's 102 role to ensure the transaction is eventually added to the master blockchain at a time that is convenient or advantageous to the IDS 102 and/or blockchain load etc. It is also the IDS's 102 role to ensure that each party to the transaction honours their part of the transaction. For example, the IDS 102 may check a user's cryptocurrency account to ensure they have enough balance to complete the transaction, the IDS 102 may then ring fence the transaction amount and prevent the user from spending more than their balance whilst the IDS 102 allows the transaction to proceed but prior to the transaction being blockchain processed. This allows the parties to proceed with the transaction practically instantaneously from receiving confirmation from the IDS 102 to proceed (albeit there may be a slight delay due to IDS 102 verification processes and the like). The IDS 102 ensures the transaction is blockchain processed at a time that suits the IDS 102. The confirmation queue 110q may be configured to receive confirmations from the distributed blockchain network 104 of transactions being added to the master blockchain 105. The IDS 102 may then provide full confirmation a transaction has successfully completed by notifying the corresponding one or more users 106a-106n and/or vendors 108a-108m of the transaction being successfully completed. The IDS 102 may further perform any further operations necessary by the IDS 102 to complete the transaction (e.g. transfer of funds between parties etc.).

[00125] The instant transaction queue 110b and primary transaction queue 110a may be managed by one or more of the worker units 112a-112w to distribute the blockchain processing load. For example, blockchain processing of transactions in the primary queue 110a may be prioritised over blockchain processing of instant transactions held in the instant queue 110b e.g. during on-peak times. Blockchain processing of instant transactions may occur when it is advantageous for the IDS 102 to proceed to do so, e.g. when there is a lull in blockchain processing load during off-peak times. This allows the blockchain processing load to be smoothed out. This also minimises a backlog of transactions in one or more memory pools (mempools) associated with the master blockchain 105, which may then be held-up for longer or held for an unacceptable period of time before confirmation of success or failure of whether the transaction has been added to the master blockchain 105. If transactions are detected as requiring to leave the IDS and thus are required to arrive on the blockchain as soon as possible, the transactions can be prioritised to ensure they take precedence over internal (IDS) transactions. Transactions taking place within the IDS are already confirmed to both parties and thus have a lower priority requirement.

[00126] Instant transactions between the parties (e.g. users and/or vendors) are allowed to proceed, after verification that the parties can satisfy the requirements of the transaction by the IDS 102 as trusted third party, and prior to the transaction being submitted to the master blockchain 105. For instant transactions, the IDS 102, after verifying the transaction may be completed or proceed and prior to blockchain processing of the instant transaction, further perform any other operations associated with the transaction that, for conventional transactions in the primary transaction queue, be otherwise performed when full confirmation has been received that the transaction has been added to the master blockchain 105. This means, for transactions that are identified as instant-type transactions, users 106a-106n and/or vendors 108a-108m involved do not have to wait for full confirmation of the transaction being added to the master blockchain 105 to proceed with their parts of the transaction until. Rather, users 106a-106n and/or vendors 108a-108m that are party to an instant-type transaction may proceed with their parts of the transaction, once the IDS 102 confirms they may do so after various verification checks have been completed that the parties can honour their parts of the transaction. Thus, instant-type transactions can practically be, from the perspective of the parties to the transaction, instantaneous, which is vastly different to conventional transactions which can take, depending on blockchain processing load in both the IDS controlled nodes 114a-114r and/or blockchain nodes 116a-116z of the distributed blockchain network 104, a long period of time (e.g. at least a few minutes, 10-20 minutes, to a few or several days depending on mining fees and the transaction load of the mempool or the like).

[00127] For example, when the hybrid blockchain transaction system 100 is configured to perform cryptocurrency transactions, the instant type transactions may include PUSH transactions (e.g. purchase transactions initiated by a user) and/or PULL transactions (e.g. subscription transactions initiated by a vendor in respect of a user). Instant transactions may be performed when the IDS 102 acts as a trusted third party and has secure access to the necessary cryptocurrency accounts of the user(s) 106a-106n and/or vendor(s) 108a-108m. Permission may be given by the user and/or vendor allowing the use of instant transactions. Once provided, the vendor may submit an instant PULL transaction to the IDS subject to the relevant permissions having been granted by the user.

[00128] For example, an instant transaction may be related to a purchase of an item by a user 106a from a vendor 108a using a cryptocurrency payment. This is a type of PUSH transaction in which the user 106a pushes the cryptocurrency payment to the vendor 108a. On receipt of the instant transaction and verification the transaction may be performed (e.g. based on balance of user's cryptocurrency account), the IDS 102 may be configured to ring fence the cryptocurrency payment amount in the user's account, preventing the user from using the ring fenced cryptocurrency payment amount for another purchase. The IDS 102 may also be configured to notify the vendor 108a that payment has been made, and even place the cryptocurrency payment in the vendor's account, or notify the payment is being held in escrow pending full confirmation, which means the vendor may release the purchased item to the user 106a. In the meantime, the instant transaction may be subsequently blockchain processed and full confirmation received that the instant transaction has been added to the master blockchain 105 of the distributed blockchain network 104. Once, full confirmation has been received, the IDS 102 may fully perform any final or further operations associated with the instant transaction. For example, for the cryptocurrency payment, this may include, by way of example only but is not limited to, completing the transaction by debiting ring fenced cryptocurrency funds from the user's 106a account and crediting the ring fenced cryptocurrency funds to the vendor's 108a account, sending notifications that the transaction has been completed and the like.

[00129] The worker unit functionality 112 may be configured to manage a plurality of worker units 112a-112w, each of which may retrieve transactions from one or more of the transaction queues 110a-110q, process and/or verify the retrieved transactions, and send the verified transactions for blockchain processing by IDS blockchain functionality provided by IDS distributed network 114. The IDS distributed network 114 includes a network of one or more IDS controlled nodes 114a-114r, or a plurality of IDS controlled nodes 114a-114r, that connect with blockchain nodes 116a-116z to form the distributed blockchain network 104. Each IDS controlled node 114a-114r may include a full copy of the master blockchain 105 i.e. a synchronised copy of the master blockchain 105, and is configured to receive one or more of the transactions retrieved from one or more of the transaction queue(s) 110a-110q by one or more worker units 112a-112w. Each IDS controlled node 114a may then blockchain process the transactions and submit the blockchain processed transactions to the distributed blockchain network 104 for adding to the master blockchain 105 of the distributed blockchain network 104.

[00130] The distributed blockchain network 104 includes distributed blockchain functionality comprising first distributed network 116 that includes the blockchain nodes 116a-116z, which comprise the majority of nodes in the distributed blockchain network 104 for establishing/maintaining consensus of the master blockchain 105 associated with the transactions. The blockchain nodes 116a-116z are essentially used to establish consensus in relation to the blockchain processed transactions submitted by one or more of the IDS controlled nodes 114a-114r for addition to the master blockchain 105. Once the distributed blockchain network 104 has reached consensus for each blockchain processed transaction that has been submitted for addition to the master blockchain 105, a full confirmation that the transaction has been added to the master blockchain 105 may be sent to the IDS 102. The full confirmation may be held in the confirmation queue 110q and processed by one or more of the worker units 112a-112b of the worker unit functionality 112. Once processed, the IDS 102 may complete the transaction in relation to the corresponding users 106a-106n and/or vendors 108a-108m.

[00131] Figure 1b is a schematic diagram illustrating an example functionality of the IDS 102 for the hybrid blockchain system 100 of figure 1a according to the invention. Reference to both figures 1a and 1b is made by way of example only. The IDS 102 has been described as including at least a transaction queue 110a configured to receive transactions from a plurality of users 106a-106n and/or vendors 108a-108m; a plurality of worker units 112a-112m for managing retrieval of transactions from the queue 110a, verifying the retrieved transactions, forwarding them to an IDS distributed network 114 of the distributed blockchain network 104 that includes at least one of a plurality of IDS controlled nodes 114a-114r. One or more of the IDS controlled nodes 114a-114r are configured to blockchain process the received transactions using one or more blockchains synchronised to a master blockchain 105. The IDS 102 is coupled to the distributed blockchain network 104, in which the distributed blockchain network 104 is configured to maintain consensus of the master blockchain 105 in relation to transactions blockchain processed by the IDS controlled nodes 114a-114r connected to the IDS 102.

[00132] As described with respect to figure 1a, the functionalities of the IDS 102 may include, by way of example only but is not limited to, a transaction queue functionality 110, a worker unit functionality 112, and an IDS blockchain functionality provided by IDS distributed network 114. These functionalities may be incorporated or controlled by the IDS 102 in many different ways or as their application demands. The following is an example outline only of how these functionalities may be performed or shared between one or more modules, devices or apparatus, in the IDS 102. The IDS 102 may include a transaction queuing module 120, a transaction module 122, a computing resources module 124, a synchronisation module 126, a user/vendor payment module 128, user/vendor interface 130, and database/storage module 132. These modules ensure that the IDS 102 operates as efficiently and intelligently as possible, find a compromise between minimising transaction times and cost of processing resources required for verification and blockchain processing, and scales as the number of users 106a-106n, vendors 108a-18m and/or number of transactions grow and increase.

[00133] The transaction queuing module 120 may be configured to receive the transactions from the plurality of users 106a-106n and/or plurality of vendors 108a-108m, manage the transaction queue functionality 110 including the one or more transaction queues 110a-110q. The transaction processing module 122 may be configured and to manage the worker unit functionality including the one or more worker units 112a-112w, and also manage the IDS blockchain functionality provided by the plurality of IDS controlled nodes 114a-114r of the blockchain network 104. This transaction processing may include, by way of example only but is not limited to, verifying transactions and submitting to IDS controlled nodes 114a-114r, blockchain processing transactions using one or more synchronised copies of the master blockchain 105, submitting blockchain processed transactions for addition to the master blockchain 105. The transaction module 122 may be further configured to control submission of block processed transactions (e.g. one or more blocks) for addition to the master blockchain 105 of the distributed blockchain network 104. Once consensus is reached in relation to a transaction by the distributed blockchain network 104, the transaction is added to a block of the master blockchain 105, and confirmation (also known as full confirmation) may be provided, which may be received by the transaction processing module 122 and passed to transaction queue module 120 for insertion into the confirmation transaction queue 110q.

[00134] The computing resource module 122 may be configured to maintain scalable blockchain processing resources such as, by way of example only but not limited to, estimating the required number of worker units 112a-112w, IDS controlled nodes 114a-114r, and/or the transaction queue(s) 110a-110q, and any other resources required by the IDS 102.

This may include identifying when more or less IDS controlled nodes 114a-114r may be required, or when more or less worker units 112a-112w may be required, and allocating/deallocating the necessary computing resources to ensure the computing resource requirements of the IDS 102 are met and ensure satisfactory or efficient processing of transactions from the users 106a-106n, and/or vendors 108a-108m. The synchronisation module 126 may be configured to maintain or ensure the IDS controlled nodes 114a-114r efficiently maintain synchronisation with the master blockchain 105. The synchronisation module 126 may identify out-of-sync IDS controlled nodes 114a-114rand ensure any blockchain processed transactions by those out-of-sync nodes are reprocessed using an IDS blockchain node that is synchronised to the master blockchain 105. The out-of-sync nodes may be restarted and synchronised before being allowed to handle further transactions from the worker units 112a-112w.

[00135] The user/vendor payment module 128 may include user and/or vendor payment/account functionality for verifying user account balances, storing user account balances in a database 109 via database/storage module 132, verifying vendors and/or users, ensuring cryptocurrency payment amounts are ring fenced in user accounts, storing subscriptions and unique tokens that are linked to users in database 109 and the like. The user/vendor interface 130 may include functionality allowing users and/or vendors to register an account and personal information with the IDS 102, login and monitor their accounts/subscription status(es) and create, modify and/or cancel subscriptions and the like, the database/storage module 132 may include the required functionality for the IDS 102 to secure store user and/or vendor account and/or personal information details, recording/storing subscription details, unique tokens, subscription rules and the like in relation to each user and other storage/database requirements and the like.

[00136] Figure 1c is a flow diagram illustrating an example control process 140 for use by the IDS 102 of figures 1a and 1b according to the invention. Steps of the control process 140 may be implemented in one of more of the modules 120-132, or may be implemented by an intelligent control module (not shown) that controls the functionality of the IDS 102. The control process 140 includes one or more of the following steps as follows:

[00137] In step 142, a plurality of transaction requests may be received from a plurality of users 106a-106n and/or plurality of vendors 108a-108m. In step 144, the received transactions are queued for verification, preparation or transaction processing and/or blockchain processing. If the transaction is of the conventional type, then it will be verified and prepared for blockchain processing. If the transaction is of the instant type, then it will be verified and at least part of the transaction will be proceeded with, i.e. the transaction will be executed between the user(s) 106a-106n and/or the vendor(s) 108a-108m associated with the transaction. The transaction may be returned to an instant transaction queue 110b for subsequent blockchain processing by an IDS controlled node 114a when it is advantageous to do so, e.g. off-peak transaction times, or when the blockchain processing load decreases etc. In step 146, each transaction may be initially processed by one of the plurality of worker units 112a-112w for verification, preparation, and/or transaction processing (e.g. execution of the transaction of the transaction is of an instant type), and, if verified and prepared, the transaction may be subsequently sent for blockchain processing by one of the plurality of IDS controlled nodes 114a-114r. For example, an IDS controlled node 114a may submit a blockchain processed transaction to the blockchain nodes 116a-116z of the distributed blockchain network 104 for addition to the master blockchain 105. In step 148, a confirmation for each submitted blockchain processed transaction may be received indicating consensus was reached and the transaction was added to the master blockchain 105. For each confirmed transaction, a notification may be sent to the user(s) 106a-106n and/or vendor(s) 108a108m associated with the transaction. If the transaction is of a conventional type, then the transaction may be executed, finalised and/or proceeded with. The process 140 returns to step 142 for receiving further transactions associated with one or more users 106a-106n and/or one or more vendors 108a-108m.

[00138] Although the steps of process 140 may be implemented serially, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that some of the steps of the process 140 may be implemented in parallel or concurrently as appropriate or as demanded by the application and processing resources of the IDS 102 and the distributed blockchain network 104. For example, whilst the IDS 102 may implement steps 142 to 146 for each transaction, one or more of these steps 142-146 may also be implemented for newly received transaction(s) in parallel with the one or more previous steps 142-146 on previously received transactions. Thus, the functions of each step 142-146 may be implemented concurrently and/or serially in the one or more modules 120-132 and the like.

[00139] Referring back to figures 1a and 1b, in particular, the transaction queuing module 120 may be configured to receive different types of transactions from one or more of the plurality of users 106a-106n and/or one or more of the plurality of vendors 108a-108m. The transactions may be of different types such as, by way of example only but not limited to, transactions of the conventional type, transactions of the instant type, and any other type of transaction. This may require different transaction queues 110a-110q to be maintained and operated on by the various worker units 112a-112w and possible subsequent blockchain processing.

[00140] Initially, the transaction queuing module 120 receives transactions in which the received transactions are all placed into an incoming transaction queue 110a, in which one or more worker units 112a-112b may be configured to process. These one or more worker units 112a-112b may identify the transaction type of each received transaction (e.g. if both parties have an account with the IDS 102, then the transaction may be of an instant-type), perform one or more transaction operations if appropriate based on the transaction type, and/or place the received transaction into the appropriate transaction queue 110b-110q for further verification and, if verified/authorised, subsequent blockchain processing. The worker unit 112a may, depending on the type of transaction, perform one or more transaction operations if appropriate based on transaction type, and/or insert the identified transaction into the appropriate transaction queue for subsequent transaction processing and/or blockchain processing.

[00141] Each of the transaction queues 110a-110q may be monitored and maintained by incrementing a transaction queue counter when placing each transaction into that transaction queue by one of the worker units 112a-112w. The transaction queue counter may be decremented when a transaction is retrieved from the queue by one of the worker units 112a112w for verification and subsequent blockchain processing. Once in the transaction queue, each transaction awaits verification by a worker unit 112a and subsequent blockchain processing by an IDS controlled node 114a. If the transaction queue counter increases above a queue overload threshold, which may be set by an IDS 102 operator, the transaction queuing module 120 may indicate to the resource module 124 to allocate further resources (e.g. further worker units and/or IDS controlled nodes) to reduce the number of transactions in the transaction queue. Alternatively or additionally, the computing resource module 124 and/or transaction processing module 122 may be configured to monitor the transaction queues and/or counters and automatically allocate or deallocate resources (e.g. worker units and/or IDS controlled nodes) to the transaction module 120 and/or transaction processing module 122. This allows the IDS 102 to adapt when transaction volumes grow, which is detected centrally and thus the required number of worker units 112a-112w and/or IDS controlled nodes 114a-114r may be allocated and/or deallocated as demand rises and/or falls.

[00142] For example, a worker unit 112a may retrieve a transaction from the incoming or primary queue 110a and identify the transaction as, by way of example only but not limited to, conventional or instant based on the types of parties to the transaction. Transactions of the conventional type may require full blockchain processing immediately before the transaction may proceed between the corresponding one or more users 106a-106m and/or one or more vendors 108a-108m. These transactions are sent to the IDS controlled nodes 114a-114r for blockchain processing for addition to the master blockchain 105. Transactions identified to be of the instant type are typically those transactions between those users 106a-106n and/or vendors 108a-108m in which the IDS 102 may act as a trusted third party and is capable of performing at least part of the transaction between the parties (e.g. a user 106a and vendor 108a) priorto the transaction being retrieved by a worker unit 112a and, after verification, subsequently blockchain processed by an IDS controlled node 114a. This may include that the parties to the transaction have an account with the IDS 102 such that the IDS may be granted authorised access to their accounts etc., to allow a transaction to proceed as described herein.

[00143] A primary transaction queue 110a may be configured to accept transactions of the conventional type. The transaction module 120 may maintain the primary transaction queue 110a by incrementing a primary queue counter when the conventional transaction is placed into the primary transaction queue 110a. The primary queue counter may be decremented when a conventional transaction is retrieved from the primary queue 110a by one of the worker units 112a-112w for verification and, if verified, subsequent blockchain processing. Once in the primary queue 110a, each transaction awaits verification by one of the worker units 112a-122w and, if verified/authorised, subsequent blockchain processing by one of the IDS controlled nodes 114a-114r.

[00144] As described previously an instant transaction is a transaction between those users 106a-106n and/or vendors 108a-108m in which the IDS 102 may act as a trusted third party and is capable of performing at least part of the transaction between the parties (e.g. a user 106a and vendor 108a) priorto the transaction being retrieved by a worker unit 112a and, after verification, subsequently blockchain processed for storage onto the master blockchain 105. The transaction queuing module 120 may be configured to maintain an instant transaction queue 110b that is configured to accept transactions of the instant type. When a transaction is retrieved from the incoming/primary queue 110a and identified by a worker unit 112a to be a transaction of the instant type, the worker unit 112a may verify the transaction, and if verified/authorised, the worker unit 112a may initiate that one or more transaction operations in relation to the transaction are performed. This means that the transaction can proceed to be executed and/or completed even though the transaction has not yet been blockchain processed. The worker unit 112a also inserts the transaction of the instant type into the instant transaction queue 110b for subsequent retrieval, at the appropriate time, by further worker units 112a-112w verification and preparation for blockchain processing by one of the IDS controlled nodes 114a-114r.

[00145] Figure 1d is a flow diagram illustrating an example instant transaction process 150 for use by the IDS of figures 1a and 1b, and/or by one or more of steps 142-148 of control process 140 in relation to instant transactions according to the invention. The instant transaction process 150 includes one or more steps as follows: In step 152 one or more transactions are received from one or more user(s) 106a-106n and/or one or more vendor(s)

108a-108m. For example, one or more user(s) 106a-106n may be transferring funds between each other, one or more user(s) 106a-106n may be buying products or services from each other, one or more users 106a-106n may be buying products and/or services from one or more vendor(s) 108a-108m, one or more vendor(s) 108a-108m may be buying products, supplies and/or service from other vendor(s) 108a-108m and/or user(s) 106a-106n, and the like. In step 154, the transaction is identified to be a transaction of an instantaneous type when the IDS 102 may act as a trusted third party and has access to the required systems/information (e.g. user accounts and/or vendor accounts for cryptocurrency payments) associated with the users and/or vendors. The process 150 proceeds to step 156 (e.g. Ύ') if a transaction is identified as an instantaneous type transaction. Otherwise the transaction may be placed in a transaction queue (e.g. primary transaction queue 110a) and awaits conventional processing and subsequent blockchain processing for addition to the master blockchain 105.

[00146] In step 156, the IDS 102 proceeds to execute the transaction such that both the user and/or vendor may complete their side of the transaction. Execution of the transaction may be stored in a database 109, and the transaction confirmed to both the user and vendor. For example, in a cryptocurrency transaction, the user's cryptocurrency payment may be ring fenced in the user's account until confirmation of the transaction being added to the master blockchain, whilst the vendor may receive the cryptocurrency payment from the IDS 102 using the ring fenced cryptocurrency payment. The vendor may then immediately release the product or service associated with the cryptocurrency payment to the user. Alternatively, the IDS 102 may withhold payment to the vendor until full confirmation that the transaction has been blockchain processed and added to the master blockchain 105. In such cases, the vendor may simply trust the IDS 102 and immediately release the product or service associated with the payment to the user.

[00147] In the meantime, in step 158, it is determined whetherthe instant transaction should be retained and placed in an instant queue 110b (e.g. 'Y) and/or whether it may be prepared and blockchain processed for submission to the master blockchain 105 (e.g. 'N'). This decision may be determined based on processing load (e.g. peak or off-peak loads) of the IDS 102 and/or distributed blockchain network 104, and/or required target transaction times for transactions, and/or based on the cost of allocating further resources if required for blockchain processing the instant transaction and the like. If it is decided that the instant transaction may be kept or retained in the instant queue until when it is advantageous to perform blockchain processing on it, the instant transaction is placed in the instant queue 110b and awaits the appropriate time, as determined by the IDS 102, for blockchain processing. The process 150 proceeds at intervals, periodically or even aperiodically to step

158 in order to determine whether it is appropriate to blockchain process the instant transaction.

[00148] In step 162, the instant transaction is finally released from the instant queue 110b and blockchain processed by IDS controlled nodes 114a-114r for submission to the distributed blockchain network 104 for addition to the master blockchain 105. Once consensus is reached by the distributed blockchain network 104 the transaction is added to the master blockchain 105. In step 164, the process 150 may receive confirmation from the distributed blockchain network 104 that the transaction has been added to the master blockchain 105. In step 166, on receipt of the confirmation the process 150 may confirm final completion of the transaction to the corresponding users 106a-106n and/or vendors 108a-108m.

[00149] Referring to figures 1a and 1b, given that the transaction of the instant type has already started to be executed and/or completed, this means that blockchain processing of the transactions of the instant type may be stored in the master blockchain 105 at a time that is at the best advantage to the blockchain processing load on the IDS controlled nodes 114a114r and/or the blockchain nodes 116a-116z of the distributed blockchain network 104. That is, the resource module 124 may monitor the blockchain processing load and determine based on the blockchain processing load and/or costs of allocating additional resources when one or more or a group of instant transactions may be blockchain processed. For example, the transaction processing module 122 and/or computing resource module 124 may monitor and choose off-peak times for blockchain processing the instant transactions, which means additional resources may not need to be allocated. Off-peak times may be times when the blockchain processing load is below a peak blockchain transaction load threshold, above which transactions are likely to be delayed in the mempool of the master blockchain 105. This allows smoothing of the blockchain processing load.

[00150] In another example of the operation of the instant queue 110b, dynamic resizing of the blocks of the master blockchain 105 may be performed depending on the transaction load. The blocks may be dynamically resized to expand when it is detected the transaction load is increasing. This allows more transactions to be stored in each block of the master blockchain 105 and thus can allow the transaction load to increase whilst enabling as many transactions as possible to be stored in the master blockchain 105 and reducing the load of the mempool. The blocks of the master blockchain 105 may be dynamically resized to contract when it is detected the transaction load is decreasing. This allows less transactions to be stored in each block of the master blockchain 105, and thus can allow a reduction in blockchain processing resources to meet the transaction load and minimise the time it takes for a block to be completed and added to the master blockchain, thus providing efficient storage.

[00151] In such cases, the transaction queuing module 120 maintains the instant transaction queue 110b for transactions identified to be of an instantaneous (or instant) type, where one or more of, or a group of, these transactions are kept or retained in the instant queue 110b when a dynamic sizing of the blockchain is detected to expand. One or more, or a group, of the instant transactions may be released from the instant transaction queue 110b or the transaction processing module 122 may instruct (on detecting from dynamic sizing of the blockchain is to decrease or prompted by transaction queuing module 120) one or more worker units 112a-112w to retrieve one or more instant transactions from the instant queue 110b. These transactions may be processed by the worker units 112a-112w for verification and preparation for subsequent blockchain processing by the IDS controlled nodes 114a-114r for addition to the master blockchain 105 when a dynamic sizing of the blockchain is detected to contract. It is noted that some of the instant transactions may be released as dynamic sizing increases if there is a decrease in blockchain load and/or fewer transactions than expected given the size of the block, which means more instant transactions may be included in a block.

[00152] In a further example of the operation of the instant queue 110b, a blockchain transaction limit or blockchain interaction limit may be determined based on current processing resources in the IDS 102 and/or the distributed blockchain network 104. This may be used to determine when instant transactions may be blockchain processed. In this case the transaction queuing module 120 and transaction processing module 122 interact to maintain the instant transaction queue 110b for instant transactions, where the instant transactions are kept in the instant queue 110b when the blockchain processing load has reached or is above a determined blockchain transaction load limit or blockchain interaction threshold. This may be determined as a function of, by way of example only but not limited to, processing resources and/or also the rate of incoming transactions. The transaction queuing module 120 when prompted by the transaction processing module 122 may release one or more transactions of the instantaneous type from the instant transaction queue 110b to one or more worker units 112a-112w for preparation for blockchain processing, by the transaction processing module 122, for addition to the master blockchain 105 when the blockchain processing load is below the determined blockchain transaction load limit or the blockchain interaction threshold.

[00153] The transaction processing module 122 may be further configured to: control, receive, request or monitor the blockchain transaction load, and to control the IDS controlled nodes 114a-114r to submit blockchain processed transactions to the master blockchain and/or the associated mempool(s) for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit. Alternatively or additionally, the transaction processing module 122 may be further configured to: control, receive, request or monitor the blockchain transaction load, and to receive transactions from the transaction queue(s) 110a and/or 110b for blockchain processing by the one or more IDS controlled nodes 114a-114r, which subsequently added the blockchain processed transactions to the master blockchain 105 when the blockchain transaction load is less than a blockchain transaction load limit. This ensures that the retrieval of transactions from the queues is made when there is sufficient blockchain resources available to minimise the time required until the transaction is stored in the master blockchain 105.

[00154] Generally, every IDS controlled node 114a-114r should synchronise its blockchain with the master blockchain 105 in order to blockchain process transactions. However, an IDS controlled node 114a cannot trust the source of any peer-to-peer data, such as the blockchain held by another blockchain node in the distributed blockchain network 104. Typically, this means each block that is downloaded from the distributed blockchain network 104 master blockchain 105 must be verified against each block mathematically. This is a time consuming and CPU intensive operation. This is especially so when spawning new IDS controlled nodes that use full blockchain as all the blocks of the master blockchain 105 are required to be downloaded and verified. Rather than downloading the blocks from the master blockchain 105, the IDS 102 may maintain a trusted blockchain node that is configured to store and synchronise a trusted copy of the master blockchain with the master blockchain 105 of the distributed blockchain network 104. This means, each current IDS controlled node 114a-114r can download from the trusted blockchain node at any time without mathematically approving each block to maintain synchronisation with the master blockchain 105.

[00155] When a new IDS controlled node is spawned, the synchronisation module 126 may be configured to maintain the trusted blockchain node (e.g. trusted blockchain server) configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network 104. On receiving a request to spawn one or more blockchain nodes from the computing resource module 124, and/or transaction processing or queuing modules 122 or 120, it may allocate the one or more requested IDS controlled nodes. Once allocated, the maintenance of the trusted copy of the master blockchain on the trusted blockchain node is paused. The synchronisation module 126 then stores a copy of the trusted master blockchain on each of the allocated IDS controlled nodes. Once the raw, unverified (but trusted) blockchain files are downloaded the IDS node can be started. These allocated IDS controlled nodes may then download and synchronise any remaining blocks from the master blockchain 105 of the distributed blockchain network 104 via peer-to-peer conventional blockchain methodology. This means only a few blocks need be downloaded and verified, which further minimises the computational resources/time for ensuring the newly allocated IDS controlled nodes are ready for blockchain processing further one or more transactions from the transaction queues 110a-110q. In addition, the trusted blockchain node is also restarted and synchronised with the master blockchain 105 of the distributed blockchain network 104. Once the trusted IDS controlled node has been restarted, it continues to synchronise itself with the master blockchain 105. The plurality of IDS controlled nodes 114a-114r may also start synchronising with the trusted copy of the master blockchain being maintained by the trusted IDS controlled node. This further minimises the required computational time required to synchronise the IDS distributed network 114 of current IDS controlled nodes 114a-114rwith the master blockchain 105 of the distributed blockchain network 104. A plurality of IDS blockchain nodes can be started, with only a single server's (or server cluster's) blockchain analysis CPU overhead (the trusted node).

[00156] Every now and then one or more IDS controlled nodes can get out of synchronisation with the master blockchain 105 and due to a number of factors, which are often out of the control of the IDS 102. For example, network traffic may delay download of blocks, or there may be errors in transmission during the synchronisation download. This is particularly problematic because an IDS controlled node that is out of synchronisation will confirm a transaction as successful when it will ultimately fail when submitted to the master blockchain 105 of the distributed blockchain network 104. Thus, the synchronisation module 126 may further be configured to receive status reports from the IDS controlled nodes 114a-114r of the IDS 102. Each status report may include data representative of a block height (or block length) of the blockchain controlled by the corresponding IDS controlled node.

[00157] Once receipt of a status report from an IDS controlled node 114a is detected/received, the synchronisation module 126 may instruct the transaction processing module 122 to restart an IDS controlled node 114a when that node 114a reports a block height differing from the consensus block height of the master blockchain 105. Prior to restarting the blockchain node 114a, the transaction processing module 122 arranges to retrieve recent transactions added to the blockchain used by the IDS controlled node 114a. These transactions are possibly incorrect due to the IDS controlled node 114a using an outof-synch blockchain to that of the master blockchain 105. The transaction module 120 may have configured another transaction queue (not shown) as a transaction verification queue, in which the recent transactions are placed. One or more worker units 112a-112w may be tasked to verify the transactions for blockchain reprocessing as required by one or more other IDS controlled nodes 114b-114r whilst the IDS controlled node 114a is re-synchronised with the master blockchain 105, which may be via the trusted IDS controlled node maintaining a trusted copy of the master blockchain 105.

[00158] To ensure efficient operation of the IDS 102 such that transactions are blockchain processed and added to the master blockchain 105 in a timely manner, the resource module 124 may monitor the transaction blockchain load and/or the transaction queues to ensure adequate worker units 112a-112w and/or IDS controlled nodes 114a-114r have been allocated and/or deallocated. The computing resource module 124 may, based on monitoring the transaction blockchain load and/or the size of the transaction queues 110a-110q determine the number of IDS controlled nodes may be required to meet the current or a future transaction load to ensure a target transaction processing time. The computing resource module 124, if the determined number of IDS controlled nodes are greater than the current number of IDS controlled nodes 114a-114r, spawn one or more IDS controlled nodes to at least meet the determined number of IDS controlled nodes that may meet or exceed the transaction blockchain load. This may occur when the transaction blockchain load reaches or exceeds a current transaction load limit of the current set of IDS controlled nodes 114a-114r. The computing resource module 124 may further be configured to remove one or more IDS controlled nodes when the determined number of IDS controlled nodes is less than the current number of IDS controlled nodes 114a-114r and/or when the transaction blockchain load falls below a current transaction load limit of the current set of IDS controlled nodes 114a-114r.

[00159] Similarly, given that the IDS 102 includes one or more or a plurality of worker units 112a-112w for retrieving and processing transactions in the one or more queues 110a-110q, the computing resource module 124 may be further configured to monitor the worker units 112a-112w operating on each of the queues 110a-110q and determine the number of worker units 112a-112w that are required to meet each of the transaction queue loads to ensure a target transaction processing time can be met. The computing resource module 124 may be configured to spawn one or more worker units that will meet the determined number of worker units for each queue when the current number of worker units 112a-112w operating on that queue is less than the determined number of worker units forthat queue and/or when the transaction queue load forthat queue reaches or exceeds a previous queue transaction load. The computing resource module 124 may be configured to remove one or more current worker units 112a-112w when the determined number of worker units is less than the current number of worker units 112a-112w and/or when the transaction queue load falls below the current queue transaction load.

[00160] Alternatively or additionally, the resource module may be further configured to, for each transaction queue 110a-110q, maintain an estimate of average queue transaction processing time for a worker unit to complete processing a transaction associated with that transaction queue. The computing resource module 124 may then determine a required number of worker units based on the number of transactions in the transaction queue, the number of transactions handled by each worker unit operating on that transaction queue, the average queue transaction processing time estimate, and/or a target transaction time required to be met by each of the worker units. Once determined, the computing resource module 124 may then allocate or deallocate one or more worker units to meet the determined required number of worker units forthat transaction queue.

[00161] Figure 1e is a schematic diagram illustrating an example cryptocurrency hybrid blockchain system 170 according to the invention. Common reference numerals from figures 1a-1d are used to indicate similar or the same features. The cryptocurrency hybrid blockchain system 170 includes an interface database system 102 that receives and processes transactions from a plurality of users 106a-106n and/or vendors 108a-108m. The IDS 102 is coupled to a distributed blockchain network 104, which maintains the master blockchain in relation to the received and blockchain processed transactions. The IDS 102 of the cryptocurrency hybrid blockchain system 170 may include a cryptocurrency wallet functionality 172, which may be stored in database 109 (which may be a secure and/or trusted database), which includes maintaining and controlling a plurality of cryptocurrency wallets 172a-172I on behalf of one or more of the plurality of users 106a-106n and/or one or more of the vendors 108a-108m. The IDS 102 also includes multiple transaction queues 110a-110q for receiving incoming transactions from users 106a-106n and/or vendors 108a108m. The IDS 102 also includes an IDS processing cloud 174 that includes worker unit functionality 112 comprising a plurality of worker units 112a-112w and the IDS blockchain functionality of the IDS distributed network 114 comprising the plurality of IDS controlled nodes 114a-114r of the distributed blockchain network 104.

[00162] The plurality of worker units 112a-112w may be split into groups of worker units for performing various functionalities of a transaction prior to the transaction being blockchain processed by one of the IDS controlled nodes 114a-114r. For example, the plurality of worker units 112a-112w may be split into a group of wallet transaction worker units 112a-112i, a group of wallet instant transaction worker units 112k-112n, a group of balance/incoming transaction checking workers 112m-112s, and any other worker units 112t-112w that may be used during the transaction. Although the worker units 112a-112w have been described for simplicity as being split into distinct functional groups, this is by way of example only and the invention is not so limited to, groups of worker units having different functionalities, it is to be appreciated by the skilled person that each of the worker units 112a-112w may be assigned, depending on processing capacity of the worker unit 112a-112w, to perform one or more of these distinct group functionalities, and any other functionality that is required for processing the transaction prior to blockchain processing the transaction, and after receiving confirmation the transaction has been added to the master blockchain 105.

[00163] For those users 106a-106m and/or vendors 108a-108m that have one or more of the cryptocurrency wallets 172a-172I, the IDS 102 may act as a trusted third party to the transaction and may be able to execute portions and/or complete the transaction prior to the transaction being blockchain processed and added to the master blockchain 105 of the distributed blockchain network 104. Thus, the IDS 102 may act as the only point of contact fora majority of the users 106a-106m and/or vendors 108a-108m holding a cryptocurrency wallet 172a-127l in the IDS 102. This allows these users/vendors to perform instant transactions (e.g. buying/selling of products/supplies/services) in a similar manner as realworld transactions without any perceivable delay in transaction completion.

[00164] Typical cryptocurrency systems only use a distributed blockchain network in which the master blockchain is decentralised/distributed. In these systems there is no single controlling authority or trusted controlling authority. As a result cryptocurrency systems heavily rely on the distributed blockchain confirmations/consensus to confirm a transaction has taken place, is legitimate and has been added to the master blockchain, and can be completed. Given this, the distributed nature of typical cryptocurrency systems creates a severe delay in the order of minutes, hours or days depending on factors such as blockchain transaction load, transaction fees (e.g. mining fees for distributed blockchain nodes) before the transaction is completed between the user and the vendor. This creates an unnecessary delay that could otherwise be circumvented enhancing the transaction experience. In this example, the cryptocurrency hybrid blockchain system 170, which includes the IDS 102 coupled to a distributed blockchain network 104, leverages the benefits of a centralised system (e.g. speed of transactions, acting as a trusted third party to a cryptocurrency transaction) and also the benefits of a distributed blockchain system (e.g. immutability and security of the master blockchain that a transaction has taken place and is legitimate) to minimise the delay in a transaction completing, and as perceived from the user(s) and vendor(s) point of view, the transaction may be considered of an instantaneous type.

[00165] The IDS 102 may control, store and maintain a first group of the cryptocurrency wallets172a-172l (e.g. stored and maintained in a secure database 109) on behalf of a group of the users 106a-106n and may control, store and maintain a second group of the cryptocurrency wallets172a-172l (e.g. stored and maintained in a secure database 109) on behalf of a group of vendors 108a-108m. In order to do this, the first group of users 106a106n and second group of vendors 108a-108m have allowed the IDS 102 to, by way of example only but is not limited to, securely store the private cryptocurrency keys (e.g. public I private key pairs and the like) in a secure database (not shown). This means the IDS 102 has permission to access the users and vendors cryptocurrency wallets 172a-172l and streamline the transaction process, such that the users and vendors have an imperceptible delay between placing the transaction and receiving payment and/or release of the purchased product/service and the like.

[00166] The IDS 102, having secure access to the private keys of the group of users and/or group of vendors, can always know in a centralised way what transactions the users and/or vendors have made, confirm a transaction cryptocurrency payment amount is feasible, and confirm the transaction cryptocurrency payment to the party receiving the payment (e.g. usually the vendor), and confirm the purchase/service and/or transfer of property to the party receiving the purchase/property/service in exchange for the payment (e.g. usually the user) in advance of blockchain processing the transaction. Blockchain processing of this type of transaction may take place at a later time that is convenient to the IDS 102.

[00167] This gives an instant checkout scenario in both point of sale of ecommerce facilities and allows a user to spend/transfer cryptocurrency from their cryptocurrency wallets 172a1721 instantly, and allows the vendor to receive funds, or be instructed that funds are on their way. This means the vendor may release any purchased products/goods/services to the user. This means less blockchain time dependency is required for these blockchain transactions and they can be stored on the blockchain at a time that is at the best advantage to the blockchain load.

[00168] As an example, a user 106a may have a cryptocurrency wallet 172a stored with the IDS 102. Similarly, a vendor 108b may also have a cryptocurrency wallet 172b stored with the IDS 102. Both the user 106a and the vendor 108b have separately agreed to allow the IDS 102 to act as a trusted third party and securely store their cryptocurrency private keys with the IDS 102. This may be a secure database that is part of the cryptocurrency wallet functionality or other functionality associated with the IDS 102. This agreement and submission of their cryptocurrency private keys may be performed at anytime, e.g. on registration with the IDS 102 for a cryptocurrency wallet 172a or 172b, or at anytime thereafter when they wish register to make instant transactions. Prior to this, the user 106a and/or vendor 108b may be able to make conventional transactions, which primarily require full confirmation that the transaction has been added to the master blockchain 105 of the distributed before the transaction may be executed and completed between the user 106a and vendor 108b.

[00169] In this example, the user 106a and vendor 108b have registered to make instant transactions. Thus, as long as both the user 106a and any other vendor 108a-108m have registered to make instant transactions, they both can benefit from the instant checkout scenario. The user 106a may select to purchase a product from the vendor 108b and thus the user may submit an instant transaction to the IDS 102 indicating, by way of example only but not limited to, the purchase, the cryptocurrency payment amount, and the vendor 108b details. The transaction may be placed in an incoming transaction queue 110a and identified by a worker unit 112m that has functionality associated with the group of balance/incoming transaction checking workers 112m-112s. The worker unit 112m may process and identify that the transaction may be classed as an instant type of transaction because both the user 106a and vendor 108a have a cryptocurrency wallet 172a and 172b that is accessible by the IDS 102 (i.e. the user 106a and vendor 108b have registered to allow instant transactions).

[00170] The wallet balance worker unit 112m then verifies that the transaction may proceed by checking the cryptocurrency balance of the user cryptocurrency wallet 172a. If there are enough cryptocurrency funds in the user cryptocurrency wallet 172a in relation to the cryptocurrency payment amount for the transaction, the wallet balance worker unit 112m ring fences the cryptocurrency payment amount in the user cryptocurrency wallet 172a. This means that the user 106a does not have access to the cryptocurrency payment amount anymore as it has been ring fenced for transferring to the vendor cryptocurrency wallet 172b. Thus, the user 106a cannot overspend. The cryptocurrency payment amount may be transferred to the vendor cryptocurrency wallet 172b, and/or notification may be sent to the vendor 108b that payment has been ring fenced and will be transferred. Given this confirmation, the vendor 108b may release the product or service to the user 106a, this may occur a very short time (e.g. almost instantly) after the user 106a submits the transaction.

[00171] The wallet balance worker unit 112m places the verified transaction into an instant transaction queue 110b for subsequent preparation and blockchain processing. The transaction may be blockchain processed a later time that is advantageous as herein described to the processing load on the IDS 102 and/or distributed blockchain network 104. When it is advantageous to do so as herein described, a worker unit 112k having the functionality of a wallet instant transaction worker from the group of wallet instant transaction worker units 112k-112n, may retrieve the transaction from the instant queue 110b and process the transaction for preparation for blockchain processing by one of the IDS controlled nodes 114a-114r. The IDS controlled node submits the blockchain processed transaction to the distributed blockchain network 104 for addition to the master blockchain 105. Confirmation of the transaction being added to the master blockchain by the distributed blockchain network may be received by the IDS 102 and placed in a confirmation queue 110q. One or more other worker units may process the confirmation queue 110q and perform any further final transaction operations in relation to the transaction such as, by way of example only but not limited to, removing the ring fenced cryptocurrency payment from the user's wallet 172a, notifying the user 106a and/or vendor 108b that the transaction and payment process are complete, and/or other transaction completion processes are complete.

[00172] Figure 2a is a schematic diagram illustrating an example transaction load graph 200 for an example blockchain transaction system. The transaction load graph 200 plots the number of transactions 202 against time 204 to produce a blockchain transaction load line 208, which can be used as a measure of the blockchain load. It is to be noted that this graph is for illustrative purposes only. Different distributed blockchain networks have different maximum transactions per second depending on their design. Such blockchain transaction systems may be able to handle an average number of blockchain transactions 206, e.g. blockchain average 206, above which the transaction completion time substantially increases. This may be due many design issues such as, by way of example only but not limited to, static block sizes of the master blockchain, dynamic block sizes not increasing fast enough compared with the transaction load, limited blockchain processing resources for performing blockchain processing of transactions, etc. When the number of transactions (or blockchain load) exceeds the blockchain average 206 (e.g. a blockchain load limit based on the number of blockchain nodes that are allocated) the blockchain load line 208 may form a transaction peak 210a for a period of time above the blockchain average 206. During this time the transaction completion time may substantially increase because there are too many transactions but too few resources to blockchain process and complete the addition of the transactions to the master blockchain. Essentially, such blockchain systems will fail to handle the transaction load and cannot scale as the popularity of the blockchain system increases, where the number of users and/or vendors increase.

[00173] Distributed blockchain networks are vulnerable to transaction peaks 210a, 210b, 210c and do not or cannot handle transaction loads very well above their blockchain average 206, or above a maximum number of transactions per second. This is particularly exacerbated during times when there are spikes or a rush of user transactions during the day, month or year such as, by way of example only but not limited to, working hours between 8am and 5pm, cyber Monday, black Friday, last minute Christmas shopping during December, large ticket events, sales and the like etc.

[00174] However, there are also times during the day, month, and/or year (e.g. off-peak times) in which the distributed blockchain system has troughs of inactivity in user transactions ora transaction load below the blockchain average 206. Although the typical blockchain system can meet their target transaction times during these times, it is not particularly useful for users or vendors whom require or would prefer the transaction to be completed during the peak-times 210a, 210b, 210c or 21 Od. These troughs 212a and 212b may not efficiently make use of the blockchain processing resources.

[00175] Furthermore, different distributed blockchain systems have different maximum transactions per second (TPS) and cannot handle peaks in transaction load above the maximum TPS very well at all. Typically, all transactions are stored in the memory pool(s) (e.g. “mempool”) associated with the master blockchain and have to wait for blockchain processing by miners. Miners are the blockchain processing nodes or servers that manage the master blockchain of the distributed blockchain system. Although the transactions wait in the mempool, the blockchain processing nodes of miners may not operate upon them in any sequential order. Rather, each transaction is chosen by each miner based on a mining fee associated with the transaction.

[00176] Typically, the transactions with the highest fees are always taken first by the miner. For small transactions or transactions with modest or low fees, this can mean long delays (e.g. hours, days, weeks or even years) before completion of the transaction based on volume. When transactions are not processed during a transaction load peak 210a, 210b, 210c or 21 Od, it is not guaranteed that these transactions will be processed during transaction load trough 212a or 212b because of the priority for miners to process high fee transactions first, which are usually the most recent transactions. Thus means that transactions may become stuck in the mempool and the blockchain operator cannot know whether the transaction has “failed” even after many weeks. This is unacceptable for any transaction between a user and a vendor.

[00177] The hybrid blockchain transaction system 100 and 170 use an IDS 102 to minimise these problems. The centralised nature of the hybrid blockchain transaction system 100 and 170 enables the IDS 102 to monitor the transaction load on the master blockchain and the distributed blockchain nodes 116a-116z, IDS controlled nodes 114a-114r, and transaction loads of the worker units 112a-112w, and apply transactions to the master blockchain at a time that is at the best advantage to the blockchain load.

[00178] The instant transaction process(es) as described herein may alleviate or even remove the peak load and trough load problems associated with distributed blockchain networks. For example, as described with respect to figures 1 a-1 e and referring to figures 1 a1e, an IDS 102 according to the invention may have a majority of the plurality of users 106a106n and a majority of the plurality of vendors 108a-108m having cryptocurrency wallets 172a-172I allowing instant transactions, or transactions of the instant type. This means that during, byway of example only but not limited to, transaction peaks 210a, 210b, 210c and 21 Od as illustrated in figure 2a, the instant transactions may be placed in an instant transaction queue 110b awaiting blockchain processing. In the meantime, as described with respect to figure 1e, the IDS 102 may process the transaction, ring fence cryptocurrency payment amounts in the user cryptocurrency wallets, and notify the corresponding user(s) and vendor(s) that the transaction has been processed. From the users and vendors point of view, the transaction has taken place and they may proceed with the purchase, e.g. release of the purchased product/goods/services etc., with the vendor knowing the crypto currency payment amount in relation to the transaction will be transferred to their cryptocurrency wallet etc.

[00179] The IDS 102 may thus perform blockchain processing of the instant transactions in the instant transaction queue 110b at a time that is advantageous to perform blockchain processing. The IDS 102 may identify times when there is capacity in the IDS controlled nodes 114a-114r, and/or the remaining nodes 116a-116zof the distributed blockchain network 104 for blockchain processing one or more groups of instant transactions in the instant transaction queue 110b and/or submission and adding the blockchain processed instant transactions to the master blockchain of the distributed blockchain network 104. In the example of figure 2a, the IDS 102 may identify the troughs or off-peak loads 212a and 212b as suitable times for releasing one or more groups of instant transactions from the instant transaction queue 110b for blockchain processing by one or more blockchain nodes 114a114r and adding the blockchain processed instant transactions to the master blockchain 105 of the distributed blockchain network 104.

[00180] The centralised nature of the IDS 102, which allows instant transactions to take place provides a mechanism for removing the transaction peaks 210a, 210b, 21 Od and also the transaction troughs 212a and 212b, which effectively smooths out and removes the spikes and dips caused by the peaks and troughs. This also ensures that target transaction times can be met at all times during peaks of transaction load; leading to improved user and vendor experience and efficient and cost effective use of blockchain processing resources for the operator of the IDS 102. This further ensures that the maximum transaction volume of cryptocurrency payment transactions can be added to the master blockchain. This also further decreases the likelihood of failed cryptocurrency payments and transactions, makes blockchain processing more efficient and cost effective. Additionally, dynamic block sizing algorithms may further be used to allow a graceful upscaling of transactions and the maximum transaction load, which can further alleviate the hybrid blockchain transaction system according to the invention from hitting the blockchain transaction load or maximum number of transactions per second/minute etc.

[00181] Dynamic block sizing allows the blocks on a blockchain to grow in size to meet demand. Many cryptocurrencies have a static block size that gives a finite maximum number of transactions per second. The hybrid blockchain transaction system 100 or 170 may use a dynamic block size in conjunction with the IDS 102 functionality to ensure the efficiency of the blockchain is maximised by controlling the transaction flow from the worker units, IDS controlled nodes onto the blockchain.

[00182] The hybrid blockchain transaction system 100 and 170 also handles conventional blockchain transactions in a similar manner as peer-to-peer distributed systems. However, the IDS 102 enables fully centralised instant transactions, allowing vendors to instantly get cryptocurrency payment (fund) verification and users to instantly check-out and complete a purchase with the cryptocurrency payment, , which means less blockchain time dependency is required for these blockchain instant transactions in which they can be stored on the blockchain at a time that is at the best advantage to the blockchain load.

[00183] Figure 2b is a further flow diagram illustrating an example instant transaction process 220 that minimises the transaction load for use by the IDS 102 of figures 1a to 1e, and/or by one or more of steps 142-148 of control process 140 in relation to instant transactions according to the invention. The instant transaction process 220 includes one or more steps as follows: In step 222 one or more transactions are received from one or more user(s) 106a-106n and/or one or more vendor(s) 108a-108m for submission to addition to the master blockchain 105. For example, one or more user(s) 106a-106n maybe performing PUSH transactions for transferring funds between each other, one or more user(s) 106a-106n performing PUSH transactions for buying products or services from each other, one or more users 106a-106n performing PUSH transactions for buying products and/or services from one or more vendor(s) 108a-108m, one or more vendor(s) 108a-108m may be performing PULL transactions for subscription products/digital products/supplies and/or services from other vendor(s) 108a-108m and/or user(s) 106a-106n and the like.

[00184] In step 224, the transaction is identified to be a transaction of an instantaneous type when the IDS 102 may act as a trusted third party and has access to the required systems/information. These may include, by way of example only but not limited to, secure access to user cryptocurrency accounts and/or vendor cryptocurrency accounts for cryptocurrency payments, secure access to a user's user subscription tokens in relation to subscriptions with one or more vendors, secure access to the private keys of the users and/or vendors allowing the IDS 102 access to view these accounts and perform transactions securely accordingly.

[00185] The process 220 proceeds to step 226 (e.g. Ύ') where it is determined whether the transaction is identified as an instantaneous type transaction. If it is identified as an instantaneous transaction, the process 220 proceeds to step 228. Otherwise the transaction proceeds to step 232, which may be placed in a transaction queue (e.g. a primary transaction queue 110a) and awaits transaction processing/preparation and, if suitable, subsequent blockchain processing for addition to the master blockchain 105.

[00186] In step 228, the IDS 102 proceeds to execute the transaction such that both the user and/or vendor may complete their side of the transaction. Execution of the transaction may be stored in a database, enacted on the corresponding accounts of the user and/or vendor as described, by way of example only but not limited to, herein, and the transaction confirmed to both the userand vendor.

[00187] For example, in a cryptocurrency PUSH transaction of the instant type, the user's cryptocurrency payment may be ring fenced in the user's account until confirmation of the transaction being added to the master blockchain, whilst the vendor may receive notification that the cryptocurrency payment from the IDS 102 has been or is going to be made using the ring fenced cryptocurrency payment. The vendor may then immediately release the product or service associated with the cryptocurrency payment to the user. From the vendor and user's perspectives, the transactions occurs relatively swiftly in a similar fashion as a point of sale transaction.

[00188] In another example, in a cryptocurrency PULL transaction of the instant type submitted by a vendor in relation to a subscription product/service that the user has subscribed to, the vendor provides a unique subscription token which is matched to a unique subscription token stored in the IDS 102 in relation to a user (e.g. in the user's cryptocurrency account), once the unique token is verified to be linked to the user and subscription the IDS 102 may authorise the subscription payment. The user's cryptocurrency payment may be ring fenced in the user's account until confirmation of the transaction being added to the master blockchain, whilst the vendor may receive notification that the cryptocurrency payment from the IDS 102 has been or is going to be made using the ring fenced cryptocurrency payment. The vendor may then immediately provide the subscription product/service associated with the cryptocurrency payment to the user. From the vendor and user's perspectives, the transaction occurs relatively swiftly in a similar fashion as a point of sale transaction or subscription payment.

[00189] In the meantime, in step 230, it is determined whether the instant transaction (and/or other instant transactions) should be retained and placed in an instant transaction queue 110b (e.g. 'Y), or whether it may be prepared and blockchain processed for submission to the master blockchain 105 (e.g. 'N'). As described with reference to figure 2a, the IDS 102 may include functionality for determining whether a peak transaction load 210a, 210b, 210c or 21 Od may be occurring or whether off-peak transaction loads 212a or 212b (e.g. transaction troughs) may be occurring. If a transaction trough is not occurring, i.e. a transaction peak load is detected to be occurring, then the instant transactions are retained in the instant transaction queue 110b and await a time when it is detected that transaction trough or offpeak transaction load is occurring. This test in step 230 may repeated periodically, aperiodically, asynchronously or only when it is detected that a transaction off-peak load is detected. The determination of whether there is a blockchain transaction peak load or offpeak load may also be based on based on processing load of the IDS 102 and/or distributed blockchain network 104, and/or required target transaction times for transactions, and/or based on the cost of allocating further resources if required for blockchain processing the instant transaction and the like. If it is decided that the instant transaction may be kept or retained in the instant queue 110b until when it is advantageous to perform blockchain processing on it, the instant transaction is retained/placed in the instant queue 110b and awaits the appropriate time, as determined by the IDS 102, for blockchain processing. Once it is determined that one or more of or a group of the instant transactions in the instant transaction queue 110b may be blockchain processed, i.e. there is a transaction load trough/off-peak load like that of 212a or 212b, then the process 220 proceed to step 232 in relation to the one or more or group of instant transactions.

[00190] In step 232, each instant transaction that is finally released from the instant transaction queue 110b may be blockchain processed by IDS controlled nodes 114a-114r for submission to the blockchain nodes 116a-116z of the distributed blockchain network 104 for addition to the master blockchain 105. Once consensus is reached by the distributed blockchain network 104 the transaction is added to the master blockchain 105. In step 234, the process 220 may receive confirmation from the distributed blockchain network 104 that the transaction has been added to the master blockchain 105. On receipt of the confirmation the process 220 may confirm final completion of the corresponding instant transaction to the corresponding users 106a-106n and/or vendors 108a-108m and the like. The process may repeat for each received transaction.

[00191] Figure 2c is a schematic and flow diagram illustrating an example instant transaction process 250 in relation to the IDS 102 of the cryptocurrency hybrid blockchain transaction system 170 of figure 1e according to the invention. Common reference numerals from figures 1a-1e are used to indicate similar or the same features. The cryptocurrency hybrid blockchain system 170 includes IDS 102 that receives and processes transactions from a plurality of users 106a-107n and/or vendors 108a-108m, which in this example, a user 106n and vendor 108a are shown. The IDS 102 is coupled to a distributed blockchain network 104 (see figure 1e), which maintains the master blockchain in relation to the received and blockchain processed transactions.

[00192] The IDS 102 includes functionality associated with the transaction queuing module 120 and functionality associated with the transaction processing module 122. The transaction queuing module 120 may include, byway of example only but is not limited to, cryptocurrency wallet functionality 172 and worker functionality 254. The cryptocurrency wallet functionality

172 further includes storing, maintaining and controlling a plurality of cryptocurrency wallets 172a-172I on behalf of one or more of the plurality of users 106a-106n and/or one or more of the vendors 108a-108m. These may be stored in a trusted and/or secure database or server 109. The wallet functionality 172 may further include an incoming transaction queue 110a for receiving incoming transactions and identifying those that are instant transactions. The transaction queue 110a may be configured to receive incoming transactions from each of the users 106a-106n and/or vendors 108a-108m (see figure 1 e). The worker functionality 254 may further include the instant transaction queue 110b that is configured to receive instant transactions, which are processed, when required or when advantageously required, by a group of worker units 112a-112w.

[00193] The transaction processing module 122 includes IDS control for IDS distributed network 114 of distributed blockchain network 104, which includes the plurality of IDS controlled nodes 114a-114r, in which only IDS controlled node 114a of the distributed blockchain network 104 is shown. The transaction processing module 122 also includes functionality that may access the plurality of cryptocurrency wallets associated with each transaction. For example, in this case wallets 172a and 1721 may be accessed in relation to the transaction. The transaction processing module 122 also includes confirmation functionality 258, which includes a confirmation queue 110q that receives confirmation of blockchain processed transactions being added to the master blockchain 105 (not shown). The confirmation queue 110q may be processed by a group of worker units 112a-112w, in which the workers confirm the blockchain transfer in relation to the transaction. The IDS 102 also includes vendor payment module or system 128 and/or processing cloud application programming interface (API) 260 both of which may include the user/vendor interface module 130 or functionality thereto to act as the interface in relation to user/vendor transactions, requests, notifications and the like. PUSH transactions may be submitted by a user 106a and PULL transactions may be submitted by the vendor 108a via the vendor payment system 128 and API 260. The user may submit PUSH transactions to the vendor payment system 128 via a vendor interface 262 (e.g. Vendor ECOM), which may also allow EPOS, WEB, and automated subscription type payments and the like.

[00194] Instant transactions in the cryptocurrency hybrid blockchain transaction system 170 allow the IDS 102 to instantly confirm that a user 106n has the required cryptocurrency balance in their cryptocurrency wallet 172I. This is because the IDS 102 may act as a trusted third party in which each users 106a-106n private cryptocurrency keys and/or each vendors 108a-108m 106n private cryptocurrency keys for accessing their cryptocurrency wallets172a172b may be stored, along with their cryptocurrency walletsl 72a-172b, in the secure trusted database or server 109.

[00195] As the IDS 102 has access to user private cryptocurrency keys fortheir cryptocurrency wallet 172I, this means that the IDS 102 may determine what transactions a user 106n has made, what balance the user 106n should have (without requiring wallet synchronisation), verify whether the user 106n has enough cryptocurrency in their cryptocurrency wallet 172I to make the cryptocurrency payment, and can confirm the transaction cryptocurrency payment amount to a vendor 108a in advance of blockchain processing and submission to the distributed blockchain network for adding to the master blockchain in relation to the transactions. The cryptocurrency payment amount could even be transferred to the vendor cryptocurrency wallet 172a. The IDS 102 also ring fences the cryptocurrency payment amount in the user's cryptocurrency wallet 1721 to prevent the user 106n from spending this amount in subsequent or future transactions.

[00196] The IDS 102 provides instant checkout scenarios (e.g. instant PUSH transactions and/or instant PULL transactions) in both point-of-sale or ecommerce facilities associated with the vendor 108a. This allows the user 106n to correctly spend cryptocurrency from their cryptocurrency wallet, for all intents and purposes, instantly. The instant PUSH or PULL transaction may be subsequently stored or added to the master blockchain. This provides the full advantages of a distributed blockchain model/system along with the added advantages of a centralised system. The instant transaction has already been acted upon by the user 106n and the vendor 108a has been instructed that cryptocurrency payment funds are on their way; or that they have been transferred already. This means the vendor 108a may release the product/digital product/service to the user 106n. An additional advantage is that the instant transactions are less dependent on less blockchain processing/submission transaction times. This is because these instant transactions can be stored on the master blockchain at a time that is at the best advantage in relation to the transaction load and/or blockchain processing load and the like. The IDS 102 may store the instant transactions in the instant transaction queue 110b until it determines they can be released and added to the master blockchain as efficiently and/or as cost effectively as possible.

[00197] The cryptocurrency hybrid blockchain transaction system 170 allows the IDS 102 to manage user wallets 172I and/or vendor wallets 172a for them. The IDS 102 may have control and/or access to the private keys associated with the user wallets 172I and/or vendor wallets 172a. This means the IDS 102 can know every transaction that takes place within that wallet 172I or 172a.

[00198] Conventionally, cryptocurrency blockchain wallets 172a-172I can take time to synchronise with the master blockchain and provide an available balance. This usually takes a minimum period of time (e.g. counted at least in minutes) to perform a transaction and have it verified by the distributed blockchain network. This is typically an unacceptable period of time for users 106a-106n and/or vendors 108a-108m to wait, which is a problem for current distributed cryptocurrency systems. Rather than synchronising with the master blockchain each time a user 106n needs to make a transaction with a vendor 108a, centralising the wallet management functionalities such that they are managed by a trusted third party, e.g. by the IDS 102, can alleviate the transaction delay substantially, [00199] The wallet management system or wallet functionality 172 is instead centralised within the IDS 102 and may use, by way of example only but is not limited to, the secure trusted database/server 109 within the IDS 102. The wallet functionality 172 may securely store the current cryptocurrency balances of the vendor 108a and/or user 106n in the secure trusted database/server 109. This enables the user 106n to make a cryptocurrency transaction (e.g. PUSH instant transaction such as a purchase via their cryptocurrency balance instantly) in an instant fashion. The wallet functionality may access the user's cryptocurrency balance and store it in the trusted database/server 109, which may be a fast access database/server. Alternatively or additionally, the vendor payment system 128 may be configured to access the users cryptocurrency balance and store it in the trusted database/server 109, which may be a fast access database. This may be stored in the cloud. Vendors may create a cryptocurrency account that will allow them to accept crypto currency payments from users submitting PUSH transactions, and/or accept cryptocurrency payments by submitting PULL transactions in relation to a user's subscription with the vendor 108a.

[00200] The instant transaction process 250 uses the above-mentioned infrastructure of the IDS 102 to enable processing and confirming transaction of the instant type (e.g. a cryptocurrency payment) as fast as possible, and almost instantly compared with other conventional distributed cryptocurrency system transactions (e.g. Bitcoin RTM, Ethereum RTM and the like). Using the infrastructure of the cryptocurrency hybrid blockchain transaction system 170, especially the IDS 102, the instant transaction process 250 can provide a process and system functionality that can provide a substantially instant or fast guarantee to the vendor 108a (e.g. seller of a product or service) that the cryptocurrency payment funds associated with a transaction have been allocated and the transaction is now accepted and will happen. The instant transaction process 250 may include the steps as follows:

[00201] Initially, a user 106n may visit a store (e.g. electronic point of sale (EPOS)) and/or vendors ecommerce system 262 (e.g. a website and the like) that accepts cryptocurrency payments via the vendor payment system 128. In step 262, the user 106n attempts to make a cryptocurrency purchase in relation to a product or service of the vendor 108a. The user 106n thus makes or sends a PUSH cryptocurrency transaction in relation to the purchase via the vendor payment system 128. In step 266, a vendor payment processing cloud or API 260 in the IDS 102 is queried in relation to the PUSH transaction from the user 106n. In step 268, the vendor payment processing cloud or API 260 communicates with wallet functionality 172 and submits the PUSH transaction from the user 106n towards the wallet functionality 172 (e.g. or vendor payment system) of the transaction module 120 via incoming transaction queue 110a. This is to check the user's cryptocurrency balance of their cryptocurrency wallet 1721.

[00202] In step 270, the wallet functionality 172, using one or more worker units from a group of worker units (not shown), retrieves the PUSH transaction from the transaction queue 110a. The wallet functionality 172 uses data or information in the PUSH transaction to determine whether the user 106n has enough cryptocurrency in their cryptocurrency wallet 172I. This is achieved quickly using the secure trusted database 109, which may store an updated balance of the cryptocurrency wallet of each user. If there is enough cryptocurrency in the users cryptocurrency wallet 172I then the cryptocurrency payment amount associated with the PUSH transaction is ring-fenced. If there is not enough cryptocurrency in the users cryptocurrency wallet 172I, then a failure message may be generated for sending back to the vendor 108a and the user 106n.

[00203] In step 272, the IDS 102 transmits via the vendor payment system 128 an instant payment success or failure message to the user 106n and the vendor 108a. If an instant payment success message is transmitted in relation to the PUSH transaction, the user 106a may check-out and the vendor may release the product/digital product/goods and/or services to the user 106n. The wallet functionality 172 may also be configured to transfer the cryptocurrency payment amount (maybe less a transaction fee) to the vendor cryptocurrency wallet 172a. Alternatively the wallet functionality 172 may simply inform the vendor 108a that the cryptocurrency payment will be transferred once full confirmation of the PUSH transaction being added to the master blockchain has been received. The vendor 108a may trust this notification and release the product/digital product/goods and/or services to the user 106n. From the point of view of the user 106n and vendor 108a, the steps from the user 106a placing the PUSH transaction to step 272 of transmitting the success or failure notification, the PUSH transaction may happen in an instantaneous manner. That is, at a speed that it seems, to the user 106n and/or the vendor 108a, that the transaction occurs at a speed or pace that may be as quick as, if not quicker, as it would for a normal credit card/debit card transaction or contactless payment via an EPOS system in a store or on a website.

[00204] In the meantime, if the instant payment success message was sent, then in step 274, the transaction module 120 of the IDS 102 places the instant transaction add transaction to relevant worker queue (spawn more workers if required on load). In step 276, at the appropriate time that is advantageous to the operation and performance of the IDS 102 and/or as described herein, a worker unit 112a of a group of worker units 112a-112w (e.g. wallet instantaneous transaction worker units) may retrieve the PUSH transaction, which is of an instantaneous type, and sends the PUSH transaction to the transaction processing module 122, in which an IDS controlled node 114 a blockchain processes the PUSH transaction for submission and addition of the transaction to the master blockchain of the distributed blockchain network 104. In step 278, the transaction processing module 122 may receive confirmation that the PUSH transaction has been added to the master blockchain, which was placed in a confirmation queue 110q. A worker unit may retrieve the PUSH transaction confirmation and process it by opening the vendor's cryptocurrency wallet 172a, that received the transfer, and verifies transfer is complete. Alternatively or additionally, in step 278, if the transfer has not yet been performed, the wallet functionality 172 and/or the IDS controlled node 114a, or a wallet worker unit (now shown), may open the vendor's cryptocurrency wallet 172a and transfer the cryptocurrency payment (maybe less a transaction fee) from the user's cryptocurrency wallet 172I to the vendor's cryptocurrency wallet 172a.

[00205] Distributed cryptocurrency blockchain systems are effectively PUSH transactions in which users 106a-106n are required to push cryptocurrency from their cryptocurrency wallet 172I to another user's or vendor's cryptocurrency wallet 172a. The instant transaction process 250 may be modified to allow PULL transactions, which allows users 106a-106n to authorise vendors 108a-108m to take or PULL any future cryptocurrency amount or an agreed subscription amount from the user's cryptocurrency wallet 1721 in each subscription period (e.g. monthly, quarterly, annually, etc.).

[00206] The user 106n may subscribe to receiving a subscription product/service from a vendor 108a, or set up an automated payment subscription with the vendor 108a in relation to a subscription product/service and the like. The vendor payment system 128 and/or processing cloud/API 260 may facilitate the agreement between user 106n and vendor 108a of the subscription rules and corresponding subscription details. This may include checking the user 106n has sufficient cryptocurrency funds/balance in their cryptocurrency wallet 1721. If successful, a vendor token in relation to the user subscription may be issued to the vendor via the vendor payment system 128. The subscription rules, subscription details, and vendor token in relation to the subscription are linked to the user 106n and stored in the trusted secure database 109. This may be stored or linked to the cryptocurrency wallet 1721 of the user 106n, or against this user 106n in the database 109. Once set up, the vendor 108a may make PULL transactions from the user cryptocurrency wallet 1721 based on the instant transaction process 250.

[00207] The instant transaction process 250 may be modified in step 262, in which rather than the user 106n visiting a store (e.g. electronic point of sale (EPOS)) and/or vendors ecommerce system 262 (e.g. a website and the like) that accepts cryptocurrency payments via the vendor payment system 128, the vendor 108a makes an automated subscription transaction. In step 262, the vendor 108a attempts to make a cryptocurrency transfer from the user 106n in relation to the subscription to a product or service of the vendor 108a. The vendor 108a may automatically, or manually, make or send a PULL cryptocurrency transaction, which may include data representative of the vendor token in relation to the user subscription (previously issued by the vendor payment system 128) via the vendor payment system 128. In step 266, a vendor payment processing cloud or API 260 in the IDS 102 is queried in relation to the PULL transaction from the vendor 108a. In step 268, the vendor payment processing cloud or API 260 communicates with wallet functionality 172 and submits the PULL transaction from the vendor 108a towards the wallet functionality 172 (e.g. or vendor payment system) of the transaction module 120 via incoming transaction queue 110a. The PULL transaction may be identified as an instant transaction as both the vendor 108a an the user 106n have cryptocurrency wallets 172a and 1721, respectively. This is to check the user's cryptocurrency balance of their cryptocurrency wallet 1721.

[00208] In step 270, the wallet functionality 172, using one or more worker units from a group of worker units (not shown), retrieves the PULL transaction from the transaction queue 110a. The wallet functionality 172 uses data or information in the PULL transaction to determine whether the user 106n has enough cryptocurrency in their cryptocurrency wallet 172I. The wallet functionality 172 also uses the data representative of vendor token in relation to the user subscription and checks whether this token matches any subscription tokens linked to the user 106n and/or their cryptocurrency wallet 1721 stored in the trusted secure database 109. In addition, the wallet functionality 172 may also use the PULL transaction to determine whether the user 106n has enough cryptocurrency in their cryptocurrency wallet 172I. This is achieved quickly using the secure trusted database 109, which may store an updated balance of the cryptocurrency wallet of each user. If there is enough cryptocurrency in the users cryptocurrency wallet 1721 and if the data representative of vendor token in relation to the user subscription matches any subscription tokens linked to the user 106n and is in line with the subscription rules associated with the subscription (e.g. to prevent the vendor 108a performing multiple PULL transactions that are not in line with the subscription period), then the cryptocurrency payment amount associated with the PULL transaction is ring-fenced. If there is not enough cryptocurrency in the users cryptocurrency wallet 1721, then a failure message may be generated for sending back to the vendor 108a and the user 106n.

[00209] In step 272, the IDS 102 transmits via the vendor payment system 128 an instant payment success or failure message to the user 106n and the vendor 108a. If an instant payment success message is transmitted in relation to the PULL transaction, the vendor 108a may release the product/digital product/goods and/or services to the user 106n. The wallet functionality 172 may also be configured to transfer the cryptocurrency payment amount (maybe less a transaction fee) to the vendor cryptocurrency wallet 172a. Alternatively the wallet functionality 172 may simply inform the vendor 108a that the cryptocurrency payment will be transferred once full confirmation of the PULL transaction being added to the master blockchain has been received. The vendor 108a may trust this notification and release the product/digital product/goods and/or services to the user 106n. From the point of view of the user 106n and vendor 108a, the steps from the vendor 108a placing the PULL transaction to step 272 of transmitting the success or failure notification, the PULL transaction may happen in an instantaneous manner. That is, at a speed that it seems, to the user 106n and/or the vendor 108a, that the transaction occurs at a speed or pace that may be as quick as, if not quicker, as it would for a normal credit card/debit card transaction or contactless payment via an EPOS system in a store or on a website.

[00210] In the meantime, if the instant payment success message was sent, then in step 274, the transaction module 120 of the IDS 102 places the instant PULL transaction into the relevant workload queue, which in this case is the instant transaction queue 110b (more worker units may be spawned if required based on load). In step 276, at the appropriate time that is advantageous to the operation and performance of the IDS 102 and/or as described herein, a worker unit 112a of a group of worker units 112a-112w (e.g. wallet instantaneous transaction worker units) may retrieve the PULL transaction, which is of an instantaneous type, and sends the PULL transaction to the transaction processing module 122, in which an IDS controlled node 114a blockchain processes the PULL transaction for submission and addition of the transaction to the master blockchain of the distributed blockchain network 104. In step 278, the transaction processing module 122 may receive confirmation that the PULL transaction has been added to the master blockchain, which is placed in a confirmation queue 110q. A worker unit may retrieve the PULL transaction confirmation and process it by opening the users wallet 172I and making a transfer to the vendor's cryptocurrency wallet 172a, , then verify transfer is complete. Alternatively or additionally, in step 278, if the transfer has not yet been performed, the wallet functionality 172 and/or the IDS controlled node 114a, or a wallet worker unit (now shown), may open the vendor's cryptocurrency wallet 172a and transfer the cryptocurrency payment (maybe less a transaction fee) from the user's cryptocurrency wallet 172I to the vendor's cryptocurrency wallet 172a.

[00211] Figure 2d is another flow diagram illustrating an instant transaction process 280 for use with the hybrid block transaction system 170 according to the invention. Referring to reference numerals to the same or similar components in figures 1a-2c, the instant transaction process 280 may include the following steps of: In step 281, the IDS 102 receives a cryptocurrency transaction between the user 106n and the vendor 108a. A worker unit 112a may process and identify the cryptocurrency transaction as a transaction of an instant type, because the wallet functionality 172 may detect that the user 106n and the vendor 108a have cryptocurrency wallets 1721 and 172a, respectively. In step 283, it is checked whether the transaction is of an instantaneous type (or instant type). If it is of the instant type (e.g. Ύ'), then the process 280 proceeds to step 284. If it is not of the instant type (e.g. 'Nj then the process 280 proceeds to step 292.

[00212] In step 284, it is determined whether the user cryptocurrency wallet 1721 is capable of handling the transaction. This may include checking the balance of the user cryptocurrency wallet 1721, which may be stored in a secure trusted database/server 109. If the balance of the user cryptocurrency wallet 1721 is less than the cryptocurrency payment required in the transaction, then the user cryptocurrency wallet 1721 is not capable of performing the transaction. However, if the balance of the user cryptocurrency wallet 1721 is greater than or equal to the cryptocurrency payment required by the transaction, then the user cryptocurrency wallet 1721 is capable of performing the transaction. In step 285, it is checked whether the user cryptocurrency wallet 1721 is capable of performing the transaction. If it is capable, i.e. (Ύ) then the process 280 proceeds to step 286, otherwise the process 280 proceeds to step 296.

[00213] In step 286, the wallet functionality 172 ring fences the transaction funds, or the cryptocurrency payment amount in the user cryptocurrency wallet 1721 such that the user 106n cannot have access to this cryptocurrency payment amount. This avoids the issues of user double-spending. In step 287, the vendor payment system 128 may confirm that the instant transaction is a success to the vendor 108a and the user 106n. The vendor may then release the product/service to the user 106n. In step 288, the instant transaction is submitted to an instantaneous transaction queue 110q. The IDS 102 may wait until an advantageous blockchain load or a trough in transaction load occurs before blockchain processing the instant transactions in the instant transaction queue 110b. Once this occurs, an IDS controlled node 114a may blockchain process the instant transaction associated with user 106n and submit the blockchain processed transaction for addition to the master blockchain of the distributed blockchain network. In step 289, the IDS 102 receives confirmation that the instant transaction associated with the user 106n has been added to the master blockchain. In step 290, the IDS 102, via the vendor payment system 128, may confirm the transaction success to the user 106n and/or vendor 108a. In step 291, the wallet functionality 172 may update the user cryptocurrency wallet 172I by removing the ring fenced cryptocurrency payment amount and the wallet functionality 172 may update the vendor cryptocurrency wallet 172a by adding the ring fenced cryptocurrency payment amount to the vendor cryptocurrency wallet 172a.

[00214] Although it is described that the cryptocurrency payment amount is transferred, by way of example only but is not limited to, to the vendor cryptocurrency wallet 172a on confirmation that the transaction was added to the master blockchain, it is to be appreciated by the skilled person that step 287 may be modified such that the wallet functionality 172 may also update the vendor cryptocurrency wallet 172a by adding the ring fenced cryptocurrency payment amount to the vendor cryptocurrency wallet 172a. At this point, it is highly like the transaction is proceeding and so this may alleviate vendor's concerns in releasing the product/service to the user 106n in relation to the transaction.

[00215] Transaction queues 110a-110q may be managed or controlled based on the worker unit processing capacity and also the IDS controlled node processing capacity. These all depend on the transaction load, which is based on the number of incoming transactions. If the number of incoming transactions is less than the number of outgoing transactions onto the master blockchain, then there may be an unnecessary amount of processing capacity in the IDS 102. In this case, there is an inefficient use of computing resources and/or unnecessary cost or expense in deploying the excess computing resource. If the number of incoming transactions is greater than the number of outgoing transactions onto the master blockchain, then there may be a requirement for additional processing capacity as the transaction queues will get ever larger. In this case, there may be an under capacity of computing/processing resources, which may further exacerbate transaction completion time and delays.

[00216] Instantaneous transactions may be queued up in the instantaneous transaction queue until it is advantageous to blockchain process them based on transaction load and/or processing capacity. Thus, it is recognised that there is no urgency in getting these transactions blockchain processed and added to the master blockchain. As well, such transactions have been assumed by the user 106n and vendor 108a to have been completed/enacted and thus there is no urgency in getting them blockchain processed until there is a drop in transaction load or blockchain load as described with reference to figures 2a-2d. However, even instantaneous transaction queues may get to full and so more processing capacity may need to be brought to bear. Similarly, conventional transactions may require the corresponding worker units and/or IDS controlled nodes to be as fast as possible as users and/or vendors may be waiting on the transaction to be confirmed to have been added to the master blockchain before the transaction is confirmed and completed.

[00217] The following describes various example management and control processes that may be included into the functionality of the IDS 102 and can assist in controlling or managing the transaction queues by allocating and deallocating processing resources towards the transaction queues as the transaction load or blockchain load increase and/or decrease.

[00218] Given the centralised nature of the IDS 102, the IDS 102 can have a much better overview of what transactions are taking place and manage them more intelligently. The IDS 102 may include the functionality of a series of monitors and controls that allow and enable intelligent control of transaction flow and processing. Thus, when transaction volumes grow or the transaction load increases, this can be detected centrally and the required amount of worker units 112a-112w and/or IDS controlled nodes 114a-114rcan be efficiently spawned, where new IDS controlled nodes (e.g. servers) are started if required.

[00219] Figure 3a is a flow diagram illustrating an example IDS controlled node management process 300 for use with the IDS 102 according to the invention. Common reference numerals from figures 1a-2c may be used to indicate similar or the same features. The IDS controlled node management process 300 may be used to control the efficient spawning and/or de-spawning of IDS controlled nodes. The process 300 may be performed by the computing resource module 124 and/or by parts of the computing resource module 124 and/or synchronisation module 126.

[00220] IDS controlled nodes 114a-114r are brought to life and retired based on transaction load and need to spawn as fast as possible to enable the efficient operation of the IDS 102 and/or hybrid blockchain transaction system 100 or 170 whilst minimising server/node costs. Operating large scale numbers of IDS controlled nodes 114a-114r requires a change in the way the these systems operate. Typically, a blockchain node operates in a decentralised manner, and as such does not trust the source of any of its peer-to-peer data such as copies of the master blockchain on its peers. This means each block that is downloaded from a peer-to-peer decentralised/distributed blockchain network must be verified against each block mathematically. This is a time consuming and processor intensive operation.

[00221] In this example, the IDS 102 has a trusted blockchain server or node that maintains a synchronised trusted copy of the master blockchain. This is kept synchronised to the master blockchain and may be used by each of the IDS controlled nodes 114a-114r to maintain the synchronisation of their copies of the master blockchain. Alternatively or additionally, once the copy of the master blockchain is downloaded, the IDS controlled nodes may synchronise new blocks directly with the master blockchain.

[00222] In any event, the centralised nature of the IDS 102 allows a (verified) trusted central copy of the master blockchain to be maintained in a “known good” environment. That is, the trusted copy of the master blockchain may be maintained on a trusted blockchain node and/or server. This means the data from this server (or servers as there may be multiple trusted blockchain nodes/servers) may be trusted implicitly. The IDS 102 includes the functionality of process 300 to enable IDS controlled nodes to be efficiently spawned. Process 300 may include the steps based on the following:

[00223] In step 302, the IDS 102 may include functionality for estimating the required number of blockchain nodes based on, by way of example only but not limited to, the number of transactions that a worker unit may concurrently process, the number of transactions that may concurrently be required to be processed by worker units 112a-112w, the number of transactions that an IDS controlled node may handle, the transaction load, blockchain load, incoming transactions and/or outgoing transactions to the master blockchain and the like. Monitoring of the transaction load and/or blockchain load may be used to generate the estimate.

[00224] For example, if there are Y (e.g. 10000) transactions in a queue, and each wallet worker unit 112a-112w can open K (e.g. 5) transactions concurrently, then the system may require fY/K] (e.g. 2000) worker units to completely process the queue divided by the required target transaction time t (e.g. 10 minutes), which may be set by the operator. The ceiling operator [ ] is used to round up to the nearest integer to ensure there are a sufficient number of wallet worker units and/or IDS controlled nodes; rounding down may mean that there would be a deficit in processing capacity. Thus, dividing fY/K] (e.g. 2000 wallet worker units) by a required target transaction time t as set by the operator (e.g. 10 minutes) gives [|Y/K]/t] = 200 wallet worker units required. However, this then means that there needs to be an adequate number of IDS controlled nodes to handle the [fY/K]/t] wallet worker unit processed transactions that will be shortly received. An estimate on the number of IDS controlled nodes to meet the demand of the worker units, may be a calculation based on the maximum number of wallets that are concurrently able to connect to a node to process transactions, i.e. fY/K], divided by an m number of worker wallets each IDS controlled node may be able to process and handle (e.g. ffY/K]/m]). For example, if an IDS controlled node can handle processing 50 concurrent wallets (e.g. m = 50), then the estimated number of IDS controlled nodes is 40 IDS controlled nodes. (200 wallet worker units 150 max concurrent connected wallets).

[00225] It is noted that the target transaction time or target time may be set by the operator and may be determined as a compromise between cost and processing capacity. For example, setting the target time to 10 minutes and using [fY/K]/t] means that it will take t times as long for [fY/K]/t] worker units to process the /transactions in the queue as opposed to processing the entire queue in a minute (e.g. t=1 minute). The target time t may be set by the operator because, in this example, the operator has accepted that the entire time t² minutes (e.g. 100 minutes when t=10 minutes) taken for processing all /transactions in the queue is an acceptable time. The operator would also look towards balancing the cost of operating the worker units (and also the IDS controlled nodes) with the time t² taken to process all the Y transactions. For example, if the cost of processing all Y transactions per minute is C, then the cost of processing all Ytransactions in t² minutes is C/t². Adjusting t allows the operator to reach an acceptable transaction time for processing Y transactions whilst also taking into account the cost C/t² of processing the Ytransactions. Typically the worker units and IDS controlled nodes are spawned on demand, but an operator may pay for a whole hour of processing time, so generally an operator would not wish to spawn enough worker units and IDS controlled nodes to remove the entire queue instantly at great cost. There is a balance that the operator needs to meet between cost and transaction time.

[00226] In another example, for a cryptocurrency hybrid blockchain transaction system 170 in which the transactions are cryptocurrency transactions each worker unit 112a-112w may be a wallet worker unit. A wallet worker unit 112a may retrieve a number of K cryptocurrency transactions from a transaction queue 110a. For each transaction, the wallet worker unit 112a may open the cryptocurrency wallet associated with each transaction and verify the transaction can be made (i.e. are there are enough cryptocurrency units in the wallet). This verification requires performing mathematical algorithms to check the entire blockchain to determine those transactions associated with the cryptocurrency wallet. Wallet worker units then send the verified transactions that can be made to an IDS controlled node 114a.

[00227] As described above, the number of wallet worker units required to process a queue of Ytransactions is the number of queued transactions /divided by the number of cryptocurrency wallets a wallet worker unit can concurrently open K divided by the required target transaction time t. As described above, the number of wallet worker units may be, by way of example only but not limited to, \Y/K}/t worker units. Based on the number of worker units, the number of IDS controlled nodes may be estimated as the required number of IDS controlled nodes to match the wallet worker units.

[00228] For example, if there are Y=10000 transactions in the queue and each wallet worker unit can open K=5 concurrent cryptocurrency wallets then, fY/K] =2000 wallet workers would be needed to process the transaction queue within 1 minute. It is noted that the transactions will be made up of instant transactions which are less time dependent items and conventional transactions. The average time for a wallet worker unit to complete a transaction may be estimated and kept in a database and updated constantly. This may allow an operator to determine an appropriate target transaction time for completing a number of transactions. Should the operator set the target time t, by dividing the [Y/Kj = 2000 wallet worker units by the target time t = 10 minutes as set by the operator, then the number of wallet worker units is ΙΪΥ/ΛΠ/t] = 200.

[00229] There is may be a different target time for instant cryptocurrency payments/transactions because these can be slower and can have less concurrent wallet worker units than conventional transactions which have to happen as fast as possible. As an example, the operator may estimate that t = 40 minutes is acceptable for processing the same number of Y = 10000 instant transactions without affecting the user or vendor, which means only [fY/Kf/t] = 50 wallet worker units may be required.

[00230] Based on the estimated number of wallet worker units that the operator may require, the number of IDS controlled nodes that may be required to meet the demand of the wallet worker units may be based on the number of wallets concurrently required to open (e.g. fY/K] = 2000) I the number of cryptocurrency wallets an IDS controlled node can handle. For example, if an IDS controlled node can handle 50 cryptocurrency wallets (connected wallets) then the above example would estimate the required number of IDS controlled nodes to be 40.

[00231] In step 304, the current number of IDS controlled nodes 114a-114r is compared with the estimated number of IDS controlled nodes. If there are more IDS controlled nodes than the estimated number of blockchain nodes (e.g. 'N'), then the process 300 proceeds to step 316. If there are more estimated number of blockchain nodes than IDS controlled nodes (e.g. Ύ'), then the process 300 proceeds to step 306. The number of IDS controlled nodes that should be spawned may be the difference, X, between the estimated number of IDS controlled nodes and the current number of IDS controlled nodes 114a-114r. That is, the difference X is the number of IDS controlled nodes that may need to be spawned to meet the transaction load and the like or the operators estimate of the required number of IDS controlled nodes and the like [00232] In step 306, the trusted IDS controlled node (or server) with the trusted copy of the master blockchain may be stopped to allow any newly spawned IDS controlled nodes to be synchronised quickly.

[00233] In step 308, X new IDS controlled nodes are allocated and spawned by the IDS 102. These X new IDS controlled nodes now require a full copy of the master blockchain.

[00234] In step 310, each of the X new IDS controlled nodes are started. In step 312, each of the X new IDS controlled nodes are synchronised with the master blockchain. This may involve downloading the trusted copy of the master blockchain from the trusted IDS controlled node. Although the trusted IDS controlled node as been offline, and may now be out-of-sync with the master blockchain, downloading the trusted copy of the master blockchain and then syncing the last few blocks directly with the master blockchain is faster using the internal network of the IDS 102 than using downloading the master blockchain from the distributed blockchain network 104 on an external network. Thus each of the X new IDS controlled nodes are synchronised with the master blockchain. In step 314, the trusted blockchain node (or server) is started and it may directly synchronise with the last several blocks of the master blockchain to ensure the trusted copy of the master blockchain is synchronised.

[00235] When a new batch of IDS controlled nodes (or servers) 114a-114r are generated/allocated, they can be synchronised with the master blockchain faster by stopping the trusted/verified IDS controlled node, then copying the raw block data to the new IDS controlled nodes. This may be achieved over an internal gigabit network using a differential copying and/or synchronising algorithm such as, by way of example only but not limited to, RDIFF. This allows the new IDS controlled nodes to have a full copy of the master blockchain in a fraction of the time it would take to download a P2P copy from the master blockchain via the distributed blockchain network 104. As soon as the copies are downloaded to each new IDS controlled node, the IDS controlled nodes may be started, and they may finish synchronising with the master blockchain on the distributed blockchain network (e.g. peer to peer blockchain) to get the last several blocks or two. The trusted/verified IDS controlled node is restarted and continues to keep a synchronised and verified copy of the master blockchain.

[00236] In step 316, the current number of IDS controlled nodes 114a-114r is compared with the estimated numberof IDS controlled nodes. If there are more IDS controlled nodes than estimated number of blockchain nodes (e.g. Ύ'), then the process 300 proceeds to step 318. Otherwise, the process 300 proceeds to step 302 as there is an equal number of IDS controlled nodes and the estimated number of IDS controlled nodes. The number of IDS controlled nodes that should be removed may be the difference, U, between the current number of IDS controlled nodes 114a-114r and the estimated number of IDS controlled nodes. That is, the difference U is the number of IDS controlled nodes that may need to be removed to meet the transaction load and the like or the operators estimate of the required number of IDS controlled nodes and the like.

[00237] In step 318, a number of 'Ll' IDS controlled nodes are removed or deallocated. The process 300 proceeds to step 302.

[00238] Figure 3b is a flow diagram illustrating another example IDS controlled node spawning process for use with the IDS according to the invention. Common reference numerals from figures 1a-2c may be used to indicate similar or the same features. The IDS controlled node management process 300 of figure 3a may be modified to reduce the computational complexity of estimating the required number of IDS controlled nodes by monitoring a transactional queue size and when it reaches a factor of a predetermined threshold X, say, an additional X nodes may be spawned. The value X may be controlled by the operator of the IDS 102 and may be a function of, by way of example only but not limited to, the number of transactions that a worker unit may concurrently process, the number of transactions that may concurrently be required to be processed by worker units 112a-112w, the number of transactions that an IDS controlled node may handle, the transaction load and/or the transaction rate or transactions per second, or transactions per minute. Alternatively or additionally, the value X may be controlled by the operator of the IDS 102 and based on, by way of example only but not limited to, step 302 of process 300. The IDS 102 may include the functionality of process 320 to enable IDS controlled nodes to be efficiently spawned. Process 320 may include the steps based on the following:

[00239] In step 322, the IDS 102 may include functionality for maintaining the IDS controlled nodes and also the trusted IDS controlled node such that they are synchronised with the master blockchain. The IDS may include functionality to monitor the size of one or more of the transaction queue(s) 110a-110q.

[00240] In step 324, when the size of the one or more transaction queue(s) 110a-110q reaches n-X, where 1<=n and n is an integer, the process 320 proceeds to step 326. Otherwise the process 320 proceeds back to step 322 for maintaining the IDS controlled nodes. X may be a step size that is set by the operator of the IDS 104 and/or may be a function of the transaction load, or transaction rate and the like. X may also be estimated as described in step 302 or process 300 and set by the operator of the IDS 104.

[00241] In step 326, the trusted IDS controlled node (or server) with the trusted copy of the master blockchain may be stopped to allow any newly spawned IDS controlled nodes to be synchronised quickly.

[00242] In step 328, X new IDS controlled nodes are allocated and spawned by the IDS 102. These X new IDS controlled nodes now require a full copy of the master blockchain.

[00243] In step 330, each of the X new IDS controlled nodes are started. In step 332, each of the X new IDS controlled nodes are synchronised with the master blockchain. This may involve downloading the trusted copy of the master blockchain from the trusted IDS controlled node. Although the trusted IDS controlled node as been offline, and may now be out-of-sync with the master blockchain, downloading the trusted copy of the master blockchain and then syncing the last few blocks directly with the master blockchain is faster using the internal network of the IDS 102 than using downloading the master blockchain from the distributed blockchain network 104 on an external network. Thus each of the X new IDS controlled nodes are synchronised with the master blockchain. In step 314, the trusted blockchain node (or server) is started and it may directly synchronise with the last several blocks of the master blockchain to ensure the trusted copy of the master blockchain is synchronised.

[00244] When a new batch of IDS controlled nodes (or servers) 114a-114r are generated/allocated, they can be synchronised with the master blockchain faster by stopping the trusted/verified IDS controlled node, then copying the raw block data to the new IDS controlled nodes. This may be achieved over an internal gigabit network using a differential copying and/or synchronising algorithm such as, by way of example only but not limited to, RDIFF. This allows the new IDS controlled nodes to have a full copy of the master blockchain in a fraction of the time it would take to download a P2P copy from the master blockchain via the distributed blockchain network 104. As soon as the copies are downloaded to each new IDS controlled node, the IDS controlled nodes may be started, and they may finish synchronising with the master blockchain on the distributed blockchain network (e.g. peer to peer blockchain) to get the last several blocks or two. The trusted/verified IDS controlled node is restarted and continues to keep a synchronised and verified copy of the master blockchain.

[00245] Figure 3c is a flow diagram illustrating an example worker unit management process 340 for supporting transaction queue processing for use with the IDS 102 according to the invention. Common reference numerals from figures 1a-2c may be used to indicate similar or the same features. The worker unit management process 340 may be used to control the efficient management, allocation and/or deallocation of worker units.

[00246] Each worker unit 112a-112w performs verification and preparation processing on a number of K transactions, where K is the number of transactions a worker unit 112a may have the processing capacity to handle at the same time. Once the transaction has been verified and prepared, it is then transferred to an IDS controlled node 114a for blockchain processing and submission for addition to the master blockchain. For example, in the cryptocurrency hybrid blockchain transaction system 170 each worker unit 112a-112w may be a wallet worker unit. A wallet worker unit 112a may retrieve a number of K cryptocurrency transactions from a transaction queue 110a. For each transaction, the wallet worker unit 112a may open the cryptocurrency wallet associated with each transaction and verify the transaction can be made (i.e. are there are enough cryptocurrency units in the wallet). This verification requires performing mathematical algorithms to check the entire blockchain to determine those transactions associated with the cryptocurrency wallet. Wallet worker nodes then send the verified transactions that can be made to an IDS controlled node 114a.

[00247] The worker units 112a-112w operate to process the transactions that are placed in transaction queues 110a-110q, thus the processing capacity of these worker units needs to be judiciously managed to ensure it matches the transaction load and/or blockchain load of system 100. The process 340 may be performed by the resource module 124 and/or by parts of the resource module 124 and/or transaction module 120. The IDS 102 includes the functionality of process 340 to enable worker units 112a-112w to be efficiently spawned. Process 340 may include the steps based on the following:

[00248] In step 342, the IDS 102 may include functionality for estimating the required number of worker units based on, by way of example only but not limited to, the number of transactions in the queue, number of transactions each worker unit may concurrently operate on, the average processing capacity of the worker units, a target transaction time, transaction load, blockchain load, incoming transactions and/or outgoing transactions to the master blockchain and the like. Monitoring of the transaction load and/or blockchain load may be used to generate the estimate.

[00249] For example, an estimated required number of worker units may be calculated based on the following. If there are Y (e.g. 10000) transactions in a queue, and each worker unit 112a-112w can open K (e.g. 5) transactions concurrently, then the system may require fY/K] (e.g. 2000) worker units to completely process the queue divided by the required target transaction time t (e.g. 10 minutes), which may be set by the operator. The ceiling operator [ ] is used to round up to the nearest integer to ensure there are a sufficient number of worker units and/or IDS controlled nodes; rounding down may mean that there would be a deficit in processing capacity. Thus, dividing |Y/F] (e.g. 2000 worker units) by a required target transaction time fas set by the operator (e.g. 10 minutes) gives = 200 worker units required. However, this then means that there needs to be an adequate number of IDS controlled nodes to handle the worker unit processed transactions that will be shortly received; this is described in process 300 in step 302 with respect to figure 3a.

[00250] It is noted that the target transaction time or target time may be set by the operator and may be determined as a compromise between cost and processing capacity. For example, setting the target time to 10 minutes and using means that it will take i times as long for worker units to process the /transactions in the queue as opposed to processing the entire queue in a minute (e.g. t=1 minute). The target time t may be set by the operator because, in this example, the operator has accepted that the entire time t² minutes (e.g. 100 minutes when t=10 minutes) taken for processing all /transactions in the queue is an acceptable time. The operator would also look towards balancing the cost of operating the worker units (and also the IDS controlled nodes) with the time t² taken to process all the /transactions. For example, if the cost of processing all /transactions per minute is C, then the cost of processing all /transactions in t² minutes is C/t². Adjusting t allows the operator to reach an acceptable transaction time for processing /transactions whilst also taking into account the cost C/t² of processing the /transactions. Typically the worker units and IDS controlled nodes are spawned on demand, but an operator may pay for a whole hour of processing time, so generally an operator would not wish to spawn enough worker units and IDS controlled nodes to remove the entire queue instantly at great cost. There is a balance that the operator needs to meet between cost and transaction time.

[00251] In another example, for a cryptocurrency hybrid blockchain transaction system 170 in which the transactions are cryptocurrency transactions each worker unit 112a-112w may be a wallet worker unit. A wallet worker unit 112a may retrieve a number of K cryptocurrency transactions from a transaction queue 110a. For each transaction, the wallet worker unit 112a may open the cryptocurrency wallet associated with each transaction and verify the transaction can be made (i.e. are there are enough cryptocurrency units in the wallet). This verification requires performing mathematical algorithms to check the entire blockchain to determine those transactions associated with the cryptocurrency wallet. Wallet worker units then send the verified transactions that can be made to an IDS controlled node 114a.

[00252] As described above, the number of wallet worker units required to process a queue of /transactions is the number of queued transactions /divided by the number of cryptocurrency wallets a wallet worker unit can concurrently open K divided by the required target transaction time t. As described above, the estimated required number of wallet worker units may be, by way of example only but not limited to, \Y/K}/t worker units. Based on the number of worker units, the number of IDS controlled nodes may be estimated as the required number of IDS controlled nodes to match the wallet worker units.

[00253] For example, if there are Y=10000 transactions in the queue and each wallet worker unit can open K=5 concurrent cryptocurrency wallets then, {Y/K] =2000 wallet workers would be needed to process the transaction queue within 1 minute. It is noted that the transactions will be made up of instant transactions which are less time dependent items and conventional transactions. The average time for a wallet worker unit to complete a transaction may be estimated and kept in a database and updated constantly. This may allow an operator to determine an appropriate target transaction time for completing a number of transactions. Should the operator set the target time t, by dividing the [Y/K] = 2000 wallet worker units by the target time t = 10 minutes as set by the operator, then the number of wallet worker units that are estimated to be required is [fY/K]/t] = 200.

[00254] There is may be a different target time for instant cryptocurrency payments/transactions because these can be slower and can have less concurrent wallet worker units than conventional transactions which have to happen as fast as possible. As an example, the operator may estimate that t = 40 minutes is acceptable for processing the same number of Y = 10000 instant transactions without affecting the user or vendor, which means only [fY/Kf/t] = 50 wallet worker units may be estimated to be required.

[00255] In step 344, the current number of worker units 112a-112w is compared with the estimated number of worker units. If there are more worker units than the estimated number of worker units (e.g. 'N'), then the process 340 proceeds to step 350. If there are less worker units than the estimated number of worker units (e.g. Ύ'), then the process 340 proceeds to step 346. The number of worker units that should be spawned may be the difference, X, between the estimated number of worker units and the current number of worker units 112a112w. That is, the difference Xis the number of worker units that may need to be spawned to meet the transaction load and the like or the operators estimate of the required number of worker units and the like.

[00256] In step 346, X new worker units are allocated and spawned by the IDS 102.

[00257] In step 348, the X new worker units may then be assigned to service or process one or more transaction queues 110a-110q.

[00258] In step 350, the current number of worker units 112a-112w is compared with the estimated number of worker units. If there are more worker units than the estimated number of worker units (e.g. Ύ'), then the process 340 proceeds to step 352. Otherwise the process 340 proceeds to step 342 as there are an equal number of current worker units to estimated worker units. The number of worker units that should be removed may be the difference, Z, between the current number of worker units 112a-112w and the estimated number of worker units. That is, the difference Z is the number of worker units that may need to be removed to meet the transaction load and the like, or the operators estimate of the required number of worker units and the like.

[00259] In step 352, a number of 'Z' worker units are removed or deallocated. The process 340 proceeds to step 342.

[00260] Figure 3d is a flow diagram illustrating an example reconciliation process 350 for outof-sync IDS controlled nodes for use by the IDS 102 according to the invention. Common reference numerals from figures 1a-2c may be used to indicate similar or the same features. Management of IDS controlled nodes is essential to the efficient operation of the IDS 102. Overtime, most blockchain nodes can crash or glitch in which their blockchain gets out of synchronisation to the master blockchain of the distributed blockchain network 104. The danger is that if a confirmed transaction is received from a blockchain node that is out of synchronisation (out-of-sync) with the master blockchain, then the confirmation from the outof-sync blockchain node will indicate ‘Success’, but when the blockchain processed transaction or blocks from the out-of-sync blockchain node are submitted to the master blockchain, they will be rejected and ultimately fail to be incorporated into the master blockchain. The reconciliation process 350 alleviates this issue to minimise the impact any out-of-sync IDS controlled node may have on the efficient operation of the IDS 102. The IDS 102 may include the functionality for reconciling any out-of-sync IDS controlled nodes 114a114r based on the reconciliation process 350. As another example, the functionality of the reconciliation process 350 may be implemented at least in part by the synchronisation module 126. The reconciliation process 350 may include one or more steps based on the following:

[00261] In step 352, each of the IDS controlled nodes 114a-114r reports on the status of their blockchain. Each report from an IDS controlled node may include status data representing the block height of the blockchain of that IDS controlled node. In one example, because there are lots of IDS controlled nodes running, then all IDS controlled nodes may report back to a database such as a trusted database 109.

[00262] In step 354, the block height of each IDS controlled node is compared with the block height of the master blockchain maintained by the distributed blockchain network 104. If the block height of an IDS controlled node is different to the block height of the master blockchain, then the process 350 proceeds to step 356. This means that the IDS controlled node is out-of-sync with the master blockchain and so some of the blockchain processed transactions for the out-of-sync blocks will most likely be incorrect. Thus, if the block height of an IDS controlled node is different to consensus then the IDS controlled node should be restarted and resynchronised to the master blockchain before it misrepresents a transaction. Effectively, an IDS controlled node can only be one block out of synchronisation before it is noticed that it is out-of-sync with the master blockchain. The out-of-sync IDS controlled node may then report back to the IDS 102.

[00263] In step 356, the transactions of one or more blocks of the out-of-sync IDS controlled node are retrieved and placed into a verification transaction queue (not shown) for reprocessing, e.g. blockchain processing using a blockchain that is synchronised to the master block chain. For example, if a transaction has taken place within the last ‘P seconds on an out-of-sync IDS controlled node, then it can be added to a specialist ‘verify queue’ and re-processed where possible or as required.

[00264] In step 358, the IDS controlled node may be restarted and re-synchronised to the master blockchain. Alternatively, one or more of steps 306, 310, 312 and/or 314 of process 300 or one or more of steps 326, 330, 332 and 334 of process 320 may be performed in relation to the out-of-sync IDS controlled node in which it synchronises with the trusted copy of the master blockchain and subsequently synchronises any remaining blocks directly with the master blockchain.

Figure 4a is a schematic and flow diagram illustrating an example automatic subscription setup process 400 for performing PULL subscription transactions in the IDS 102 of cryptocurrency hybrid blockchain transaction system 170 of figure 1e according to the invention. Common reference numerals from figures 1a-2d may be used to indicate similar or the same features. Typical cryptocurrency blockchain systems are PUSH systems where users are required to PUSH cryptocurrency payments to other cryptocurrency wallets. The cryptocurrency hybrid blockchain system 170 includes functionality or process(es) 400, 430 and 450 that allows a user 106n to subscribe to a vendor's 108a product(s) and/or service(s); authorise the vendor 108a and/or, by way of example only but not limited to, functionality within the IDS 102 such as, by way of example only but not limited to, vendor payment system 128 or processing cloud API 260 within the IDS 102 (e.g. see figure 2c) to automatically take any future amount or an agreed subscription cryptocurrency amount from the cryptocurrency wallet of the user 106n each subscription period (e.g. monthly / quarterly / yearly etc.) whilst the user 106n may retain control over the subscription and may cancel such subscriptions at the appropriate time.

[00265] Referring to figures 1e, 2c and 4a, the cryptocurrency hybrid blockchain system 170 includes IDS 102 that receives and processes transactions from a plurality of users and/or vendors, which in this example, are user 106n and vendor 108a. The IDS 102 also includes vendor payment module or system 128 and/or processing cloud application programming interface (API) 260 both of which may act as an interface in relation to user/vendor transactions, subscriptions, requests, notifications and the like.

[00266] PULL transactions allow a user 106n to authorise a vendor 108a or even the functionality of the IDS 102 (e.g. vendor payment system 128 or processing cloud API 260) to automatically take or PULL any current and/or future cryptocurrency amount or an agreed subscription amount from the user's cryptocurrency wallet in each subscription period (e.g. monthly, quarterly, annually, etc.). Once authorised by a user 106n (which occurs when the user 106n subscribes or accepts a subscription to a product/service provided by the vendor 108a on a subscription basis), PULL transactions may be submitted by the vendor 108a and/or vendor payment system 128/processing cloud API 260 automatically (or even manually) to pull a crypto currency payment or other equivalent payment from the cryptocurrency wallet of user 106n via the vendor payment system 128 to the cryptocurrency wallet of the vendor 108a. This example focuses on PULL subscription transactions in which the user 106n subscribes to a product/service from the vendor 108a and authorises the vendor 108a and/or vendor payment system 128/API 260 to pull or take a cryptocurrency payment amount associated with the subscription from the cryptocurrency wallet of user 106n in each subscription period and transfer it to the crypto currency wallet of the vendor 108a.

[00267] The PULL transaction associated with the subscription may be processed based on, by way of example only but not limited to, one or more of steps 270-278 of instant transaction payment process 250 as described with reference to figure 2c in relation to PULL transactions, or one or more of steps 284-291 of process 280 with reference to figure 2d in relation to PULL transactions. Instant transactions in the cryptocurrency hybrid blockchain transaction system 170 allow the IDS 102 to instantly confirm that a user 106n has the required cryptocurrency balance in their cryptocurrency wallet 1721. This is because the IDS 102 may act as a trusted third party and have access to each of the users 106a-106n private cryptocurrency keys and/or each vendors 108a-108m private cryptocurrency keys allowing the IDS 102 to access, as a trusted third party, which may be stored along with their cryptocurrency walletsl 72a-172I in the secure trusted database or server 109. PULL transactions may be of the instant type.

[00268] As the IDS 102 has access to user private cryptocurrency keys fortheir cryptocurrency wallet, this means that the IDS 102 may determine what transactions a user 106n has made, what balance the user 106n should have (without requiring wallet synchronisation), verify whether the user 106n has enough cryptocurrency in their cryptocurrency wallet to make the cryptocurrency payment, and can confirm the transaction cryptocurrency payment amount to a vendor 108a in advance of blockchain processing and submission to the distributed blockchain network for adding to the master blockchain in relation to the transactions. The cryptocurrency payment amount could even be transferred to the vendor cryptocurrency wallet prior to blockchain processing of a PULL transaction associated with a subscription linked to the user 106n. The IDS 102 also ring fences the cryptocurrency subscription payment amount in the user's cryptocurrency wallet to prevent the user 106n from double-spending this amount in subsequent or future transactions.

[00269] A user 106n may subscribe to a vendor's product or service and be required to make periodic payments to the vendor 108a as part of the subscription agreement to continue to receive or access the product and/or service. The IDS 102 includes functionality such as, by way of example only but not limited to, vendor payment system 128 or cloud API 260 that can be configured to act as a third party, set-up the subscription and be authorised by the user 106n to automatically make PULL transactions to pull a periodic subscription cryptocurrency payment from the cryptocurrency wallet of the user 106n at the appropriate time according to the subscription agreement and transfer the periodic subscription cryptocurrency payment to the cryptocurrency wallet of the vendor 108a. This type of PULL transaction may be made in a similar fashion as an instant type of transaction based on, by way of example only but not limited to, one or more of steps 270-278 of instant transaction payment process 250 as described with reference to figure 2c in relation to PULL transactions, or one or more of steps 284-291 of process 280 with reference to figure 2d in relation to PULL transactions. During set up of the automatic subscription, a unique token identifying the user 106n may be generated for the first subscription cryptocurrency payment, this unique token is stored along with the subscription rules/details in a database 109 and linked with the user 106n or the cryptocurrency wallet of the user 106n. This information may be used by the IDS 102 or IDS blockchain functionality to make periodic subscription cryptocurrency payments from the cryptocurrency wallet of the user 106n as a transfer to the cryptocurrency wallet of the vendor 108a. The subscription may be a periodic subscription in which the user 106n The subscription set-up process 400 for performing PULL subscription transactions may include the following steps of:

[00270] The user 106n may use a vendor interface 262, which may allow EPOS, web online shopping (e.g. WEB), or the user 106n may use an interface linked to the IDS 102 via vendor payment system 128 or processing cloud API 260 that may allow the user 106a to subscribe to a product or service of the vendor 108a. In step 402, the user 106n may wish to pay for and/or subscribe to have access to an ecommerce enabled website (e.g. WEB) associated with the vendor 108a using a cryptocurrency payment/transaction. The ecommerce enabled website may be a digital product provided by a vendor 108a in which a user 106n may obtain access via single payment or subscribe to have ongoing access by making multiple future or periodic payments (e.g. weekly, monthly, quarterly and/or yearly). The user 106n may select a cryptocurrency payment option from the checkout and may be presented with an interface and login to the vendor payment system 128 of the IDS 102 (of cryptocurrency hybrid blockchain system 170).

[00271] In step 404, the user 106n selects a subscription format from various available options that include, by way of example but not limited to, regular Fiat payment amount(s) 404a (cryptocurrency to the market value of a fixed fiat currency amount at the time of the subscription payment, for example if the value of the underlying cryptocurrency changes against the US Dollar the regular subscription amount would fluctuate but the transaction value in US Dollars would remain the same each period), regular cryptocurrency payment amount(s) 404b, one off Fiat payment amount 404c (cryptocurrency to the market value of a fixed fiat currency amount at the time of the payment), one off cryptocurrency payment amount 404d, Direct Debit style full access Fiat 404e (cryptocurrency to the market value of a fixed fiat currency amount at the time of the transaction payment), Direct Debit style full access crypto 404f.

[00272] On the first payment of a subscription the user 106n may be presented with the option to approve future subscription payments every X periods. A period X may be, by way of example only but not limited to, a daily period, weekly period, monthly period, yearly period. Alternatively, the period X may be a monthly period falling on the same day of the month each month, or a yearly period falling on the same day in the same month each year. Alternatively or additionally, rather than X periods, the subscription may be based on a regular payment schedule agreed to by the user 106n and/or vendor 108a. Although regular payment periods X may be described in terms of days, weeks, months, years, bi-annually and the like, it is to be appreciated by the skilled person that the invention using subscription payment periods may modified to be based, by way of example only but not limited to, another fixed period, a set number of multiple payments and/or modified based on, by way of example only but not limited to, irregular payment periods or even irregular payments that are not known in advance, a payment schedule or multiple payments that may be aperiodic or irregular or some other type of payment schedule or structure.

[00273] For example, a subscription that may have irregular payments that are not known in advance may be products or service such as, by way of example only but not limited to, a user 106n subscribing to a shared car scheme of a vendor 108a. Although some of the fees may be periodic, e.g. a minimum monthly payment, other fees may be irregular depending on when the user 106a uses the car. These fees may include the hire fee depending on how long the car is hired for, which may be paid prior to the car being used, and mileage fees which may be paid after the care has been used. Thus, this type of subscription may have multiple periodic and irregular payments, in which the irregular payments are not known in advance until the car is booked and after usage, at which times vendor 108a may automatically generate a PULL transaction in relation to each of these fee payments. Thus, subscriptions may have different payment periods, some of which are known in advance, and some of which are unknown until the user 106n takes some sort of action in relation to the subscription, product and/or service in relation to the subscription.

[00274] The subscription payment amount would be made in cryptocurrency units(e.g. Electroneum (ETN)) from the cryptocurrency wallet of the user 106n, so depending on what subscription format the user 106n chooses, a conversion to the cryptocurrency units (e.g. ETN) of the user cryptocurrency wallet may be necessary. For example, if the user selected the subscription format to be regular cryptocurrency payment amount(s) to the value of YY ETN per period X (e.g. 50 ETN per week, 2000 ETN per month and the like), then this subscription amount will be transferred from their cryptocurrency wallet every period X. However, if the user selected a regular Fiat payment(s) of ZZ Fiat currency per period X, then in each period X the ZZ Fiat currency will be automatically converted into the equivalent ETN amount at the spot price at the time that future subscription payment is made (e.g. £12 GBP worth of ETN per month; $140 USD worth of ETN per year and the like). Although it seems that the cryptocurrency subscription payment is described, by way of example only but is not limited to, as a constant periodic value (e.g. YY cryptocurrency per month), it is to be appreciated by the skilled person that the cryptocurrency subscription payment may vary or be different on each subscription payment period/cycle.

[00275] In step 406, the user 106n confirms their subscription options and agrees to the terms and conditions. If the user 106n selects option 416 (Yes) then the process 400 proceeds to step 408. If the user 106n selects option 418 (No) then the process 400 indicates option 420 (Cancel Transaction), which on selection terminates the subscription set up and cancels the transaction.

[00276] In step 408, based on vendor settings and the options available, the user 106n may select option 422 (Fiat Transaction) to be charged in a fiat currency amount converted at spot rate 424 to a cryptocurrency amount e.g. $15 USD (150 ETN), where ETN is a cryptocurrency amount. Alternatively the user 106n may select option 426 (Crypto Transaction) to be charged in cryptocurrency amount e.g. 200 ETN. The process 400 proceeds to step 410, in which the first cryptocurrency payment in relation to the subscription is made based on PULL transactions of the instantaneous type.

[00277] In step 410, the vendor payment system 128 creates a PULL transaction based on the options selected and the PULL transaction may be processed based on, by way of example only but not limited to, one or more of steps 270-278 of instant transaction payment process 250 as described with reference to figure 2c in relation to PULL transactions, or one or more of steps 284-291 of process 280 with reference to figure 2d in relation to PULL transactions. The vendor payment system 128 may set up a unique token or unique vendor token associated with the user 106n in relation to the subscription on the first payment. The unique vendor token can be used to identify the user 106n on the vendors system. The first payment to the vendor 108a from the user 106n returns an almost instant YES or NO confirmation for the subscription of the user 106n to the vendor 108a, allowing the checkout process to complete with a SUCCESS or FAILURE message to both the vendor 108a and user106n.

[00278] For example, the vendor payment system 128 automatically generates the PULL transaction in relation to the first cryptocurrency payment to pull the cryptocurrency payment amount in relation to the subscription from the cryptocurrency wallet of the user 106n. Given this is an instantaneous transaction, the cryptocurrency wallet of the user 106n is checked to determine whether the user 106n has sufficient cryptocurrency funds/balance in their cryptocurrency wallet. If there are sufficient cryptocurrency funds/balance, then the cryptocurrency payment amount in relation to the subscription is ring-fenced in the cryptocurrency wallet of the user 106n. This means user 106n cannot double spend.

[00279] The user 106n and vendor 108a are notified of the success of the instant transaction along with details of the transaction in an instantaneous fashion. The vendor 108a may be notified of the unique token in relation to the subscription for identifying the user 106n on the vendors system; and which may be used to identify the user on subsequent periodic payments in relation to the subscription. The vendor 108a may also be notified that the first cryptocurrency payment amount in relation to the subscription is on its way; in response, the vendor 108a may release the product and/or service, or provide the user 106n with access to the product or service. Thus, the check-out process for the user 106n occurs practically instantly. Alternatively or additionally, the first cryptocurrency payment amount may be transferred from the crypto currency wallet of the user 106n to the cryptocurrency wallet of the vendor 108a. Effectively, the user 106n and vendor 108a have been notified immediately that the transaction has been made, e.g. instantly. In the meantime, the PULL transaction is then submitted to the instantaneous transaction queue, and at a time that is advantageous to the IDS 102 in relation to blockchain load, a worker unit may retrieve the PULL transaction, and verify and prepare the transaction for submission to the IDS controlled nodes, which will blockchain process the processed transaction and submit it to be added and recorded on the master blockchain.

[00280] In step 412, the vendor payment system 128 stores the subscription rules, subscription details (e.g. payment periods and formats) and the generated unique vendor token, which are linked to the user 106a, in database 109 (or trusted database/server). The unique token or unique vendor token can be used to identify the user 106n on the vendor's payment system or within the vendor's cryptocurrency wallet and the like. This may be used by the vendor 108a to identify each of the cryptocurrency payments from user 106n in relation to the subscription. Furthermore, the vendor 108a may use the unique vendor token (or unique token) associated with the user 106n by including it in PULL transactions in relation to a subscription stored in database 109. The PULL transaction may be automatically submitted by the vendor system to the vendor payment system 128 and recognised as an instantaneous transaction for pulling a cryptocurrency amount in relation to the subscription from the cryptocurrency wallet of the user 106n for transfer to the cryptocurrency wallet of the vendor 108a. The subscription rules and details ensure that cryptocurrency payments are automatically made from the cryptocurrency wallet of the user 106n for transfer to the cryptocurrency wallet of the vendor 108a at the appropriate times. The subscription rules and details also allow the vendor payment system 128 to monitor PULL transactions in relation to the subscription that may be automatically generated by the vendor system of the vendor 108a, to prevent double-charging the user 106n for the subscribed products and/or services and the like.

[00281] For example, if the first cryptocurrency payment in relation to the subscription is successful, a unique vendor token in relation to the user subscription may be issued to the vendor 108a via the vendor payment system 128. The subscription rules, subscription details, and vendor token in relation to the subscription are linked to the user 106n and stored in the trusted secure database 109. This may be stored or linked to the cryptocurrency wallet of the user 106n, or against this user 106n in the database 109. Once set up, the vendor 108a may automatically make PULL transactions from the user cryptocurrency wallet using an instant transaction process based on, by way of example only but not limited to, one or more of steps 270-278 of instant transaction payment process 250 as described with reference to figure 2c in relation to PULL transactions, or one or more of steps 284-291 of process 280 with reference to figure 2d in relation to PULL transactions; and/or as described herein.

[00282] The first payment to the vendor 108a from the user 106n returns an almost instant YES or NO confirmation for the subscription of the user 106n to the vendor 108a, allowing the checkout process to complete with a SUCCESS or FAILURE message to both the vendor 108a and user 106n.

[00283] As described with respect to figure 2c, the user 106n may subscribe to receiving a subscription product/service from a vendor 108a; the user 106n may authorise the set up of an automated payment subscription with the vendor 108a in relation to a subscription product/service and the like; or the user 106n may authorise the set up an automated payment subscription with a trusted third party such as, by way of example only but not limited to, the vendor payment system 128 in relation to a subscription product/service of the vendor 108a and the like, where the vendor payment system 128 automatically oversees the periodic subscription payments from user 106n to the vendor 108a. The vendor payment system 128 may facilitate the agreement between user 106n and vendor 108a of the subscription rules and corresponding subscription details (e.g. subscription payment period(s) and also payment amount).

[00284] The cloud based processing API system of the IDS 102 may be configured to check the available cryptocurrency balance (or funds) of user 106n in the required cryptocurrency wallet. If there are sufficient cryptocurrency funds, the transaction is confirmed to the vendor 108a. The cryptocurrency funds are ring fenced by the IDS 102 as described in relation to figure 2c or 2d. This prevents double spend and the payment details are sent to the transaction cloud.

[00285] Figure 4b is a schematic and flow diagram illustrating an example subscription-retry process 430 for performing further PULL subscription transactions in the IDS 102 of cryptocurrency hybrid blockchain transaction system 170 of figure 1e according to the invention. Common reference numerals from figures 1a-2d may be used to indicate similar or the same features. Figure 4a described the setting up of a subscription linked to the user 106n via the vendor payment system 128, in which the subscription rules, details and a unique token associated with the user are linked to the user and stored in database 109 of IDS 102. This allows the vendor payment system 128 to police the subscription linked to the user 106n such that PULL subscription transactions submitted by a vendor 108a to automatically pull a cryptocurrency payment amount from the cryptocurrency wallet of the user 106n are fully scrutinised, verified and approved. Furthermore, storing the subscription rules, details and a unique token associated with the user are linked to the user and stored in database 109 centrally allows the vendor payment system 128 to automatically make the PULL transactions of the instantaneous type at the appropriate time in accordance with the subscription rules and details linked with the user 106n without requiring input from the vendor 108a or the user 106n.

[00286] Thus, on subsequent subscription periods (e.g. weekly I monthly I quarterly I yearly etc.) the vendor payment system 128 or other functionality in the IDS 102 may attempt to automatically re-process the user's subscription following the vendor’s settings and the user’s agreement. An instant SUCCESS or FAILURE confirmation would be passed back to the vendor 108a along with the vendor token (unique to this subscription) via API / Webhooks regarding the processing of the subscription and the allocation of cryptocurrency funds. Assuming the cryptocurrency payment amount/funds in relation to the subscription would be allocated/ring fenced, the transaction would be passed to the transaction cloud/queue for cryptocurrency payment fulfilment via the blockchain. The vendor 108a and user 106n may be informed by email (or other means, e.g. text via small message service (SMS) or some other mobile app etc.) of the success or failure of the subscription cryptocurrency payment in an efficient manner; whilst the PULL transaction is queued, processed and/or submitted for addition to the master blockchain.

[00287] The subscription-retry process 430 may include the following steps of: In step 432, the vendor payment system 128 automatically retrieves the details of the subscription linked to the user 106n, the subscription rules, details, and unique vendor token linked to the user 106n are stored in database 109. The vendor payment system 128 may periodically check or poll the subscriptions linked to user 106n and/or the other users of the system 100, or may have a separate payment schedule of subscriptions linked to each user to enable the vendor payment system 128 to identify when a subscription payment in relation to a user may be due. In any event, the vendor payment system 128 attempts to re-process the user's subscription. The vendor payment system 128 may class the subscription invalid 444 if there is an invalid subscription in place because, byway of example only but not limited to, the cryptocurrency payment amount in relation to the subscription may not be due yet, or the subscription has expired, or there is a lack of cryptocurrency funds in the cryptocurrency wallet of the user. Alternatively, if there is a valid subscription in place, i.e. the subscription is classed as valid 440, and the vendor payment system 128 sees that the cryptocurrency payment amount in relation to the subscription is due and pays the vendor's cryptocurrency wallet or account the correct cryptocurrency payment amount in relation to the subscription from the cryptocurrency wallet or account of the user 106n. An instant success 442 may be generated.

[00288] In step 434, based on the instant payment success 442 an instant SUCCESS confirmation may be passed to vendor 108a via API / Webhook including the unique token (e.g. unique vendor token) for identifying the user's subscription payment on the vendor system. Alternatively or instead, based on the invalid subscription 442, an instant FAILURE confirmation may be passed to vendor 108a via API I Webhook including their unique subscription token.

[00289] In step 436, the vendor 108a and user 106n are notified of the success or failure based on whether an instant success 442 is generated in relation to re-processing the subscription. The notification to the user 106n and vendor 108a will be an instant payment notification and acts just like an instant payment. That is, an API call goes to the vendors system letting the vendor 108a know that the cryptocurrency payment amount (e.g. XX ETN) in relation to the subscription of user 106n (identified by the unique token (e.g. unique vendor token)) has been allocated for the vendor 108a from the user 106n (identified by the unique token). The notification may further include details of the subscription and any exchange information if cryptocurrency (e.g. ETN) conversion from a fiat value has been calculated (e.g. $14 USD of ETN). The notification to the user 106n and vendor 108a may be, by way of example only but is not limited to, in the form of an email or text/SMS message that may be sent to user 106n and/or vendor 108a informing them of the successful subscription cryptocurrency payment. The notification to the user 106n and vendor 108a is an instant payment notification that acts, from the point of view of the user 106n and vendor 108a, just like an instant payment. The vendor 108a uses this instant payment notification to allow the user 106n to continue their subscription and have access to the product and/or service and the like.

[00290] In step 438, the vendor payment system 128 or other functionality of the IDS 102 creates, by way of example only but is not limited to, a PULL transaction of the instant type. The subscription cryptocurrency payment amount is ring-fenced in the cryptocurrency wallet of the user 106n (e.g. users account), which is to prevent double-spend by the user, and then the transaction is passed to the instantaneous queue and/or transaction queue (depending on blockchain load) to ensure the blockchain record takes place. That is, the transaction is retrieved from the instant transaction queue by a worker unit and then blockchain processed by an IDS controlled node, which submits the blockchain processed transaction to the distributed blockchain network for addition to the master blockchain. Once it is confirmed that the PULL transaction has been recorded onto the master blockchain, the cryptocurrency payment amount in relation to the subscription is transferred from the cryptocurrency wallet of the user 106n and placed into cryptocurrency wallet of the vendor 108a. Thus, the subscription funds are transferred or allocated to the cryptocurrency wallet of the vendor 108a. The PULL transaction is based on the instantaneous transaction process based on, by way of example only but not limited to, one or more of steps 270-278 of instant transaction payment process 250 as described with reference to figure 2c in relation to PULL transactions, or one or more of steps 284-291 of process 280 with reference to figure 2d in relation to PULL transactions, where the PULL transaction is instead passed by the vendor payment system 128 (rather than the vendor 108a) to the transaction cloud/queue for cryptocurrency payment fulfilment and blockchain processing onto the master blockchain.

[00291] Figure 4c is a schematic and flow diagram illustrating an example subscriptiontermination process 450 in relation to cancelling PULL subscription transactions in the IDS of cryptocurrency hybrid blockchain transaction system 170 of figure 1e according to the invention. Common reference numerals from figures 1a-2d may be used to indicate similar or the same features. Figure 4a described the setting up of a PULL subscription transaction that a vendor 108a may use to pull a cryptocurrency payment amount from the cryptocurrency wallet of the user 106n. Figure 4b described subscription retries/reprocessing in which the vendor payment system 128 automatically, according to the rules and/or details of the subscription, created a PULL subscription transaction to pull a cryptocurrency payment amount in relation to a subscription linked to the user 106n from the cryptocurrency wallet of the user 106n and transfers it to that of the vendor 108a. The user 106n, who is a subscriber, can cancel the automatic subscription by cancelling the subscription permission(s) at any time from the vendor payment system 128.

[00292] The user 106n is able to control the permissions on any subscription linked to the user 106n via an interface 262 to, by way of example only but not limited to, the vendor payment system 128, or user/vendor interface module 130 or other functionality of the IDS 102, that shows the user 106n subscription information such as, by way of example only but not limited to, what subscriptions the user 106n has in place, when the subscriptions expire, due dates for subscription payments, etc. A user 106n would be able to cancel any future subscription payment via the interface to the vendor payment system 128. In this situation the user 106n and the vendor 108a would be notified by email/text/SMS and the like that the subscription has been cancelled, and an API call would be made to the vendor's system to let them know that no future payments will be coming from this user 106n.

[00293] The subscription-termination process 450 may be based on the following steps of: In step 452, the user 106n be using an interface 262 for accessing the vendor payment system

128 and may login to their account (e.g. login to their cryptocurrency wallet or other account) on the IDS 102. In step 454, the user 106n may view their subscription list and subscription information for each subscription on the list. They may select the subscriptions they would like to cancel/terminate. In step 456, the user 106n may select a subscription from the list and select the option to cancel 462 to cancel any further automated payments in relation to the selected subscription. On step 458, the vendor 108a and user 106n are notified that future automations/future automatic payments based on this subscription are cancelled or terminated. In step 460, an API endpoint call may be made to the vendor system or vendor services/subscription to let them know that no further payments will be coming from this user. The API endpoint call may include the unique vendor token linked to the subscription that the user 106n cancelled.

[00294] As an option, the vendor payment system 128 may also, for example after step 460, remove the unique vendor token and corresponding subscription details and rules associated with the cancelled subscription from the database 109 in relation to the cancelled/terminated subscription linked to the user 106n. This may prevent the vendor 108a from using the unique vendor token in an attempt to PULL further cryptocurrency payment amounts in relation to the cancelled subscription.

[00295] Figure 5 is a schematic diagram illustrating an example computing system 500 comprising a computing apparatus or device 502 according to the invention. The computing apparatus or device 502 may include one or more processor unit(s) 504 (e.g. each processor unit including one or more processors), a memory unit 506 and a communication interface 508. The processor unit(s) 504 may be connected to the memory unit 506 and the communication interface 508. The processor unit 504 and memory 506 may be configured to implement one or more steps of one or more of the method(s), computer-implemented method(s), and/or process(es) 140, 150, 220, 250, 280, 300, 320, 340, 350, 400, 430, and 450 as described with reference to figures 1a to 4c, modifications thereof, and/or as described herein. The processor unit 504 may include one or more processor(s), controller(s) or any suitable type of hardware(s) for implementing computer executable instructions to control apparatus 502 according to the invention. The computing apparatus 502 may be connected via communication interface 508 to a network 512 for communicating and/or operating with other computing apparatus/system(s) (not shown), IDS 102, distributed blockchain network 104 for implementing the invention accordingly.

[00296] The computing system 500 may be a server system, which may comprise a single server or network of servers configured to implement the invention as described herein. Thus, the server system may include one or more or a plurality of computing apparatus or devices that may be configured to implement one or more steps of one or more of the method(s), computer-implemented method(s), and/or process(es) 140, 150, 220, 250, 280, 300, 320, 340, 350, 400, 430, and 450 as described with reference to figures 1a to 4c, modifications thereof, and/or as described herein. In some examples the functionality of the server system may be provided by a network of servers distributed across a geographical area, such as a worldwide distributed network of servers, and a user may be connected to an appropriate one of the network of servers based upon a user location.

[00297] The above description discusses embodiments of the invention with reference to a single user for clarity. It will be understood that in practice the system may be shared by a plurality of users, and possibly by a very large number of users simultaneously.

[00298] The embodiments described above are fully automatic. In some examples a user or operator of the system may manually instruct some steps of the method(s), process(es), and/or computer-implemented method(s) to be carried out.

[00299] In the described embodiments of the invention the system may be implemented as any form of a computing and/or electronic device. Such a device may comprise one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in orderto gather and record routing information. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[00300] Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computerreadable media may include, for example, computer-readable storage media. Computerreadable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. A computer-readable storage media can be any available storage media that may be accessed by a computer. By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, flash memory or other memory devices, CD-ROM or other optical disc storage, magnetic disc storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and bluray disc (BD). Further, a propagated signal is not included within the scope of computerreadable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.

[00301] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs). Complex Programmable Logic Devices (CPLDs), etc.

[00302] Although illustrated as a single system, it is to be understood that the computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device.

[00303] Although illustrated as a local device it will be appreciated that the computing device may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[00304] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

[00305] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[00306] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.

[00307] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method steps or elements identified, but that such steps or elements do not comprise an exclusive list and a method or apparatus may contain additional steps or elements.

[00308] As used herein, the terms component and system are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computerexecutable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices.

[00309] Further, as used herein, the term exemplary is intended to mean serving as an illustration or example of something.

[00310] Further, to the extent that the term includes is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term comprising as comprising is interpreted when employed as a transitional word in a claim.

[00311] The figures illustrate exemplary methods. While the methods are shown and described as being a series of acts that are performed in a particular sequence, it is to be understood and appreciated that the methods are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a method described herein.

[00312] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and/or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and/or the like. Still further, results of acts of the methods can be stored in a computer-readable medium, displayed on a display device, and/or the like.

[00313] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of 5 any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[00314] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

1. A cryptocurrency blockchain transaction system comprising:

an interface database system, IDS, comprising:

a plurality of user and vendor cryptocurrency wallets;

one or more transaction queues for receiving cryptocurrency transactions between users and vendors;

a plurality of wallet worker units configured to retrieve cryptocurrency transactions from the one or more transaction queues, and verifying the cryptocurrency transactions in relation to the corresponding user cryptocurrency wallets;

a plurality of IDS controlled nodes configured to blockchain process one or more verified cryptocurrency transactions and submit the blockchain processed cryptocurrency transactions for addition to a master blockchain in relation to the transactions; and a distributed blockchain network coupled to the IDS, the distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, wherein the distributed blockchain network is configured to maintain consensus of the master blockchain in relation to the transactions.

2. An interface database system comprising:

a plurality of user and vendor cryptocurrency wallets;

a plurality of IDS controlled nodes configured to blockchain process one or more verified cryptocurrency transactions and submit the blockchain processed cryptocurrency transactions for addition to a master blockchain in relation to the transactions; and wherein the blockchain processed cryptocurrency transactions are submitted to a distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

3. The system of claims 1 or 2, wherein one or more worker units are configured to:

maintain a second transaction queue for cryptocurrency transactions identified to be of an instantaneous type, wherein the cryptocurrency transactions are kept in the second queue during detected transaction peak loads;

release one or more crypto currency transactions of the instantaneous type from the second transaction queue to one or more of the plurality of IDS controlled nodes for blockchain processing and addition to the master blockchain during detected transaction offpeak loads.

4. The system of claim 3, wherein one or more worker units are configured, prior to placing a cryptocurrency transaction of the instantaneous type in the second transaction queue, to:

determine whether a user cryptocurrency wallet is capable of handling a cryptocurrency payment associated with the cryptocurrency transaction;

ring-fence the cryptocurrency payment in the user cryptocurrency wallet when the cryptocurrency wallet is capable of handling a cryptocurrency payment;

confirm instant transaction success to the user and vendor associated with the cryptocurrency transaction.

5. The system of claims 3 or 4, wherein one or more worker units are configured to:

receive confirmation from the master blockchain of the distributed blockchain network that the cryptocurrency transaction has been added to the master blockchain; and update the user cryptocurrency wallet by transferring the ring-fenced cryptocurrency payment to the vendor cryptocurrency wallet.

6. The system of any preceding claim, wherein the cryptocurrency transaction is a PUSH cryptocurrency transaction, the PUSH cryptocurrency transaction is submitted to the IDS by the user for transferring a cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with a vendor, the cryptocurrency transaction includes data representative of an authorisation by the user for the vendor to request transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the crypto currency wallet of the vendor; or wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with functionality of the IDS, the cryptocurrency transaction includes data representative of a transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

7. A computer-implemented method for processing a cryptocurrency transaction of an instant type received by an interface database system according to claims 1 or 2, the method comprising:

determining whether a user cryptocurrency wallet associated with the user is capable of handling a cryptocurrency payment associated with a cryptocurrency transaction between a user and a vendor of the plurality of users and vendors;

ring-fencing the cryptocurrency payment in the user cryptocurrency wallet associated with the user when the user cryptocurrency wallet is capable of handling a cryptocurrency payment;

confirming an instant transaction success to the user and vendor associated with the cryptocurrency transaction and indicating the cryptocurrency payment will be transferred from the user cryptocurrency wallet to the vendor;

maintaining a second transaction queue for cryptocurrency transactions identified to be of an instantaneous type, wherein the cryptocurrency transactions are kept in the second queue during detected transaction peak loads; and releasing one or more cryptocurrency transactions of the instantaneous type from the second transaction queue to one or more of the plurality of IDS controlled nodes for addition to the master blockchain of the distributed blockchain network during detected transaction offpeak loads.

8. The computer-implemented method of claim 7 further comprising:

receiving confirmation from the master blockchain of the distributed blockchain network that the cryptocurrency transaction has been added to the master blockchain; and updating the user cryptocurrency wallet by transferring the ring-fenced cryptocurrency payment to the vendor cryptocurrency wallet.

9. The computer-implemented method of claim 7 or 8, wherein the cryptocurrency transaction is a PUSH cryptocurrency transaction, and the cryptocurrency transaction is submitted to the IDS by the user.

10. The computer-implemented method of claim 7 or 8, wherein the cryptocurrency transaction is a PULL cryptocurrency transaction associated with a vendor, wherein the cryptocurrency transaction includes data representative of an authorisation by the user for the vendor to request transfer of the cryptocurrency payment from the cryptocurrency wallet of the user to the cryptocurrency wallet of the vendor.

11. The computer-implemented method of claim 10, wherein the PULL cryptocurrency transaction is associated with a subscription to a product or a service from the vendor, the method further comprising:

allocating a vendor token to the subscription, the vendor token representative of an authorisation from the user to the vendor in relation to transferring a cryptocurrency payment from the cryptocurrency wallet of the user to the crypto currency wallet of the vendor.

12. A computer-implemented method for creating an automated subscription in an interface database system, IDS, according to claims 1 or 2, the method further comprising:

receiving a selected subscription associated with a vendor from a user; generating the rules of the subscription;

receiving authorisation from the user for a cryptocurrency payment to be transferred from the cryptocurrency wallet of the user to that of the vendor in relation to the subscription;

creating a PULL transaction in relation to the subscription and cryptocurrency payment; and storing the subscription rules, cryptocurrency payment, subscription details, and a vendor token linked to the user in a database of the IDS, wherein the vendor token represents the user authorisation.

13. A computer-implemented method for automatically processing a subscription associated with a vendor in an interface database system, IDS, of claims 1 or 2, wherein the subscription is created according to the method of claim 12, the method comprising:

reprocessing a selected subscription linked to a user and stored in the database of the IDS;

determining whether the subscription is valid or invalid;

transmitting a success confirmation to the vendor and user when the subscription is valid; and transferring the cryptographic payment from the user to the vendor in accordance with the method according to claim 7 for processing a cryptocurrency transaction of an instant type.

14. A computer-implemented method for terminating a subscription with a vendor in an interface database system, IDS, , wherein the subscription is created according to the method of claim 12, the method comprising:

receiving a request from a user to cancel the subscription;

notifying the vendor and user that the subscription is cancelled; and removing the subscription rules, details and vendor token associated with the user from the database of the IDS.

15. A computer-implemented method for reconciling an interface database system, IDS, controlled node in an IDS according to claims 1 or 2, the method comprising:

receiving status reports from IDS controlled nodes of the IDS, wherein each status report includes data representative of a block height of the blockchain of the corresponding IDS controlled node;

restarting an IDS controlled node when it reports a block height differing from consensus of the master blockchain of the distributed blockchain network;

prior to restarting the IDS controlled node, retrieving recent transactions added to the blockchain of the IDS controlled node;

adding the retrieved recent transactions to a transaction verification queue of the IDS for blockchain reprocessing as required.

16. A computer-implemented method for spawning interface database system, IDS, controlled nodes in an IDS according to claims 1 or 2, the method comprising:

maintaining a trusted IDS blockchain node configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network;

estimating the required number of IDS controlled nodes;

in response to the estimated number of IDS controlled nodes being greater than the current number of IDS controlled nodes, spawning one or more IDS controlled nodes to meet the required number of IDS controlled nodes;

pausing maintenance of the trusted copy of the master blockchain on the trusted blockchain node;

storing a copy of the trusted master blockchain on each of the spawned IDS controlled nodes;

synchronising the spawned IDS controlled nodes and the trusted IDS blockchain node with the master blockchain of the distributed blockchain network.

17. A computer-implemented method according to claim 16, wherein:

estimating the required number of IDS controlled nodes further comprises when a transaction queue size reaches a factor of a predetermined number of IDS controlled nodes, and setting the estimated required number of IDS controlled nodes to the current number of IDS controlled nodes combined with the predetermined number of IDS controlled nodes.

18. A computer-implemented method according to claim 16, wherein estimating the required number of IDS controlled nodes further comprises:

determining the number of cryptocurrency wallets that worker units are concurrently required to open;

determining the number of cryptocurrency wallets an IDS controlled node can handle; and estimating the required number of IDS controlled nodes based on dividing the number of cryptocurrency wallets that worker units are concurrently required to open by the number of cryptocurrency wallets an IDS controlled node can handle.

19. A computer-implemented method for spawning worker units in an interface database system, IDS, according to claims 1 or 2, the method comprising:

estimating the required number of worker units to process one or more transaction queues;

in response to the estimated number of worker units being greater than the current number of worker units, spawning one or more worker units to meet the required number of worker units;

assigning the spawned worker units to one or more of the transaction queues;

in response to the estimated number of worker units being less than the current number of worker units, removing one or more worker units to meet the required number of worker units.

20. A computer-implemented method according to claim 19, wherein estimating the required number of worker units further comprises:

determining the transaction queue size;

determining the number of transactions each worker unit can concurrently handle; receiving an operator selected time target;

estimating the number of worker units to be the transaction queue size divided by the number of transactions each worker unit can concurrently handle divided by the time target.

21. A blockchain transaction system comprising:

an interface database system, IDS, configured to receive transactions from a plurality of users and blockchain process the transactions using one or more blockchains synchronised to a master blockchain; and a distributed blockchain network coupled to the IDS, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

22. The system of claim 21, the IDS further comprising:

a plurality of IDS controlled nodes, each IDS controlled node configured to perform blockchain processing for adding transactions to the master blockchain, wherein each IDS controlled node operates on a blockchain synchronised to the master blockchain; and a transaction queue configured to queue transactions prior to blockchain processing depending on blockchain load.

23. An interface database system, IDS, comprising:

a transaction queue configured to receive transactions from a plurality of users; and a plurality of IDS controlled nodes coupled to the transaction queue, wherein each of the IDS controlled nodes are configured to blockchain process one or more of the transactions using a blockchain synchronised to a master blockchain; and wherein the IDS is coupled to a distributed blockchain network, the distributed blockchain network comprising a plurality of blockchain nodes and the IDS controlled nodes, the distributed blockchain network configured to maintain consensus of the master blockchain in relation to the transactions.

24. The system of any of claims 21 to 23, the IDS further comprising:

a transaction module configured to receive the transactions from the plurality of users;

a transaction processing module configured to perform the blockchain processing to add transactions to one or more copies of the master blockchain;

a resource module configured to maintain scalable blockchain processing resources in relation to the transaction processing module and the transaction module;

wherein the transaction processing module is configured to submit one or more blocks to the distributed blockchain network for consensus with the master blockchain.

25. The system of claim 24, wherein the transaction module is configured to:

maintain a second transaction queue for transactions identified to be of an instantaneous type, wherein the transactions are kept in the second queue when a dynamic sizing of the blockchain is detected to expand;

release one or more transactions of the instantaneous type from the second transaction queue to the transaction processing module for addition to the master blockchain when a dynamic sizing of the blockchain is detected to contract.

26. The system of claim 24, wherein the transaction module is configured to:

maintain a second transaction queue for transactions in the transaction queue identified to be of an instantaneous type, wherein the transactions are kept in the second queue when the blockchain processing load has reached a blockchain transaction load limit orblockchain interaction threshold; or release one or more transactions of the instantaneous type from the second queue to the transaction processing module for addition to the master blockchain when the blockchain processing load is below the blockchain transaction load limit or the blockchain interaction threshold.

27. The system of any of claims 24 to 26, wherein the transaction processing module is further configured to:

monitor the blockchain transaction load;

store transactions to the mempool for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

28. The system of any of claims 24 to 27, wherein the transaction processing module is further configured to:

monitor the blockchain transaction load;

receive transactions from the transaction queue(s) for adding to the master blockchain when the blockchain transaction load is less than a blockchain transaction load limit.

29. The system of any of claims 24 to 28, wherein the transaction processing module is further configured to:

receive status reports from IDS controlled nodes of the IDS, wherein each status report includes a block height of the blockchain controlled by the corresponding IDS controlled node;

restart an IDS controlled node when it reports a block height differing from consensus of the master blockchain;

priorto restarting the IDS controlled node, retrieve recent transactions added to the blockchain of the IDS controlled node and add the recent transactions to a transaction verification queue for blockchain reprocessing as required.

30. The system of any of claims 24 to 29, wherein the resource module is further configured to:

monitor transaction blockchain load;

spawn one or more IDS controlled nodes when the transaction blockchain load reaches or exceeds a current transaction load limit of the blockchain nodes and/or IDS controlled nodes; and remove one or more IDS controlled nodes when the transaction blockchain load falls below a current transaction load limit of the blockchain nodes and/or IDS controlled nodes.

31. The system of claim 30, the IDS further comprising a synchronisation module configured to:

maintain a trusted blockchain node configured to store and synchronise a trusted copy of the master blockchain with the master blockchain of the distributed blockchain network;

receive a request to spawn one or more IDS controlled nodes from the resource module;

allocate the one or more requested IDS controlled nodes;

pause maintenance of the trusted copy of the master blockchain on the trusted blockchain node;

store a copy of the trusted master blockchain on each of the allocated IDS controlled nodes;

synchronise the allocated IDS controlled nodes and the trusted blockchain node with the master blockchain of the distributed blockchain network.

32. The system of any of claims 24 to 29, wherein the IDS further comprises a plurality of worker units for processing the transaction queue(s), and the resource module is further configured to:

monitor the number of worker units required to meet a transaction queue load;

spawn one or more worker units when the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

33. The system of claim 32, the resource module further configured to:

maintain an estimate of average queue transaction processing time for a worker unit to complete processing a transaction;

determine a required number of worker units based on the number of transactions in the transaction queue, the number of transactions handled by each worker unit, and the average queue transaction processing time estimate;

allocate or deallocate one or more worker units to meet the determined required number of worker units.

34. The system of any of claims 32 or 33, wherein the resource module is further configured to:

monitor the number of worker units required to meet a transaction queue load;

spawn one or more worker units when more the transaction queue load reaches or exceeds a previous queue transaction load; and remove one or more worker units when the transaction queue load falls below the current queue transaction load.

35. The system of any of claims 21 to 34 wherein the transaction comprises a PUSH transaction from a user to a vendor, ora PULL transaction from a vendor to a user.

36. The system of any of claims 21 to 35, wherein:

the master blockchain is a cryptocurrency master blockchain;

the IDS further comprises a database including a plurality of user wallets associated with one or more of the plurality of users for storing data representative of cryptocurrency units, and wherein the transactions are cryptocurrency transactions.

37. A computer-readable medium comprising data or instruction code, which when executed on one or more processor(s), causes the one or more processor(s) to implement one or more of the computer-implemented method(s) according to an of claims 7 to 20.

38. An apparatus comprising a processor unit and a memory unit, the processor unit coupled to the memory unit, the memory unit including computer-readable medium comprising data or instruction code, which when executed on the processor unit, causes the processor unit to implement one or more of the computer-implemented method(s) according to any of claims 7 to 20.