WO2020065242A1

WO2020065242A1 - Method and system for transaction processing in decentralized network by network nodes in collaborative decision-making

Info

Publication number: WO2020065242A1
Application number: PCT/GB2018/052755
Authority: WO
Inventors: Igor Chugunov; Eugeniy BUTYAEV
Original assignee: C S Solutions Technology Limited
Priority date: 2018-09-27
Filing date: 2018-09-27
Publication date: 2020-04-02

Abstract

The present invention relates to the tools for generating and executing transactions in a decentralized network. More particularly, the invention relates to the transaction generation and execution tools in group collaborative decision-making by the nodes of a decentralized network associated, e.g., with the platform underpinning the blockchain transaction environment or the platform behind the smart contract environment. The invention contributes to more efficient generation, execution, validation, and verification of transactions in a decentralized network, where any decisions made by the decentralized network nodes in respect of transactions are acceptable to any and all network nodes. In one embodiment, the invention represents a method comprising clubbing a set of nodes into a network; initiating a ledger containing information about one or more transactions; saving such ledger; selecting a number of nodes and entrusting one of such nodes with the validation and verification of the most recently generated transaction pool in a decentralized network; building the node list by adding a set of nodes containing an updated ledger on the node entrusted with recording the latest block; randomly selecting the main node and trusted nodes from the node list; verifying transactions on each trusted node; validating one or more candidate transactions; generating a new block to be recorded in the ledger, which represents a verified and validated transaction pool; selecting a new recording node in order to record the new block in the ledger.

Description

METHOD AND SYSTEM FOR TRANSACTION PROCESSING IN DECENTRALIZED NETWORK BY NETWORK NODES IN COLLABORATIVE

DECISION-MAKING

The present invention relates to the tools for generating and executing transactions in a decentralized network. More particularly, the invention relates to the transaction generation and execution tools in group collaborative decision-making by the nodes of a decentralized network associated, e.g., with the platform underpinning the blockchain transaction environment or the platform behind the smart contract environment.

There are currently known technology solutions which implement group collaborative decision-making in a decentralized network.

Examples include the collaborative decision-making algorithm known as DPoS (Delegated proof-of-stake), which is an alternative consensus algorithm for a decentralized environment.

The above-mentioned algorithm, similarly to the claimed solution, is employed in the generation and execution of transactions in a decentralized environment.

Generally, the underlying principle of DPoS operation can be expressed as distinguishing between the voting and validating peers/nodes of the decentralized environment. That said, the nodes nominated in the algorithm as eligible to vote in system voting have no right to validate transactions. Consequently, in this case, one subset of nodes (eligible to vote) and the other subset of nodes (eligible to validate transactions) select the third subset which in turn has a vested right to generate transaction blocks.

In this algorithm, validator nodes need to connect, fulfill specific verification conditions, and declare their readiness to maintain continuous work, the ability to verify transactions and generate new blocks in a timely manner.

Pursuant to the rule applicable to the consensus process execution, every node is entitled to put itself forward as a candidate for validator node. Then all nodes vote for candidates, with the weight of every vote depending on the sum of the voter node’s assets.

Once the voting is complete, the results of votes are used to select a limited natural number of candidates which may be eligible to generate new transaction blocks. Specific rules of procedure apply to guarantee correct decision-making if most assets of the nodes that participate in voting are controlled by honest nodes.

The validator nodes selected via voting are mixed in a pseudorandom manner, thus forming a queue. Mixing is performed such that the queue cannot be predicted beforehand but appears identical to all honest nodes of the network. This is followed by establishing the period of time during which each of the validator nodes must generate one queue block. Every validator node is given a limited time interval. Accordingly, in one scenario the validator node manages to validate new transactions and generate a new block based on the previous one, failing which (unless the validator node completes the task in the preset interval) this operation is entrusted to the next validator node in the queue. When the preset time has elapsed, validator nodes get mixed up, thus forming a new queue.

In the above-mentioned algorithm, stakeholder nodes can revote for candidates at random times. The current group of validator nodes can change and the new queue of validator nodes will be formed by the nodes of different identities. One stakeholder node can vote for more than one candidate, allocating the weight of its“coin” on a pro rata basis among several candidates.

In the above-mentioned algorithm, the“coins” available on nodes can simultaneously participate in voting and be used for transfers. As a result of node balance changes, voting weights will change, too.

Likewise, for example, there is a technology solution disclosed in US 20150244690 Al. The aforesaid solution, e.g., discloses the tools for creating a unique entity identifier in the blockchain environment, which implement the so-called consensus process execution (i.e., decision-making by the blockchain environment nodes with the aim of developing final decisions that would be acceptable to all network nodes in user transaction management). The source delivers voting processes in respect of trusted node selection, node list building, the calculation of transactions and transaction fees, the verification of transactions by trusted nodes, the exchange of transaction outcomes among trusted nodes; discloses specific policies for transaction management, the calculation of transaction fees and cryptocurrency balance in the users’ wallet.

Other technology solutions include US 9,830,593 B2. Similarly to the source mentioned in the previous paragraph, this source discloses the tools for supporting the consensus process in the blockchain environment decentralized network. This source describes the tools enabling the execution of cryptocurrency transactions by carrying out validated transactions in the blockchain environment. The source describes a specific alternative peer-verification ledger which allows collaborative decision-making by the trusted nodes associated with such ledgers, in which case, for transaction verification purposes, the nodes requesting a transaction store the transaction security profile associated with the platform customer, where a transaction is first sent to the administrative platform server entrusted with the pre- verification of transactions. The above-mentioned information source, similarly to all other currently known information sources, discloses some of the transaction generation and execution options in collaborative decision-making by the decentralized network nodes; they are unable to perform such processes effectively enough as such solutions are not capable of delivering inter-node transaction actions at high security level (including absolutely secure validation and verification of any and all transactions being generated in the system), high transaction processing speeds (e.g., as high as 1,000,000 transactions per second).

Regard should be also given to the fact that, in addition to the above, any decisions made in respect of transactions in this invention will be a priori acceptable to all nodes of the decentralized network. None of the currently known technology solutions is capable of offering the aforesaid benefits.

This invention is designated to develop fundamentally new tools which do not have any drawbacks of earlier solutions (the prior art) and contribute to implementing the most effective tool for the generation, execution, validation, and verification of transactions in a decentralized network, where any decisions made by the decentralized network nodes in respect of transactions are acceptable to any and all network nodes. It is noteworthy that, for purposes of this invention, “transactions” mean, e.g., cryptocurrency transactions, transactions in the delivery of the smart contract environment or any other currently known types of data transactions.

In general terms, the claimed invention is, arguably, capable of proposing the new conceptual model of the generation, execution, validation, and verification of transactions in a decentralized network, entailing group collaborative decision-making by its heterogeneous nodes (e.g., consumer devices), with decisions being acceptable to all nodes of the decentralized network.

The foregoing is achieved in the claimed invention due to the fact that one embodiment of this invention represents a method of transaction processing in a decentralized network by its nodes in collaborative decision-making with employment of a digital decentralized network, comprising: clubbing a set of nodes, each containing a processor and data storage, into a network; initiating a ledger containing information about one or more transactions confirmed in the course of decision-making in respect of transactions by the network nodes; saving such ledger on each node in the set of decentralized network nodes; selecting a number of nodes from the set of nodes to be involved in the collaborative decision-making process and entrusting one of such nodes with the validation and verification of the most recently generated transaction pool in a decentralized network; building the node list by adding a set of nodes containing an updated ledger of collaborative decisions allowed to be made in respect of transactions on the node entrusted with recording the latest block, a set of the remaining nodes which have undergone the node filtering process by preset response time and/or sent coinciding hashes; randomly selecting from the node list the main node and trusted nodes, each containing an updated ledger; performing the verification of transactions on each trusted node, including the obtainment of vector of candidate transactions from the transaction pool to be added to the ledger by each trusted node from each of the remaining trusted nodes, and the verification of each such transaction in the above-mentioned vector of candidate transactions by each trusted node in respect of its own ledger; validating one or more candidate transactions which have been successfully verified on each trusted node, more specifically, adding a note indicating that such candidate transactions are to be added to the ledger; generating a new block to be recorded in the ledger, which represents a verified and validated transaction pool; and selecting a new recording node from the above-mentioned trusted nodes or main node in order to record the new block in the ledger.

In an alternative embodiment, the verification of transactions on each trusted node comprises calculating and comparing one or more wallet deltas which denote the node balance remaining after all candidate transactions for such trusted node are confirmed.

In a further alternative embodiment, where one or more candidate transactions are validated, with node balance remaining after all candidate transactions for such trusted node are confirmed and one or more transactions being sent by such node, the amount of which transaction exceeds the above-mentioned remaining node balance, it being guaranteed that added to the balance were one or more transactions in an amount which can cover such balance up to a positive value, the total balance of sent and received transactions is calculated in respect of the aforesaid transactions within the same block and, if the total balance is positive, all transactions within such block are treated as validated.

In a yet further alternative embodiment, trusted nodes further exchange transaction delta vectors.

In a yet further alternative embodiment, the matrices of transaction deltas received from all trusted nodes are further generated on each trusted node and trusted nodes exchange such transaction delta matrices.

A yet further alternative embodiment further includes generating a vector of the most common transaction deltas on each trusted node, calculating the final vector for the majority of deltas based on the delta majority matrix received from all trusted nodes in respect of each transaction, and generating on each trusted node the resulting vector containing the values of approved transactions, which is identical for all trusted nodes.

In a yet further alternative embodiment, the transaction fee associated with the sending node is further calculated for at least one transaction recorded onto the block.

In a yet further alternative embodiment, the total number of transactions in a round of decentralized network operation factors in the transaction fee calculation.

In a yet further alternative embodiment, the amount of transaction fee is interrelated to the number of trusted nodes involved in a round of decentralized network operation.

In a yet further alternative embodiment, the amount of transaction fee is interrelated to the place occupied by a transaction in the physical blockchain data storage.

In a yet further alternative embodiment, the amount of transaction fee is interrelated to the sending node’ s transaction activity.

In a yet further alternative embodiment, if one or more trusted nodes contain any transactions which are not available on the main node, then one or more trusted nodes send such unavailable transactions to the main node.

In a yet further alternative embodiment, the transaction contains at least information about the sending node and denotes a transfer of the transaction amount from the sending node to the receiving node.

In a yet further alternative embodiment, the transaction further contains information about at least one of the following: the sending node address, the smart contract address, or such parameters as may be necessary to execute the transaction.

A yet further alternative embodiment further entails forming a vector of candidate transactions to be added to the transaction pool ledger, containing transactions to be included in the ledger, through the use of the main node and sending such vector to all trusted nodes.

In a yet further alternative embodiment, after the main node is selected, transactions from all of the decentralized network nodes with an updated ledger are sent to such main node.

In a yet further alternative embodiment, the new recording node generates a hash of the new block.

In a yet further alternative embodiment, the new recording node disseminates the new block among all of the decentralized network nodes.

The foregoing is achieved in the claimed invention, inter alia, due to the fact that a yet further embodiment of this invention represents a system for transaction processing in a decentralized network by its nodes in collaborative decision-making, comprising a digital decentralized network including at least one processor unit; memory containing the instructions executed by one or more processor units, which instructions, when executed by one or more processor units, prompt the digital decentralized network to do the following: club a set of nodes, each containing a processor and data storage, into a network; initiate a ledger containing information about one or more transactions confirmed in the course of decision-making in respect of transactions by the network nodes; save such ledger on each node in the set of decentralized network nodes; select a number of nodes from the set of nodes to be involved in the collaborative decision-making process and entrust one of such nodes with the validation and verification of the most recently generated transaction pool in a decentralized network; build the node list by adding a set of nodes containing an updated ledger of collaborative decisions allowed to be made in respect of transactions on the node entrusted with recording the latest block, a set of the remaining nodes which have undergone the node filtering process by preset response time and/or sent coinciding hashes; randomly select from the node list the main node and trusted nodes, each containing an updated ledger; perform the verification of transactions on each trusted node, including the obtainment of vector of candidate transactions from the transaction pool to be added to the ledger by each trusted node from each of the remaining trusted nodes, and the verification of each such transaction in the above-mentioned vector of candidate transactions by each trusted node in respect of its own ledger; validate one or more candidate transactions which have been successfully verified on each trusted node, more specifically, add a note indicating that such candidate transactions are to be added to the ledger; generate a new block to be recorded in the ledger, which represents a verified and validated transaction pool; and select a new recording node from the above-mentioned trusted nodes or main node in order to record the new block in the ledger.

In a yet further alternative embodiment, the verification of transactions on each trusted node entails the calculation and comparison of one or more wallet deltas which denote the node balance remaining after all candidate transactions for such trusted node are confirmed.

In a further alternative embodiment, where one or more candidate transactions are validated, with node balance remaining after all candidate transactions for such trusted node are confirmed and one or more transactions being sent by such node, the amount of which transaction exceeds the above-mentioned remaining node balance, it being guaranteed that added to the balance were one or more transactions in an amount which can cover such balance up to a positive value, the total balance of sent and received transactions is calculated in respect of the aforesaid transactions within the same block and, if the total balance is positive, all transactions within such block are treated as validated. In a yet further alternative embodiment, the decentralized network is further prompted to exchange transaction delta vectors among trusted nodes.

In a yet further alternative embodiment, the decentralized network is further prompted to generate the matrices of transaction deltas received from all trusted nodes on each trusted node and exchange transaction delta vectors among trusted nodes.

In a yet further alternative embodiment, the decentralized network is further prompted to generate a vector of the most common transaction deltas on each trusted node, calculate the final vector for the majority of deltas based on the delta majority matrix received from all trusted nodes in respect of each transaction, and to generate on each trusted node the resulting vector containing the values of approved transactions, which is identical for all trusted nodes.

In a yet further alternative embodiment, the decentralized network is further prompted to calculate the transaction fee associated with the sending node for at least one transaction recorded onto the block.

In a yet further alternative embodiment, the decentralized network is further prompted to form a vector of candidate transactions to be added to the transaction pool ledger, containing transactions to be included in the ledger, through the use of the main node and to send such vector to all trusted nodes. In a yet further alternative embodiment, after the main node is selected, the decentralized network is further prompted to send transactions from all of the decentralized network nodes with an updated ledger to such main node.

In a yet further alternative embodiment, the new recording node is capable of disseminating the new block among all of the decentralized network nodes.

Brief description of the drawings

Specific embodiments of the present invention will be described below by way of example only with reference to the accompanying drawings. The drawings are provided for purposes of visual demonstration of the principles of operation and functioning for the claimed invention. The drawings are intended only to illustrate certain aspects and shall not be considered limiting of the spirit and scope of the claimed invention.

Fig. 1 is a schematic view of the decentralized network nodes;

Fig. 2 exemplifies a diagram showing the sequence of actions to determine which nodes are eligible to participate in the collaborative decision-making process;

Fig. 3 shows an embodiment of the diagram for selection of the head and trusted nodes for the collaborative decision-making process;

Fig. 4 shows an embodiment of the chart showing how transactions are sent from all of the decentralized network nodes to the main node.

Fig. 5 schematically shows how the vector of candidate transactions to be added to the ledger is sent to trusted nodes;

Fig. 6 schematically illustrates the exchange of transaction deltas among all trusted nodes;

Fig. 7 schematically illustrates the exchange of transaction delta matrices among all trusted nodes;

Fig. 8 illustrates the selection of a new trusted recording node to be entrusted with recording a new block in the ledger.

Fig. 9 illustrates the calculation of vectors for the majority of transaction deltas for each transaction matrix received from all trusted nodes.

Fig. 10 visually exemplifies a graph of the fee component of transactions.

Fig. 11 visually exemplifies the graph of dependence of the fee component of transaction price on the sender's transaction activity. Fig. 12 exemplifies a graph of transactions executed within one round of the decentralized network operation.

Detailed description of the embodiments

For a better understanding of the spirit and scope of the claimed invention, example embodiments of the claimed invention are hereinafter described with reference to the following drawings. After reading this description, the above-mentioned and other advantages of the claimed invention will become apparent to one of ordinary skill in the art.

In order to point out with particularity the spirit and scope of the claimed invention, due regard should be given at least to the terms and definitions used in this description below. More specifically, the following key terms must be defined:

“Balance” means the amount of currency (e.g., cryptocurrency) in the wallet of the group collaborative decision-making system user, such as blockchain wallet.

“Wallet” (“blockchain wallet”) in turn means specialist hardware or software storage of data with high levels of security, which allows the visual indication of dynamic changes in a personal user account; the term“balance” means the amount of currency (e.g., cryptocurrency) in such wallet in real time. In the present invention, possible wallets include web wallet or other types of wallets, such as desktop, mobile, hardware, online wallets or other types and modifications of wallets.

“Block” means a set of transactions which have undergone the process of collaborative decision-making (consensus process) by nodes with a positive outcome.

“Blockchain” is a decentralized/peer-to-peer system without no central authority, i.e., blockchain is a continuous and consistent chain of blocks (linked list) containing information that builds upon certain rules, with copies of block chains being stored on a variety of computers of system users (nodes) independently of each other such that altering, damaging or falsifying the information contained in such blocks is nearly impossible.

“Node” in a decentralized network context means a totality of user application (installed on the user's electronic device) and updated ledger linked to the broader system, which participates in voting rounds aimed at selecting the main node and trusted nodes, validates/rejects transactions and saves them to a dedicated ledger. It is further understood that, until the ledger is updated by user application, the node cannot be treated as valid node in the network, i.e., is unable to participate in the main node and trusted nodes selection process.

For purposes of this description, the term“regular node” hereinafter means the node which participates in selecting the main node and trusted nodes;“main node” means the node enabling the analysis and validation of transactions (whitelist, i.e., reliable list), the adding of transactions to the dedicated ledger of decentralized network;

“trusted node” means the node enabling transaction analysis and a preparation of the initial transactions whitelist;

“recording node” means the node which records the latest block during the previous round and is authorized to initiate a new round;

“node validation” means the specific process proving that the node is real and has in place the sought-for (necessary and sufficient) resources to enable the decentralized network operation.

For purposes of this patent application, the term“consensus” means the process of group decision-making by nodes in a decentralized network aimed at arriving at final decisions acceptable to any and all nodes of the network, while the term“round” means the cycle of federated voting by the decentralized network nodes on the whitelisting of transactions.

For purposes of this invention,“ledger” means interrelated tools and methods of data storage in the decentralized network system pertaining to any system transactions/actions already completed in the account computing/value system; i.e., generally, the ledger, inter alia, carries information about the list of transactions validated by the system saved across all nodes of the decentralized network.

Lastly, “transaction” means the minimum system unit which is inherent in the decentralized network system, denotes a request for action to be performed in the system and the results of such actions to be recorded on the blockchain.

For a more detailed understanding of the processes undergone by transactions in group collaborative decision-making by the decentralized network nodes, due regard should also be given to the general principles of platform operation in a decentralized network as pointed out below.

All network nodes in this invention are decentralized and none of them prevails over the rest. That said, it is necessary to clearly identify the network node to process the queue of transactions stored on different network nodes. The so-identified node then must record the newly generated block of transactions in the ledger.

The platform employs its own combined protocol based on calculating the mathematical function of all transactions in the ledger with employment of Proof of Work principles. The use of specific protocol offers the opportunity of clearly and unambiguously determining the storage of the most recently updated copy of the ledger and software on such node (Proof of Capacity) by computing the checksum of values of the entire content known as hash code. There are further determined the size of files, the evidence that it is the most recently updated copy, and hash code of the latest transaction recorded in the system.

In order to become the main node of a network, the node finds the value of hash function by calculating it based on the most recently saved ledger. All of the network nodes constitute a competitive environment which enables fair competition to qualify as the main node and be eligible to generate and save a new ledger.

Once the function is calculated and the result is obtained, it is forwarded to all network nodes for verification. The result carries a timestamp of the calculation date and the value found by calculating the ledger and software files’ function. All nodes receive the so-calculated value, compare the calculation time allocated for finding the main server of the network, verify the same, prove that it is a trusted node eligible to compete to be the main node of the network.

The obtainment of approvals from all network nodes is followed by building the list of nodes which have correctly calculated the function value and contain a timestamp. The node which receives the correct result and is the first to approve the same with all nodes becomes the current main node of the network.

The hash sum of a file may be calculated using, e.g., the SHA-2 algorithm concept. The hash functions of the SHA-2 family build on the Merkle-Damgard construction. That said, it should be obvious to one of ordinary skill in the art that the above-mentioned algorithm is not a restrictive example. Any known hashing algorithm may be employed.

The original message after padding is broken into blocks, with each block possibly broken into, for example, a certain number of words (e.g., 16 words).

The algorithm feeds each message block through the cycle with a preset number of iterations/rounds (e.g., 64 or 80 rounds or a different value).

During each iteration, for example, 2 words are transformed and the transformation function is defined by the remaining words.

The processing results for each block are summed up, with the sum representing the hash function value.

The internal state of the system is initialized depending on the processing results for the previous block.

Generally, group decision-making process in a decentralized network (consensus process) can be described as the use of federated model of decision-making - voting by trusted validator nodes. Consensus decision-making algorithm is essentially a finite state automaton algorithm. Consensus runs in cycles (time steps). At each time step, transactions are retrieved from the decentralized network and bundled into a pool (one-dimensional array).

Once in the pool, all transactions are sent to trusted nodes in order to receive a response. If response is received, the transaction in respect of which the request for adding to the ledger was sent can be added to the ledger of this validator node. The transaction is then sent to the next validators in the decentralized network. When consensus - the end point of the chain - is reached and the legality and legitimacy of transfer are fully confirmed, the transaction is forwarded for validation and marked as the transaction to be recorded and saved in the ledger.

At any given time, the system contains the most recently updated copy of the ledger. The most recently updated copy of the ledger is automatically created by the node responsible for forming the ledger after a consensus is reached. The block is sent to all system nodes such that an updated copy of the ledger status is maintained across all system nodes.

Each node is connected with all remaining nodes in the network, while continuously exchanging (dynamically) new blocks containing transaction data such that all nodes have updated information in place. All blocks form a set of candidate transactions waiting to be added to the ledger. At the same time, each server of the system forms the suggested sets of candidates for other servers and the suggested set of transactions. Once a dedicated verification procedure is complete, it is decided whether to add or not add the same to the ledger.

This enables multiple savings of ledger data on multiple nodes of the system, thus allowing all information about transactions in the system to be protected. The greater the number of system nodes, the higher the system reliability and independence levels.

Each channel of communication, for instance, between the main node of the network and any other node of the network is a separate flow within which data is encrypted before being transferred when the transaction is executed. For network security purposes, all data is encoded before transmission among validator nodes and each inter-node communication session is enabled, for example, by a network library-based low-level connection. Should an error occur during data transmission, the flow must be automatically interrupted, with the relevant entry being placed for recording onto the logging system and then onto a log file. Data is transmitted through typed variables. The so-transmitted data may be encrypted, for instance, using the RC4 symmetric algorithm or any other suitable algorithm based on pseudorandom bits. Possible key lengths vary between 40 bits and 2048 bits. All generated bits are evenly distributed.

The aforesaid algorithm employs a common secret key, which key is transmitted in an encrypted form where inter-node connection is created following, for example, the Diffie- Hellman algorithm or any other suitable encryption algorithm. As regards the Diffie-Hellman algorithm, it relies on the difficulty of computing discrete logarithms. Like many other public- key algorithms, it makes calculations modulo a big prime number P. It starts from specifically selecting a natural number A less than P. If the value X is to be encrypted, then it computes Y = A X mod P. Given X calculating Y is relatively easy. The opposite problem of calculating X given Y is relatively difficult. The exponential X is called the discrete logarithm of Y. Accordingly, knowing about the difficulty of computing discrete logarithms, the number Y can be publicly transmitted over any communication channel since with a big module P cracking the initial value X will be nearly impossible.

The received key can be used to exchange messages with employment of symmetric encryption.

Any actions in the system are referenced to timestamp, the previous block number, user log-in, and dedicated identifier, such as smart contract identifier. Duplicates are thus detectable in the course of execution. If a duplicate has been found, it is possible to retrieve, e.g., the first transaction from the pool, while treating the remaining transactions in the transaction pool as illegitimate.

In order to avoid duplicate transactions with the same identifier in the same block, the system agrees that the transaction which is the first to arrive for processing on the validator node is the only reliable transaction. As the validator node already contains a record saying that a transaction has already been executed from the current node account and no more values are held in the node account to carry out a transaction, consensus cannot be reached.

Where a transaction is executed and information is received and verified by the validator node, information about the ledger status change is automatically disseminated among all nodes on the trusted node list, whereupon the ledger gets synchronized across all nodes.

In order for an updated transaction ledger to be available at all times across all trusted nodes for the current validator node, the incoming transaction is resynchronized in the ledger of all nodes. A separate synchronization port is used for this purpose (where possible, optional). To the extent possible, the processing speed in respect of the validator node's input information further increases due to the port load sharing. The synchronization flow runs at all times and is loop-structured. Main memory and processor load sharing (the use of processor cycles) is below average, thus reducing resource consumption. The memory space can accommodate, e.g., the most recently updated 1,000 operations and the status of their respective accounts (in an encrypted form following the synchronous algorithm), which makes it possible to improve the speed of response to requests from other validator nodes. Adding transactions to the ledger is invoked only by the validator node once the consensus is reached and the whitelist (i.e., trusted list) is ready, resulting in transactions being saved in the ledger. Furthermore, external systems cannot invoke such adding for enhanced security purposes.

Possible input parameters include a transaction-specific object; the object containing a unique timestamp of the transaction, the sender; the resulting parameter of the recipient node, transmitted value, transactions cost matching, the target value, the transmitted value amount, the target value amount and other system information which is allowed to be altered as needed.

Transaction price can vary depending on network load, the“capacity” of a specific system user which can potentially send a big flow of transactions at peak times.

The price of transactions can be tailored to different types of transactions and operations or set using the automatic transaction pricing algorithm.

The aforesaid process arrangements disclosed in further detail below enable a significant efficiency of the transaction generation and execution process (as previously mentioned), which will become apparent to one of ordinary skill in the art after reading the full description below.

Fig. 1 shows a schematic layout of the decentralized network, where each endpoint represents a network node - the aggregate of the user application installed on their electronic devices and the updated ledger that are connected with a common system participating in the rounds of voting for selection of the main node and trusted nodes.

In other words, node in the decentralized network in this invention is, for example, a user computer (e.g., that of a cryptocurrency platform or a party to the smart contract), with the full client of special-purpose system installed on such computer, i.e., specific software that connects such user computer and the decentralized network, including other nodes of the decentralized network.

A computer with such“full client” is thus able to verify transactions and record them in the ledger.

User computer may be represented by any currently known device of this kind, including, but not limited to, personal computer, portable computer, server station, tablet computer device, etc.

User computer must have a reliable network connection. The network may be a public network (e.g., Internet), private network (e.g., local network (LAN), distributed network (WAN)), or any combinations of the same. That said, it will be apparent to those skilled in the art that any other known types of networks may be employed, including but not limited to, e.g., GPRS, 3G, 4G/LTE, Wi-Fi, etc.

At the initial stage known as the “initialization stage” it may be necessary to initiate/generate the initial ledger. In order to do so, a node in the decentralized network generates the first transaction and then, provided that all conditions applicable to a specific action are met, the user - through the use of the full client installed on user computer - initiates an action in the decentralized network (with employment of the decentralized network platform software, e.g., the blockchain platform or smart contract platform). In order to follow the principles set by the platform, for example, the validator kernel tracks the synchronization and immutability of the most recently updated version of the ledger.

Once the consensus decision is made, all transactions received during the current cycle of the system, including the user transaction, are then grouped/clubbed into the blockchain block. This block is assigned a particular number, for example, consisting of a timestamp and the node identifier transformed into a hash code. The block can then be placed in the consensus reaching and execution module.

Once the initial initialization is complete, the group collaborative decision-making process (consensus process) can be started by the network nodes in respect of transactions. Generally, the consensus process can be“logically” divided into several stages.

Such“stages” may include:

• Filtering out all nodes with an outdated ledger

• Selecting nodes to be involved in the consensus process (i.e., selecting the main node and trusted nodes)

• Forming a vector of candidate transactions to be added to the ledger

• Specific calculation of transaction deltas and exchanging results among the selected trusted nodes

• Exchanging transaction delta matrices among the trusted nodes

• Determining quantitative majority for each transaction

• Forming a vector of approved transactions

• Selecting a new recording block to record the block

• This can also be followed by calculating the transaction fees and extracting a subset of valid transactions from a set of given transactions

• Recording the new block of blockchain in the ledger

Then the next round of decentralized network operation begins.

With reference to the drawings, the invention will now be described in more detail in accordance with various embodiments of the above-mentioned transaction handling in collaborative decision-making by the decentralized network nodes in respect of transactions, which decisions are acceptable to any and all network nodes.

Referring now to Fig. 2, a diagram is provided illustrating the sequence of steps to identify the nodes eligible to participate in the collaborative decision-making process in respect of transactions.

The main node and trusted nodes must meet specific requirements, namely have an adequate capacity, i.e., for example, the nodes which respond in a given amount of time.

In order to select the nodes to be subsequently involved in the consensus process, certain preset steps are taken, such as the initial filtering, e.g., by (adequate) node capacity.

Each network node sends the hash (Hash in Fig. 2, simply put, the term“hash” means a unique sequence of symbols of a certain type which is generated based on data) of the most recently updated block available on the node concerned to one of the nodes from the previous round of the decentralized network platform operation which has recorded the most recently updated block on the blockchain.

A fixed period of time (e.g., including, without limitation, 0.2 seconds to 2.0 seconds) is given to send a hash, and all nodes from which no hash has been received within this time interval drop out of the competition for eligibility to participate in the consensus process. In this way the so-called initial filtering of nodes by capacity is performed.

The node receiving the above-mentioned hashes compares them with the block’ s hash recorded by such node during the previous round. All nodes sending a mismatching hash are then discarded (drop out). Accordingly, the node with an outdated ledger does not qualify as main node or trusted node, for example, for the next round.

Referring now to Fig. 3 , a diagram is provided illustrating a selection of the head and trusted nodes for the collaborative decision-making process in respect of transactions.

A list of given length, e.g., the length n of nodes with an updated ledger (for any nodes sending matching hashes, see Fig. 2 description above) is generated on the decentralized network platform node which records the most recently updated block on the blockchain.

Each round of the decentralized network platform operation may have a preset number of, for example, m nodes participating in the process of voting on transactions, i.e., nodes which qualify as trusted nodes and the main nodes.

A given number m of nodes, for example, the nodes 3m or any other given number is randomly selected from the nodes n (e.g., by a random number generator).

Then m number of nodes is randomly selected (e.g., by a random number generator, too) from these nodes 3m, with one of them appointed as main node for the next round, and the remaining m nodes as trusted nodes for the next round.

The transactions received from all decentralized network platform nodes are then forwarded to main node 1 as shown in Fig. 4. Referring now to Fig. 4, a flowchart is provided illustrating how transactions are sent from all decentralized network nodes to the main node (denoted on the drawings identically to node 1 (main node)).

Initially, a transaction is generated and stored on the sending node. A transaction contains information, for example, about user activity. All transactions generated in the system while the main node and trusted nodes are being selected (as previously noted with reference to Fig. 2 and Fig. 3) are sent from all non-trusted nodes to the main node.

Main node 1 of the decentralized network platform, as shown in Fig. 5, then forms a vector of candidate transactions to be added to the ledger. This vector in turn is sent by main node 1 to all trusted nodes (nodes 2, 3, m in Fig. 4).

The above-mentioned vector of candidate transactions may look, for example, like this:

Where T parameters stand for the transactions containing information, for example, about the sending node and a transaction number associated with the sending node; values in the transaction vector can read, for example, as follows:

T_a-b stands here for a transaction sent by the node a, whereas b denotes the transaction number within the node in question. x_y means the number of transactions on the node y.

Transaction deltas, as illustrated in Fig. 6, can then be exchanged among all trusted nodes of the decentralized network on the decentralized network platform.

However, in order to do so, after a vector of candidate transactions to be added to the ledger is received, each trusted node verifies each transaction for such vector throughout its own ledger.

Transactions are verified by calculating and comparing, for example, on each trusted node the wallet deltas (blockchain wallets) denoting, e.g., node balances remaining after all candidate transactions for this trusted node are confirmed.

Delta wallets can be computed, for example, based on the following formula:

where denotes the wallet balance of node a in the ledger of node c,

°a_b^~ denotes the price of transaction b of node a,

a_b denotes the delta of wallet a in transaction b, which delta is calculated on node c.

Once the verification of transactions is complete, each trusted node adds trusted node specific digital signature (“digital signature” can mean a unique digital signature (e.g., digital timestamp), for example, randomly generated for each network node, which signature is added by the node to data). Digital signature is uniquely tailored to every node and can, for example, be generated for each node when connecting to the system. Digital signature is the identifier of the node performing data operations) to a vector of transaction deltas and resends such vector of transaction deltas to all remaining trusted nodes.

For example, the above-mentioned delta vector calculated on the node m (shown on the drawing) can look like this:

(A^m A^ml_2> ^a A^mN_X_N l)

After the vector of transaction deltas (i.e., data difference) is sent to trusted node, each trusted node has a formed matrix of the transaction deltas received from all trusted nodes. This is followed by the exchange of delta transaction matrices (as shown in Fig. 7) similarly to the aforesaid principle following which the vector of delta transactions is sent to all trusted nodes.

The delta transaction matrix containing the values of transaction deltas can look, for example, like this:

Once the exchange of delta transaction matrices is complete, it is possible to calculate a “cube of transaction deltas” on any and all trusted nodes for decision-making in respect of more common transaction values.

The matrices of, e.g., the following deltas are collected from all trusted nodes:

Where A^c~d _b denotes the delta of wallet (blockchain wallet) a in transaction b, which delta is calculated on node c and received from node d.

Each trusted node goes through all of the received matrices to form a vector of the most common transaction deltas (see Fig. 9) which can look, for example, like this

It is noteworthy that should several different more common values of transaction deltas be found, the resulting vector eventually contains an empty value for this transaction.

Further, once a vector of the most common transaction deltas has been formed, each trusted node is patterned to calculate the final vector of most deltas based on the matrix of most deltas received from all trusted nodes in respect of each transaction.

The above-mentioned matrix of most deltas can look, for example, like this:

The above-mentioned majority vector in respect of each transaction, can look, for example, like this:

(D'i i; D'_{1 2}; ... A'_n-Xn)

Similarly to the foregoing, should several more common transaction delta values be found where a vector of transaction deltas is formed, the resulting vector eventually contains an empty value for this transaction.

After the resulting vector is computed on each trusted node, each of such trusted nodes enables forming a vector containing the values of approved transactions only, with such vector being identical across all honest nodes.

It may be assumed that this stage already allows forming the final block of the blockchain that can be written to the ledger with“clean” transactions only. Fig. 8 illustrates how the new trusted recording node is selected to record a new block in the ledger.

A new block must be recorded in the ledger using one of the trusted nodes which has previously made a positive decision on the block that is identical with most other trusted nodes. Such node can be referred to as“reliably honest node” (reliably honest node).

The procedure for intercepting and discarding the so-called“betrayer nodes” from trusted nodes can be performed, for example, by verifying the outcome of decision-making in determining the plurality for each transaction (as described above).

All trusted nodes whose decisions are mismatched with the majority decision are removed from the list of trusted nodes which can potentially record a new block in the ledger. The remaining list will be identical at all honest nodes.

Any node is randomly selected from the remaining nodes and subsequently represents a new node writing a block in the blockchain.

Once a new recording node has been selected, the transaction fees can now be calculated.

Each transaction recorded in the block, for example, can be subject to a fee charged from the sending node for issuing a transaction, e.g., with the total number of transactions in a particular round of decentralized network operation factored in. Fig. 10 illustrates an example of the graph of the pricing component of transactions, showing the dependence of fees on the number of transactions in a particular round of decentralized network operation.

For purposes of this invention, the“fee” can have a specific range of fee components.

Network sets the number of transactions in a particular round of operation assuming that the greater the number of transactions in a round, the lower the fee.

Factored in the total number of transactions in a particular round is the number of transactions in such round received from the same node and the total number of participant nodes of the round concerned.

Fig. 10 shows dependence of the fee component of a transaction on the number of transactions in a particular round, where the number of transactions is the abscissa and the transaction processing price is the ordinate. Connecting the abscissas and ordinates of the resulting graph gives us the graph of the transaction pricing component.

The pricing component of the transaction value depending on the total number of transactions in the current round (see Fig. 10) is a piecewise- linear function which is defined by a set of value pairs (number of transactions - round price for this number of transactions).

Due regard should be given to the fact that this invention can be based on the assumption about direct interdependence between the number of trusted nodes in a particular round and the fee amount, e.g., where the greater the number of trusted nodes in a round, the higher the fee.

The number of trusted nodes can satisfy, for example, the following expression: 3 < m < predetermined number.

That said, nominal value m (= predetermined number) can range, for instance, from 3 to 300.

Price (fee amount) grows linearly pro rata to the number m of trusted nodes in a round with a certain calibration constant of proportionality since all nodes have equal rights.

Price also grows quadratically with respect to the number m² of trusted nodes in a round with a certain other calibration constant since the consensus process used to build a block contains message passing among all trusted nodes with a quadratic dependence relative to the m of trusted nodes in a round.

For example, dividing a certain round price by the number of transactions in this round we get dependence of one transaction on the number of trusted nodes in a round.

As for physical transaction size, it is assumed that the bigger the“disk space” used by a transaction on the blockchain, the higher the transaction fee. The maximum and minimum transaction size limits are assumed to be used.

For example, the above-mentioned minimum value is appointed as the nominal transaction value, whereas the maximum value is not defined.

As for physical length in bytes, transaction price, for example, can be proportional to sesquialteral length growth rate. 808 -byte transaction or any other value are assumed to be unit length transaction. Accordingly, if transaction length is L bytes, its component- and length- based price will look, for example, like this: f £ A { 1 \^b 3

- l _, More generally & - j *g , by wa ol example {_% ~ k b ~ y ~ 0 808 i \ S0§ j ^' 2 ^' where a and b are given calibration constants.

In addition, the fee calculation can further have, for example, the sending node’s transaction activity factored in.

It may be assumed that the greater the number of transactions generated by the sender, the higher the fee.

The dependence of this fee component on the sender's transaction activity is shown in Figure 11. The pricing component of the transaction value depending on the total number of transactions outbound from one sender per second is defined identically to the total number of transactions in the current round, i.e., by the piecewise-linear function which is set parametrically for a set of value pairs (total number of transactions per second for one sender - transaction markup for the sender’ s given transaction activity) in each segment.

Whenever the resulting transaction price is calculated, due regard is given to the highest possible transaction fee before a block is generated. Once the list of confirmed transactions is complete, the updated values of transaction fees are calculated.

It is then possible to extract a subset of valid transactions from a set of transactions as described below.

We are given a set of T {/'' }^~ _=l transactions, where transaction is a weighted relationship between the sender and recipient of the price P, namely Sender — E~~ Recipient

Let us denote by V = {v‘ } a union of the entire set of senders O = {o‘ } and the entire set of recipients P = {n^p }^F _p=l and refer to this set as a set of participants in transactions T .

Let us plot a directed graph G = {V, E] where a set of vertexes V of graph G is a set of transaction participants V , and a set of edges E of graph G is a set of transactions above a set of transaction participants. Edge weight is equal to the price of the relevant transaction. Each of the graph nodes is assigned a four-component vector of node weights w = (w₁ , w₂, w₃, w₄ ) , where

w _l denotes transaction participant’s current/initial balance which corresponds to the current status of blockchain and, of course, does not account for the transactions T, which are treated as part of the process in question.

j— i \Q

W2 denotes the sum of transaction prices in the set ^{1 f q}“^x , namely the transactions in which this node participated in its capacity as the sender of transactions 7.

T ~ {f\~

w denotes the sum of transaction prices in the set ^J '^r" , namely the transactions in which this node participated in its capacity as the recipient of transactions T.

W4 denotes a new balance:

W4 = Wl - W2 + W3

With regard to graph G = { V, E) let us divide a set of edges E into two disjoint subsets

such that the weight vector for each node in the resulting graph G¹ = { V,

^■} satisfies the following: W4 > 0. The weight vector of the participating nodes is built similarly to the process of computing the participant’ s balance assuming that all transaction edges of the current graph are already embedded in the next blockchain except that these values of the fourth component of weights in the current graph can be negative and our process is tailored to remove a certain (where possible, the minimum) number of transaction edges with the aim of procuring the fourth components of weight vector for each vertex to be strictly positive in the remaining transactions graph.

If all of the fourth weight components of the resulting graph are positive, then a set of the remaining transactions E¹ corresponding to the graph G¹ = { V¹ , E¹} with the positive fourth components for all participating nodes guarantees that the balance for each participating node of this graph G¹ = { V¹, E¹} is not negative.

If graph G = {V, E) is such that all fourth components of weight vector of the participating nodes are positive, then in respect of each participating node from the transaction T=

set - the balance counted on the current blockchain (first component of weight vector

) will be greater than the sum of all spendings in transactions T involving the same in its capacity as sender (second component of weight vector w₂ ) less all of its beneficial holdings with due regard to the entire transaction set T (third component of weight vector w_¾) in its capacity as recipient. In other words, if H¼ > 0,

then

(3) Wi> W₂- W3

It follows from (1) that w₄ = wi - w₂ + w¾. With (2) in mind, we get w_\ - w₂ + w₂ > 0, which is equivalent to wi > w₂ - w_¾. Consequently, the assertion that the balance counted on the current blockchain is greater than spendings in transactions T in its capacity as sender less beneficial holdings with due regard to the entire transaction set transactions T in its capacity as recipient for each participant node of the transaction - proved.

The process itself can be described as follows:

V€

We select node V in graph G = {V, E] such that its fourth component of weight vector w ⁴, £ 0 is non-positive. Then we delete the minimum number of outbound edges from vertex v such that the sum of weights of the remaining outbound edges satisfies the following relation:

where

i_s the sum of weights of the remaining transaction edges which satisfy (4). The edges to be removed are selected using the best possible method.

In this case the fourth weight component for the participating node v will become

¾ = ¾ - ¾ + w_¾ > 0

positive - indeed, if (4) is true, then

Accordingly, in this iteration we removed a certain number of edges - at least one edge (which means that the relevant number of transactions will be left out of the final block).

We recalculate the components of weight vectors for all nodes V of graph, where a set of edges W is a set of edges of the initial graph less the edges removed during step 1 of the first iteration.

We apply step 1 and step 2 to the resulting graph until all of the fourth components of weight vectors become strictly positive for all of the participating nodes.

We generate a new block consisting of the remaining transaction edges on which, according to assertion 1 proved above, the balances of all participating nodes will be non negative.

By way of graphic example, Fig. 12 shows an exemplary graph of transactions executed within the same round of decentralized network operation.

Let us assume that sender A has balance 10. In the next round sender A participates in four transactions in its capacity as sender and in two transactions in its capacity as recipient. All of these transactions are part of the same round. For example, the table below can provide an illustration of the foregoing:

With the above transactions factored in, the balance of participant A is as follows: (Current balance) - (sum of the prices of“sent” transactions) + (sum of the prices of

‘received” transactions):

10 - (9 + 10 + 11 + 15) + (7+8+12) = 10 - 45 + 27 = -8 It can be seen that, for example, sender A issues one transaction more - accordingly, if we delete from the table above any single transaction involving A in its capacity as sender, then the participant’s balance in respect of all remaining transactions becomes positive.

In Fig. 12, all transactions involving A in its capacity as sender are represented by heavy lines. All transactions involving A in its capacity as recipient are highlighted with intermittent lines. The transaction which, if deleted, makes A's balance positive, is represented by a fine line.

However, the removal of the transaction A->B reduces the balance of participant B, thus necessitating a recalculation of the balance of participant B and all other participants in this round whose balance could have been indirectly affected by the removal of transaction A- >B in accordance with the above-mentioned algorithm.

Once all of the processes described above are complete, a new recording node forms a hash of the new block and writes such new block of the blockchain to the ledger. It is this node that will disseminate the new block among all nodes of the system. After the new block of the blockchain has been disseminated, a new round / time step of system operation begins on the decentralized network platform.

It should be thus apparent to those skilled in the art that the way in which the transaction generation and execution process is organized in group collaborative decision-making by network nodes offers advantages such as, for example, enhanced security of transactions due to secure validation and verification procedures for any and all transactions being generated in the system as each newly generated transaction is validated and verified in the ledger of each trusted node, with such information being synchronized with each of the remaining trusted and main nodes in the system; incredibly high transaction processing speeds in the system - at least 1,000,000 transactions per second; with all decisions made by nodes in respect of transactions being acceptable to all nodes in the system, thus adding security, too.

Regard should be also given to the fact that, in addition to the above, any decisions made in respect of transactions in this invention will be a priori acceptable to all nodes of the decentralized network.

It should be further noted that the way in which the process of collaborative decision making by nodes is organized procures nodes to be partition tolerant since no potential unavailability of any single node, e.g., its physical disconnection or any other circumstances, will disrupt the availability of the ledger and the rest of the system - the system will continue functioning as normal - or impact the quality, speed, or efficiency of the system decision making in respect of transactions. It is to be understood that the foregoing description of the preferred embodiment is intended to be illustrative and not restrictive of the spirit and scope of the invention.

Other embodiments of the invention will become more readily apparent to those skilled in the art from the following claims in conjunction with the accompanying description and drawings, which fully and clearly support such claims.

Claims

1. A method of transaction processing in a decentralized network by its nodes in collaborative decision-making with employment of a digital decentralized network, comprising:

creating a network with a set of nodes, each of which includes a processor and a data storage;

initializing a ledger containing information about one or more transactions confirmed in the course of decision-making in respect of transactions by the network nodes;

saving such ledger on each node in the set of decentralized network nodes;

selecting a number of nodes from the set of nodes to be involved in the collaborative decision-making process and entrusting one of such nodes with the validation and verification of the most recently generated transaction pool in a decentralized network;

generating the node list by adding a set of nodes containing an updated ledger of collaborative decisions allowed to be made in respect of transactions on the node entrusted with recording the latest block, from among a plurality of the remaining nodes which have undergone the node filtering process by preset response time and/or sent coinciding hashes;

randomly selecting from the node list the main node and trusted nodes, each containing an updated ledger;

performing the verification of transactions on each trusted node, including the obtainment of vector of candidate transactions from the transaction pool to be added to the ledger by each trusted node from each of the remaining trusted nodes, and the verification of each such transaction in the above-mentioned vector of candidate transactions by each trusted node in respect of its own ledger;

validating one or more candidate transactions which have been successfully verified on each trusted node, more specifically, adding a note indicating that such candidate transactions are to be added to the ledger;

generating a new block to be recorded in the ledger, which represents a verified and validated transaction pool; and

selecting a new recording node from the above-mentioned trusted nodes or main node in order to record the new block in the ledger.

2. The method of claim 1, wherein verifying transactions on each trusted node comprises calculating and comparing one or more wallet deltas which denote the node balance remaining after all candidate transactions for such trusted node are confirmed.

3. The method of claim 2, wherein, where one or more candidate transactions are validated, with node balance remaining after all candidate transactions for such trusted node are confirmed and one or more transactions being sent by such node, the amount of which transaction exceeds the above-mentioned remaining node balance, it being guaranteed that added to the balance were one or more transactions in an amount which can cover such balance up to a positive value, the total balance of sent and received transactions is calculated in respect of the aforesaid transactions within the same block and, if the total balance is positive, all transactions within such block are treated as validated.

4. The method of claim 2, further comprising the exchange of transaction delta vectors among trusted nodes.

5. The method of claim 4, further comprising generating on each trusted node the matrices of transaction deltas received from all trusted nodes and exchanging such transaction delta matrices among trusted nodes.

6. The method of claim 5, further comprising generating a vector of the most common transaction deltas on each trusted node, calculating the final vector for the majority of deltas based on the delta majority matrix received from all trusted nodes in respect of each transaction, and generating on each trusted node the resulting vector containing the values of approved transactions, which is identical for all trusted nodes.

7. The method of claim 1, further comprising calculating the transaction fee associated with the sending node for at least one transaction recorded onto the block.

8. The method of claim 7, wherein the total number of transactions in a round of decentralized network operation factors in the transaction fee calculation.

9. The method of claim 7, wherein the amount of transaction fee is interrelated to the number of trusted nodes involved in a round of decentralized network operation.

10. The method of claim 7, wherein the amount of transaction fee is interrelated to the place occupied by a transaction in the physical blockchain data storage.

11. The method of claim 7, wherein the amount of transaction fee is interrelated to the sending node’ s transaction activity.

12. The method of claim 1 , wherein if one or more trusted nodes contain any transactions which are not available on the main node, then one or more trusted nodes send such unavailable transactions to the main node.

13. The method of claim 1, wherein the transaction contains at least information about the sending node and denotes a transfer of the transaction amount from the sending node to the receiving node.

14. The method of claim 13, wherein the transaction further contains information about at least one of the following: the sending node address, the smart contract address, or such parameters as may be necessary to execute the transaction.

15. The method of claim 1, further comprising forming a vector of candidate transactions to be added to the transaction pool ledger, containing transactions to be included in the ledger, through the use of the main node and sending such vector to all trusted nodes.

16. The method of claim 1, wherein, after the main node is selected, transactions from all of the decentralized network nodes with an updated ledger are sent to such main node.

17. The method of claim 1, wherein the new recording node generates a hash of the new block.

18. The method of claim 17, wherein the new recording node disseminates the new block among all of the decentralized network nodes.

19. A system for transaction processing in a decentralized network by its nodes in collaborative decision-making, comprising:

a digital decentralized network including at least one processor unit;

memory containing the instructions executed by one or more processor units, which instructions, when executed by one or more processor units, prompt the digital decentralized network to do the following:

club a set of nodes, each containing a processor and data storage, into a network; initiate a ledger containing information about one or more transactions confirmed in the course of decision-making in respect of transactions by the network nodes;

save such ledger on each node in the set of decentralized network nodes;

select a number of nodes from the set of nodes to be involved in the collaborative decision-making process and entrust one of such nodes with the validation and verification of the most recently generated transaction pool in a decentralized network;

build the node list by adding a set of nodes containing an updated ledger of collaborative decisions allowed to be made in respect of transactions on the node entrusted with recording the latest block, a set of the remaining nodes which have undergone the node filtering process by preset response time and/or sent coinciding hashes;

randomly select from the node list the main node and trusted nodes, each containing an updated ledger;

perform the verification of transactions on each trusted node, including the obtainment of vector of candidate transactions from the transaction pool to be added to the ledger by each trusted node from each of the remaining trusted nodes, and the verification of each such transaction in the above-mentioned vector of candidate transactions by each trusted node in respect of its own ledger;

validate one or more candidate transactions which have been successfully verified on each trusted node, more specifically, add a note indicating that such candidate transactions are to be added to the ledger;

generate a new block to be recorded in the ledger, which represents a verified and validated transaction pool; and

select a new recording node from the above-mentioned trusted nodes or main node in order to record the new block in the ledger.

20. The system of claim 19, wherein verifying transactions on each trusted node comprises calculating and comparing one or more wallet deltas which denote the node balance remaining after all candidate transactions for such trusted node are confirmed.

21. The system of claim 20, wherein, where one or more candidate transactions are validated, with node balance remaining after all candidate transactions for such trusted node are confirmed and one or more transactions being sent by such node, the amount of which transaction exceeds the above-mentioned remaining node balance, it being guaranteed that added to the balance were one or more transactions in an amount which can cover such balance up to a positive value, the total balance of sent and received transactions is calculated in respect of the aforesaid transactions within the same block and, if the total balance is positive, all transactions within such block are treated as validated.

22. The system of claim 20, wherein the decentralized network is further prompted to exchange transaction delta vectors among trusted nodes.

23. The system of claim 22, wherein the decentralized network is further prompted to generate the matrices of transaction deltas received from all trusted nodes on each trusted node and exchange transaction delta vectors among trusted nodes.

24. The system of claim 23, wherein the decentralized network is further prompted to generate a vector of the most common transaction deltas on each trusted node, calculate the final vector for the majority of deltas based on the delta majority matrix received from all trusted nodes in respect of each transaction, and to generate on each trusted node the resulting vector containing the values of approved transactions, which is identical for all trusted nodes.

25. The system of claim 19, wherein the decentralized network is further prompted to calculate the transaction fee associated with the sending node for at least one transaction recorded onto the block.

26. The system of claim 25, wherein the total number of transactions in a round of decentralized network operation factors in the transaction fee calculation.

27. The system of claim 25, wherein the amount of transaction fee is interrelated to the number of trusted nodes involved in a round of decentralized network operation.

28. The system of claim 25, wherein the amount of transaction fee is interrelated to the place occupied by a transaction in the physical blockchain data storage.

29. The system of claim 25 , wherein the amount of transaction fee is interrelated to the sending node’ s transaction activity.

30. The system of claim 19, wherein if one or more trusted nodes contain any transactions which are not available on the main node, then one or more trusted nodes send such unavailable transactions to the main node.

31. The system of claim 19, wherein the transaction contains at least information about the sending node and denotes a transfer of the transaction amount from the sending node to the receiving node.

32. The system of claim 31, wherein the transaction further contains information about at least one of the following: the sending node address, the smart contract address, or such parameters as may be necessary to execute the transaction.

33. The system of claim 19, wherein the decentralized network is further prompted to form a vector of candidate transactions to be added to the transaction pool ledger, containing transactions to be included in the ledger, through the use of the main node and to send such vector to all trusted nodes.

34. The system of claim 19, wherein, after the main node is selected, the decentralized network is prompted to send transactions from all of the decentralized network nodes with an updated ledger to such main node.

35. The system of claim 19, wherein the new recording node generates a hash of the new block.

36. The system of claim 35, wherein the new recording node is capable of disseminating the new block among all of the decentralized network nodes.