Technical field

The present disclosure relates to data transaction systems, for example to data systems for providing secure and reliable data transaction when data transactions are executed in a public network including a plurality of nodes coupled together (for example, via a data communication network), for example when nodes involved in the data transaction system are temporally dynamically changing with new nodes joining and existing nodes disconnecting (for example, from the data communication network). Moreover, the present disclosure concerns methods of operating aforesaid data transactions systems. Furthermore, the present disclosure relates to computer program products comprising a non- transitory (non-transient) computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute aforementioned methods. Background

Referring to FIG. 1, a contemporary data communication system, for example the Internet®, is indicated generally by 10 and comprises an arrangement of nodes coupled via communication links 20. The nodes include user devices 30, servers 40, routers 50 and so forth. Moreover, the communication links 20 include, for example, wireless links, optical fibre links, wired links and similar. The user devices 30 include, for example, personal computers, mobile telephones, smart phones, surveillance devices (for example remote cameras), and so forth. Various private networks or private networks are susceptible to being hosted via the data communication system 10, for example: (i) a central "star formation network", wherein an administration hub associated with a centre of the star formation network supervises data transactions occurring within the star formation network;

(ii) a " token ring network" in which data is communicated around at least one ring of communicating nodes, wherein the data is accompanied by corresponding tokens that govern transactions made in respect of the data; and

(iii) a " peer-to-peer " network including a plurality of nodes that are interconnected via a data communication network, without any distinct ring-like structure or star-like structure.

Peer-to-peer (P2P) networks allow member nodes to join and leave them in a flexible dynamic manner. Moreover, such peer-to-peer networks can also potentially become very extensive, for example including thousands or even millions of nodes. However, when such peer-to-peer networks are used for transaction of resources, for example data representative of real physical resources (for example, sale and purchase of real physical objects such as houses, real estate, manufactured products, foodstuffs and so forth), or abstract resources (for example, data representative of a cryptocurrency (for example Bitcoin®) which in turn are tradeable for real physical resources), a technical problem arises with verification of data transactions occurring within the peer-to-peer networks. For Bitcoin® and similar cryptocurrencies, it is customary practice to use a blockchain to function as a ledger for transactions. However, a blockchain is technically challenging, especially when it increases in size; the blockchain is not scalable and also becomes less efficient as it increases in size, becuse every node shares the entire blockchain and proof of work is very environmentally unfriendly to implement in a peer-to-peer network, especially when the peer-to-peer network is public and susceptible to receive a dynamically changing membership of participating nodes, as well as there being a finite time for information to propagate within the peer- to-peer network. When performing data transactions with a peer-to-peer network or similar type of diffuse network of nodes, for example hosting a blockchain ledger, a need arises to achieve a decentralized consensus when performing data transactions that have potentially associated therewith significant financial or material consideration.

Some known implementations of data communication networks have sought to try to address the aforementioned issue of decentralized consensus, but there are always some associated caveats.

It is also known to employ " proof of work"

(https://en.wikipedia.org/wiki/Proof-of-work_system) as a contemporary algorithm within decentralised blockchain networks when performing transactions of data respresentative of resources, but has well known and well documented security, efficiency and environmental limitations. Presently, such " proof of work" algorithms allow miners (for example, Bitcoin® miners) to order or include certain transactions in a block of transactions. Such a situation means that a given ordering of transactions is not network agreed, but is network accepted; this means that a given transaction ordering is not certain and can be based on fees paid or some similar metric. A more formal and complete solution is desired to guarantee an order that is not open to any individual node to set, but instead to ensure that transactions are all network agreed. However, a satisfactory approach to achieve such an aim has hitherto not been devised.

It is known to employ “proof of stake“

(https://en.wikipedia.org/wiki/Proof-of-stake ) in order to try to achieve a distributed consensus within a given data communication network, but known implementations employing such“proof of stake" are very limited, with many contemporary people are sceptical of their viability when implemented practically.

Within a technical field of distributed computing, nodes in a decentralised network must be able to agree a state without a central authority being employed, as aforementioned. Known existing state-of-the-art consensus mechanisms have drawbacks with regard to their complexity, their lack of security and their lack of scalability. Asynchronous consensus/node ordering mechanisms represent a potential solution within non- dynamic/permissioned networks, but fail to do so in public/non- permissioned networks; the present disclosure seeks to address such limitations of known technical approaches. Thus, the present disclosure seeks to provide a technically elegant solution to aforementioned problems of known art, and enables nodes to agree a state within a network that includes a dynamically changing numbers of nodes involved.

Following recent successes of cryptocurrencies and similar types of data transactions implemented by employing blockchain and other distributed computing technologies, many persons are realising efficiency and performance benefits therefrom. Both businesses and persons are becoming increasingly reliant on distributed networks implementing transaction platforms, and billions of dollars (US dollar, $) of trade are carried out each day using such platforms. Known deficiencies of such platforms limit the performance and security of these platforms; in order to continue to cope with contemporary data transactions, better approaches solutions are very much required.

Some known distributed database systems attempt to achieve a consensus for values therein (e.g., regarding a temporal order in which transactions occur). For example, an online multiplayer game might have many computer servers that users can access to play the online multiplayer game; if two users attempt to pick up a given item in the online multiplayer game at the same time, then it is important that the servers within the distributed database system eventually reach agreement regarding which of the two users picked up the given item first.

Such distributed consensus can be handled by methods and/or processes such as the Paxos® algorithm or its variants. Under such methods and/or processes, one server of the database system is set up as the "leader", and the leader decides the order of events; events (e.g., within multiplayer games) are forwarded to the leader, the leader chooses an ordering for the events, and the leader broadcasts that ordering to the other servers of the database system.

Such known approaches, however, use a server operated by a party (e.g., a central management server) trusted by users of the database system (e.g., game players). Accordingly, a need exists for methods and apparatus for a distributed database system that does not require a leader or a trusted third party to operate the database system.

Other distributed databases are designed to have no leader, but are inefficient. For example, one such distributed database is based on a "blockchain" data structure, which can achieve consensus. Such a system, however, can be limited to a small number of transactions per second total, for all of the participants put together (e.g., 7 transactions per second), which is insufficient for a large-scale game or for many traditional applications of databases. Accordingly, a need exists for a distributed database system that achieves consensus without a leader, and which is efficient. Such improvement is especially important when blockchain entries achieved by a consensus are used to control a real physical system in real-time, for example a manufacturing plant including manufacturing equipment. In a published European patent application EP3054405A1 (Applicant: Ripple Labs Inc.; inventors Stefan and Way) (" Temporary consensus sub network in a distributed network for payment processing"), there is described a method of doing business. The method utilizes computing hardware operating under software execution for making a payment transaction between a payor (having an associated payor computer with a ledger storage for the payor) and a payee (having an associated payee computer with a ledger storage for the payee) in a consensus payment network having a plurality of nodes each comprising a respective computer with ledger storage and relying on consensus determinations; an initiator is provided for making the payment transaction between the payor and the payee, wherein the initiator is either the payor, the payee, or an intermediary having an associated intermediary computer. The respective initiator computer creates a temporary payment transaction consensus sub-network comprising a set of validation nodes acceptable to both the payor and the payee; the set of validation nodes comprises fewer than all of the plurality of nodes in the payment network. The initiator with the respective client computer processes the payment transaction via the consensus payment network from the payor to the payee based on a determination of consensus by the consensus network.

In a published international PCT application W02017/004547A1 (Applicant: Google Inc.; inventors: Shraer, Merchant, Sharov and Cooper) ("Distributed storage system with replica location selection"), there is described a system that comprises a plurality of computing clusters, wherein each computing cluster comprises computer memory and a computer processor. The system further includes a distributed database running on at least a subset of the plurality of the computing clusters and that interacts with a client application running on a client computer; the distributed database is configured to use each computing cluster of the computing clusters of the distributed database according to a respective role assigned to the computing cluster that identifies functions of the computing cluster. Moreover, the system further includes an activity monitor service that is configured to:

(i) monitor interactions between the client application and the distributed database;

(ii) generate, from the monitoring of the interactions between the client application and the distributed database, workload data describing the interactions between the client application and the distributed database.

The system utilizes a task assigning service configured to receive an indication that a number (M) of the computing clusters are to be assigned to a voting role of the distributed database. Moreover, for each particular computer cluster of at least some of the computer cluster, the task assigning service:

(i) considers the particular computing cluster as a candidate leader;

(ii) identifies, using the workload data, ( +l)/2 computer clusters having ( +l)/2 lowest latencies with the particular computing cluster as voters corresponding to the candidate leader;

(iii) identifies M-(M+\)/2 unidentified computing clusters as voters corresponding to the candidate leader;

(iv) identifies a number (N) of unidentified computing clusters as replicas corresponding to the candidate leader;

(v) selects the candidate leader computing cluster, corresponding voters, and corresponding replicas having a best score on a metric;

(vi) assigning, to the selected candidate computer cluster, a leader role within the distributed database;

(vii) assigning, to the selected M computer clusters, the voting role within the distributed database; and

(viii)assigning, to the selected N computer clusters, the replica role within the distributed database.

Known ledger systems for providing blockchain functionalities are potentially susceptible to being attacked by malicious third parties, and their reliability in many circumstances cannot be fully guaranteed. Although known ledger systems employ elaborate voting mechanisms and proof mechanisms for verifying nodes and ledger entries, a third-party attack on networks hosting such mechanisms can effectively disrupt the mechanisms with potentially disastrous consequences, for example with disastrous financial consequences. When such ledgers are employed to control operation of real physical systems (for example, transactions involved with operation of a manufacturing plant producing a physical product), malfunction of the real physical systems can occur that represents a potential apparatus safety issue.

In a granted European patent EP 3 257 191 B1 (" Registry and automated management method for blockchain-enforced smart contracts ") (Applicant: Nchain Holdings Limited St. John's (AG); inventors: Wright and Savanah), there is described a computer-implemented method of controlling the visibility and/or performance of a contract, the method comprising the steps:

(a) storing a contract on or in a computer-based repository;

(b) broadcasting a transaction to a blockchain, the transaction comprising:

(i) at least one unspent output (UTXO); and

(ii) metadata comprising an identifier indicative of the location

where the contract is stored;

(c) interpreting the contract as open or valid until the unspent output (UTXO) is spent on the blockchain; and

(d) renewing or rolling the contract on by:

(i) generating a new key using data relating to a previous key associated with the contract;

(ii) generating a script comprising the new key, the location of the contract and a hash of the contract; and

(iii) paying an amount of currency to the script. Summary

The present disclosure seeks to provide an improved data transaction system that is operable to provide an increased degree of transaction data security and transaction reliability, for example when the data transaction systems has a temporally dynamically changing membership of nodes and associated users.

Moreover, the present disclosure seeks to provide an improved method of operating a membership data transaction system which is operable to provide an increased degree of transaction data security and transaction reliability, for example when the membership data transaction systems has a temporally dynamically changing membership of nodes and associated users.

According to a first aspect, there is provided a data transaction system including one or more data computing nodes and a data communication network linking the one or more data computing nodes, wherein the data transaction system includes a ledger arrangement for recording transaction events implemented in respect of one or more resource elements; wherein the one or more data computing nodes are categorized into one or more trusted nodes and one or more untrusted nodes; wherein a trust verification arrangement determines whether a given node is a trusted node or an untrusted node; and wherein the data transaction system includes a voting arrangement that receives votes from the trusted nodes to compute a consensus for verifying one or more transaction events to be recorded or already recorded on the ledger arrangement, characterized in that

(a) the data transaction system is operable to store data used by the nodes by:

(i) dividing the data into a plurality of data chunks that are then encrypted and/or obfuscated; and

(ii) storing the one or more encrypted and/or obfuscated data chunks at one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map; and

(b) the data transaction system is operable to retrieve data used by the nodes by:

(iii) retrieving one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in the at least one data map; and

(iv) applying decryption to the data chunks and/or de-obfuscating the data chunks by swapping data between the data chunks, and combining the plurality of the decrypted and/or de-obfuscated data chunks to generate the data used by the nodes.

The invention is of advantage in that the data transaction system is able to provide, by handling data via processes of encryption, decryption, obfuscation, and de-obfuscation, a more reliable transaction of data therein, despite nodes leaving and joining the data transaction system in a dynamically changing manner, for example where the nodes are coupled via a publicly-accessible data communication network.

In overview, the present invention provides a data transaction system that combines an asynchronous consensus/node ordering mechanism that functions within a public/non-permissioned network where network members are temporally dynamically changing. Furthermore, the present invention is capable of working within an encrypted decentralised data and communications network that utilises spare computing resources of users of the network. Additionally, the present invention can be used within any decentralised network requiring autonomous decision making including: decentralised app development platforms, corporate data networks, crypto currency and financial trading platforms, decentralised applications and gaming.

According to a second aspect, there is provided a method of operating a data transaction system including one or more data computing nodes and a data communication network linking the one or more data computing nodes, wherein the data transaction system includes a ledger arrangement for recording transaction events implemented in respect of one or more resource elements; wherein the method includes:

(i) using the one or more data computing nodes that are categorized into one or more trusted nodes and one or more untrusted nodes;

(ii) using a trust verification arrangement to determine whether a given node is a trusted node or an untrusted node; and (iii) arranging for the data transaction system to include a voting arrangement that receives votes from the trusted nodes to compute a consensus for verifying one or more transaction events to be recorded or already recorded on the ledger arrangement, characterized in that the method further includes:

(a) operating the data transaction system to store data used by the nodes by:

(i) dividing the data into a plurality of data chunks that are then encrypted and/or obfuscated; and

(ii) storing the one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map; and

(b) operating the data transaction system to retrieve data used by the nodes by:

(iii) retrieving one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in the at least one data map; and

(iv) applying decryption to the data chunks and/or de-obfuscating the data chunks by swapping data between the data chunks, and combining the plurality of the decrypted and/or de-obfuscated data chunks to generate the data used by the nodes.

According to a third aspect, there is provided a computer program product comprising a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute a method of the aforesaid second aspect.

It will be appreciated that features of the invention are susceptible to being combined in various combinations without departing from the scope of the invention as defined by the appended claims.

Description of the diagrams

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. 1 is an illustration of a data transaction system of the present disclosure including a plurality of data computing nodes coupled together via a data communication network;

FIG. 2 is an illustration of steps of a method of storing data files used by the data computing nodes in fragmented, encrypted and obfuscated form within a data transaction system pursuant to the present disclosure;

FIG. 3 is an illustration of steps of a method of retrieving data files used by the data computing nodes in de-fragmented, decrypted and de-obfuscated form within a data transaction system pursuant to the present disclosure;

FIG. 4 is an illustration of a data transaction system for sharing data in an obfuscated encrypted manner between a plurality of user devices of a data transaction system;

FIG. 5 is an illustration of a manner of monitoring data traffic in a membership data transaction system;

FIG. 6 is an illustration of steps of a method of using the data transaction system of FIGs. 1 to 5, for implementing transactions in bitcoin or other cryptocurrency. In the accompanying diagrams, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non-underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

Description of embodiments

In overview, in a first aspect, embodiments of the present disclosure include a data transaction system including one or more data computing nodes and a data communication network linking the one or more data computing nodes, wherein the one or more data computing nodes are categorized into one or more trusted nodes and one or more untrusted nodes; wherein a trust verification arrangement determines whether a given data computing node is a trusted node or an untrusted node; and wherein the data transaction system includes a voting arrangement that receives votes from the trusted nodes to compute a consensus for verifying one or more transaction events.

Beneficially, the data transaction system is operable to store data used by the data computing nodes by:

(i) dividing the data into a plurality of data chunks that are then encrypted and/or obfuscated; and

(ii) storing the one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map; and the data transaction system is operable to retrieve data used by the data computing nodes by:

(iii) retrieving one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in the at least one data map;

(iv) applying decryption to the data chunks and/or de-obfuscating the data chunks by swapping data between the data chunks, and combining the plurality of the decrypted and/or de-obfuscated data chunks to generate the data used by the data computing nodes.

Optionally, the data transaction system includes a ledger arrangement for recording transaction events implemented in respect of one or more resource elements; and wherein the data transaction system includes the voting arrangement that receives votes from the trusted nodes to compute the consensus for verifying one or more transaction events to be recorded or already recorded on the ledger arrangement.

Optionally, the data transaction system is implemented such that the data communication network is a publicly-accessible network wherein nodes are able to disconnect from the publicly-accessible network and/or nodes are able to connect to the publicly-accessible network as a function of time. More optionally, the data transaction system is implemented such that a given node connecting to the publicly-accessible network is initially assumed by the system to be an untrusted node until the trust verification arrangement transitions the given node from being assumed to be an untrusted node to become a trusted node of the system. Yet more optionally, the data transaction system is implemented such that the trust verification arrangement is implemented to access a distributed database, and the trust verification arrangement uses the database for:

(i) determining a speed with which the given node is able to receive information related to transaction events occurring within the system; (ii) determining a degree to which the given node has access to information indicative of events associated with transaction events occurring within the system;

(iii) determining a previous historical performance of the given node when earlier verifying one or more transaction events occurring within the system; and

(iv) an age of the given node and a reputation parameter that the given node has in respect of other nodes of the system.

Optionally, the data transaction system combines an asynchronous consensus/node ordering mechanism that functions within a public/non- permissioned network wherein network members are temporally dynamically changing.

Optionally, the data transaction system is implemented such that the at least one data map is stored in an encrypted form at one or more locations in a plurality of one or more data computing nodes.

Optionally, the data transaction system is implemented such that the at least one data map is modified after each new block is added to the blockchain and the ledger arrangement has been correspondingly updated. Such updating makes it extremely difficult for any given malicious third party to remove blocks that have been added to the blockchain and substitute the blocks with alternative blocks. Optionally, the data transaction system is implemented such that the at least one data map that is employed for storing and retrieving data for untrusted nodes is mutually different to the at least one data map that is employed for storing and retrieving data for trusted nodes. Such multiple layers of data protection that are thereby provided assist to make the data transaction system more robust against malicious third-party attacks. Optionally, the data transaction system is implemented such that the data communication network is configured to function as a peer-to-peer (P2P) network.

Optionally, the data transaction system is implemented such that the data computing nodes at the locations whereat the one or more encrypted and/or obfuscated data chunks are stored are operable to maintain multiple copies of their respective encrypted and/or obfuscated data chunks, and to regenerate from uncorrupted copies of the encrypted and/or obfuscated data chunks one or more replacement encrypted and/or obfuscated data chunks to replace any copy of the encrypted and/or obfuscated data chunks which have been corrupted.

Optionally, the data transaction system is operable to enable the plurality of data communication nodes to access their respective data, by retrieving the at least one encrypted data map against a user ID, to decrypt the at least one data map to determine the locations whereat the one or more encrypted and/or obfuscated data chunks are stored, to fetch the one or more encrypted and/or obfuscated data chunks from the locations, to decrypt and/or de-obfuscate the one or more encrypted and/or obfuscated data chunks to generate one or more corresponding decoded data chunks, and to assemble the one or more decoded data chunks to regenerate the respective data.

Optionally, the data transaction system is implemented such that data to be transacted corresponds to a currency value (cryptocurrency) which is authenticated by a blockchain entry made by the ledger arrangement, as approved by a consensus of the trusted nodes. Optionally, the data transaction system is implemented such that data to be transacted corresponds to a currency value (cryptocurrency) represented by coins (SAFECOIN), wherein each coin has an identification that is connected/attributed to a corresponding specific node of the system (10) that owns the coin, wherein node that owns the coin is able to transfers ownership of the coin to another node by sending the coin to the another node, and wherein transfer of the coin is devoid of recordal on any ledger arrangement.

Optionally, the data transaction system is implemented such that known information from user data is used by the system as an encryption key for encrypting the data chunks and/or for encrypting the data map. Optionally, the data transaction system is operable to encrypt each data chunk separately, and wherein, for each data chunk, known information from another chunk is data used as the encryption key.

Optionally, the data transaction system is operable to determine a hash value for the data, and to use the determined hash value to determine at least one of: sizes of the data chunks, the number of data chunks corresponding to the data.

Optionally, the data transaction system is operable to determine a hash value of each data chunk and to rename the chunk using the determined hash value of the data chunk.

Optionally, the data transaction system is operable to store the encrypted and/or obfuscated data chunks on a distributed nodal network.

Optionally, the data transaction system is implemented as a voting system for achieving network consensus. Optionally, the data transaction system is operable to employ encryption keys when encrypting the data chunks and/or the data map, wherein the encryption keys are never reused.

Optionally, the data transaction system is operable to increase its security of the encrypted and/or obfuscated data chunks proportionately to a chosen hashing algorithm employed by the system. According to a second aspect, there is provided a method of operating a data transaction system including one or more data computing nodes and a data communication network linking the one or more data computing nodes, wherein the method includes: (i) categorizing the one or more data computing nodes into one or more trusted nodes and one or more untrusted nodes, wherein a trust verification arrangement determines whether a given node is a trusted node or an untrusted node; and (ii) including in the data transaction system a voting arrangement that receives votes from the trusted nodes to compute a consensus for verifying one or more transaction events.

Beneficially, the method includes operating the data transaction system to store data used by the nodes by:

(i) dividing the data into a plurality of data chunks that are then encrypted and/or obfuscated; and

(ii) storing the one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map; and operating the data transaction system to retrieve data used by the nodes by:

(iii) retrieving one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in the at least one data map; and

(iv) applying decryption to the data chunks and/or de-obfuscating the data chunks by swapping data between the data chunks, and combining the plurality of the decrypted and/or de-obfuscated data chunks to generate the data used by the nodes.

Optionally, the method includes arranging for the data transaction system to include a ledger arrangement for recording transaction events implemented in respect of one or more resource elements; and arranging for the data transaction system to include the voting arrangement that receives votes from the trusted nodes to compute the consensus for verifying one or more transaction events to be recorded or already recorded on the ledger arrangement.

Optionally, the method includes modifying the at least one data map after each new block is added to the blockchain and the ledger arrangement has been correspondingly updated. Such updating makes it extremely difficult for any given malicious third party to remove blocks that have been added to the blockchain and substitute the blocks with alternative blocks, thereby enhancing an operating robustness of the data transaction system. Optionally, the method includes implementing the data transaction system such that the at least one data map that is employed for storing and retrieving data for untrusted nodes is mutually different to the at least one data map that is employed for storing and retrieving data for trusted nodes. Such multiple layers of data protection assist to make the method more robust against malicious third-party attacks.

According to a third aspect, there is provided a computer program product comprising a non-transitory computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a computerized device comprising processing hardware to execute a method of the aforesaid second aspect.

Following from the overview above, the present disclosure is concerned with data transaction systems employing a configuration of nodes which is generally akin to the data system 10 of FIG. 1, except that a manner in which such data systems store and access data is very different to, for example, the contemporary Internet®. In an example data transaction system pursuant to the present disclosure, a given user has one or more of his/her user data files substantially only intact at a computing device of the given user, and/or at one of more computing devices of one or more other users respectively which the given user has allowed to receive the user data files. Elsewhere in the data system, for example in remote servers thereof, the user's data files are stored in fragmented, encrypted and obfuscated form as data fragments. These data fragments are substantially impossible for an unauthorized third party to reconstitute to regenerate the given user's data files. A record of data fragmentation, encryption and obfuscation applied to each of the data fragments is recorded in an encrypted data map to which only the given user has access, or to one or more other parties to which the given user has granted permission. In such a user-centric data system, data mining by unauthorized third parties is practically infeasible in contradistinction to known forms of data system where users' files are stored intact in their entirety in external servers of a data network, as in contemporary cloud computing. Aforementioned data fragmentation, encryption and obfuscation will next be described with reference to FIG. 2. In a step SI, the given user generates a data file denoted by 100. The data file 100 exists locally within a computing device of the given user; the computing device is implemented, for example, as a personal computer (PC), a tablet computer, a smart phone, a smart wrist-worn device, and similar. Optionally, the data file 100 exists only at a specific user software layer (namely " Maidsafe system software layer") of a software operating system of the computing device of the given user, for example to avoid spyware, unbeknown to the given user, executing at a different software layer of the user's computing device relative to the specific user software layer, gaining access to the data file 100.

In a step S2, as shown in FIG. 2, the data file 100 is partitioned to generate a plurality of fragments, for example four fragments 100A, 100B, 100C, 100D, although other numbers of fragments are feasible. Optionally, the fragments 100A, 100B, 100C, 100D are of mutually similar size. Alternatively, optionally, the fragments 100A, 100B, 100C, 100D are of mutually different size. In a step S3, data indicative of a manner in which the data file 100 is partitioned into the fragments 100A, 100B, 100C, 100D is recorded in a parameter file denoted by "P". Optionally, partitioning of the data file 100 is implemented using a function which is seeded, namely " salted ", by one or more passwords provided by the given user.

In a step S4, the fragments from the step S3 are subject to encryption to generate corresponding encrypted fragments; for example, in the step S3, the fragments 100A, 100B, 100C, 100D are encrypted to generate corresponding encrypted data files 110A, HOB, HOC, 110D, respectively. In the step S4, data indicative of encryption applied to the fragments 100A, 100B, 100C, 100D to generate the encrypted data files 110A, HOB, HOC, HOD is also included in the parameter file denoted by "P". Optionally, a mutually similar encryption algorithm is employed to encrypt the fragments 100A, lOOB, lOOC, lOOD to generate the encrypted data files 110A, HOB, HOC, 110D. Optionally, alternatively, mutually dissimilar encryption algorithms are employed to encrypt the fragments lOOA, lOOB, lOOC, lOOD to generate the encrypted data files 110A, HOB, HOC, HOD. Optionally, selection of the encryption employed to encrypt the fragments lOOA, lOOB, lOOC, lOOD to generate the encrypted data files 110A, HOB, HOC, HOD is implemented using a function which is seeded, namely " salted ", by one or more passwords provided by the given user. Although four encrypted data files 110 are described here, it will be appreciated that other numbers of encrypted data files are optionally employed in the step S4.

In a step S5, the encrypted data files 110A, HOB, HOC, HOD are subject to obfuscation, which is optionally achieved by swapping one or more bytes of data between the encrypted data files 110A, HOB, HOC, HOD, to generate corresponding obfuscated data files 120A, 120B, 120C, 120D respectfully. Data indicative of a manner in which the obfuscation is implemented is also included in the parameter file denoted by "P". Optionally, such obfuscation is achieved using a relatively simple logic function, for example an XOR function, which is native to a data processor of the given user's computing device. Although four obfuscated data files 120 are described here, it will be appreciated that other numbers of encrypted data files are optionally employed in the step S5.

Subsequently, the parameter file P and the obfuscated data files 120A, 120B, 120C, 120D are stored on a data storage medium of the given user's computing device, for example on an encrypted hard disc drive or non-volatile solid state data memory of the given user's computing device; alternatively, or additionally, the obfuscated data files 120A, 120B, 120C, 120D are stored on the one or more servers 40 of the system 10. Beneficially, the one or more servers 40 are operable to support the user-centric data system by storing the obfuscated data files 120 that they receive in multiple copies and employ a majority voting system to detect and repair any errors arising in the obfuscated data files 120A, 120B, 120C, 120D when stored on the one or more servers 40. Optionally, the parameter file P is stored on a different server 40 relative to one or more servers 40 employed to store the obfuscated data files 120A, 120B, 120C, 120D. Beneficially, parameter file P is stored in encrypted form, and is accessible to the given user by using a password known to the given user.

Referring next FIG. 3, there are shown steps of recovering a data file from the one or more servers 40 of the system 10, when the system 10 is configured in a user-centric manner pursuant to the present disclosure. In a first step Rl, the given user loads or otherwise recovers the parameter file P, which is beneficially stored in an encrypted state either on the given user's computing device and/or at a server 40 of the network 10; access to the parameter file P, namely a data map, is achieved via use of at least one password which is known only to the given user.

In a step R2, the parameter file P is decrypted and the locations of the obfuscated data files 120A, 120B, 120C, 120D is determined.

Thereafter, the obfuscated data files 120A, 120B, 120C, 120D are recovered from their respective one or more servers 40 of the system 10 and provided to the computing device of the given user. Next, in a step R3, obfuscation processes used to generate the obfuscated data files 120A, 120B, 120C, 120D are determined from the parameter file P, and an inverse of these processes is then applied to the obfuscated data files 120A, 120B, 120C, 120D to regenerate corresponding encrypted data files 110A, HOB, 110C, HOD.

In a step R4, encryption processes that were used to generate the encrypted data files 110A, HOB, HOC, HOD are determined from the parameter file P, and an inverse of such encryption processes is applied to the encrypted data files 110A, HOB, HOC, 110D to generate corresponding decrypted fragments 100A, 100B, 100C, 100D.

Thereafter, in a step R5, a manner of fragmentation that was used to generate the fragments 100A, 100B, 100C, 100D is determined from the parameter file P, and an inverse of such fragmentation is then applied to the fragments 100A, 100B, 100C, 100D to regenerate the data file 100. Again, it will be appreciated that other numbers of fragments can be employed, and that four fragments are shown in FIG. 3 merely for illustrative purposes.

It will be appreciated from the forgoing that the data file 100 only exists in a complete intact form within the computing device of the given user, and exists in a fragmented, encrypted and obfuscated form within the system 10, namely spatially remote from the given user's computing device. Methods associated with FIG. 2 and FIG. 3 enable, for example a secure and confidential data "drop box " to be provided to the given user via the system 10 in a manner which substantially renders infeasible third-party eavesdropping and data mining. Such a manner of operation is in distinct contradistinction to conventional Internet® and similar, wherein data files are stored intact at servers which are remote from a given user's computing device.

Optionally, in the system 10 implemented in a user-centric manner, as illustrated in FIG. 4, a user of a user device 30A is able to share his/her data file 100 by generating the parameter file P which is provided to other user devices 30A, 30B, 30C. The data file 100 is fragmented, encrypted and obfuscated, as aforementioned, and obfuscated encrypted fragments of the data file 100 are stored in a plurality of servers 40A, 40B, 40C. These servers 40A, 40B, 40C are operable to supply the obfuscated encrypted fragments to the other user devices 30B, 30C, 30D, whose computing devices are operable to process the obfuscated encrypted fragments to regenerate locally at these computing devices replicas of the data file 100. The parameter file P is also provided to the other user devices 30B, 30C, 30D to enable their computing devices to regenerate the replicas of the data file 100. Optionally, the data servers 40A, 40B, 40C are implemented in a proxy manner, namely the user devices 30B, 30C, 30D are only provided access to proxy servers which mirror content of the servers 40A, 40B, 40C to which the user device 30A has access.

The system 10 as implemented pursuant to FIG. 4 allows for secure and confidential file sharing, for example document sharing, between user devices 30. Moreover, such operations are useful for activities which require a very high degree of confidentiality. Optionally, flows of obfuscated encrypted fragments along paths as depicted in FIG. 4 occurs in a bi-directional manner.

Optionally, in an embodiment, the system 10 configured in a user-centric manner is operable to store, recover and share its data files by employing obfuscated encrypted data fragments.

In view of the system 10 implemented in a user-centric manner pursuant to the present disclosure provides control to users of the user devices 30, in contradistinction to the conventional Internet which provides control to operators of servers thereof for deleting, analyzing and disseminating user data stored in the servers. Flowever, the system 10 implemented in a user-centric manner is beneficially provided with a management function, for example for controlling use of the servers 40 (although it will be appreciated that the servers 40 of the system 10 are optionally not servers in a convention sense, but are beneficially implemented as SAFE nodes), as well as methods of data repair when multiple copies of user fragments are stored at the servers 40, and majority-voting arrangement is employed to detect errors in data, without needing to be provided any information to what the user fragments pertain. In such a majority-voting arrangement, in an event that a given user's data fragment is stored in three copies, in an event that a first copy of the three copies deviates from a second copy and a third copy of the three copies which remain mutually similar, the first copy is determined by the system 10 to be in error. Such error is, for example, corrected in the system 10 by copying either the second copy or the third copy to overwrite the first copy. Other majority-voting arrangements are optionally employed to correct for data errors, for example parity-bit checking and so forth. If a given node of the system 10 implemented in a user-centric manner consistently results in data error, for example a given server 40 of the system 10 has developed a fault in one or more of its hard disc drives or has been infected by malware, the given node is recorded by the system 10 to be a bad node, and data provided from user devices 30 are directed to other nodes, for example servers, which the system 10 has recorded as being reliable nodes.

The system 10 implemented in a user-centric manner pursuant to the present disclosure is optionally configured to function in a peer-to-peer (P2P) manner, namely user devices send their data fragments to the data into a communication network of the system 10 with an indication of a server 40 in which the data is to be stored, and the network passes the data therethrough in a peer-to-peer manner, until the data reaches the server 40 that has been specified. Optionally, the server 40 is defined by a URL as in conventional HTTP, although other types of communication protocol are optionally alternatively employed. Use of a peer-to-peer network configuration for the system 10 implemented in a user-centric manner pursuant to the present disclosure further places control away from any manager of the system 10 and more beneficially in favour of the users of the user devices 30.

The system 10 implemented in a user-centric manner pursuant to the present disclosure is suitable for use in providing an alternative to contemporary fiat currency systems. Earlier, currency systems based upon precious metals, were in use in many parts of the World, to allow for trade and commerce. In order to expand money supply, " fractional banking" systems were implemented, wherein a given piece of gold held by a bank could, in effect, be lent to multiple parties. In more recent times, fiat currencies such as the US dollar (US$) and the Euro have been used, wherein such monetary denominations are created from nothing, and have no intrinsic value, but merely a value allocated to them by way of operations of contemporary financial markets. Frustration in the manner in which many contemporary fiat currency financial markets function has resulted in cryptocurrencies being increasingly used, for example " Bitcoin ". A Bitcoin payment system is operable, such that payments in the Bitcoin system are recorded in a public ledger using its own unit of account, which is also called a "bitcoin". The bitcoin system is not controlled by a single entity, such as a central bank, and is therefore considered to be a "decentralized currency".

Bitcoins are, for example, created as a payment reward for processing work, wherein users offer their computing power to verify and record payments into a public ledger associated with Bitcoin. Moreover, such processing work is referred as "mining", wherein, in practice, individuals or companies engage in processing work in exchange for transaction fees and newly created bitcoins. Besides mining, bitcoins can be obtained in exchange for other currencies, products, and services.

The aforementioned Bitcoin ledger records financial transactions which have executed using bitcoins. Recording such financial transactions is accomplished without an intermediation of any single, central authority. Instead, multiple intermediaries exist in a form of computer servers executing bitcoin software. These computer servers form a network connected via, for example, the Internet®, wherein anyone can potentially join the network. Transactions accommodated by the network are of a form: "payer A wants to send Z bitcoins to payee B", wherein the transactions are broadcast to the network using readily available software applications. The computer servers function as Bitcoin servers that are operable to validate these financial transactions, add a record of them to their copy of the ledger, and then broadcast these ledger additions to other servers of the network.

All bitcoin transfers are recorded in a computer file that acts as a ledger, as aforementioned; the computer file is referred as a " block chain". Bitcoins are simply entries in a block chain and do not exist outside the block chain. However, this then requires that the integrity and accuracy of entries in the block change have to be reliable in order for the Bitcoin system to function in practice. Such integrity and accuracy is difficult to achieve in networks, for example open public networks, having a dynamically changing combination of nodes therein, with certain nodes leaving and other nodes joining the networks from time-to-time.

As aforementioned, maintaining the block chain is referred to as " mining ", and parties which do such maintenance are rewarded with newly created bitcoins and transaction fees. Miners process payments for verifying each transaction as valid when added to the block chain; such verification is achieved via consensus provided by a plurality of miners, and assumes that there is no systematic collusion between minors. To claim a reward for mining, a special transaction called a coinbase is included with the processed payments.

Ownership of bitcoins associated with a certain bitcoin address can be demonstrated with knowledge of a private key belonging to the address. For a given owner, it is important to protect the private key from loss or theft. If a private key of a given user is lost, the given user cannot prove ownership by any other means. The bitcoins are then lost and cannot be recovered. Since anyone with knowledge of the private key has ownership of any associated bitcoins, theft occurs when a private key is revealed or stolen. Thus, a technical problem addressed by the data transaction system 10 pursuant to the present disclosure is how to trade more readily in bitcoins, and yet maintain a high degree of security in respect of such private keys, for example when nodes leave or join the system 10 in a temporally dynamic manner.

A bitcoin wallet is something "...that stores digital credentials for a given user's bitcoin holdings..." and allows the given user to access and spend the bitcoin holdings. The Bitcoin system utilizes public-key cryptography, in which two cryptographic keys, one public key and one private key, are generated. The public key can be thought of as an account number, and the private key can be thought of as ownership credentials. At its most basic, a bitcoin wallet is a collection of these keys.

An important issue in relation to bitcoin security is preventing unauthorized transactions occurring in respect of a given user's bitcoin wallet. A bitcoin transaction permanently transfers ownership of a given bitcoin to a new address, wherein the transaction has an associated data string having a form of random letters and numbers derived from public keys by application of a hash function and an encoding scheme. The corresponding private keys act as a safeguard for the given user; a valid payment message from an address must contain an associated public key and a digital signature proving possession of the associated private key. As anyone with a private key can spend all of the bitcoins associated with the corresponding address, protection of private keys is very important in the Bitcoin system. Loss of a private key may result in theft; a risk of theft can be reduced by generating keys offline on an uncompromised computer and saving them on external storage or paper printouts. The data transaction system 10, by way of its user-centric manner of operation, using obfuscated encrypted fragments for storing information, is able to create a computer system which is infeasible to compromise. However, there also arises an issue that information describing cryptocurrency transactions takes a finite time to propagate within a given data communication network, that can generate uncertainty in information recorded at a ledger associated with a given cryptocurrency. According to embodiments of the present disclosure, such uncertainty is resolved using consensus amongst trusted nodes, as will be described in greater detail below.

A theft of a given bitcoin is an unauthorized transfer from a bitcoin address using an associated private key to unlock the address. However, as aforementioned, generating and storing keys offline mitigates the risk of theft. Most large-scale bitcoin thefts occur at exchanges or online wallet services that store the private keys of many users. A thief hacks an online bitcoin wallet service by finding a bug in its website or spreading malware to computers holding the private keys.

The contemporary Bitcoin (for example, implemented in a P2P manner) network itself is potentially vulnerable to attack and corruption, as will next be elucidated. There are two main ways the blockchain ledger can be corrupted to steal bitcoins, namely by fraudulently adding to or modifying the ledger. The Bitcoin system protects the blockchain against both using a combination of digital signatures and cryptographic hashes.

Payers and payees using the Bitcoin system are identified in the blockchain by their public cryptographic keys. Most contemporary bitcoin transfers are from one public key to a different public key; in practice hashes of these keys are used in the blockchain, and are called " bitcoin addresses ". In principle, a hypothetical attacker Userl could steal money from User2 and User3 by simply adding transactions to the blockchain ledger like "User2 pays Userl 100 bitcoins" , "User3 pays Userl 100 bitcoins", and so on, using of course these users' bitcoin addresses instead of their names. The bitcoin protocol prevents this kind of theft by requiring every transfer to be digitally signed with the payer's private key; only signed transfers can be added to the blockchain ledger. Since Userl cannot forge User2'a signature, Userl cannot defraud User2 by adding an entry to the blockchain ledger equivalent to " User2 pays Userl 100 bitcoins". At the same time, anyone can verify User2's signature using his/her public key, and therefore that he/she has authorized any transaction in the blockchain ledger where he/she is the payer.

Another contemporary principal way to steal bitcoins is to modify blockchain ledger entries. Aforementioned Userl could buy something from User2 by adding a signed entry to the blockchain ledger equivalent to Userl pays User2 100 bitcoins. Later, Userl could modify that blockchain ledger entry to read instead: " Userl pays User2 1 bitcoin", or even delete the entry. Digital signatures cannot prevent this attack: Userl can simply sign his/her entry again after modifying it.

The Bitcoin system addresses a problem common to all digital currency and payment schemes, namely a problem of "double-spending" . With paper money or physical coins, when a given payer transfers money or physical coins to a given payee, the payer cannot keep a copy of that money or physical coins, for example a US dollar bill. However, in contradistinction, with digital money, which is just a computer file, such exclusion from copying is not the case, and the payer could in principle spend the same money again and again, via repeatedly copying of the file. With bitcoin, when Userl offers to pay User3 some bitcoins, User3 can always first check the blockchain ledger to verify that Userl actually owns that many bitcoins. Of course, Userl could try to pay many people simultaneously, but the contemporary Bitcoin system can defend against that. If Userl offers to pay User3 some bitcoins in exchange for goods, User3 can stipulate that he/she will not deliver the goods until Userl 's payment to User3 appears in the blockchain, which typically involves waiting about ten minutes. A race attack in the Bitcoin system can potentially occur as follows: if a given bitcoin transaction has no confirmations, shops and services which accept payment via bitcoins can be exposed to a "race attack". For example, two bitcoin transactions are created for the same funds to be sent to different shops/services. Bitcoin system rules ensure that only one of those bitcoin transactions can be added to the block chain. Information propagation delays within a peer-to-peer (P2P) network of nodes can potentially give rise to a risk of a race attack occurring. Embodiments of present disclosure address such "race attack" risk by providing consensus voting amongst a plurality of trusted nodes, as will be elucidated in greater detail below.

It will be appreciated from the foregoing that the Bitcoin system has several potential weaknesses when employed in practice to make payments.

It will be appreciated that the data transaction system 10 implemented in a user-centric manner pursuant to the present disclosure is capable of providing an enhanced degree of data security and robustness. In particular, storing private-key encoded bitcoin information in an obfuscated encrypted manner assists to protect against bitcoin theft. Moreover, transfer of a parameter file "P" is beneficially employed as a manner of transferring bitcoin ownership during financial transactions. Furthermore, a two-stage transfer of a bitcoin via communicating the parameter file "P", followed by transfer of a password to decrypt the parameter file "P" for accessing a given bitcoin is optionally employed, wherein transfer of the parameter file "P" indicates an intention of a given user to make a financial transaction, for example a purchase of a product, and transfer of the password to decrypt the parameter file "P" corresponds to execution of the financial transaction. In an event that the user or a supplier of the product in the financial transaction default, the supplier is not paid, and the user can be potentially traced from the parameter file "P", for example via a user-identification portion of the parameter file "P". Bitcoiri can also optionally be employed to make anonymous payments, for example where the user's identity cannot be determined from the parameter file "P".

The process of financially transacting bitcoins or related cryptocurrency, and other related types of cryptocurrencies, involves a process of passing the bitcoin or related cryptocurrency that preferably alters the signature on the bitcoin to the seller's signature. This new signature is reported back to the bitcoin or related cryptocurrency issuing authority.

According to a related aspect of the present disclosure, users are able to purchase digital cash or credits from any seller of the cash. The seller beneficially creates actual cash data chunks which are signed and serialised to prevent forgery. This is preferably accountable as with contemporary actual cash, to prevent fraud and counterfeiting. The users are able to purchase bitcoins or related cryptocurrencies for cash and store these in their database of files in the data transaction system 10 implemented in a user-centric manner pursuant to the present disclosure.

When a given bitcoin is purchased, it is preferably unusable and in fact simply a reference number used to claim the bitcoin's monetary value by the purchaser's system. This reference number is preferably valid for a period of time. The purchaser then logs into his/her data transaction system 10, beneficially implemented in a user-centric manner, and then inputs the reference number in a secure communications medium as a bitcoin request. This request is analysed by the bitcoin issuing authority and the transaction process begins. Preferably, the bitcoin is signed by the bitcoin issuing authority, wherein the bitcoin issuing authority preferably encrypts it with the purchaser's public key and issues a signing request. The bitcoin is not valid at this point. Only when a signed copy of the bitcoiri is received by the bitcoiri issuing authority is the serial number made valid and the bitcoin is live.

This given bitcoin now belongs to the purchaser and validated by the bitcoin issuing authority. To carry out a transaction, this process is preferably carried out again, wherein the authority then simply updates the current owner of the bitcoin in their records, namely transaction ledger. The data transaction system 10 implemented in a user-centric manner is susceptible to data overload in communication links 20 thereof, and needs to be managed in order to reduce response times for the user devices 30. Data flow management within the data transaction system 10 is beneficially implemented in a distributed manner and/or a centralized manner; however, data propagation delays occurring in operation within the system 10 are susceptible to causing uncertainty. Moreover, conflicts of ledger information can arise when the system 10 is affected by a dynamically changing number of nodes coupling to and disconnecting from the data transaction system 10.

In a first manner of operation, when the routers 50 and the links 20 are implemented pursuant to http IP protocol, for example, data flows via the routers 50 are reported to a control facility of the system 10 that then sends control information to the one or more user devices 30, for enabling them to send their obfuscated encrypted fragments via alternative routers 50 which are less loaded with data flow. Alternatively, in a second manner of operation, data flows via the routers 50 are reported directly to one or more user devices 30 sending data to them for enabling the one or more user devices 30 to select alternative routes to send their obfuscated encrypted fragments. Optionally, a combination of the first and second manners of operation is employed within the data system 10. Similar considerations also pertain to the one or more servers 40, when they are sending obfuscated encrypted fragments back to the one or more user devices 30. Optionally, to avoid abuse by third parties desirous to eavesdrop upon the data system 10, routes of data flows of obfuscated encrypted fragments through the routers 50 are monitored and unexpected diversion of obfuscated encrypted fragments is flagged as a potential eavesdropping event, and one or more alternative data communication routes through the routers 50 and data links 20 are selected to thwart such eavesdropping. The data transaction system 10 is beneficially arranged to include one or more data nodes and a network, for example data communication network, linking the one or more data nodes. Moreover, the system 10 is operable to store user data by:

(i) dividing the user data into a plurality of data chunks; and

(ii) applying encryption to the data chunks and/or obfuscating the data chunks by swapping data between the data chunks, thereby provided corresponding encrypted and/or obfuscated data chunks; and

(iii) storing the one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map.

Furthermore, the membership data transaction system 10 is operable to retrieve user data by:

(iv) retrieving one or more encrypted and/or obfuscated data chunks at the one or more data computing nodes, wherein locations of the one or more data computing nodes whereat the one or more encrypted and/or obfuscated data chunks are stored are recorded in at least one data map;

(v) applying decryption to the data chunks and/or de-obfuscating the data chunks by swapping data between the data chunks, thereby provided a plurality of corresponding decrypted and/or de- obfuscated data chunks; and

(vi) combining the plurality of the decrypted and/or de-obfuscated data chunks to generate the user data.

Additionally, the data transaction system 10 includes a memory arrangement including a distributed database at a first data node, and a processing arrangement that is operable according to (i) to (vi) for storing and retrieving data. The processing arrangement is operatively coupled to the distributed database.

Steps of a method of operating the data transaction system 10 are illustrated in FIG. 6.

At a step Tl, the processing arrangement is configured to define, at a first time, a first transaction event linked to a first plurality of events; for example, each event from the first plurality of events is a sequence of bytes.

At a step T2, the processing arrangement is configured to receive, at a second time after the first time and from a second data computing node, a signal representing a second transaction event (1) defined by the second computing node and (2) linked to a second plurality of events; for example, each event from the second plurality of events is a sequence of bytes.

At a step T3, the processing arrangement is configured to identify an order associated with a third plurality of events based at least on a result of a protocol, each event from the third plurality of events being from at least one of the first plurality of events or the second plurality of events. At a step T4, the processing arrangement is configured to store in the distributed database the order associated with the third plurality of events. As aforementioned, the data transaction system 10 combines an asynchronous consensus/node ordering mechanism that functions within a public/non-permissioned network where network members are dynamic, namely temporally leaving or joining the data transaction system 10. Furthermore, the data transaction system 10 is capable of working within an encrypted decentralised data and communications network that utilises spare computing resources of users of the network. Additionally, the membership data transaction system can be used within any decentralised network requiring autonomous decision making including: decentralised app development platforms, corporate data networks, crypto currency and financial trading platforms, decentralised applications and gaming.

A proof-of-stake protocol is optionally used in the data transaction system 10. This allows the distributed database system 10 to correctly converge, for example, to a consensus, for example by employing voting amongst such honest active members. In some implementations, other members can join the distributed database system 10 and other individuals or entities can buy bitcoins, either directly from founding entities, or on an exchange. The system 10 can be open without permissioning requirements (e.g. without having to be invited to join by a founding member). Various criteria can be used within the system 10 to determine whether or not a given user, for example represented by a node of the system 10, is a trusted member or an untrusted member. When achieving a consensus for verifying a given transaction in a ledger, consensus voting amongst trusted members is employed in the system 10. Such criteria can, for example, relate to one or more of following: (i) a speed with which a given node is able to receive information related to transaction events affecting the ledger of the system 10;

(ii) a degree to which a given node has access to information indicative of events associated with transaction events occurring within the system 10;

(iii) a previous historical performance of a given node when earlier verifying one or more transaction events affecting the ledger of the system 10. When a given node or user couples to the system 10, the given node is initial treated as an untrusted node until its reliability can be established, wherein the untrusted node then becomes a trusted node and is then able to vote when providing a consensus regarding a validity of one or more entries made in the ledger of the system 10.

When a trusted node leaves the system 10, for example disconnects from its data communication network, the trusted node either transitions to become an untrusted node and then decouples from the system 10, or the trusted node simply disappears from the system 10 on disconnection therefrom.

The example systems described above are expected to create and/or achieve an efficient convergence mechanism for achieving a distributed consensus, with eventual consensus being attained, for example when modifying a ledger blockchain when transacting data representative of cryptocurrencies, for example bitcoiri.

Modifications to embodiments of the disclosure described in the foregoing are possible without departing from the scope of the invention as defined by the accompanying claims. Expressions such as " including ", " comprising ", " incorporating ", " consisting of', " have ", "/s" used to describe and claim the present invention are intended to be construed in a non- exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. Numerals included within parentheses in the accompanying claims are intended to assist understanding of the claims and should not be construed in any way to limit subject matter claimed by these claims.