Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
GROUP COLLABORATIVE DECISION-MAKING BY DECENTRALIZED NETWORK NODES
Document Type and Number:
WIPO Patent Application WO/2020/058655
Kind Code:
A1
Abstract:
The invention relates to the means of collaborative decision-making by the nodes in a data transmission network. The invention is developed to create new means contributing to the most effective collaborative decision-making by the nodes in the decentralized network, including at least the utmost security while performing the procedure of the group collaborative decision-making in the decentralized network, which ensures, for example, the generation and performance of transactions, for example, such as cryptocurrency transactions or implementation of the smart contract environment. One of the invention alternatives is the method comprising stages at which the following is performed: creating a network with a set of nodes; initiating the ledger, which comprising information on at least one transaction; saving the said ledger at each node of the set of decentralized network nodes; selecting at least three nodes from the set on nodes and sending a hash of the last block available on the node by each of the set of decentralized network nodes to one of at least three nodes that have performed validation and verification of the last transaction pool, and in this case the nodes from the decentralized network node set, from which no hash has been received within the preset time and/or mismatching hashes have been received, are excluded from the set of nodes subject to participation in collaborative decision-making in the decentralized network; compiling a list of the first nodes with up-to-date ledger of the preset length at the node from the set of remaining nodes subject to participation in collaborative decision-making, which has written the last block; randomly selecting from the list of first nodes a preset number of second nodes with up- to-date ledger, from which a preset number of third nodes is selected, the random one of which is nominated as the main node, and the rest of nodes from the first nodes are nominated as the trusted nodes; generating a new block that is to be written to the ledger; selecting the new writing for writing the new block to the ledger.

Inventors:
CHUGUNOV IGOR (GB)
BUTYAEV EUGENIY (GB)
Application Number:
PCT/GB2018/052673
Publication Date:
March 26, 2020
Filing Date:
September 19, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
CS SOLUTIONS TECH LIMITED (GB)
International Classes:
G06F11/16; G06F11/18; G06F21/64
Foreign References:
US20150244690A12015-08-27
US9830593B22017-11-28
Other References:
ANONYMOUS: "Consensus mechanism in CREDITS distributed system - Credits", 13 May 2018 (2018-05-13), XP055573721, Retrieved from the Internet [retrieved on 20190325]
ALYSSON BESSANI ET AL: "State Machine Replication for the Masses with BFT-SMART", 2014 44TH ANNUAL IEEE/IFIP INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS, 1 June 2014 (2014-06-01), pages 355 - 362, XP055573588, ISBN: 978-1-4799-2233-8, DOI: 10.1109/DSN.2014.43
YOSSI GILAD, ROTEM HEMO, SILVIO MICALI, GEORGIOS VLACHOS, NICKOLAI ZELDOVICH: "Algorand : Scaling Byzantine Agreements for Cryptocurrencies", PROCEEDINGS OF THE 26TH SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES , SOSP '17, 1 January 2017 (2017-01-01), New York, New York, USA, pages 51 - 68, XP055573405, ISBN: 978-1-4503-5085-3, DOI: 10.1145/3132747.3132757
Attorney, Agent or Firm:
MURGITROYD & COMPANY et al. (GB)
Download PDF:
Claims:
CLAIMS

1. The method of collaborative decision making by the decentralized network nodes, using the digital decentralized network and containing stages at which the following is performed:

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

initializing the ledger including the information on at least one transaction confirmed in the course of decision-making by the network nodes;

saving the said ledger on each of the nodes from the set of nodes of the decentralized network;

selecting at least three nodes from the set of decentralized network nodes subject to participation in the collaborative decision-making procedure where each of the decentralized network node set sends a hash of the last block available on the node to one of at least three nodes that have performed validation and verification of the last transaction pool, and in this case the nodes from the decentralized network node set, from which no hash has been received within the preset time and/or mismatching hashes have been received, are excluded from the set of nodes subject to participation in collaborative decision-making in the decentralized network;

generating a list of first nodes with the up-to-date ledger of the preset length on the node from the set of remaining nodes subject to participation in collaborative decision-making, which has written the last block;

randomly selecting from the list of first nodes a preset number of second nodes with an up-to-date ledger, from which a preset number of third nodes is randomly selected and the random one of which is nominated as the main node, while the rest of the nodes from the first nodes are nominated as the trusted nodes;

verifying transactions on each trusted node;

generating a new block to be written to the ledger;

selecting a new writing node for writing a new block to the ledger, in this case the selection is performed among the nodes of the set of nodes nominated as the trusted ones, where the new writing node has made a positive decision on the block that is identical to the majority of decisions made by the majority of nodes out of those nominated as the trusted nodes.

2. The method according to claim 1 characterized in that, while making a decision all received transactions are combined in the platform into a block, which is assigned with a number consisting of least a timestamp and a node identifier converted into the hash code.

3. The method according to claim 2, characterized in that after the nomination of the main node the transactions from all decentralized network nodes with up-to-date ledger is sent to it.

4. The method according to claim 3, wherein, if the tmsted node contains transactions that are missing at the main node, then the trusted node sends the missing transactions to the main node.

5. The method according to claim 3 characterized in that the transaction comprises at least the information on the receiving node and specifies the transfer of the transaction amount from the sending node to the node receiving the transaction.

6. The method according to claim 5, wherein the transaction additionally contains the information on at least one of the sending node’s addresses, smart contract address, and parameters required to perform the transactions.

7. The method according to claim 3, further comprising the generation of a vector of the transactions to be included in the ledger by means of the main node and sending the said vector to all nodes nominated as the trusted ones.

8. The method according to claim 7, further comprising the verification of the transactions vector at each node nominated as the trusted one, by the ledger of each node nominated as the trusted one.

9. The method according to claim 8, further comprising putting the electronic signature on the transaction vector by each node nominated as the tmsted one, upon successful verification.

10. The method according to claim 9 characterized in that the new writing node serves as the generator of hash for the new block.

11. The method according to claim 10 characterized in that the new writing node verifies and signs the new block.

12. The method according to claim 11 characterized in that the new writing node distributes the new block to all nodes in the network.

13. The method according to claim 12 characterized in that the selection of the new writing node among the nodes of the set of nodes nominated as the trusted one, where the new writing node has made a positive decision on the block that is identical with the majority of decisions made by the majority of nodes nominated as the trusted ones, is performed in a random way.

14. The method according to claim 1 , wherein the node nominated as the main node is selected as the new writing node.

15. The method according to claim 1, characterized in that while selecting a preset number of third nodes, the first of them is nominated as the main one.

16. The method according to claim 1 characterized in that the nodes from the set of the decentralized network nodes, from which no hash has been received within the preset time and/or mismatching hashes have been received, may participate in one or more subsequent rounds of making collaborative decisions by the decentralized network nodes.

17. The method according to claim 1, wherein the block is a verified and validated pool of transactions.

18. The system for collaborative decision making by the decentralized network nodes, comprising a digital decentralized network, including at least one processing device and memory, which contains instructions executed at least by one processing device, and the execution of these instructions by at least one processing device prompts the digital decentralized network to act as follows:

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

initialize the ledger including the information on at least one transaction confirmed in the course of decision-making by the network nodes;

save the said ledger on each of the nodes from the set of nodes of the decentralized network;

select at least three nodes from the set of decentralized network nodes subject to participation in the collaborative decision-making procedure where each of the decentralized network node set sends a hash of the last block available on the node to one of at least three nodes that have performed validation and verification of the last transaction pool, and in this case the nodes from the decentralized network node set, from which no hash has been received within the preset time and/or mismatching hashes have been received, are excluded from the set of nodes subject to participation in collaborative decision-making in the decentralized network;

generate a list of first nodes with the up-to-date ledger of the preset length on the node from the set of remaining nodes subject to participation in collaborative decision-making, which has written the last block;

randomly select from the list of first nodes a preset number of second nodes with an up- to-date ledger, from which a preset number of third nodes is randomly selected and the random one of which is nominated as the main node, while the rest of the nodes from the first nodes are nominated as the trusted nodes;

verify transactions on each trusted node;

generate a new block to be written to the ledger; and

select a new writing node for writing a new block to the ledger, in this case the selection is performed among the nodes of the set of nodes nominated as the trusted ones, where the new writing node has made a positive decision on the block that is identical to the majority of decisions made by the majority of nodes out of those nominated as the trusted nodes.

19. The system according to claim 18 characterized in that while making a decision in the decentralized network, all received transactions are combined in the platform into a block, which is assigned with a number consisting of least a timestamp and a node identifier converted into the hash code.

20. The system according to claim 19 characterized in that after nominating the main node in the decentralized network, the transactions from all decentralized network nodes with the up-to-date ledgers are sent to this main node.

21. The system according to claim 20, wherein if the trusted node contains transactions that are missing at the main node, then the trusted node sends the missing transactions to the main node.

22. The system according to claim 20 characterized in that the transaction in the decentralized network includes at least the information on the receiving node and specifies the transfer of the transaction amount from the sending node to the node receiving the transaction.

23. The system according to claim 22, wherein the transaction additionally includes information on at least one of the sending node addresses, smart contract address, and parameters required to perform the transaction.

24. The system according to claim 20, further comprising the formation in the decentralized network of a vector of transactions that are to be added to the ledger by means of the main node and sending the said vector to all nodes nominated as the trusted ones.

25. The system according to claim 24, further comprising a verification in the decentralized network of the transaction vector at each node nominated as the trusted one by the ledger of each node nominated as the trusted one.

26. The system according to claim 25, further comprising putting the electronic signature on the transaction vector by each node nominated as the trusted one, upon successful verification in the decentralized network.

27. The system according to claim 26, characterized in that the new writing node serves as the generator of a new block hash in the decentralized network.

28. The system according to claim 27, characterized in that the new writing block verifies and signs the new block in the decentralized network.

29. The system according to claim 28, characterized in that the new writing block in the decentralized network distributes the new block to all nodes in the network.

30. The system according to claim 29, characterized in that the new writing node is randomly selected in the decentralized network from the nodes of the set of nodes nominated as the trusted ones, where the new writing node has made a positive decision on the block that is identical to the majority of decisions made by the majority of node from the nominated as the trusted nodes.

31. The system according to claim 18, wherein the node nominated as the main node is selected as the new writing node.

32. The system according to claim 18, characterized in that while selecting a preset number of the third nodes, the first of them is nominated as the main node in the decentralized network.

33. The system according to claim 18, characterized in that the nodes in the decentralized network from a set of the decentralized network nodes, from which no hash has been received within the preset time and/or mismatching hashes have been received, may participate in one or more subsequent rounds of collaborative decision-making by the decentralized network nodes.

34. The system according to claim 18, wherein the block is a verified and validated pool of transactions.

Description:
GROUP COLLABORATIVE DECISION-MAKING BY DECENTRALIZED

NETWORK NODES

This invention relates to the means of collaborative decision-making by heterogeneous nodes in a data transmission network. More particularly, the invention relates to the means of group collaborative decision-making by the nodes of, for example, such network as a decentralized data transmission network for generation and implementation of, for example, blockchain environment for transmitting data or smart contracts.

The prior art provides technical solutions that implement group collaborative decision making in the decentralized network.

For example, there is a known technical solution disclosed in US 20150244690 Al. The said solution, for example, discloses the means for creating a unique entity identifier in the blockchain environment, which implement the so-called consensus procedure (i.e. making decisions by the blockchain nodes with the aim to develop final decisions acceptable for all network nodes). In the source, the consensus procedure is performed in general by filtering nodes with a mismatching hash, implementing the voting algorithm at the option of trusted nodes, building a list of nodes of a preset length, calculating verified transactions that were verified by the trusted nodes, and further by exchanging the results of transactions only among the trusted nodes.

Besides, for example, there is a known technical solution provided in US 9,830,593 B2. This source, in the same way as the above-mentioned one, discloses the means for ensuring the consensus procedure in the blockchain environment decentralized network. This source describes the means allowing the performance of cryptocurrency transactions using the blockchain environment, namely, it provides a detailed description of a specific alternative of the peer-verification ledger, by means of which the consensus can be ensured only among the trusted nodes associated with the said ledger.

Notwithstanding that both the above-mentioned solutions and other solutions known from the prior art disclose specific alternatives of the collaborative decision-making by heterogeneous nodes in the decentralized network of, for example, such environment as the blockchain one, they are not able to implement them with a sufficient degree of effectiveness, security and at the least costs for heterogeneous nodes that may have absolutely different computational power, data processing rate and the capacity, for example, to generate and process transactions in the decentralized network for implementation of, for example, the blockchain environment or smart contracts environment or any other similar environment that requires collaborative decision-making by the nodes in the decentralized network.

Besides, there exists, for example, such decision-making algorithm as DPoS (Delegated proof-of- stake), which is an alternative of the consensus algorithm in the decentralized environment.

In general, the main principle of the DPoS operation can be expressed as dividing the voting and validating peers (nodes) of the decentralized environment. Thereat, the nodes, which have been nominated in the algorithm as having votes in the voting in the system, have no right to validate the transaction. Consequently, in this case, one subset of nodes (having a right to vote) and the other subset of nodes (having a right to validate transactions) select the third subset, which, in its turn, is vested with a right to generate transaction blocks.

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

While performing the consensus procedure, a rule is applied pursuant to which every node has a right to come forward as a candidate for a validator node. After that, all the nodes vote for candidates, where a weight of every vote is determined by total assets of the voting node.

Further, the results of the voting are used as grounds for selecting a limited natural number of candidates, which can be vested with the right to generate new transaction blocks. Specific protocol rules are applied that shall guarantee correct decision-making if a greater part of assets of the nodes, participating in the vote is controlled by honest nodes.

Validator nodes selected as a result of voting are mixed in a pseudorandom manner, forming a queue. The mixing is made in such a way that it is impossible to foresee the queue, but it appears identical to all honest nodes of the network. After that, a period of time is set during which each of the validator nodes shall generate one queue block. Every validator node is provided with a limited interval of time. In such a way, in one alternative the validator node manages to check new transactions and generate a new block based on the previous one, otherwise (if the validator node fails to manage with the task within the preset period) the performance of this operation is assigned to the next validator node in the queue. After the preset time has elapsed the validator nodes are mixed and a new queue is formed.

The above-mentioned algorithm is, to a certain extent, a premise for creating this invention, however, it has a number of disadvantages inherent in the currently known solutions that are designed for group collaborative decision-making by the decentralized system nodes, for example, such as insufficient effectiveness of decision-making, inadequate security of decision-making (including the increased exposure to attacks, as it is impossible to select the trusted nodes in a dynamic way), and heavy consumption of power and resources by nodes participating in the procedure, which may have absolutely different computational power, data processing rate and the capacity, for example, to generate and process transactions in the decentralized network for implementation of, for example, blockchain environment or smart contracts environment or any other similar environment that requires collaborative decision making by the nodes in the decentralized network.

This invention is created with the purpose to develop absolutely new means facilitating the most effective collaborative decision-making by the nodes in the decentralized network, including at least the utmost security in the course of group collaborative decision-making procedure in the decentralized network, ensuring, for example, the generation and carrying out data transmission transactions, for example, such as cryptocurrency transactions or implementation of the smart contract environment or carrying out the transmission of other currently known types of data.

In general terms, it can be said that the claimed invention can propose a new conceptual model of making group collaborative decisions by the decentralized network nodes (for example, by users’ devices), acceptable for all decentralized network nodes, based on building a new decentralized ledger and dynamic selection of the trusted nodes, where, for example, trusted nodes can be selected by the speed of response and/or randomly.

The above-mentioned is achieved in the claimed invention thanks to the fact that in one alternative it appears as a method of collaborative decision-making by the decentralized network nodes performed with the use of a digital decentralized network and comprising stages, at which the following actions are performed: creating a network with a set of nodes, each of which includes a processor and data storage; initiating a ledge, containing information on at least one transaction that was confirmed in the course of decision making by the nodes; saving the said ledger on each node of the decentralized network node set; selecting at least three nodes from the set of decentralized network nodes that subject to participation in the collaborative decision-making procedure, where each of the decentralized network node set sends a hash of the last block available on the node to one of at least three nodes that have performed validation and verification of the last transaction pool, and in this case the nodes from the decentralized network node set, from which no hash has been received within the preset time and/or mismatching hashes have been received, are excluded from the set of nodes subject to participation in collaborative decision-making in the decentralized network; generating a list of first nodes with the up-to-date ledger of the preset length on the node from the set of remaining nodes subject to participation in collaborative decision-making, which has written the last block; randomly selecting from the list of first nodes a preset number of second nodes with up- to-date ledger, from which a preset number of third nodes is randomly selected and the random one of which is nominated as a main node, while the rest of the nodes from the first nodes are nominated as the trusted nodes; verifying transactions on each trusted node; generating a new block to be written to the ledger; selecting a new writing node for writing a new block to the ledger, in this case the selection is performed among the nodes of the set of nodes nominated as the trusted ones, where the new writing node has made a positive decision on the block that is identical to the majority of decisions made by the majority of nodes out of those nominated as the trusted nodes.

According to another additional alternative, while making a decision all received transactions in the platform are combined into a block, which is assigned with a number, consisting of at least a timestamp and a node identifier converted into a hash code.

According to another additional alternative, after nominating the main node, the transactions from all the decentralized network nodes having up-to-date ledgers are sent to this main node.

According to another additional alternative, if a trusted node contains transactions that are missing on the main node, then the trusted node sends corresponding transactions to the main node.

According to another additional alternative, a transaction includes at least the information on a receiving node and indicates a transfer of the transaction amount from the sending node to the transaction receiving node.

According to another additional alternative, a transaction includes information on at least one of the sending node addresses, smart contract address, and parameters required to perform the transaction.

Another alternative of the invention further comprises the formation of a vector of transactions to be included in the ledger by means of the main node and sending the above- mentioned vector to all nodes that were nominated as the trusted ones.

Another alternative of the invention further comprises the verification of transaction vector at every node nominated as the trusted one, by the ledger of every node nominated as the trusted one.

Another alternative of the invention further comprises putting an electronic signature on a transaction vector by each node nominated as the trusted one, upon successful verification. Another alternative of the invention, wherein, a new writing node serves as a hash generator for a new block.

Another alternative of the invention, wherein, a new writing node performs verification and signing of a new block.

Another alternative of the invention, wherein, a new writing node distributes the new block to all the nodes in the network.

Another alternative of the invention, wherein, the selection of a new writing node from the set of nodes nominated as the trusted nodes, where the new writing node has made a positive decision on the block, which is identical with a majority of decisions made by a majority of nodes out of nominated as the tmsted nodes, is performed in a random way.

Another alternative of the invention, wherein, a node nominated as the main node is selected as the new writing node.

Another alternative of the invention, wherein, when selecting the preset number of third nodes, the first of them is nominated as the main one.

Another alternative of the invention, wherein, the nodes from a set of the decentralized network nodes, from which no hash has been received within the preset time and/or mismatching hashes have been received, may participate in one or more subsequent rounds of collaborative decision-making by the decentralized network nodes.

Another alternative of the invention, wherein, a block is a verified and validated pool of transactions.

Another alternative of the claimed invention is a system for collaborative decision making by the decentralized network nodes that comprises a digital decentralized network, including at least one processing device and memory, which contains instructions executed at least by one processing device, and the execution of these instructions by at least one processing device prompts the digital decentralized network to act as follows: create a network with a set of nodes, each of which includes a processor and a data storage; initialize the ledger including the information on at least one transaction confirmed in the course of decision-making by the network nodes; save the said ledger on each of the nodes from the set of nodes of the decentralized network; select at least three nodes from the set of decentralized network nodes subject to participation in the collaborative decision-making procedure where each of the decentralized network node set sends a hash of the last block available on the node to one of at least three nodes that have performed validation and verification of the last transaction pool, and in this case the nodes from the decentralized network node set, from which no hash has been received within the preset time and/or mismatching hashes have been received, are excluded from the set of nodes subject to participation in collaborative decision-making in the decentralized network; generate a list of first nodes with the up-to-date ledger of the preset length on the node from the set of remaining nodes subject to participation in collaborative decision-making, which has written the last block; randomly select from the list of first nodes a preset number of second nodes with up-to-date ledger, from which a preset number of third nodes is randomly selected and the random one of which is nominated as a main node, while the rest of the nodes from the first nodes are nominated as the trusted nodes; verify transactions on each trusted node; generate a new block to be written to the ledger; and select a new writing node for writing a new block to the ledger, in this case the selection is performed among the nodes of the set of nodes nominated as the trusted ones, where the new writing node has made a positive decision on the block that is identical to the majority of decisions made by the majority of nodes out of those nominated as the trusted nodes.

Another alternative of the invention, wherein, while making a decision, all the received transactions in the platform are combined into a block, which is assigned with a number consisting of at least a timestamp and a node identifier converted into a hash-code.

Another alternative of the invention, wherein, after the nomination of the main node, transactions from all nodes of the decentralized network with up-to-date ledgers are sent to this main node.

Another alternative of the invention, wherein, if the trusted node contains transactions that are missing on the main node, then the trusted node sends the missing transactions to the main node.

Another alternative of the invention, wherein, a transaction in the decentralized network includes at least information on the receiving node and indicates a transfer of the transaction amount from the sending node to the transaction receiving node.

Another alternative of the invention, wherein, a transaction additionally includes information on at least one of the sending node addresses, smart contract address, and parameters required to perform the transaction.

Another alternative of the invention, wherein, a vector of transactions that are to be included in the ledger by means of the main node is formed in the decentralized network and the said vector is sent to all nodes nominated as the trusted ones.

Another alternative of the invention comprises the verification of transaction vector at every node nominated as the trusted one, by the ledger of every node nominated as the trusted one in the decentralized network.

Another alternative of the invention comprises putting an electronic signature on a transaction vector by each node nominated as the trusted one, upon successful verification, in the decentralized network.

Another alternative of the invention, wherein, a new writing node serves as a hash generator for a new block in the decentralized network.

Another alternative of the invention, wherein, a new writing node performs verification and signing of a new block in the decentralized network.

Another alternative of the invention, wherein, a new writing node distributes the new block to all the network nodes in the decentralized network.

Another alternative of the invention comprises the random selection of a new writing node from the set of nodes nominated as the trusted nodes, where the new writing node has made a positive decision on the block, which is identical with a majority of decisions made by a majority of nodes out of nominated as the trusted nodes in the decentralized network.

Another alternative of the invention, wherein, a node nominated as the main node is selected as a new writing node.

Another alternative of the invention, wherein, when selecting the preset number of third nodes, the first of them is nominated as the main one in the decentralized network.

Another alternative of the invention, wherein, the nodes from a set of the decentralized network nodes, from which no hash has been received within the preset time and/or mismatching hashes have been received, may participate in one or more subsequent rounds of collaborative decision-making by the decentralized network nodes in the decentralized network.

Another alternative of the invention, wherein, the block is a verified and validated pool of transactions.

Brief description of the drawings

This invention is supported by specific examples of embodiments as described below that are associated with drawings referenced to below for a visual demonstration of the operation principles and functioning of the claimed invention, which are not meant to limit the spirit of the claimed invention but to provide a graphic representation of some aspects.

Fig. 1 shows a visual schematic layout of the decentralized network nodes;

Fig. 2 shows an example of a sequence diagram for determining the nodes appropriate for participation in the collaborative decision-making;

Fig. 3 shows an alternative diagram of selecting the main and trusted nodes for the collaborative decision-making procedure; Fig. 4 shows an alternative diagram of sending transactions from all nodes of the decentralized network to the main one.

Fig. 5 gives a schematic view of distributing a vector of transaction-candidates to be added to the trusted nodes ledger;

Fig. 6 gives a schematic view of exchanging transaction deltas among all trusted nodes; Fig.7 gives a schematic view of exchanging transaction delta matrices among all trusted nodes;

Fig. 8 shows the selection of a new trusted writing node for writing a new block to the ledger.

Embodiment of the Invention

To make the spirit of the claimed invention better understood, the examples of the claimed invention embodiment, which will make the above-mentioned and additional advantages of the claimed invention apparent to those skilled in the art, are disclosed below, including with references to the positions marked in the drawings.

To disclose the spirit of the claimed invention in a more exact way, it is necessary to consider at least the terminology used in this description below, and namely, it is necessary to define such basic term as:

Balance - total currency (for example, such as cryptocurrency) in a wallet of the user of the group collaborative decision-making system, for example, of such wallet as the blockchain- wallet.

By wallet (blockchain- wallet), in its turn, is meant a specially configured hardware or software storage of data with a high level of security, which allows the visual indication of dynamic changes in a personal user’s account; by the term“balance” is meant total currency (for example, such as cryptocurrency) in the specified wallet at the current time. In this invention, a web-wallet, or other types of wallet, for example, such as desktop, mobile, hardware, online-wallets or other types of wallets and their modifications can be used as a wallet.

By block is meant a set of transactions that have passed the procedure of collaborative decision-making (consensus) by nodes with a positive result.

Blockchain is a decentralized (peer-to-peer) system, which has no central controller, i.e. blockchain is a continuous sequential chain of blocks (linked list of blocks) built pursuant to certain rules, with the blocks containing certain information, and thereat copies of the block chains are stored on multiple different computers of the system users (nodes) independently of each other, so the information contained in the blocks cannot be virtually changed, damaged or falsified.

By node in the decentralized network is meant an aggregate of the user’s application installed on their electronic device and the up-to-date ledger that is connected with the common system participating in rounds of voting for selection of the main node and trusted nodes, confirming/rejecting transactions and saving them to the special-purpose ledger. Yet, until the ledger is updated by the user’s application, the node cannot be considered as a valid node in the network, i.e. cannot participate in the procedure of selecting the main and tmsted nodes.

Further, the term“common node” as used herein means a node participating in the selection of the main and trusted nodes;“main node” - node of the decentralized network ensuring analysis and confirmation of transactions (white list, i.e. reliable list) as well as adding transactions to a special-purpose ledger;

“trusted node” - a node ensuring analysis of transactions and compiling a white list of transactions;

“writing node” - a node that has written the last block in the previous round and has authorities to initiate a new round;

“node validation”- a specific process confirming the validity of the node which has the sought-for (necessary and sufficient) resources to ensure the operation of the decentralized network.

The term“consensus” as used herein means the execution of the group decision-making procedure by nodes in the decentralized network aimed at generating final decisions acceptable for all the network nodes without exception and by the term“round” is meant a cycle of (federative) voting by the decentralized network nodes on compiling the white list of transactions.

“Ledger” as used herein means the interconnected means and methods of storing necessary data on the transactions (actions) that have been already completed in the decentralized network system, performed in the system for evaluating the value of an environment user’s account, i.e. in general words it can be said that the ledger among other things bears the information on the list of transactions confirmed by the system and saved on all the decentralized network nodes.

And finally, by“transaction” is meant a minimum unit of the system inherent in the decentralized network system, denoting a request to perform an action in the system and recording the results of such actions in the blockchain. For a clearer understanding of the group collaborative decision-making procedure by the decentralized network nodes, it is also worth paying attention to the general principles of the platform operation in the decentralized network, as discussed below.

All network nodes in this invention are decentralized and none of them has a priority over the other nodes. Thereat, it is necessary to specify the network node, which will perform the operation of processing a queue of transactions stored on different network nodes. After that, the indicated node shall enter a newly generated block of transactions into the ledger.

The platform uses its own combined protocol based on the calculation of the mathematical function of all ledger transactions, applying the Proof of Work principles. The use of specific-purpose ledger allows unambiguous determination of storage of the latest up- to-date copy of the ledger and software at this node (Proof of Capacity), by calculating the checksum of values of the entire contents - the hash code. The size of files is determined as well, as evidence that this is the latest up-to-date copy and the hash-code of the latest transaction recorded in the system.

To become the main network node, the node searches for the value of the hash function that it calculates based on the last stored ledger. A competitive environment established between all the network nodes provides an opportunity to become the main node on equal terms, to generate and store a new ledger.

After calculating the function and obtaining the result, it is sent to all network nodes for verification. The result contains a timestamp of the calculation date and a value based on the calculation of the function of the ledger files and software. All nodes receive the calculated value, compare the calculation time allocated for the search of the main network server, verify it and confirm the trust factor of the node, and also confirm its opportunity to participate in the competition to become the main network node.

After receiving approval from all network nodes, the nodes that correctly calculated the value of the function and contain timestamps are arranged in a list. The node that received the correct result and had it approved with all nodes in the fastest time, becomes the main network node of the moment.

To calculate the hash sum of the file, for example, the SHA-2 algorithm concept may be used. Hash functions of the SHA-2 family are built on the basis of the Merkle-Damgard structure. In this case, those skilled in the art will be able to establish that the above-mentioned algorithm is not a limitative example. It is possible to use any known hashing algorithm.

After the addition, the initial message is divided into blocks, each block may be divided, for example, into a certain number of words, for example, into 16 words. The algorithm passes each message block through a cycle of a set number of iteration (rounds), for example, 64 or 80 rounds, or any other value.

At each iteration, for example, 2 words are converted, and the rest of the words define the conversion function.

The results of each block processing are summarized. The sum is the hash function value.

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

In general, the procedure of group decision-making in the decentralized network (consensus) in this invention can be described as the use of a federative model of decision searching - voting of trusted validator nodes. The consensus building algorithm is essentially an algorithm for passage of a finite-state automation.

Consensus works by cycles (time steps). Per time step, transactions are extracted from the decentralized network and placed in a pool (one-dimensional array). After being placed in this pool, all transactions are sent to trusted nodes in order to receive a response. If the response is received, then the transaction for which the request to add to the ledger was sent, can be added to the ledger of this validator. After that, the transaction is sent to the next validator in the decentralized network. When consensus is built - at the end of the chain where the transfer legality is fully confirmed, the transaction is sent to validation and marked for writing and saving to the ledger.

Thanks to the above-mentioned organization of the procedure, given the further detailed disclosure of the group collaborative decision-making procedure, a significant effectiveness of the procedure has been achieved (as it was already mentioned above), that will become apparent to those skilled in the art while reading the description in full.

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

In other words, the node in the decentralized network in this invention is, for example, a user’s computer (for example, of a cryptocurrency platform or a party of smart contract) with installed complete client of the special-purpose system representing a specific software that connects the user’s computer and the decentralized network, including other nodes of the decentralized network. So, the computer by means of the“complete client” is able to verify transactions and write them to the ledger.

The user’s computer may be represented by any currently known device of such kind, including but not limited to a personal computer, portable computer, server station, tablet-type computer device, etc.

The user’ s computer shall have a reliable connection to the network. This network may be a public network (for example, Internet), a private network (for example, local network (LAN) or a distributed network (WAN)), as well as the combination thereof. Having said that, it shall be apparent to those skilled in the art that any other known types of networks, including but not limited to, for example, GPRS, 3G, 4G/LTE, Wi-Fi, etc., may be applied.

At the initial stage - initialization stage - it is necessary to initiate (generate) an initial ledger. For this purpose a node in the decentralized network generates the first transaction, then, when all conditions of a specific action are met, the user, by means of the complete client installed on the user’ s computer, initiates the action in the decentralized network (through the decentralized network platform software, for example, of the blockchain platform or smart contract platform). To follow the principles set by the platform, for example, the kernel of validator keeps track of synchronization and invariance of the latest up-to-date ledger version.

Further, at the time of building the consensus, all transactions, including the user’s transaction, received during the current cycle of the system are joined (combined) in the blockchain block. This block is assigned with a number, for example, consisting of a timestamp and a node identifier converted into a hash code. Then, the block can be placed in the consensus module.

After initial initialization, the group collaborative decision-making procedure (consensus procedure) can be started by the network nodes. In general, the consensus procedure can be“logically” divided into several stages as described in details below with reference to the drawings.

Such“stages” can be as follows:

• Filtration of nodes with out-of-date ledger

• Selection of nodes subject to participation in the consensus procedure (i.e. selection of the main and trusted nodes)

• Forming of a vector of transaction-candidates to be added to the ledger

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

• Determination of a quantitative majority for each transaction

• Forming a vector of approved transactions

• Selection of a new writing block for writing the block

• Also, the transaction commission can be calculated and a subset of valid transactions can be extracted from the set of preset transactions

• Writing the new blockchain block to the ledger

Then, the next round of the decentralized network operation starts.

All information set forth below with reference to the drawings provides a detailed description of the above-mentioned“logical” stages of the decision-making procedure.

Fig. 2 shows the sequence diagram for determining the nodes appropriate for participation in the collaborative decision-making procedure.

The main and tmsted nodes are subject to specific requirements, in particular, availability of adequate power in these nodes, i.e., for example, nodes that manage to respond within a preset period of time.

To select the nodes subject to participation in the consensus procedure the certain preset actions are performed, for example, such as described below initial filtration, for example, by (adequate) node power.

Each network node sends the hash (hash in Fig. 2, simply put, the term“hash” means a unique sequence of symbols of a certain kind that is generated on the basis of data) of the very last block, which is available at this node, to one of the nodes from the previous round of the decentralized network platform operation that has written the last block to the blockchain.

A preset period of time (for example, but not limited to, from 0.2 to 2.0 seconds inclusive) is given for sending the hash, and the nodes, from which no hash has been received within this time, drop out of the contest for the right to participate in the consensus procedure. In such a way the so-called initial filtration of the nodes by power is performed.

The node, which has received the said hashes, compares them with the block’s hash that was written by it in the previous round. Then, the nodes which sent the mismatching hashes are isolated (drop out). So, the node with the out-of-date ledger cannot become the main or tmsted node, for example, for the next round.

Fig. 3 illustrates the diagram of selecting the main and tmsted nodes for the collaborative decision-making procedure. A list of preset length, for example, n of the nodes with up-to-date ledger (those sent coinciding hashes - description of Fig. 2 above) is generated at the decentralized network platform node, which has written the last block to the blockchain.

Each round of the decentralized network platform operation may have a preset number of, for example, m nodes participating in the voting procedure on transactions, i.e. nodes, that can be the trusted and main ones. The indicated number of nodes m shall be equal to such number, that, for example, it shall satisfy the expression of interconnection between m and n nodes, which, for example, can be chosen by way of experiment, therewith, a preset threshold is established for the m value.

Then, the preset number of m nodes, for example, 3m nodes or any other preset number is selected among n nodes in a random way (for example, by a random number generator).

After that, out of these 3m nodes in a random way (also by means of, for example, the random number generator) m nodes are selected, the first of which is nominated to be the main node of the next round and the rest of m nodes are nominated as the trusted nodes of the next round.

Then, transactions received from all nodes of the decentralized network platform come to main node 1, as shown in Fig. 4. Fig. 4 illustrates the flowchart of sending transactions from all nodes of the decentralized network to the main one (marked in the drawings as node 1).

Initially, the transaction is generated and stored at the sending node. The transaction contains, for example, information on the user’s actions. The transactions generated during the selection of the main and trusted nodes, as it was mentioned above with reference to Figs. 2 and 3, are sent from all nodes, except the trusted ones, to the main node.

Further, as it is shown in Fig. 5 , main node 1 of the decentralized network platform for s a vector of transaction-candidates to be included in the ledger. The said vector, in its turn, is sent by main node 1 to all trusted nodes (in Fig. 4 - nodes 2, 3, m).

The said vector of the transaction-candidates may look, for example, as follows:

Where, T parameters are the transactions containing information, for example, about the sending node and a transaction number associated with the sending node.

Then, as it is shown in Fig. 6 the deltas of transactions can be exchanged among all trusted decentralized network nodes in the decentralized network platform. However, for this purpose each trusted node, after receiving the vector of the transaction-candidates to be included in the ledger, verifies each transaction in the indicated vector by its own ledger.

To verify the transactions each trusted node may calculate and compare, for example, wallet deltas (blockchain wallets), which, for example, denote the balance of the nodes after confirmation of all transaction-candidates for this trusted node. After verifying the transactions, each trusted node puts a digital signature that is individual for each trusted node (by digital signature may be meant a unique digital signature (for example, a digital stamp), generated, for example, in a random way for each node of the network, that is put by the node on the data). The digital signature is unique for each node and, for example, can be generated for each of the nodes at its connection to the system. The digital signature is an identifier of the node that has made operations with data to the transaction deltas vector and it redirects the transaction deltas vector to all other trusted nodes.

After sending the transaction deltas vector (i.e. the difference in data) to the trusted nodes, each of the trusted nodes has a generated transaction delta matrix received from all trusted nodes. Then, the transaction delta matrices are exchanged (as shown in Fig. 7), under the principle analogous to the above-mentioned sending the transaction delta vector to all trusted nodes.

The transaction delta matrix containing values of the transactions deltas may look, for example, as follows:

Then, after the exchange of transaction delta matrices is completed, each of the tmsted nodes, without exception, can calculate the“cube of transaction deltas” for making a decision

by the most frequently encountered values of the transactions.

Delta matrices are collected from all trusted nodes, for example, looking as follows:

Where, D c a d b - wallet delta (blockchain delta)“a” for transaction“b”, calculated in node “c”, received from node“d”.

Each trusted node goes through all obtained matrices and generates the vector of the most frequently encountered deltas of the transactions, for example, looking as follows

( \ m . n m . . m

al_2 > a N_X N )

It should be noted that if in the course of going through all obtained matrices several different most frequently encountered values of deltas for transactions are discovered, then an empty value is written to the resulting vector for this transaction.

Further, after generating the vector of the most frequently encountered deltas of transactions each trusted node is configured to calculate the final vector of majority for each transaction.

The said matrix of the delta majority may look, for example, as follows:

The majority vector for each transaction may look, for example, as follows:

(D'i,; D' 1z ; ... D' NCn

Similarly to the above-mentioned, if while creating the vector of transaction deltas several different most frequently encountered values of deltas for the transaction are discovered, then the empty value will be written to the resulting vector for this transaction.

After calculation of the resulting vector at each trusted node it is already possible to generate the vector containing values of only approved transactions, and in this case, the said vector shall be identical at each honest node.

It can be assumed that at this stage it is already possible to generate a complete blockchain block that can be written to the ledger only with clean transactions.

Fig. 8 illustrates the selection of the new trusted writing node for the writing of the new block to the ledger.

To write the new block to the ledger one of the trusted nodes shall be used, that earlier has made a positive decision on the block, identical to the majority of other tmsted nodes. It can be said that such node is a“guaranteed honest node”.

The procedure of isolation of the so-called“traitor nodes” from the number of trusted nodes, that shall be isolated, can be performed, for example, by means of verifying the result of decision-making while determining the majority for each transaction (as described above).

The trusted nodes, which have made decisions mismatching with the majority’s decision, are excluded from the list of trusted nodes that potentially can write the new block to the ledger. The remaining list will be identical at all honest nodes.

Any node is randomly selected from the remaining nodes. This node afterward becomes the new writing node of the block to the blockchain.

The new writing node serves as a new block hash generator and writes the new block of the blockchain to the ledger. This very node will distribute the new block among all nodes in the system. After distributing the new blockchain block, a new round (stage) of the system operation starts in the decentralized network platform.

So, it should be apparent to those skilled in the art that such arrangement of the group collaborative decision-making by the network nodes made it possible to achieve such advantages as, for example, availability of the ledger itself, as the network nodes can write data to the ledger and read it from the ledger any time.

Therewith, the“flexibility” or modifiability of the system is ensured, as all the nodes of the system, without exception, participate in decision making, and such decisions are consensus and acceptable for all the network nodes without exception.

Also, such new arrangement of the decision-making procedure ensures unambiguous and absolute consistency of all network nodes without exception, as all of them (including the tmsted ones) see an identical version of the ledger, which shall be updated after making changes to the ledger.

It should further be noted that such arrangement of the collaborative decision making procedure by the nodes ensures resistance of nodes to separation, as, if one (any) of the nodes becomes inoperable, for example, in case of its physical disconnection or due to other circumstances, the operation capability of the ledger and entire system will not be affected, the system keeps working in a routine mode and it does not affect the quality, speed, and effectiveness of making decisions by the system.

It should be realized that the above description is aimed to disclose but not to limit the spirit of the invention by the embodiment example provided. Other alternative embodiments of the invention will also become apparent to those skilled in the art as it follows from the claims, the full and clear proof of which are the description and drawings attached hereto.