Method and system for performing electronic transactions

Abstract

A method of performing an electronic transaction, comprising the steps of: a) a first user client (110) digitally sending transaction information to a first node (150), said transaction information comprising a first user predictable transaction counter, said counter being unique for the combination of said first user and said electronic transaction, and a user transaction state summary, said user transaction state summary being the output of a one-way function calculated based on previous electronic transactions registered with respect to said first user; b) said first node (150) validating said transaction information; c) said first node (150) digitally transmitting said transaction information to other nodes (160, 170) on an electronic transaction network consisting of such nodes; d) at least one of said other nodes (160, 170) validating said transaction information; e) verifying that at least a predetermined number of nodes have validated transaction information; f) registering a transaction based on said transaction information and digitally propagating information about the positive validation status of at least said predetermined number of nodes to all nodes (150, 160, 170) on said network.

Description

TECHNICAL FIELD

[0001] The present invention relates to methods and systems for performing electronic transactions. In particular, the present invention relates to such methods and systems for performing cryptographically linked such transactions, such as blockchain-based such transactions. BACKGROUND

[0002] There are many known ways to perform cryptographically linked electronic transactions today. Here, that a transaction is "cryptographically linked" means that the transaction in question is sealed using a cryptographic one-way function that is computed using the state of a previous transaction as input, effectively linking successive transactions to each other in a cryptographic chain that can be mathematically verified. Such a chain of transactions is generally considered secure and can be implemented in a distributed manner with high availability to the parties involved.

[0003] If a group of individual transactions are collected and signed at the group level, the chain of transactions is generally referred to as a blockchain.

[0004] One major problem with such chain-based transactions is transaction throughput. Major protocols such as Bitcoin, Ethereum, and Ripple (XRP) are generally associated with maximum throughputs that are too low to serve a large number of concurrent users. For example, some estimates suggest that the Bitcoin blockchain supports only the order of 10 transactions per second.

[0005] One reason for such low transaction throughput is that chain-based transaction protocols must provide effective protection against a type of fraud known as "double spending", in which a particular amount of value is paid from a consumer to two different recipients at the same time. To achieve this, many blockchain protocols use deliberately time-consuming or otherwise difficult tasks (such as the so-called "proof of work") in combination with consensus algorithms that guarantee that the entire network of blockchain nodes has indeed reached consensus on the current state of the blockchain.

[0006] Such proof of work often results in high energy transaction costs.

[0007] In addition to preventing double spending and providing high maximum transaction throughput, a chain-based transaction system should also provide short transaction verification and settlement times. For example, in the Bitcoin protocol, it is conventional practice to wait for a certain number of blocks, such as up to six blocks of "mining", before considering a transaction to be fully verified. This can take an hour or more, which is a relatively long time for the parties to a transaction to wait before the final verification is available.

[0008] In addition, a chain-based transaction system should provide full transparency to the users involved and full anonymity when required.

[0009] Such a chain transaction system should also be flexible, dynamically implementable and scalable, capable of expanding or contracting rapidly according to changes in user demand.

[0010] In addition to these requirements, in some cases, the functionality of a superuser should also be supported, so that a trusted central party, such as a central bank, can control individual transactions, such as preventing fraud and seizing funds, and ban certain participants.

[0011] Furthermore, in the event of fraud or any other inappropriate behavior, it is desirable to be able to safely roll back the chain of transactions. SUMMARY

[0012] The object of the present invention is to at least solve some of the problems mentioned above.

[0013] The present invention therefore relates to a method for performing an electronic transaction, comprising the steps of: a) a first user client digitally sending transaction information to a first node, said transaction information comprising a first user predictable transaction counter, said counter being unique for the combination of said first user and said electronic transaction, and a user transaction state summary, said user transaction state summary being the output of a one-way function calculated based on previous electronic transactions registered with respect to said first user; b) said first node validating said transaction information; c) said first node digitally transmitting said transaction information to other nodes on an electronic transaction network composed of such nodes; d) at least one of said other nodes validating said transaction information; e) verifying that said transaction information was validated by at least a predetermined number of nodes; f) registering the transaction based on said transaction information and digitally propagating information about the positive validation status of at least said predetermined number of nodes to all nodes on said network. BRIEF DESCRIPTION OF DRAWINGS

[0014] The present invention will be described in detail below with reference to embodiments thereof and to the attached drawings, in which:

[0015] Figure 1 is an overview of a system in which the method according to the present invention can be implemented;

[0016] Figure 2 is a flowchart illustrating the method according to the present invention;

[0017] Figure 3 is a flowchart illustrating the method according to the present invention as well;

[0018] Figure 4 the relationship between consecutive blocks is illustrated; and

[0019] Figure 5 is a flowchart illustrating the method according to the present invention as well. DETAILED DESCRIPTION

[0020] Figure 1 A system 100 in which the method according to the present application can be implemented is shown. The various components of the system 100 are interconnected via the Internet 101 or via any other suitable digital wide area network.

[0021] The system 100 comprises a plurality of computer clients 110, 120, 130, each of which is a physical general purpose programmable computing entity, such as a personal computer, a tablet computer or a smartphone, or a virtual general purpose programmable computing entity, such as a distributed or virtualized virtual computing resource. Each computer client 110, 120, 130 is configured to, e.g. on or from the hardware of said client 110, 120, 130, execute client software functionality which in turn is configured to perform the steps prescribed for the computer client 110, 120, 130 according to the present method. Such functionality includes, for example, communication with other entities, data processing / computing and storage.

[0022] Each computer client 110, 120, 130 is typically configured to allow one specific user to access the system 100 and, in particular, to request / perform the digital transaction which will be described in the following. Each computer client 110, 120, 130 can also be configured to allow the user to access and edit user account information from the account server 140 described below. In this regard, each computer client 110, 120, 130 can be configured to provide an interactive user interface to the respective user in question. Such a user interface can be, for example, an interactive graphical user interface presented on the screen display of the computer client 110, 120, 130 in question. The system 100 can also serve automated users and, in this and other cases, each client 110, 120, 130 can provide a digital interface such as an API (application program interface) through which commands and the like are accepted.

[0023] The computer hardware comprised in or configured to run on the computer clients 110, 120, 130 typically includes at least one CPU, at least one RAM memory and at least one computer bus.

[0024] The system 100 further comprises a computer account server 140 which can be of the respective type as described with respect to the computer clients 110, 120, 130. Thus, the account server 140 can be physical or virtual and configured to run specific account server software functionality which in turn is configured to perform the method steps prescribed for the account server 140 by the present method.

[0025] Generally, the account server 140 is configured to maintain a current resource account of at least one of the users. Such an account can be a financial account, holding some type of value in any currency, including digital currency, or any type of ownership share. The account server 140 can thus belong to a bank. However, in a preferred embodiment, the account is internal to the system 100, in the sense that the account server 140, including the account it holds, is an integral part of the system 100, not providing any external interface through which a third party can access the account information. For example, the account server 140 can be an integral functional part of each of the nodes 150, 160, 170, so as to not allow account changes without a vote by the nodes on such changes, as described below.

[0026] The account information is held in a digital database 141.

[0027] The system 100 further comprises a plurality of computer transaction nodes 150, 160, 170 of a corresponding construction with the computer clients 110, 120, 130. Thus, the nodes 150, 160, 170 each are associated with a respective node software functionality (in a manner corresponding to that already described with respect to the computer clients 110, 120, 130) configured to perform the present method steps with respect to the nodes 150, 160, 170. In particular, the nodes 150, 160, 170 are responsible for tracking, verifying, and registering the current type of digital transactions. Each of the computer clients 110, 120, 130 includes or is in contact with a respective hardware and / or software database 151, 161, 171, each in turn holding information about the digital ledger in which the transactions are registered, as will be described below. Each such database 151, 161, 171 can also include information about registered users in the system 100, including user identification information and user status information (see below).

[0028] The system 100 can include at least 5, preferably at least 10, interconnected nodes of the type described, each node participating in the voting process described below for a single transaction request. There can be no one-to-one association between the various nodes 150, 160, 170 and the various users. In other words, all nodes can serve all users of the system 100. Then, for each node 150, 160, 170, there can be multiple users, for example at least 10 users, or even at least 100 or at least 1000 users per node.

[0029] Each node 150, 160, 170 can store a partial or complete ledger for at least one user, or for at least some users, or even for all registered users. In particular, each node 150, 160, 170 can store a partial (“frontier state”, see below) or complete ledger for each user that is a party to a current type transaction. For each user for which information is stored, each stored ledger can include a complete set of transactions counting from the most recently registered transaction and running backwards in time until some respective earliest stored transaction. The case of partial ledgers is discussed in more detail below.

[0030] In general, each node 150, 160, 170 holds a digital ledger and additional information about users registered with the system 100 in a respective digital copy, and these separate copies are kept synchronized as an automatic result of the transaction processing process described below. Some nodes can need to hold the entire ledger (the entire transaction history), while other nodes can only need to hold a more recent set of transactions (e.g. the “frontier state” of the ledger, see below).

[0031] The nodes 150, 160, 170 together form a “network of nodes”, which can be interconnected over the public internet and can be configured to communicate with each other using well-defined interfaces and using encrypted channels to avoid eavesdropping.

[0032] In general, everything said here about the computer clients 110, 120, 130 applies equally to the described client software functionality. The same is true for the account servers / account software functionality, and for the transaction nodes / node software functionality. Each of the described entities 110, 120, 130, 140, 150, 160, 170 is equipped with a suitable digital communication interface for communicating with other system 100 internal entities and, as appropriate, with external entities. All communication described here can be encrypted, e.g. based on PKI (Public Key Infrastructure). Furthermore, all communication can be asynchronous, message-based communication between the respective entities involved. Thus, each entity can e.g. implement a message queue, processing each incoming message in order, resulting in sending certain actions and / or further messages (or response messages).

[0033] There can be several different account servers 140, each serving one or more users. As mentioned above, each node 150, 160, 170 can include account server 140 functionality. Furthermore, there can be any number of computer clients, e.g. at least 10 computer clients, at least 100 computer clients, or even at least 1000 computer clients.

[0034] Each registered user can use any of the clients 110, 120, 130 and can be identified to the system 100 (e.g. to the nodes 150, 160, 170 to which transaction information is sent) by means of a regular login or similar.

[0035] Figure 2 A method for performing electronic, digital transactions according to the present application is illustrated.

[0036] The method starts with a first step.

[0037] In a subsequent step, the first computer client 110 sends a transaction request including transaction information to the first transaction node 150 in digital form. The transaction information can be in the form of a message sent from the first client 110 to the first node 150 containing a set of information defining a transaction that the user of the first computer client 110 (the "first" user) wishes to register and perform.

[0038] The transaction can be a financial transaction, e.g. defining a specific currency value to be transferred into or out of an account held by the first user with the account server 140. However, the transaction can also define any other state change related to the first user and / or the first computer client 110 operated by the first user, e.g. a first user personal information update transaction; a first user key change or update transaction; or a first user addition or user deletion transaction (e.g. deletion of a specific user as an active user from the system at the initiative of a super user). See below for examples.

[0039] The term "transaction" as used herein will therefore be interpreted broadly as a digital defined, electronically communicated system 100 state change with respect to at least one identified user. Such transactions are typically verified by the system 100 (in particular by the nodes 150, 160, 170), registered in the ledger and performed. The performance can occur entirely in an internal manner of the system 100, e.g. by updating information or state information identifying the user stored in the databases 151, 161 and / or 171; or involve external parties, e.g. involve a funds transfer instruction to an external funds account.

[0040] In a preferred embodiment, the account server 140 is part of the system 100 and all transactions involving a value transfer are performed in relation to an account held and defined by the account server 140, whereby the performance of the transactions described herein does not involve the activation of any external value account holding entity. In other words, the value transferred as a result of the current type of transaction is in this case only performed between registered users of the system 100 through the interfaces provided by the clients 110, 120, 130. Furthermore, in this case, other types of transactions can be defined that involve external entities, e.g. external value deposit and withdrawal transactions.

[0041] The transaction information sent from the first client 110 to the receiving node 150 preferably defines the desired transaction completely to the system 100.

[0042] In particular, the transaction information comprises a first user predictable transaction counter, which is unique for the combination of the first user and the transaction. The counter "unique" means that two transactions initiated by a particular user are not identical. However, in some embodiments, the user transaction counter is not unique between several different users of the system 100, in addition to the first user requesting the transaction defined by the transaction information in question, there are different users.

[0043] The counter is "predictable" means that the receiving node 150 can explicitly predict the expected value of the transaction counter in question, using only at least one known previous transaction information and / or a registration transaction initiated by the same user (e.g. transaction information and / or a registration transaction of a previous transaction), in particular using the respective transaction counter value of such previous transaction information. For example, for each individual user, the transaction counter can be a respective simple monotonically increasing numerical counter (1, 2, 3...).

[0044] The transaction information further comprises a user transaction state digest. The user transaction state digest can be the output of a one-way function calculated based on at least one previous electronic transaction registered with respect to the same first user, preferably based on a plurality or even all such previous electronic transactions, in many cases at least based on the immediately preceding transaction registered with respect to the same first user. Furthermore, the user transaction state digest can be calculated as the output of a one-way function calculated based on the last transaction registered with respect to the requesting first user and also based on other previously registered transactions registered with respect to the same first user. For example, each user state can be calculated as the last result of a chain of one-way function calculations. In this and other examples, each user state digest can be calculated based in part on the value of a previous user state digest.

[0045] The one-way function can be any suitable one-way function requiring relatively few computational resources in calculating the result of the one-way function, but in fact which result of the one-way function is not sufficient to determine the input to the one-way function. Such one-way functions are well known and will not be described in further detail here.

[0046] However, the user transaction status summary can also be a summary calculated based on respective hash values of previous transactions registered with respect to said user, e.g. all such previously registered transactions. Such a hash can then be calculated using a predetermined function. The user transaction status summary can then be a simple exclusive OR (XOR) of respective hashes of each of said previous transactions registered with respect to said user, which XOR value can be updated with respect to each new transaction using the previous XOR value and the hash of the new transaction.

[0047] It is understood that the first node 150 in this example is a receiving node. However, any of said nodes 150, 160, 170 can in theory be a receiving node of a transaction request from any of said computer clients 110, 120, 130 initiated by any of said users. Different transaction requests can be sent to different receiving nodes 150, 160, 170.

[0048] In a subsequent step, the first / receiving node 150 confirms said transaction information. This confirmation can include verifying at least one, preferably a plurality, of the individual pieces of information in said transaction information. These verifications can relate to data stored by the first node 150, e.g. in a database 151. In particular, said verifications can be performed at least partially with respect to information stored in said ledger and / or a user-related synchronization file stored in each node 150, 160, 170 (see example below).

[0049] In case the confirmation is unsuccessful, e.g. at least one of said verifications results in a negative, the first node 150 will immediately reject the transaction request (“fast reject”), returning a failure message to the requesting client 150, without transmitting the transaction information to any of the other nodes 160, 170.

[0050] Otherwise, in a subsequent step, the first node 150 digitally transmits the transaction information received in said transaction request from the first client 110 to the other nodes 160, 170 on the electronic transaction network of these nodes. In a preferred embodiment, all nodes 150, 160, 170 participate in each transaction request at least as potential “yes” voters. That is, said other nodes 160, 170 and the first node 150 together constitute all nodes 150, 160, 170 on said network.

[0051] In a subsequent step, at least some, preferably all, of the other nodes 160, 170 each perform a positive or negative confirmation of the transaction information received from the first node 150, e.g. performing the same verifications as performed by the first node 150 in the previous step.

[0052] For each of the other nodes 160, 170, the result of the validation is positive (all verifications are positive) or negative (at least one verification is negative). The result can be returned to the first node 150 to verify the total number of positive validations from the nodes 150, 160, 170.

[0053] Thus, in a subsequent step, in the present exemplary embodiment, at least one of the other nodes 160, 170 validates the transaction information as described above.

[0054] Then, in a subsequent step, it is verified that at least a predetermined number of the first and other nodes 150, 160, 170 have validated the transaction information. The predetermined number can be an absolute number, or a certain percentage of the nodes 150, 160, 170 in the network, for example a percentage greater than 50%. In some embodiments, the predetermined number is at least 60% of the total number of nodes, or even at least 70% of the nodes 150, 160, 170 that must report a positive validation of the transaction information, in order to achieve a positive verification that at least the predetermined number of nodes have validated the transaction information. In the present example, the latter means that at least two of the three nodes 150, 160, 170 must report a positive validation of the transaction information.

[0055] It is noted that once the information is received that at least the predetermined number of nodes have validated the transaction information, the method can proceed to the next step without waiting for all nodes 150, 160, 170 to report their findings. For example, delayed reporting can be due to certain nodes being down, communication problems, etc.

[0056] In some embodiments, all other nodes 160, 170 report the result of the validation to one specific node, for example the first (receiving) node 150. It is then this specific node that verifies the validation. This provides a fast, flexible system 100. However, in many embodiments, the verification of the validation occurs at several different nodes, for example separately at all nodes 150, 160, 170. Such separate validation can then occur independently in each such node 150, 160, 170, and the transaction is then also registered in each such node. As used herein, the term “registered” in relation to a transaction can include executing the transaction, for example updating the account server 140 data, as well as updating the public transaction ledger, including the block state and the user state (see below).

[0057] If the result of the verification is negative, the transaction is thus rejected, and the rejection result is fed back to the requesting client 110, for example by the verifying node 150.

[0058] On the other hand, if the verification result is positive, in a subsequent step the verification node 150 registers the transaction based on the transaction information. This registration can include updating a local copy of the ledger (stored in the database 151) with the digital transaction and then committing the transaction. The registration of the transaction can also include the execution of the transaction, e.g. updating user information according to the transaction information or settling a financial transaction based on the transaction information.

[0059] The verification node 150 digitally propagates information about the positive confirmation status related to the transaction information of at least the predetermined number of nodes to all other nodes 160, 170 on the network of nodes.

[0060] The other nodes 160, 170 can then also register the transaction information in their respective locally stored information sets, including their respective locally stored copies of the ledger. In this way, the ledger will be kept synchronized between the nodes 150, 160, 170.

[0061] In particular, in response to the propagation of the verified positive (above threshold) votes from the receiving node 150, all nodes 150, 160, 170 can register the transaction and update their respective local information about the current first user transaction counter and first user state information. This updated information can then be used when performing the confirmation related to a subsequent transaction requested for the same first user.

[0062] With regard to the execution of the transaction, in particular in the case of an information updating type transaction, the execution (in terms of information updating) can be performed for each node locally stored information. If the execution requires interaction with an entity outside the network of nodes, e.g. a financial transaction involving an account of the account server 140, the execution is performed only once. In the latter case, the verification node 150 can perform the transaction, or a centrally arranged monitoring service can monitor the ledger and perform each financial transaction registered on the ledger.

[0063] In a subsequent step, the method ends.

[0064] In this way, a very flexible method and system 100 for handling, registering and executing digital transactions is achieved. The user can use any node to request a transaction, so a single receiving node propagates the received transaction information across the network of nodes. Then the very simple voting algorithm described above is automatically performed, and if a positive vote is confirmed, the transaction can be immediately registered and executed, with minimal delay. The voting algorithm also provides strong protection against double spending, as will be clear from the more specific examples provided below.

[0065] As all participating nodes 150, 160, 170 can arrive at a respective transaction information defining each requested transaction, each node 150, 160, 170 can keep an updated copy of the ledger at all times, the result being identical in the network of nodes, at least except for one or more transactions that were recently processed. In some embodiments, the nodes 150, 160, 170 can only differ in their “frontier state” (see below). Thus, the view of the global transaction history is always well-defined and sufficiently synchronized throughout the network of nodes (the nodes are at least in a state of mutual non-contradiction). Due to the mechanisms described herein, a transaction registered by one node will also be registered by the other nodes soon. In a sense, the true state of the ledger is determined by a majority vote among the nodes 150, 160, 170.

[0066] The same is true with respect to the user information files that are also kept synchronized among the nodes 150, 160, 170.

[0067] A very important aspect of the present invention is that the individual chain of transactions interconnected by the user transaction state summaries is automatically constructed and maintained by all nodes 150, 160, 170 for each individual user, independent of any blockchain structure involving transactions of multiple different users (see below). This user-specific chain structure enables the processing of each requested transaction in a very fast manner without losing reliability or security. This user-individual transaction chain can itself be seen as a lightweight blockchain, even though the individual transactions constituting this lightweight, user-specific blockchain can constitute part of the global blockchain (see below).

[0068] As mentioned above, the expected value of the first user transaction counter can be determined (and in fact also determined) deterministically from the previous first user transaction counter used in another first user-related transaction immediately preceding the currently requested first user-related transaction. In some embodiments, each node 150, 160, 170 on the network of nodes includes information about the previous first user transaction counter. The confirmation of the transaction information then includes verifying that the first user transaction counter provided in the received transaction information matches the expected value of the first user transaction counter by comparison with the stored previous first user transaction counter.

[0069] Each node 150, 160, 170 in the network of nodes can include information about the updated user transaction state summary. The local confirmation of the transaction information defining the requested transaction in each individual node 150, 160, 170 can then include verifying that the user transaction state summary provided in the transaction information in question matches the updated user transaction state summary in the confirming node 150, 160, 170 in question.

[0070] In very preferred embodiments, the system 100 and the nodes 150, 160, 170 are configured to register said type of transaction on a blockchain. Blockchains are well known and will not be explained in detail here. It is noted, however, that a blockchain is formed by collecting sets of transactions in blocks of transactions, each block containing a one-way function digest (e.g. hash) of a previous block, thus forming an easily verifiable chain of transactions over time.

[0071] That is, the method can in this case also comprise forming such verified and registered blocks of electronic transactions, each block being associated with a specific unique block identifier. The transaction information can then also comprise information about a unique block identifier associated with one of said blocks formed previously. The block identifier is "unique" in the sense that it is globally unique for the system 100, so that no two blocks have the same identifier. For example, each formed block can have as unique identifier a number in a deterministic and monotonically increasing series of numbers, e.g. a simple series of numbers 1, 2, 3, 4, etc.

[0072] Preferably, the transaction information is required to comprise information about a unique block identifier of a block that is explicitly defined in relation to the requested transaction, e.g. based on the currently formed block of registered transactions.

[0073] In some embodiments, the system 100 is arranged to form global blocks, in the sense that the formed blocks generally comprise transactions relating to different users, in this case relating to the first user, but also to one or several different users, e.g. at least also to a second user requesting a digital electronic transaction using the second client 160.

[0074] In some embodiments, one of said blocks formed previously, whose unique block identifier is comprised in the transaction information, is not the last formed block. For example, from the transaction information it can be possible to explicitly identify a block, in the case where the requested transaction would constitute a part thereof if it were registered. This identification can be based on system global information about the block currently being formed. Each transaction information can then be required to comprise a valid unique block identifier that identifies a block that is prior to a predetermined number of blocks, e.g. not the last formed complete block, but a block formed prior to the last formed complete block (see Figure 4 ). This information is then verified in said transaction information validation performed by each node 150, 160, 170 in said network of nodes.

[0075] In one particular example, the transaction information further comprises information on a global, preferably synchronised between the nodes 150, 160, 170, transaction timeline, which is used by the first node and the other nodes to determine to which block the electronic transaction belongs. For example, the global transaction timeline can be the number of milliseconds since January 1, 1970, independently used by each node 150, 160, 170, in combination with a specific predetermined block formation / closing time frequency, for example once every 30 seconds, to determine the current block, and thus also a specific closed block a predetermined number of blocks (for example two) back in time.

[0076] In some embodiments, the sending client 110 can time stamp the transaction in question using this global transaction timeline, and the processing nodes 150, 160, 170 can then only verify this time stamp, with the aim of voting "no" if the time stamp differs from the expected time stamp based on the internal clock of the other node in question by more than a predetermined number of seconds.

[0077] Thus, each block can collect all transactions requested within a specific predetermined time period as a timestamp on each respective transaction provided by the sending client 110, 120, 130. Thus, in this case, each block does not contain a predetermined number of transactions, but is defined by said common timeline. The time period can preferably be at most 1 minute, preferably at most 10 seconds, preferably at most 5 seconds.

[0078] Furthermore, the transaction information defining the transaction request can comprise a block state information or block state summary, for example in relation to the same previous block identified by said unique block identifier, which is also included in the transaction information.

[0079] In a manner corresponding to the user transaction state summary discussed above, the block state information can be calculated as a one-way function or even a chain of one-way functions (as described above for the user transaction state summary). It can also be an XOR type summary, calculated from the respective explicitly defined hash value of each verified electronic transaction (also in relation to other users), forming part of the block in question, for example the XOR of said hash values.

[0080] The block state information can also be calculated (for example using a one-way function or an XOR type summary of the type described) from the block state information and / or the respective explicit hash value of each verified electronic transaction forming part of the previous block, for example the immediately preceding block. In this way, a blockchain can be constructed in which the block state of each block is calculated based on all previous blocks, in particular all previously verified electronic transactions forming part of all previous blocks.

[0081] In addition to the above-mentioned verification of the user transaction counter; the user transaction status summary; and the block status summary, other verifications that can be included in the validation of the transaction information performed by each of the nodes 150, 160, 170 in the network of nodes includes verifying that the first user making the request is authorized with respect to the electronic transaction. Such authorization can be based on first user information previously stored in the first node 150 and the other nodes 160, 170, and can, for example, be with respect to whether the first user is authorized by the system 100 to perform the type of transaction to which the requested transaction belongs. Such authorization can in turn be based on user type information stored by each of the nodes 150, 160, 170 in the network.

[0082] In addition, such other verifications can also include verifying the authenticity of the first user signature included in the transaction information. That is, prior to sending the transaction request to the first node 150, the first user can be required to sign the transaction information using a private key (e.g., the private key in a public-private PKI key pair). The validation performed by all of the nodes can then include verifying that the signature was in fact made using the private key using the corresponding public (known) key of the first user.

[0083] Many of these checks can result in a quick rejection by the receiving node 150 prior to the transaction information being propagated to the other nodes 160, 170.

[0084] Likewise, if any of the above-mentioned verifications fail, the validation by that node is negative.

[0085] In some embodiments, each of the first node 150 and the other nodes 160, 170 (e.g., all of the nodes in the network) includes a respective first user operation counter reference for a respective different set of different types of operations that can be initiated by the user with respect to the node and with respect to the same first user making the request. In this context, each such operation is initiated by requesting a corresponding type of and as described above corresponding transaction. Examples of such operation / transaction types include “transfer funds to / from account X”, “update user public key”, and “update user identification information”.

[0086] Each of the first user operation counter references is then configured to reference a particular respective value of a corresponding one of the first user transaction counters. Preferably, each such user operation counter references a particular one of the first user transaction counters storing a value that identifies the last registered transaction of the particular transaction type by the same first user.

[0087] The registration of transactions performed by all nodes 150, 160, 170 can then also include the discussed nodes updating one or more related references in the first user operation counter references (stored by the nodes) depending on the type of operation or operations that the transaction represents. Thus, in this example, the set of user operation counter references is not used for transaction confirmation, but is only updated as a result of the registration of each transaction after the final verification of the transaction in question.

[0088] Once such user operation counter references are stored in the nodes 150, 160, 170, they can be used to very quickly recover a failed node. This method of failure node recovery is illustrated as Figure 3

[0089] The method starts in a first step that can be performed before the method illustrated in Figure 2

[0090] In a subsequent step, it is determined, e.g. by at least one of the nodes 150, 160, 170 in the network of nodes, that a particular node has failed. Such a failure can include the particular node becoming unresponsive, being detected as faulty or hacked (see example below) or similar. The detection can be made by any other node.

[0091] In a subsequent step, the particular node is started, e.g. newly installed and / or restarted. At this point, the node in question can be the recovered node that previously had its failure detected. However, for a newly started node, the same method steps can be performed as described below.

[0092] In a subsequent step, the particular node reads the previously stored and preferably (but not necessarily) updated first user transaction state summary, as well as the previously stored and preferably (but not necessarily) updated blockchain state summary. This reading can be performed from any other node, or from a previously stored backup made by the particular node itself before the failure. The information read can include one or several of the information types described in example 7 below (the "frontier state").

[0093] In connection herewith, the particular node also reads the updated set of first user operation counter references for the particular one, more or all users registered with the system 100. This reading is performed from a different one of the nodes 150, 160, 170 in the network, which is first set to a temporary read-only mode.

[0094] ​​Thus, the particular node can read the following defined type of frontier state from a different node that can have been first set in a temporary read-only mode. More generally, the particular node can read a minimised state from a different node that can have been first set in a temporary read-only mode, which is much smaller than the entire ledger, but still sufficient to continue operation (the minimised state can be the frontier state).

[0095] In a subsequent process, the particular node can use the first user operation counter reference set for validation to verify that the first user information stored by the particular node is up to date. This verification can be done on the basis of the value of each individual user operation counter reference, determining how far back in the transaction history the user-specific information must be complete. If necessary after such a check, the particular node can request updated such first user information from any other node.

[0096] Thus, the ledger held, maintained and updated in the respective identical copy of each of the nodes 150, 160, 170 of the network of nodes is a ledger run by different, trusted, non-hierarchical nodes 150, 160, 170. As mentioned above, these nodes 150, 160, 170 approve or reject operations by voting. If a certain number or percentage of participating nodes 150, 160, 170 (e.g. a qualified majority of nodes) approve an operation, then all nodes will commit the operation. Otherwise not. Unlike many traditional blockchain cryptocurrencies, each node does not approve a block of transactions, but rather individual operations / transactions. Thus, a user can get almost immediate confirmation of whether a particular requested operation was approved or rejected by the network of nodes 150, 160, 170.

[0097] Reference Figure 4 and Figure 5 Examples of the method according to the application will be described below.

[0098] Thus, the current type of transaction request is an operation of a user previously registered in the system, defining an operation to change the public ledger. As mentioned above, such an operation can be a monetary transfer of a share of funds, or an operation to change information about a user. Note that all such information targeted by the operation is typically stored by each node 150, 160, 170 in the respective synchronised copy held by each node 150, 160, 170.

[0099] The transaction information in the present example comprises the following data. Typically, such data is provided by the client 110, 120, 130 or user and verified by each node 150, 160, 170 involved:

[0100] requesting_user: information identifying the user requesting the operation.

[0101] operation_user: The user that operated the transaction, usually the requesting_user. But it can also be the case that a level user locked the user's account for suspicious activity.

[0102] counter: The number of operations this user has submitted previously plus one.

[0103] epoch_ms: The number of milliseconds since UTC 1970-01-01T00:00:00.

[0104] block_id: int(epoch_ms / 30000) (Note that the current block is defined directly by the current time).

[0105] ref_block_id: block_id minus two.

[0106] user_state: The XOR of the hashes of the individual payloads of all previously submitted operations on operation_user.

[0107] ref_block_state: The XOR hash of all operations (registered transaction information) up to the operations engraved on the block until the block identified by reference_block_id.

[0108] Note that in some types of transactions, for example of the transfer type, multiple users can be involved (for example the sending and receiving users). However, for the purposes of the present invention, it is the operation_user that defines for which user the transaction in question is executed. Preferably, each transaction is executed for only one user.

[0109] In this example (see Figure 4 ), the block size is 30 seconds and the reference block is the current block id minus two. In alternative examples, other configurations can be used, for example a block size of 1 millisecond and a ref_block_id that is 30000 blocks behind the block_id. In other words, in such an example block_id = epoch_ms and reference_block_id = block_id - 30000.

[0110] Figure 5 A more detailed scheme of the processing of the requested transactions is shown. The transaction requests can be sent to any of the nodes 150, 160, 170. Each node processes incoming sets of transaction information in two different but similar modes - it either receives a transaction request from a user or it receives transaction information from another node (for example a node that received a user request).

[0111] First, for incoming transaction information, some aspects are verified.

[0112] 1. Is the operation defined by the transaction information new to the node in question, or has the node already received the transaction information?

[0113] 2. Are the transaction counter, transaction timestamp, user_state and ref_block_state all correct (as expected)?

[0114] 3. Is the operation valid and correctly signed, and does the requesting_user have the privilege (be authorized) to perform the operation?

[0115] 4. Has the user already no pending operations?

[0116] If any of the checks 1, 2, 3, 4 above fail, one of the following two cases occurs. If the node in question receives the transaction information from another node, the node in question votes against, and the sending node is also informed of this vote. On the other hand, if the node in question receives the transaction information from the user (the node in question is the receiving node of the transaction request), the transaction is quickly rejected, and the node in question does not perform any more work, and the transaction information is not distributed to other nodes.

[0117] In this and other embodiments, when the nodes 150, 160, 170 send a proposed transaction between them, they attach their respective votes to the information passed. This means that each node 150, 160, 170 can already know from the received transaction information whether the node was contacted as a first transaction receiving node (receiving the transaction request from the client 110, 120, 130) or as a secondary node (receiving the transaction information from another node 150, 160, 170). Preferably, the voting information is added to the transaction information sent by the sending node, and the resulting information is signed by the voting node. The public key corresponding to the private key used for this signature is available on the public ledger, which is why a client cannot deceive such a vote by cryptographic means. If the first node receiving the transaction would vote "against" and there is no voting information in the received transaction information, the first node will quickly reject instead of asking other nodes to consider the transaction.

[0118] On the other hand, if all checks 1, 2, 3 and 4 are passed, the processing node votes in favor and propagates information about this vote to other nodes, for example by sending nodes.

[0119] If the transaction request defines a transfer of money or other funds, the relevant account from which the funds are to be transferred is checked for the presence of sufficient funds. If this is not the case, the receiving node can again quickly reject the transaction.

[0120] The receiving node then signs the transaction information and submits the user as a user waiting for an in-progress transaction.

[0121] Thereafter, the votes are collected and held by the receiving node. If a predefined threshold of votes in favor is passed, the transaction is committed. The voting or approval status is sent by the receiving node to the other nodes.

[0122] All nodes then check whether the transaction was approved in the voting. If this is not the case, the user is in a pending state and the transaction is rejected (by at least one node, for example the receiving node) back to the client 110 used by the user to request the transaction.

[0123] If the transaction is approved, one of the following two cases occurs.

[0124] In the first case, the transaction request is an "document change" type of operation, in other words the transaction information defines an operation to save one or more documents containing user information. For example, the transaction information can specify "this is my new phone number" or "this is my new public key". The system 100 preferably has a defined set of possible such documents and there can be a list of allowed document types (see below).

[0125] After the operation is registered and / or executed and thus the user is not pending, the operation counter is updated to the block state and the user state. Then, a transaction approval is sent, for example to the requesting user. Multiple such transaction approvals can be sent by different processing nodes.

[0126] As mentioned above, the system 100 can define multiple types of documents, possibly including the following types:

[0127]

[0128]

[0129] Thus, each of the nodes 150, 160, 170 can keep each of these files, which are kept synchronized by all nodes 150, 160, 170 that process all transactions requested and passed through the system 100.

[0130] In particular, with respect to the user transaction counter included in the transaction information received in the requested transaction and in the transaction information circulated between the nodes 150, 160, 170, the parameter forces the execution of operations on a specific user in a well-defined order. If each node 150, 160, 170 has a different opinion about the expected value of the current counter, it rejects the operation. For example, if a user has four previously registered transactions and a new transaction request is sent for the same operation_user and specifies counter = 7, the transaction request will be rejected. If two different operations are sent for the same user, both specifying counter = 5, at most one of them will be approved by the majority of the voting nodes 150, 160, 170. As a result, the voting mechanism according to the present application will automatically handle the double-spending rejection on a single transaction basis.

[0131] Thus, the counter parameter contained in each transaction information orders the operations of a given user, without ordering the operations of different users (related to each other). In fact, it is preferred that no internal order between the transactions performed for different registered users is defined in the system 100. This actually provides a more efficient system 100, since all the orders in one and the same block do not need to appear in any particular order.

[0132] With particular reference to the parameter user_state, this parameter is also contained in the received transaction information and circulated between the nodes 150, 160, 170. Using this parameter, the node majority and the user (with respect to the object of the executed transaction) are forced to agree on the entire state of the user's history. This makes the system 100 cryptographically impossible to cheat the user in question. Even if the rest of the ledger is hidden from the user, the user can verify that the state of its history is not corrupted.

[0133] With particular reference to the ref_block_state parameter, this parameter is also contained in the received transaction information and circulated between the nodes 150, 160, 170. Using this parameter will ensure that the node majority agrees on the block state, returning two steps (or how far the distance is from the reference block used). This will happen without negotiation between the nodes 150, 160, 170 and will be handled in the normal voting process.

[0134] In particular with respect to the type_counter, which is an internal parameter to a node, it is not distributed between the nodes 150, 160, 170 during normal processing of transactions, but can be communicated to a node that is initialized as described above. Each of the nodes 150, 160, 170 maintains a history of the type_counter for each user. In particular, the type_counter is a mapping for each user that indicates the type of operation that the relevant user requested for each counter (what was the value of the user transaction counter when the relevant user last requested a transaction of that type). Here is an example of a particular user whose current operation counter is 5:

[0135] Counter "ReadAuth": 2

[0136] Counter "VerifiedUserInfo": 3

[0137] Counter "WalletHolder": 4

[0138] Counter "WalletRef": 5

[0139] Counter "WriteAuth": 1

[0140] last_epoch_ms: 1548590802702

[0141] operation_counter: 5

[0142] user_id: "bcPImBotUSuNKKGox31lLA=="

[0143] For example, in this data we can read that the user last changed their WriteAuth (encryption key) at counter 1. This information can be used to perform an effective recovery.

[0144] Using some or all of the parameters specifically described above, the inventors have found that this type of system 100 can achieve a throughput of 100,000 transactions per second, or even higher. This is much more than is known for conventional digital transaction systems, such as using the Bitcoin protocol.

[0145] In the method according to the invention, there is no need to wait for a negotiated block before submitting a transaction. If the transaction is approved in the voting procedure, the registration will be submitted immediately and possibly followed by subsequent execution. In the example of a currency transaction involving a deposit of currency in digital storage, the round-trip transaction time will typically be less than a second, and then the recipient can use the currency. Confirmation is much faster for the relevant user.

[0146] Furthermore, each user can only see actions relevant to that user. Because the `user_state` parameter is updated for each transaction, a user can detect and prove whether the system is trying to deceive her, even if she cannot see the entire ledger.

[0147] Due to the individual approval of transactions on each voting node (150, 160, 170), and further due to the fact that there is no negotiation among the nodes in the ref_block_state (it's simply a result of transactions being voted "yes" and thus committed), the protocol according to this method can also run at high transaction speeds. With high-performance hardware, a throughput of 1 MTPS should be unattainable. The separate voting process also enables horizontal scalability for each of the 150, 160, 170 nodes.

[0148] Furthermore, the method according to the invention has the potential to increase support for superuser capabilities, which may be necessary for control. For example, in the case of a setup where assets traded in the current type of transaction are stored in a closed system by the account server 140 (as described above), the ability to allow control instances to lock or seize assets is easily implemented.

[0149] Example 1: Processing transactions normally without rejection

[0150] In this example, the user sends a payment request to node #1. The following table shows the selection steps and data flow:

[0151]

[0152]

[0153] Example 2: Transfer Operation

[0154] In this example, a request is made to transfer an amount of 100 from the first wallet "1" to the second wallet "2".

[0155] A transaction request might look like this (pseudocode):

[0156]

[0157]

[0158] When receiving node 150 receives a transaction request containing this transaction information, it performs the following verification:

[0159] 1. The current user counter for user "test" is "3".

[0160] 2. User "test" has no pending operations.

[0161] 3. The node's current time is not far from epoch_ms.

[0162] 4. The wallet "1" belongs to the user "test".

[0163] 5. The balance of the wallet "1" is at least 100.

[0164] 6. The given epoch_ms actually belongs to the block with block_id "28".

[0165] 7. The block_id reference to the block "28" actually is the block "26".

[0166] 8. The block_state of the block "26" actually is "11111111...".

[0167] 9. The user_state of the user "test" actually is "10101010...".

[0168] 10. The payload_hash actually is "11110000...".

[0169] 11. The proof "0001001" is a valid signature of the user "test".

[0170] When any of the nodes 150, 160, 170 collects a total number of votes showing more than a threshold approval for the requested transaction, the collecting node performs the transaction processing in the following operational steps:

[0171] 1. Move the amount 100 from the wallet "1" to the wallet "2".

[0172] 2. Update the counter of the user "test" from "3" to "4".

[0173] 3. Set the user state to the XOR of the previous user state and payload_hash.

[0174] 4. Set the block_state of the block_id "28" to the XOR of the previous block_state of the block "28" and payload_hash.

[0175] Thus, for a successful transaction, these steps are performed by each node 150, 160, 170 in the network using the respective local information of the node in question at the time. However, these steps can be performed by different nodes at different points in time, depending on the flow of information in the network.

[0176] Before and after the full processing of the registration transaction, the state in each node 150, 160, 170 is as follows table:

[0177] Object Before transaction After transaction block_state (26) 11111111... 11111111... block_state (28) 01010101... 10100101... user_state 10101010... 01011010... user_counter 3 4 Balance wallet "1" 100 0 Balance wallet "2" 100 200

[0178] Example 3: Admin writes user information

[0179] In this example, an admin user (which is a semi-super user with the right to perform certain operations on other users) updates the user information stored in the synchronization file mentioned above.

[0180] The transaction request can look like this (pseudo code):

[0181]

[0182]

[0183] When the nodes 150, 160, 170 verify the operation and approve it by voting, each node will execute the operation (register / execute transaction) by performing the following steps:

[0184] 1. Write the information under the data clause into the user_info document belonging to the user "EZ2j...".

[0185] 2. Update the user counter from "28" to "29".

[0186] 3. Update the user_state in the same way as in example 2 (above), but use the payload_hash in this operation.

[0187] 4. The block id is handled in the same way as in example 2.

[0188] Example 4: Double spend transaction

[0189] In this example, a user tries to cheat the system 100 by sending two payment instructions with the same counter to all nodes, hoping that both payments will go through.

[0190] The table below shows the selection steps and data flow:

[0191]

[0192]

[0193] Example 5: Hacked node, double spend, grid collapse

[0194] Here, the user attempts to cheat the system 100 by sending two payment instructions with the same counter to all nodes 150, 160, 170, hoping that both payments will go through. This time, the user gets the help of node 2, which has been hacked to approve all requests. Thus, in this case, node 2 does not work as it should according to the invention, but has been illegally modified.

[0195] The following table shows the selection steps and data flow:

[0196]

[0197]

[0198] Example 6: External withdrawal, private payment use case

[0199] This example illustrates schematically how the system 100 can provide for private payments (payer identity known to the system 100 but not to the payee). Here, an external user (e.g. an online news media) has been authorized to withdraw funds on behalf of unknown users with limited powers, e.g. to pay for access to individual news articles.

[0200]

[0201]

[0202] Example 7: The "frontier state" of the ledger

[0203] Each node 150, 160, 170 is configured to (and at least some of them will) hold every transaction in the transaction history of the system 100, in order to recreate the entire history and prove the state of the ledger when challenged. However, in order to be able to operate as a functioning node in the system 100, and approve / reject individual transactions, only a small fraction of that state is needed.

[0204] For example, assume that the user has updated her public key contained in the write auth document 100 times previously (in respective prior registered transactions). When a new transaction request from the same user is issued, only the current (last) version of write auth is relevant when looking at the verification of this transaction signature.

[0205] The case is similar for a particular wallet. If the balance of the wallet is 1000, then the order of operations leading to this exact balance is not important, and when the user wants to transfer 100.0, it is important that there are enough funds in the wallet to support such a transaction.

[0206] Thus, each individual node 150, 160, 170 only needs the following information in order to recover operations from a particular point in time, and continue processing transaction information:

[0207] 1. The latest version of each document in the ledger

[0208] 2. The balance of each wallet

[0209] 3. The last two block states in the system block size configuration or the number of last block states (but at least two last block states)

[0210] The information in the above points 1-3 is referred to as the "frontier state" of the system 100. Note that the "frontier state" information is significantly less than the entire ledger. That is, the entire ledger size is roughly O(time*#users) and the frontier state is roughly O(#users).

[0211] Then assume that the node 160 has been down for a long time and the rest of the nodes 150, 170 have approved and executed a large number of transactions in that down time. One way to recover the node 160 is to recover the transactions from the last known state before the node 160 went down. If this strategy is followed, it will take a long time to catch up to the node 160. Instead, another node 170 can be manually stopped so that it does not respond to any incoming transactions. Then, this other node 170 can save its frontier state and send this information to the non-updated node 150. After this operation, both nodes 160, 170 can resume operations from this state. Depending on the configuration of the system 100, from this state, the nodes 160, 170 can be only about 1-2 minutes behind the other nodes 150, so fast catch-up is feasible.

[0212] In addition, all nodes 150, 160, 170 are configured to ask each other (through the digital interface discussed above) about all transactions that occurred in a particular block. Thus, if a particular node is only a few blocks behind, it can ask another fully up-to-date node about the transactions in those blocks. Then, the catch-up node in question can start registering those operations on its ledger and perform document updates as appropriate. As long as the catch-up node is faster than incoming transactions, it will update relatively quickly.

[0213] By using the above frontier state functionality and the following block operation requests, each node 150, 160, 170 is able to catch up quickly after various lengths of downtime. The same mechanism can also be used when recovering a hacked node that has entered a broken state (as in example 5 above). Using this example 5, the manual recovery process can look like this:

[0214] 1. Stop all operations on all nodes.

[0215] 2. Ignore the hacked node.

[0216] 3. Recursively delete operations that get majority vote approval but any non-hacked guest node rejects execution (in the case of example 5, there are two such operations, i.e. two double spends of the same operation counter).

[0217] 4. Verify that the block_state of all non-hacked nodes is the same.

[0218] 5. Wipe clean the hacked nodes.

[0219] 6. Save the frontier state of one of the non-hacked nodes and put it in the database of the hacked nodes.

[0220] 7. Resume operations.

[0221] 8. Contact the payees from the two double spend operations that will get a valid receipt of payment without having to credit the respective account balances in the restored version of this ledger.

[0222] 9. Negotiate potential compensation to these users depending on the value they sent due to (in this case) proof of payment corruption.

[0223] Such a process can be performed by a control entity or node (not shown in Figure 1 which has superuser status relative to all other nodes.

[0224] Some important aspects that can be used in the present invention include the following.

[0225] First, the user operation counter is included in every transaction request sent to the system 100.

[0226] Second, the user state is included in every transaction request sent to the system 100.

[0227] Third, the system (block) state can be included in every transaction request sent to the system 100.

[0228] Fourth, every user has a separate blockchain (as described above) where each block can contain only one operation / transaction.

[0229] Fifth, the system 100 can keep a current and historical ledger of type counters.

[0230] Sixth, any node can go offline for a while and come back online and produce a frontier state consistent with itself and then resume operation based on that frontier state information. The frontier state is much smaller than the entire state and can be used by other nodes to resume operations.

[0231] The above has described preferred embodiments. However, it will be obvious to a person skilled in the art that many modifications can be made to the disclosed embodiments without departing from the basic idea of the application.

[0232] For example, many other features than those described herein can be implemented in the system 100 configured to perform the method according to the application.

[0233] Generally, the various aspects of the different examples provided herein are freely combinable. Each of these examples has been chosen to highlight certain important aspects of the application.

[0234] The application is therefore not limited to the described embodiments, but can vary within the scope of the appended claims.

Claims

1. A method for performing an electronic transaction, comprising the steps of: a) a first user client (110) digitally sending transaction information to a first node (150), said transaction information comprising a first user predictable transaction counter, said counter being unique for the combination of said first user and said electronic transaction, and a user transaction state summary, said user transaction state summary being the output of a one-way function computed with respect to at least the immediately preceding electronic transaction registered by said first user; b) said first node (150) acknowledging said transaction information; c) said first node (150) digitally communicating said transaction information to other nodes (160, 170) on an electronic transaction network consisting of such nodes; d) at least one of said other nodes (160, 170) acknowledging said transaction information; e) said first node (150) and one or more of said other nodes (160, 170) verifying that at least a predetermined number of nodes have acknowledged transaction information; f) said first node (150) and one or more of said other nodes (160, 170) registering a transaction based on said transaction information and digitally propagating information about the positive acknowledgement status of at least said predetermined number of nodes to all nodes (150, 160, 170) on said network, wherein each of said first node (150) and other nodes (160, 170) comprises information about a previous first user transaction counter and about an updated user transaction state summary, and said acknowledging said transaction information comprises verifying that said first user transaction counter matches its expected value by comparing it with said information about a previous first user transaction counter and said information about an updated user transaction state summary in said all nodes (150, 160, 170), and verifying that said user transaction state summary matches said updated user transaction state summary; and wherein said user transaction state summary is computed as the last result of a chain of one-way function computations, so that said all nodes (150, 160, 170) automatically build and maintain for each user an independent chain of transactions connected to each other by user transaction state summaries.

2. The method of claim 1, wherein the expected value of said first user transaction counter can be determined from an electronic transaction immediately preceding said electronic transaction using said previous first user transaction counter.

3. The method of claim 1, wherein said first user transaction counter is not unique among a plurality of different users existing in addition to said first user.

4. The method of claim 1, wherein said user transaction state summary is computed as the output of a one-way function computed with respect to a last electronic transaction registered by said first user and also with respect to other previous electronic transactions registered by said first user.

5. The method of claim 4, wherein the user transaction state summary is computed as an output based on a one-way function computed with respect to all previous electronic transactions registered by the first user.

6. The method of claim 1, wherein in step e the verification is negative and wherein the electronic transaction is therefore rejected.

7. The method of claim 1, wherein in response to the propagation in step f, the all nodes (150, 160, 170) register the transaction and update their respective information about the current first user transaction counter and the updated first user transaction state summary for use in performing step d in connection with a subsequent electronic transaction related to the first user.

8. The method of claim 1, wherein the method includes forming a verified electronic transaction block, wherein each block is associated with a particular unique block identifier, and wherein the transaction information further includes information about a unique block identifier associated with one of the blocks previously formed.

9. The method of claim 8, wherein at least one of the blocks includes transactions related to the first user and to a different second user.

10. The method of claim 8, wherein one of the blocks previously formed is not the last block formed.

11. The method of claim 8, wherein the transaction information further includes information about a transaction timestamp used by the first node (150) and the other nodes (160, 170) to determine to which block the electronic transaction belongs.

12. The method of claim 8, wherein the transaction information further includes block state information.

13. The method of claim 12, wherein the block state information is computed based on a respective hash value of each verified electronic transaction that forms part of the block.

14. The method of claim 13, wherein, The block state information is computed based on an exclusive or of the hash values of each verified electronic transaction that forms part of the block.

15. The method of claim 13, wherein the block state information is further computed based on block state information of a previous block.

16. The method of claim 1, wherein the confirming the transaction message further includes verifying that the first user has obtained authorization for the electronic transaction based on first user information previously stored in the first node (150) and other nodes (160, 170).

17. The method of claim 1, wherein the transaction information further includes a first user signature, wherein the confirming the transaction message further includes verifying the authenticity of the first user signature.

18. The method of claim 1, wherein the first node (150) performs the verification in step e.

19. The method of claim 18, wherein the all nodes (150, 160, 170) individually perform the verification in step e.

20. The method of claim 1, wherein each of said first node (150) and other nodes (160, 170) comprises a respective first user operation counter reference for a set of different types of operations that the user can initiate against all nodes (150, 160, 170), each of said first user operation counter references being configured to reference a particular respective one of the values of the transaction counter of the first user, wherein said registration transaction in step f comprises one or more of said all nodes (150, 160, 170) updating one or more of the relevant ones of said first user operation counter references according to one or more operations of said electronic transaction representation.

21. The method of claim 20, wherein said method comprises a step of initiating a particular node, in which said particular node reads a frontier state from a different node than said particular node, said different node possibly having been first set to a temporary read-only mode.

Images