WO2019199205A1 - Method of scaling a distributed information system - Google Patents

Method of scaling a distributed information system Download PDF

Info

Publication number
WO2019199205A1
WO2019199205A1 PCT/RU2019/000213 RU2019000213W WO2019199205A1 WO 2019199205 A1 WO2019199205 A1 WO 2019199205A1 RU 2019000213 W RU2019000213 W RU 2019000213W WO 2019199205 A1 WO2019199205 A1 WO 2019199205A1
Authority
WO
WIPO (PCT)
Prior art keywords
recipient
transaction
node
subchain
sabchain
Prior art date
Application number
PCT/RU2019/000213
Other languages
French (fr)
Russian (ru)
Inventor
Максим Михайлович МИХАЙЛЕНКО
Игорь Олегович БЕЛОУСОВ
Original Assignee
Максим Михайлович МИХАЙЛЕНКО
Игорь Олегович БЕЛОУСОВ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Максим Михайлович МИХАЙЛЕНКО, Игорь Олегович БЕЛОУСОВ filed Critical Максим Михайлович МИХАЙЛЕНКО
Publication of WO2019199205A1 publication Critical patent/WO2019199205A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the invention relates to the field of digital data processing using electrical devices, in particular to digital computing or data processing methods designed for specific functions, including information retrieval, as well as database structuring for this purpose.
  • a hash is a sequence of characters formed by using a mathematical function, which consists in converting input data of an arbitrary length into an (output) line of a fixed, shorter length. With any change in the input data, the hash of this data will be different from the hash of unchanged input data.
  • Blockchain is a data structure consisting of data blocks in which each block (except the first) has a hash of the block created by the previous one. A certain “chain” of blocks is created where each next block is “connected” (has a link to a hash) with the previous block. This structure ensures that if even one bit in the data block changes, its hash will change, which means that the link to the changed block in the next block will not coincide with the new hash. Break will happen chains, which is easily found with a simple check (here you can insert pictures almost everywhere)
  • a blockchain network is a set of nodes with the same blockchain software implementation, which have one more identical software that allows them to communicate with each other through communication channels, exchange blocks and create new blocks.
  • Subchain is a blockchain network, the software of which provides for the possibility of interaction with other blockchain networks through communication channels having the same software.
  • Sidechain is a blockchain network, the software of which provides the ability to interact with the main (parent) blockchain network.
  • Sidechain model a model of interaction between blockchain networks, the main (parent) blockchain network and sidechains.
  • Node - a computer that has means of communication with other computers on which the software runs with some kind of blockchain.
  • the Merkle tree is a complete binary tree, in the leaf vertices of which hashes from data blocks are placed, and the inner vertices contain hashes from adding values in child vertices.
  • the confirmation of the Merkle tree is one branch of the full Merkle tree of the block, in which there is information about only one transaction (the confirmation of which is generated), and all other vertices contain only hashes from neighboring branches.
  • Verification methods as a result of which it can be unambiguously confirmed that the data in question does not contain errors or forgery.
  • a method for verifying a transaction already entered into a block by its MTP First, the correspondence of the information contained in the transaction of the user's signature is checked, then the hash of the transaction is calculated and checked whether it matches what is specified in the MTP, then all the following hash pairs are calculated and their compliance with the data in the MTP is checked, up to the root hash of the block. Then the validity of the block hash is checked.
  • Block validity is a way to check the block hash, confirming that this block belongs to the blockchain of the corresponding sacchain and was created in the consensus process of this subchain. For verification, it is enough to check all the digital signatures of the block hash provided by the subchain nodes. If all signatures belong to the nodes that at that time participated in the consensus on the creation of this block, then the hash of the block passed the check.
  • a digital signature is a small sequence of characters that, using cryptographic transformations, unambiguously allows you to determine that it was used for signing information and the user's private key signing this information.
  • Consensus is a way of interactions between nodes in a blockchain network (participants), as a result of which a new block is created.
  • Digital value is a record with data in the blockchain, which has an owner. The possession of such data is easily verified using software that implements the ability to work with the blockchain, in which the possession of digital values is possible.
  • a double waste is the actions of an attacker, in which information about the transfer of digital value that has already been transferred earlier is proposed for recording in the new block of the blockchain.
  • a new amount of unsecured values appears in the blockchain.
  • Scalability the ability of a system to cope with an increase in workload (increase its productivity) when adding resources. Distinguish between vertical and horizontal scaling.
  • Decentralization is the process of transferring decision-making rights from a single decision-making structure to more numerous dispersed or distributed structures.
  • a single node adoption making decentralized systems as low as possible
  • such a system is called centralized.
  • nodes are added to the system, the failure of which does not lead to the termination of the system, a decentralization process takes place.
  • this is information generated by the user for writing on the blockchain.
  • it may contain an instruction to re-register the value from one owner to another.
  • the authenticity of the order is ensured by the user signing this information with a digital signature of the user
  • User address is a small sequence of characters that is directly related to the user's public key. This connection can be created using cryptographic functions as well as other actions (for example, a user’s address can be just a public key of a user).
  • the way the user address is associated should be easily verifiable. For example, a public key hash is one way to communicate this. It is easy to establish that when changing even one bit in an open key, the address will also change.
  • a single user address space is a requirement for subchains.
  • all subchains use the same way of communication between the user's address and his public key; Subchains have a way of searching and finding a user's subchain, provided that the user's address is known.
  • P2P structure is the structure of a computer network based on the equal rights of participants. In such a structure, each computer is both a client (receives data for its needs from servers) and a server (sends data to other users). Unlike the classical client-server architecture, this structure allows you to maintain the operability of the communication network with any number and any combination of available nodes.
  • SPV is a simplified payment verification
  • the data structure in the blockchain described in US20160330034A1 is used to confirm the fact of blocking digital values in one blockchain network for their subsequent transfer to another blockchain network.
  • IBC Inter-blockchain Communication
  • Inter-blockchain Communication a protocol by which a data packet is transferred from one blockchain network to another via the Cosmos Hub in the Cosmos project.
  • the described system allows you to create a lot of sidechains around the parent blockchain, which, working independently from each other, can transfer values created inside the parent blockchain to each other through the parent blockchain (Fig. 1).
  • the method describes only the transfer of values from the parent blockchain to the sidechain and then the return of these values back.
  • the method does not include work with non-financial transactions. Also, the possibility of sidechains to transfer their values to the parent blockchain or other sidechains is not provided.
  • the indicated method also uses the model shown in Fig. 1, but uses it primarily for scaling: 1. All the main actions take place in sidechains, called “zones” in this project.
  • Parent blockchain (Cosmos hub is named in this method) is used for the most part only as a guarantor for transferring transactions (both value and other) between zones (Fig. 2).
  • Fig. 2 guarantor for transferring transactions (both value and other) between zones (Fig. 2).
  • htps //raw.githubusercontent.com/gnuclear/atom-whitepaper / master / images / hub_and_zones.png - drawing from the project).
  • the problem is that when you capture most of the nodes in the blockchain network, from a person who has access to most of the nodes in the blockchain network, it is possible to produce double spending.
  • the essence of the way of using sidechains, proposed in the indicated technical solution, is based on the fact that the central (main parent) blockchain has much greater security compared to sidechains due to greater decentralization.
  • sidechains who cannot “trust” each other due to security problems due to low decentralization can “trust” the central blockchain and use it as
  • the disadvantages of this method is that any inter-zone transaction must go through the Cosmos HUB, which increases the time of inter-zone transactions by several times relative to intra-zone ones.
  • the time of the inter-zone transaction will be equal to the sum of the times of registration of the transaction in the source zone, registration of the fact of the transaction in Cosmos HUB, registration in the recipient zone.
  • the present invention is intended to solve the technical problem of enabling horizontal scaling of a distributed information system consisting of blockchain networks by increasing the overall performance of this system by adding an unlimited number of blockchain networks to the system.
  • the technical result consists in providing the possibility of forming multi-level structures from peer-to-peer interacting blockchain networks acting as separate cells for next-level networks.
  • the block validation algorithm is the same in all subchains (firstly, it allows you to relatively quickly and reliably validate the block from another subchain, due to the unified block validation algorithm common to all subchains; secondly, it allows nodes to leave the same subchain and enter to another subchain by removing the entire old subchain from the blockchain node and uploading the whole new subchain to the node of the other blockchain; thirdly, it allows the nodes to merge to create a new subchain);
  • Each subchain node has a complete picture of the structure of all other subchains due to the fact that each subchain node contains information about the addresses of all other nodes and their affiliation to the subchains. This allows any node to easily validate the received block or packet with data from other subchains. Each node also has the same mechanism for obtaining information about changes in these structures;
  • Subchains due to the fulfillment of the requirements of paragraph 3, can be combined into a two-level p2p structure (Fig. 1).
  • the total throughput of such a structure will be equal to the sum of the throughputs of all participating subchains.
  • Communication between subchains is of two types.
  • the first type is the transfer of transactions from one subchain to another via the standard protocol for this method (clause 3)
  • the second type of interaction is maintaining a generalized register of all nodes (blockchain subchains) and their organization into subchains.
  • blockchain subchains To maintain this registry, the same consensus method is used as in the blockchain network, only subchains are used as consensus participants (in order for the subchain to vote for validation of the block for consensus between subchains, you must provide confirmation that inside the subchain voice confirmation was recorded in the block of this subchain and validated by the nodes included in it).
  • transactions from one sub-chain of the 1st level are also directly transferred to the recipient of the sub-chain of the 1st level, while the approval of the node registry goes through multi-level validation.
  • the number of nodes in the subchain can be any, but the rule must be observed according to which it is possible to reduce the number of nodes only to a safe minimum. For each specific situation, depending on the field of activity of the enterprise for which the claimed method is used, the safe minimum may be different. However, a balance must be struck between decentralization, efficiency and responsibility of nodes.
  • the essence of the claimed for registration in this application method is as follows: The user who sends the transaction signs the transaction by applying a cryptographic function to the transaction and its own private key (a mechanism similar to the operation of digital signature), which results in a transaction signature. After that, the user who sends the transaction sends the transaction and the transaction signature to the subchain node through the communication channel (for example, via the Internet).
  • the Sabchain node through communication channels with other Sabchain nodes, transfers the transactions received by it and the transaction signatures of the users of the transaction senders to other nodes of the Sabchain for inclusion by the Sabchain nodes of the transactions sent by this Sabchain node of the transactions and the transaction signatures of the users of the transaction senders in a new data block.
  • all transactions where the user-recipient of the transaction is registered in the wrong sub-chain in which the user-sender of the transaction is registered are allocated in a separate section of the new data block. Thus, two sections are created in the new data block:
  • the nodes After a new block is included in the sender subchain blockchain, the nodes extract all transactions from their MTP from the 2nd section of this block. Then the node forms outgoing transaction packets with their MTP for each recipient recipient. Each transaction package with their MTP contains the number of the package for the recipient sub-chain, the address of the recipient sub-chain, the header of a new data block, as well as transactions from their MTP.
  • the nodes included in the sender’s subchain transmit over the communication channels all the generated packets at least to one of the recipient’s subchain nodes.
  • the nodes of the Sabchain recipients of packets with transactions with their MTP Upon receipt by the nodes of the Sabchain recipients of packets with transactions with their MTP from the sending sabchain, the nodes of the Sabchain recipients of packets with transactions with their MTP first check the number of each transaction packet with their MTP by correlating the number of the received packet with the transactions with their MTP with the number of the previous registered transaction package with their MTP, and if the number of the received package with transactions with their MTP is 2 or more than the number of the previous transaction packet receiver registered in the subchain with their MTP, recipient subchain nodes direct these received packets with transactions from their MTP to the waiting queue for missed transaction packets from their MTP, which, in turn, as the missing transaction packets arrive from their MTP, go to the next stage.
  • the packet with the next packet number after the recipient previously registered in the subchain is validated by the subchain-recipient nodes by validating all transactions contained in the packet with their MTP.
  • the transaction package with their MTP is included in the new recipient subchain block, and the balances of user-recipient transactions from the transaction package with their MTP are changed in accordance with these transactions.
  • the recipient’s subchain sends via the communication channels to the sender’s subchain the information about entering the transaction packet from their MTP into the new data block of the recipient’s subchain from the MTP of the transaction packet from
  • the sender's subchain node validates the MTP of the transaction packet from their MTP. If validation is carried out by the sender’s Sabchain node, information about entering the transaction packet from their MTP into a new data block of the recipient’s Sabchain from the MTP of the transaction packet from their MTP is entered into the new sender’s Sabchain block. This completes the work of registering a user’s transaction.
  • the sender’s Sabchain node If the sender’s Sabchain node has not received information on entering the transaction packet from their MTP into the new recipient’s Sabchain data block from the MTP of the transaction packet from their MTP via the communication channels for the time specified by the blockchain network settings, the sender’s Sabchain node re-sends the transaction packet with their MTP to the address of the recipient sabchain node. This continues until the sender’s Sabchain node receives, through communication channels, information about the introduction of the transaction packet from their MTP into the new data block of the recipient’s Sabchain from the MTP of the transaction packet from their MTP.
  • the described method will help in the logistics industry. Take a company that has several warehouses. To prevent cases of substitution of goods or changing data on deliveries retroactively, the management decided to use the blockchain. Using our method, all warehouses can be represented as subchains. In these subchains everything that happens inside their respective warehouses is fixed. And logistic movements between warehouses are executed in the form of intersubschain transactions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention relates to the field of digital data processing with the aid of electrical devices, and particularly to methods of digital computing or data processing that are intended for specific functions, inter alia, information retrieval and also structuring databases for this purpose. The technical result consists in making it possible to create multi-level structures from peer-to-peer blockchain networks functioning as separate cells for next-level networks. A method of scaling a distributed information system consists in creating a transaction, signing said transaction, sending said transaction to a subchain node where it is entered into a new block, and then sending the transactions in which the recipient is registered in a different subchain to the subchain of the recipient and including said transactions in the new data block of recipient subchain, then transferring information from the subchain of the recipient confirming the receipt of the transactions to the subchain of the sender and entering said information into the new data block of sender subchain. The claimed method can be used for organizing data exchange in enterprises working in the logistics field, in robotized industrial facilities, in the banking sector, and in other fields.

Description

Способ масштабирования распределенной информационной системы  Method for scaling a distributed information system
Область техники, к которой относится изобретение FIELD OF THE INVENTION
Изобретение относится к области обработки цифровых данных с помощью электрических устройств, в частности к методам цифровых вычислений или обработки данных, предназначенных для специфических функций, в том числе информационного поиска, а также структурирования баз данных для этой цели. The invention relates to the field of digital data processing using electrical devices, in particular to digital computing or data processing methods designed for specific functions, including information retrieval, as well as database structuring for this purpose.
Глоссарий Glossary
С целью обеспечения достаточности раскрытия изобретения и обеспечения возможности проведения информационного поиска в отношении заявляемого технического решения ниже приведен перечень терминов, используемых в настоящем описании. In order to ensure the sufficiency of the disclosure of the invention and to enable the information search in relation to the claimed technical solution, the following is a list of terms used in the present description.
Хеш - последовательность символов, формируемая с помощью применения математической функции, заключающейся в преобразовании входных данных произвольной длины в (выходную) строку установленной, меньшей длины. При любом изменении входных данных хеш этих данных будет отличаться от хеша неизменных входных данных. A hash is a sequence of characters formed by using a mathematical function, which consists in converting input data of an arbitrary length into an (output) line of a fixed, shorter length. With any change in the input data, the hash of this data will be different from the hash of unchanged input data.
Блокчейн— структура данных, состоящая из блоков данных, в которой в каждом блоке (кроме первого) имеется хеш созданного предыдущим блока. Создается некая “цепочка” блоков где каждый следующий блок“связан” (имеет ссылку на хеш) с предыдущим блоком. Такая структура гарантирует, что при изменении даже одного бита в блоке данных изменится его хеш, а значит, ссылка на измененный блок в следующем блоке не будет совпадать с новым хешем. Произойдет разрыв цепочки, что легко находится при простой проверке (тут почти везде можно картинки вставлять) Blockchain is a data structure consisting of data blocks in which each block (except the first) has a hash of the block created by the previous one. A certain “chain” of blocks is created where each next block is “connected” (has a link to a hash) with the previous block. This structure ensures that if even one bit in the data block changes, its hash will change, which means that the link to the changed block in the next block will not coincide with the new hash. Break will happen chains, which is easily found with a simple check (here you can insert pictures almost everywhere)
Блокчейн сеть - множество узлов с одинаковой программной реализацией блокчейна, имеющие еще одно одинаковое программное обеспечение позволяющее им связываться между собой через каналы связи, обмениваться блоками и создавать новые блоки. A blockchain network is a set of nodes with the same blockchain software implementation, which have one more identical software that allows them to communicate with each other through communication channels, exchange blocks and create new blocks.
Сабчейн — блокчейн сеть, программное обеспечение которой предусматривает возможность взаимодействия с другими блокчейн сетями через каналы связи, имеющими такое же программное обеспечение. Subchain is a blockchain network, the software of which provides for the possibility of interaction with other blockchain networks through communication channels having the same software.
Сайдчейн — блокчейн сеть, программное обеспечение которой предусматривает возможность взаимодействия с основной (родительской) блокчейн сетью. Sidechain is a blockchain network, the software of which provides the ability to interact with the main (parent) blockchain network.
Модель Сайдчейн — модель взаимодействия между блокчейн сетями -основной (родительской) блокчейн сетью и сайдчейнами. Sidechain model - a model of interaction between blockchain networks, the main (parent) blockchain network and sidechains.
Узел— ЭВМ, имеющая средства связи с другими ЭВМ, на которой исполняется программное обеспечение с каким-либо вариантом блокчейн. Node - a computer that has means of communication with other computers on which the software runs with some kind of blockchain.
МТР - подтверждение дерева Меркла (Merkle Tree Proof). Деревом Меркла называют полное двоичное дерево, в листовые вершины которого помещены хеши от блоков данных, а внутренние вершины содержат хеши от сложения значений в дочерних вершинах. Подтверждение дерева Меркла, это одна ветка полного дерева Меркла блока, в котором есть информация только об одной транзакции (подтверждение которой и формируется), а все остальные вершины содержат лишь хеши от соседних веток. При предоставлении МТР, в случае верности всех хешей узлов и совпадении корневых хешей МТР и блока можно однозначно утверждать, что МТР является частью блока. Валидация— имеет два значения: 1. Способ проверки, с помощью которого узел подтверждает, что созданный блок не содержит ошибок или подлога. MTP - confirmation of the Merkle Tree Proof. The Merkle tree is a complete binary tree, in the leaf vertices of which hashes from data blocks are placed, and the inner vertices contain hashes from adding values in child vertices. The confirmation of the Merkle tree is one branch of the full Merkle tree of the block, in which there is information about only one transaction (the confirmation of which is generated), and all other vertices contain only hashes from neighboring branches. When MTP is provided, if all hashes of the nodes are true and the root hashes of the MTP and the block coincide, we can clearly state that the MTP is part of the block. Validation - has two meanings: 1. The verification method by which the node confirms that the created block does not contain errors or forgery.
2. Способы проверки, в результате которых можно однозначно подтвердить, что рассматриваемые данные не содержат ошибок или подлога. Как частный случай рассмотрим способ проверки транзакции уже внесенной в блок по её МТР. Сначала проверяется соответствие информации содержащейся в транзакции подписи пользователя, затем вычисляется хеш транзакции и проверяется соответствует ли он тому что указан в МТР, затем вычисляется все следующие пары хешей и проверяется их соответствие с данными в МТР, вплоть до корневого хеша блока. Затем проверяется валидность хеша блока. 2. Verification methods, as a result of which it can be unambiguously confirmed that the data in question does not contain errors or forgery. As a special case, we consider a method for verifying a transaction already entered into a block by its MTP. First, the correspondence of the information contained in the transaction of the user's signature is checked, then the hash of the transaction is calculated and checked whether it matches what is specified in the MTP, then all the following hash pairs are calculated and their compliance with the data in the MTP is checked, up to the root hash of the block. Then the validity of the block hash is checked.
Валидность блока (валидность хеша блока )— способ проверки хеша блока, подтверждающий, что это блок принадлежит блокчейну соотвествующего сачбейна и создан в процессу консенсуса этого сабчейна. Для проверки достаточно проверить все представленные узлами сабчейна цифровые подписи хеша блока. Если все подписи принадлежат узлам, в то время участвовавшим в консенсусе по созданию этого блока, то хеш блока прошел проверку. Block validity (block hash validity) is a way to check the block hash, confirming that this block belongs to the blockchain of the corresponding sacchain and was created in the consensus process of this subchain. For verification, it is enough to check all the digital signatures of the block hash provided by the subchain nodes. If all signatures belong to the nodes that at that time participated in the consensus on the creation of this block, then the hash of the block passed the check.
Цифровая подпись — небольшая последовательность символов, которая с помощью криптографических преобразований однозначно позволяет определить то, что для ее создания использовалась подписываемая информация и закрытый ключ пользователя, подписывающий эту информацию. A digital signature is a small sequence of characters that, using cryptographic transformations, unambiguously allows you to determine that it was used for signing information and the user's private key signing this information.
Консенсус — способ взаимодействий узлов в блокчейн-сети (участников), в результате которого создается новый блок. Цифровая ценность— запись с данными в блокчейн, которая имеет владельца. Владение такими данными легко проверяется с помощью программного обеспечения, реализующего возможность работы с блокчейном, в котором возможно владение цифровыми ценностями. Consensus is a way of interactions between nodes in a blockchain network (participants), as a result of which a new block is created. Digital value is a record with data in the blockchain, which has an owner. The possession of such data is easily verified using software that implements the ability to work with the blockchain, in which the possession of digital values is possible.
Двойная трата— действия злоумышленника, при которой в новый блок блокчейна предлагается для записи информация о передаче цифровой ценности, уже переданной ранее. В случае создания блока с такой записью в блокчейне появляется новый объем необеспеченных ценностей. A double waste is the actions of an attacker, in which information about the transfer of digital value that has already been transferred earlier is proposed for recording in the new block of the blockchain. In the case of creating a block with such an entry, a new amount of unsecured values appears in the blockchain.
Масштабируемость - способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов. Различают вертикальное и горизонтальное масштабирование. Scalability - the ability of a system to cope with an increase in workload (increase its productivity) when adding resources. Distinguish between vertical and horizontal scaling.
Вертикальное масштабирование - увеличение общей производительности путем замены одного из составляющих системы на более производительный аналог. Однако в любой момент времени у такого масштабирования есть ограничения, так как после замены всех частей на наиболее мощные, нет возможности дальнейшего улучшения. Vertical scaling - an increase in overall performance by replacing one of the components of the system with a more productive analogue. However, at any point in time, such scaling has limitations, since after replacing all parts with the most powerful ones, there is no possibility of further improvement.
Горизонтальное масштабирование - увеличение общей производительности создания новых копий объектов системы (добавление серверов, процессоров). Этот способ увеличения производительности сильно зависит от модели взаимодействия объектов системы. Чем более удачная модель принята, тем больший эффект достигается при добавлении новых копий. Horizontal scaling - increasing the overall productivity of creating new copies of system objects (adding servers, processors). This method of increasing productivity is highly dependent on the model of interaction between system objects. The more successful the model is adopted, the greater the effect is achieved when adding new copies.
Децентрализация— процесс передачи прав принятия решений от единой структуры принятия решения к более многочисленным рассеянным или распределенным структурам. В случае информационных систем, о которых говорится в данном способе, при единичном узле принятия решений децентрализованность системы максимально низкая, такую систему называют централизованной. При добавлении таких узлов в систему, выход которых из строя не приводит к прекращению работы системы, происходит процесс децентрализации. Чем больше независимых друг от друга узлов в системе, тем выше её децентрализованность. Например, у системы bitcoin в настоящее время более 10 тысяч независимых узлов. Decentralization is the process of transferring decision-making rights from a single decision-making structure to more numerous dispersed or distributed structures. In the case of the information systems referred to in this method, with a single node adoption making decentralized systems as low as possible, such a system is called centralized. When such nodes are added to the system, the failure of which does not lead to the termination of the system, a decentralization process takes place. The more nodes are independent from each other in the system, the higher is its decentralization. For example, the bitcoin system currently has over 10 thousand independent nodes.
Транзакция — в рамках данного способа это информация, сформированная пользователем для записи в блокчейне. В частном случае может содержать поручение на перерегистрацию ценности от одного владельца к другому. Подлинность поручения обеспечивает подписание пользователем этой информации цифровой подписью пользователя Transaction - in the framework of this method, this is information generated by the user for writing on the blockchain. In a particular case, it may contain an instruction to re-register the value from one owner to another. The authenticity of the order is ensured by the user signing this information with a digital signature of the user
Балансы пользователя — совокупность всех транзакций, обеспечивающих изменение ценностей в блокчейне, в которых принимал участие пользователь (его адрес). Так как таких транзакций может быть много, отслеживается только результат расходных и природных транзакций по каждому виду цифровых ценностей. User balances - the totality of all transactions that provide a change in values in the blockchain in which the user (his address) participated. Since there can be many such transactions, only the result of expendable and natural transactions for each type of digital value is tracked.
Адрес пользователя— небольшая последовательность символов, которая напрямую связана с открытым ключом пользователя. Эта связь может быть создана как с помощью криптографических функций, так и иных действий (например, адрес пользователя может быть просто открытым ключом пользователя). Способ, которым связан адрес пользователя, должен быть легко проверяем. Например, хеш открытого ключа - один из способов такой связи. Легко установить, что при смене даже одного бита в открытом ключе изменится и адрес. User address is a small sequence of characters that is directly related to the user's public key. This connection can be created using cryptographic functions as well as other actions (for example, a user’s address can be just a public key of a user). The way the user address is associated should be easily verifiable. For example, a public key hash is one way to communicate this. It is easy to establish that when changing even one bit in an open key, the address will also change.
Единое пространство адресов пользователей — требование к сабчейнам. Реализуется с помощью следующих особенностей: все сабчейны используют одинаковый способ связи между адресом пользователя и его открытым ключом; сабчейны имеют способ поиска и нахождения сабчейна пользователя при условии, что известен адрес пользователя. р2р структура— это структура сети связей ЭВМ, основанная на равноправии участников. В такой структуре каждая ЭВМ является одновременно и клиентом (получает данные для своих нужд от серверов) и сервером (отправляет данные другим пользователям). В отличие от классической архитектуры клиент-сервера, такая структура позволяет сохранять работоспособность сети связи при любом количестве и любом сочетании доступных узлов. A single user address space is a requirement for subchains. Implemented using the following features: all subchains use the same way of communication between the user's address and his public key; Subchains have a way of searching and finding a user's subchain, provided that the user's address is known. P2P structure is the structure of a computer network based on the equal rights of participants. In such a structure, each computer is both a client (receives data for its needs from servers) and a server (sends data to other users). Unlike the classical client-server architecture, this structure allows you to maintain the operability of the communication network with any number and any combination of available nodes.
SPV — упрощенная проверка платежа (simplified payment verification) структура данных в блокчейне, описанная в патенте US20160330034A1, применяется для подтверждения факта блокировки цифровых ценностей в одной блокчейн сети для последующего их перевода в другую блокчейн сеть. SPV is a simplified payment verification, the data structure in the blockchain described in US20160330034A1 is used to confirm the fact of blocking digital values in one blockchain network for their subsequent transfer to another blockchain network.
IBC — Межблокчейновое взаимодействие (Inter-blockchain Communication) — протокол, с помощью которого происходит перемещение пакета данных из одной блокчейн сети в другую через Cosmos Hub в проекте Cosmos. IBC - Inter-blockchain Communication (Inter-blockchain Communication) - a protocol by which a data packet is transferred from one blockchain network to another via the Cosmos Hub in the Cosmos project.
Уровень техники State of the art
Впервые модель взаимодействия между двумя блокчейнами, названная впоследствии сайдчейн, была описана в статье “Enabling Blockchain Innovations with Pegged Sidechains” от 2014-10-22. Позже был выдан патент US20160330034A1 отражающий способ, описанный в этой статье. Данный патент раскрывает новые методы взаимодействия двух блокчейнов по переносу цифровых ценностей из одного блокчейна (названного основным или родительским) в другой (названный сайдчейном), с возможностью последующего возврата этих ценностей и с защитой от появления двойной траты, как при нахождении ценностей внутри сайдчейна, так и в процессе передачи как в сайдчейн, так и из сайдчейна. For the first time, the model of interaction between the two blockchains, later called the sidechain, was described in the article “Enabling Blockchain Innovations with Pegged Sidechains” from 2014-10-22. Patent US20160330034A1 was later issued reflecting the method described in this article. This patent discloses new methods of interaction between two blockchains for transferring digital values from one blockchain (called primary or parent) to another (called sidechain), with the possibility of subsequent return of these values and with protection against double spending, as when finding values inside the sidechain, and in the process of transferring both to the sidechain and from the sidechain.
Таким образом, описанная система позволяет создавать вокруг родительского блокчейна множество сайдчейнов, которые, работая независимо друг от друга, могут передавать ценности, созданные внутри родительского блокчейна, между собой, через родительский блокчейн (Фиг. 1). Thus, the described system allows you to create a lot of sidechains around the parent blockchain, which, working independently from each other, can transfer values created inside the parent blockchain to each other through the parent blockchain (Fig. 1).
Также возможна схема с многоуровневыми сайдченами, когда сайдчейн верхнего уровня выступает родительским блокчейном для другого сайдчейна, однако, насколько нам известно, такой способ пока не был нигде использован. A scheme with multi-level sidechains is also possible, when the top level sidechain acts as the parent blockchain for another sidechain, however, as far as we know, this method has not been used anywhere else.
К достоинствам способа, раскрытого в патенте US20160330034A1, можно отнести следующие показатели: The advantages of the method disclosed in the patent US20160330034A1 include the following indicators:
1. С помощью данного способа можно безопасно переносить ценности из родительского блокчейна в сайдчейны и обратно, в частности, при осуществлении данного способа невозможно возникновение двойной траты при переносе ценностей. 1. Using this method, you can safely transfer values from the parent blockchain to sidechains and vice versa, in particular, when implementing this method, it is impossible to incur double spending when transferring values.
2. Если несколько транзакций были совершены внутри сайдчейна, они производятся без нагрузки на родительский блокчейн, следовательно, такой способ теоретически позволяет добиться большей производительности, чем обычный блокчейн, и, следовательно, позволяет масштабировать модель. Тем не менее, данный способ имеет следующие недостатки: 2. If several transactions were made inside the sidechain, they are carried out without load on the parent blockchain, therefore, this method theoretically allows for greater performance than a conventional blockchain, and, therefore, allows you to scale the model. However, this method has the following disadvantages:
1. Метод описывает только перенос ценностей из родительского блокчейна в сайдчейн и потом возвращение этих ценностей обратно. Способ не предусматривает работу с нефинансовыми транзакциями. Также не предусматривается возможность сайдчейнов передавать свои ценности в родительский блокчейн или другие сайдчейны. 1. The method describes only the transfer of values from the parent blockchain to the sidechain and then the return of these values back. The method does not include work with non-financial transactions. Also, the possibility of sidechains to transfer their values to the parent blockchain or other sidechains is not provided.
2. Реализовать описанную ранее в качестве положительного результата возможность масштабирования и повышения производительности рассматриваемого способа на практике не представляется возможным, так как данный способ основывается на методе SPV, что обуславливает наличие существенного периода ожидания в 1-2 дня (пункт [0042] в патенте US20160330034A1) при переходе и возврате ценностей между родительским блокчейном и сайдчейном.  2. To realize the possibility of scaling and improving the performance of the method described above as a positive result in practice is not possible, since this method is based on the SPV method, which leads to a significant waiting period of 1-2 days (paragraph [0042] in the patent US20160330034A1 ) during the transition and return of values between the parent blockchain and sidechain.
Впоследствии идею, указанную в патенте US20160330034A1, развили до способа использования этой модели с похожими связями между блокчейнами для масштабирования Subsequently, the idea indicated in patent US20160330034A1 was developed to a method of using this model with similar connections between blockchains for scaling
(htps://cosmos.network/whitepaper). (htps: //cosmos.network/whitepaper).
Указанный способ также использует модель, представленную на рис. 1, но использует ее, в первую очередь, для масштабирования: 1. Все основные действия происходят в сайдчейнах, названных в этом проекте «зонами». The indicated method also uses the model shown in Fig. 1, but uses it primarily for scaling: 1. All the main actions take place in sidechains, called “zones” in this project.
2. Родительский блокчейн (в этом способе назван Cosmos hub) используется в большинстве своем только как гарант по переносу транзакций (как ценностных, так и иных) между зонами (Фиг. 2). (htps://raw.githubusercontent.com/gnuclear/atom- whitepaper/master/images/hub_and_zones.png - рисунок из проекта). Проблема заключается в том, что при захвате большинства узлов в блокчейн-сети, у лица, имеющего доступ к большинству узлов в блокчейн- сети, возникает возможность производить двойные траты. Суть способа использования сайдчейнов, предлагаемая в указанном техническом решении, основывается на том, что центральный (главный родительский) блокчейн имеет гораздо большую защищенность по сравнению с сайдчейнами в силу большей децентрализованности. Таким образом, сайдчены, которые не могут «доверять» друг другу из-за проблем с безопасностью в силу низкой децентрализованности, могут «доверять» центральному блокчейну и используют его как надежную среду для передачи ценностей. 2. Parent blockchain (Cosmos hub is named in this method) is used for the most part only as a guarantor for transferring transactions (both value and other) between zones (Fig. 2). (htps: //raw.githubusercontent.com/gnuclear/atom-whitepaper / master / images / hub_and_zones.png - drawing from the project). The problem is that when you capture most of the nodes in the blockchain network, from a person who has access to most of the nodes in the blockchain network, it is possible to produce double spending. The essence of the way of using sidechains, proposed in the indicated technical solution, is based on the fact that the central (main parent) blockchain has much greater security compared to sidechains due to greater decentralization. Thus, sidechains who cannot “trust” each other due to security problems due to low decentralization, can “trust” the central blockchain and use it as a reliable medium for transferring values.
К достоинствам способа, раскрытого в патенте US20160330034A1, можно отнести, тот факт, что в отличии от способа, описанного в патенте US20160330034A1, вместо SPV применяется IBC, что существенно уменьшает время на передачу транзакций между Cosmos HUB и зонами. В результате возможно масштабирование пропускной способности системы.  The advantages of the method disclosed in US20160330034A1 include the fact that, in contrast to the method described in US20160330034A1, IBC is used instead of SPV, which significantly reduces the time for transferring transactions between Cosmos HUB and zones. As a result, system bandwidth can be scaled.
Недостатками данного способа является то, что любая межзонная транзакция должна пройти через Cosmos HUB, что в несколько раз увеличивает время межзонных транзакций относительно внутризональных. Время межзонной транзакции будет равно сумме времен регистрации транзакции в зоне источнике, регистрации факта транзакции в Cosmos HUB, регистрации в зоне получателя. The disadvantages of this method is that any inter-zone transaction must go through the Cosmos HUB, which increases the time of inter-zone transactions by several times relative to intra-zone ones. The time of the inter-zone transaction will be equal to the sum of the times of registration of the transaction in the source zone, registration of the fact of the transaction in Cosmos HUB, registration in the recipient zone.
Существует верхний предел пропускной способности по обработке транзакций у Cosmos HUB, связанный с тем, что Cosmos HUB представляет собой обычный блокчейн. При увеличении количества зон, вероятность появления межзонных транзакций увеличивается. Все межзонные транзакции проходят через Cosmos HUB. В случае если количество межзонных транзакций в единицу времени превысят пропускную способность Cosmos HUB, часть межзонных транзакций будет ожидать очереди. Таким образом, предел пропускной способности Cosmos HUB ограничивает и пропускную способность всей системы. There is an upper limit on transaction processing throughput at Cosmos HUB, due to the fact that Cosmos HUB is a regular blockchain. With an increase in the number of zones, the likelihood of inter-zone transactions increases. All interzonal transactions go through the Cosmos HUB. If the number of inter-zone transactions per unit time exceeds the bandwidth of Cosmos HUB, part of the inter-zone transactions will be wait in line. Thus, the Cosmos HUB bandwidth limit also limits the bandwidth of the entire system.
Настоящее изобретение предназначено для решения технической задачи по обеспечению возможности горизонтального масштабирования распределенной информационной системы, состоящей из блокчейн сетей, за счет увеличения общей производительности данной системы с помощью добавления неограниченного количества блокчейн сетей в систему. The present invention is intended to solve the technical problem of enabling horizontal scaling of a distributed information system consisting of blockchain networks by increasing the overall performance of this system by adding an unlimited number of blockchain networks to the system.
Технический результат заключается в обеспечении возможности формирования многоуровневых структур из равноправно взаимодействующих блокчейн сетей, выступающих в качестве отдельных ячеек для сетей следующего уровня. The technical result consists in providing the possibility of forming multi-level structures from peer-to-peer interacting blockchain networks acting as separate cells for next-level networks.
Указанный технический результат при использовании заявляемого способа достигается за счет применения взаимодействующих между собой раскрытым в настоящей заявительной документации способом сабчейнов. Раскрытие изобретения The specified technical result when using the proposed method is achieved through the use of interacting with each other as described in the present application documentation by the method of subchains. Disclosure of invention
Для увеличения производительности блокчейн системы количество узлов, участвующих в консенсусе по созданию новых блоков должно быть ограничено. Чем больше узлов участвует в консенсусе, тем больше тратится времени на согласование. Поэтому в целом для увеличения производительности блокчейн системы необходимо создавать отдельные блокчейны, а потом их каким-либо образом связывать. To increase the productivity of the blockchain system, the number of nodes participating in the consensus on the creation of new blocks should be limited. The more nodes involved in consensus, the more time is spent on reconciliation. Therefore, in general, in order to increase the productivity of the blockchain system, it is necessary to create separate blockchains, and then link them in some way.
Для обеспечения возможности взаимодействия блокчейнов между собой к каждому такому блокчейну предъявляются стандартизированные требования. Блокчейны, которые поддерживают такие требования, мы называем сабчейнами. Стандартные требования, которые в заявленном способе предъявляются к сабчейнам: To ensure that blockchains can interact with each other, standardized requirements are imposed on each such blockchain. Blockchains that support such requirements are called subchains. Standard requirements that apply to the subchain in the claimed method:
1. Алгоритм валидации блока одинаков во всех сабчейнах (во- первых, это позволяет относительно быстро и максимально достоверно валидировать блок из другого сабчейна, за счет единого для всех сабчейнов унифицированного алгоритма валидации блоков; во-вторых позволяет узлам выходить из состава одного сабчейна и входить в состав другого сабчейна путем удаления с узла блокчейна всего старого сабчейна и загрузки на узел другого блокчейна всего нового сабчейна; в-третьих, позволяет узлам объединяться для создания нового сабчейна); 1. The block validation algorithm is the same in all subchains (firstly, it allows you to relatively quickly and reliably validate the block from another subchain, due to the unified block validation algorithm common to all subchains; secondly, it allows nodes to leave the same subchain and enter to another subchain by removing the entire old subchain from the blockchain node and uploading the whole new subchain to the node of the other blockchain; thirdly, it allows the nodes to merge to create a new subchain);
2. Каждый узел сабчейна имеет полное представление о структуре всех остальных сабчейнов за счет того, что каждый узел сабчейна содержит информацию об адресах всех остальных узлов и их принадлежности к сабчейнам. Это позволяет любому узлу легко проводить валидацию полученного блока или пакета с данными от других сабчейнов. Также каждый узел имеет одинаковый механизм получения информации об изменении в этих структурах;  2. Each subchain node has a complete picture of the structure of all other subchains due to the fact that each subchain node contains information about the addresses of all other nodes and their affiliation to the subchains. This allows any node to easily validate the received block or packet with data from other subchains. Each node also has the same mechanism for obtaining information about changes in these structures;
3. Во всех сабчейнах одно общее пространство адресов пользователей (все сабчейны работают с одними и теми же адресами, что и все остальные), в сабчейне присутствует стандартная для настоящего способа система передачи транзакции из сабчейна источника в сабчейн приемника.  3. In all subchains, there is one common user address space (all subchains work with the same addresses as all the others), in the subchain there is a standard system for transferring a transaction from the source subchain to the receiver subchain for the present method.
Сабчейны, благодаря выполнению требований из пункта 3, могут объединятся в двухуровневую р2р структуру (Фиг. 1). При этом общая пропускная способность такой структуры будет равна сумме пропускных способностей всех участвующих сабчейнов.  Subchains, due to the fulfillment of the requirements of paragraph 3, can be combined into a two-level p2p structure (Fig. 1). In this case, the total throughput of such a structure will be equal to the sum of the throughputs of all participating subchains.
Связи между сабчейнами (Фиг. 3) представляет из себя два типа. Первый тип— это передача транзакций из одного сабчейна в другой по стандартному для настоящего способа протоколу (пункт 3), второй тип взаимодействия - это ведение обобщенного реестра всех узлов (блокчейн сабчейнов) и их организации в сабчейны. Для ведения этого реестра используется тот же самый способ консенсуса, что и в блокчейн сети, только в качестве участников консенсуса используются сабчейны (при этом для того, чтобы сабчейн подал голос за валидацию блока для консенсуса между сабчейнами, необходимо предоставить подтверждение того, что внутри сабчейна подтверждение голоса было записано в блоке этого сабчейна и валидировано узлами входящими в него). Communication between subchains (Fig. 3) is of two types. The first type is the transfer of transactions from one subchain to another via the standard protocol for this method (clause 3), the second type of interaction is maintaining a generalized register of all nodes (blockchain subchains) and their organization into subchains. To maintain this registry, the same consensus method is used as in the blockchain network, only subchains are used as consensus participants (in order for the subchain to vote for validation of the block for consensus between subchains, you must provide confirmation that inside the subchain voice confirmation was recorded in the block of this subchain and validated by the nodes included in it).
В случае двухуровневой модели сабчейнов (Фиг. 3) возможно появление большого числа сабчейнов, что приведет к снижению общей производительности системы ведения реестра всех узлов (Фиг. 3). Для предотвращения таких проблем предлагается использовать многоуровневую структуру, показанную на Фиг. 4. In the case of a two-level model of subchains (Fig. 3), a large number of subchains may appear, which will lead to a decrease in the overall performance of the registry system of all nodes (Fig. 3). To prevent such problems, it is proposed to use the layered structure shown in FIG. four.
В многоуровневой системе сабчейнов транзакции от одного сабчейна 1-го уровня также напрямую передаются к получателю сабчейну 1-го уровня, при этом согласование реестра узлов проходит многоуровневую валидацию. Количество узлов в сабчейне может быть любым, но должно соблюдаться правило, по которому снижать количество узлов можно только до безопасного минимума. Для каждой конкретной ситуации, в зависимости от сферы деятельности предприятия, для которого используется заявляемый способ, безопасный минимум может быть разным. Однако необходимо соблюдать баланс между децентрализацией, эффективностью и ответственностью узлов. In a multi-level system of subchains, transactions from one sub-chain of the 1st level are also directly transferred to the recipient of the sub-chain of the 1st level, while the approval of the node registry goes through multi-level validation. The number of nodes in the subchain can be any, but the rule must be observed according to which it is possible to reduce the number of nodes only to a safe minimum. For each specific situation, depending on the field of activity of the enterprise for which the claimed method is used, the safe minimum may be different. However, a balance must be struck between decentralization, efficiency and responsibility of nodes.
Сущность заявляемого на регистрацию в настоящей заявке способа заключается в следующем: Пользователь-отправитель транзакции подписывает транзакцию путем применения криптографической функции к транзакции и собственному приватному ключу (механизм аналогичный работе электронно-цифровой подписи), в результате чего получается подпись транзакции. После этого пользователь-отправитель транзакции направляет транзакцию и подпись транзакции узлу сабчейна через канал связи (например, через сеть Интернет). The essence of the claimed for registration in this application method is as follows: The user who sends the transaction signs the transaction by applying a cryptographic function to the transaction and its own private key (a mechanism similar to the operation of digital signature), which results in a transaction signature. After that, the user who sends the transaction sends the transaction and the transaction signature to the subchain node through the communication channel (for example, via the Internet).
Узел сабчейна по каналам связи с другими узлами сабчейна передает полученные им транзакции и подписи транзакции пользователей- отправителей транзакций другим узлам сабчейна для включения узлами сабчейна отправленных этим узлом сабчейна транзакций и подписей транзакций пользователей-отправителей транзакций в новый блок данных. При формировании нового блока данных все транзакции, где пользователь-получатель транзакций зарегистрирован не в том сабчейне, в котором зарегистрирован пользователь-отправитель транзакции, выделяются в отдельную секцию нового блока данных. Таким образом, в новом блоке данных создаются две секции: The Sabchain node, through communication channels with other Sabchain nodes, transfers the transactions received by it and the transaction signatures of the users of the transaction senders to other nodes of the Sabchain for inclusion by the Sabchain nodes of the transactions sent by this Sabchain node of the transactions and the transaction signatures of the users of the transaction senders in a new data block. When forming a new data block, all transactions where the user-recipient of the transaction is registered in the wrong sub-chain in which the user-sender of the transaction is registered are allocated in a separate section of the new data block. Thus, two sections are created in the new data block:
1. секция нового блока данных, содержащих транзакции, у которых пользователь-получатель транзакции зарегистрирован в том же сабчейне, что и пользователь-отправитель транзакции; 1. section of a new data block containing transactions for which the user-receiver of the transaction is registered in the same subchain as the user-sender of the transaction;
2. секция нового блока данных, содержащих транзакции, у которых пользователь-получатель транзакции не зарегистрирован в том сабчейне, в котором зарегистрирован пользователь-отправитель транзакции, а пользователь-получатель транзакции зарегистрирован в другом сабчейне.  2. section of a new block of data containing transactions for which the user-recipient of the transaction is not registered in the subchain in which the user-sender of the transaction is registered, and the user-recipient of the transaction is registered in another subchain.
После включения нового блока в блокчейн сабчейна-отправителя, узлы извлекают из 2-й секции этого блока все транзакции с их МТР. Затем узел формирует исходящие пакеты транзакций с их МТР для каждого сабчейна-получателя. Каждый пакет транзакций с их МТР содержит номер пакета для сабчейна-получателя, адрес сабчейна- получателя, заголовок нового блока данных, а также транзакции с их МТР. After a new block is included in the sender subchain blockchain, the nodes extract all transactions from their MTP from the 2nd section of this block. Then the node forms outgoing transaction packets with their MTP for each recipient recipient. Each transaction package with their MTP contains the number of the package for the recipient sub-chain, the address of the recipient sub-chain, the header of a new data block, as well as transactions from their MTP.
Затем узлы, входящие в сабчейн отправителя, передают по каналам связи все сформированные пакеты по меныпей мере в один из узлов сабчейнов получателей. Then, the nodes included in the sender’s subchain transmit over the communication channels all the generated packets at least to one of the recipient’s subchain nodes.
При получении узлами сабчейнов-получателей пакетов с транзакциями с их МТР от сабчейна-отправителя, узлы сабчейнов- получателей пакетов с транзакциями с их МТР в первую очередь проверяют номер каждого пакета транзакций с их МТР путем соотнесения номера полученного пакета с транзакциями с их МТР с номером предыдущего зарегистрированного пакета транзакций с их МТР, и в том случае, если номер полученного пакета с транзакциями с их МТР на 2 и более больше, чем номер предыдущего зарегистрированного в сабчейне получателя пакета транзакций с их МТР, узлы сабчейнов-получателей направляют эти полученные пакеты с транзакциями с их МТР в очередь ожидания пропущенных пакетов транзакций с их МТР, которые в свою очередь по мере поступления пропущенных пакетов транзакций с их МТР переходят к следующему этапу. Пакет со следующим после ранее зарегистрированного в сабчейне получателя номера пакета, валидируется узлами сабчейна-получателя путем валидации всех содержащихся в пакете транзакций с их МТР. Upon receipt by the nodes of the Sabchain recipients of packets with transactions with their MTP from the sending sabchain, the nodes of the Sabchain recipients of packets with transactions with their MTP first check the number of each transaction packet with their MTP by correlating the number of the received packet with the transactions with their MTP with the number of the previous registered transaction package with their MTP, and if the number of the received package with transactions with their MTP is 2 or more than the number of the previous transaction packet receiver registered in the subchain with their MTP, recipient subchain nodes direct these received packets with transactions from their MTP to the waiting queue for missed transaction packets from their MTP, which, in turn, as the missing transaction packets arrive from their MTP, go to the next stage. The packet with the next packet number after the recipient previously registered in the subchain is validated by the subchain-recipient nodes by validating all transactions contained in the packet with their MTP.
После валидации пакет транзакций с их МТР включается в новый блок сабчейна получателя, а балансы пользователей-получателей транзакций из пакета транзакций с их МТР изменяются в соответствии с этими транзакциями. После включения блока с пакетом транзакций с их МТР в блокчейн сабчейна получателя, сабчейн получателя отправляет по каналам связи в сабчейн отправителя информацию о внесении пакета транзакций с их МТР в новый блок данных сабчейна получателя с МТР пакета транзакций с ихAfter validation, the transaction package with their MTP is included in the new recipient subchain block, and the balances of user-recipient transactions from the transaction package with their MTP are changed in accordance with these transactions. After the block with the transaction package from their MTP is included in the recipient’s subchain blockchain, the recipient’s subchain sends via the communication channels to the sender’s subchain the information about entering the transaction packet from their MTP into the new data block of the recipient’s subchain from the MTP of the transaction packet from
МТР. MTP.
После получения через каналы связи узлом сабчейна отправителя от узла сабчейна получателя информации о внесении пакета транзакций с их МТР в новый блок данных сабчейна получателя с МТР пакета транзакций с их МТР, узел сабчейна отправителя валидирует МТР пакета транзакций с их МТР. Если валидация осуществлена узлом сабчейна отправителя, информация о внесении пакета транзакций с их МТР в новый блок данных сабчейна получателя с МТР пакета транзакций с их МТР вносится в новый блок сабчейна отправителя. На этом работа по регистрации транзакции пользователя закончена. After receiving through the communication channels of the sabchain node of the sender from the sabchain node of the recipient information about entering the transaction package from their MTP into the new data block of the sabchain of the recipient with the MTP of the transaction packet from their MTP, the sender's subchain node validates the MTP of the transaction packet from their MTP. If validation is carried out by the sender’s Sabchain node, information about entering the transaction packet from their MTP into a new data block of the recipient’s Sabchain from the MTP of the transaction packet from their MTP is entered into the new sender’s Sabchain block. This completes the work of registering a user’s transaction.
В случае если узел сабчейна отправителя не получил по каналам связи за предусмотренное настройками блокчейн сети время информацию о внесении пакета транзакций с их МТР в новый блок данных сабчейна получателя с МТР пакета транзакций с их МТР, узел сабчейна отправителя повторно отправляет по каналам связи пакет транзакций с их МТР в адрес узла сабчейна получателя. Это продолжается до тех пор, пока узел сабчейна отправителя не получит по каналам связи информацию о внесении пакета транзакций с их МТР в новый блок данных сабчейна получателя с МТР пакета транзакций с их МТР. If the sender’s Sabchain node has not received information on entering the transaction packet from their MTP into the new recipient’s Sabchain data block from the MTP of the transaction packet from their MTP via the communication channels for the time specified by the blockchain network settings, the sender’s Sabchain node re-sends the transaction packet with their MTP to the address of the recipient sabchain node. This continues until the sender’s Sabchain node receives, through communication channels, information about the introduction of the transaction packet from their MTP into the new data block of the recipient’s Sabchain from the MTP of the transaction packet from their MTP.
Так, например, описанный способ поможет в индустрии логистики. Возьмем компанию, имеющую несколько складов. Для предотвращения случаев подмены грузов или изменения данных о поставках задним числом руководством было принято решение использовать блокчейн. Применяя наш способ, все склады можно представить сабчейнами. В этих сабчейнах происходит фиксация всего, что происходит внутри соответствующих им складов. А логистические движения между складами оформляются в виде межсабчейновых транзакций. So, for example, the described method will help in the logistics industry. Take a company that has several warehouses. To prevent cases of substitution of goods or changing data on deliveries retroactively, the management decided to use the blockchain. Using our method, all warehouses can be represented as subchains. In these subchains everything that happens inside their respective warehouses is fixed. And logistic movements between warehouses are executed in the form of intersubschain transactions.
Пример для применения при роботизации производств. Представим предприятие, часть цехов которого на 100% роботизировано. Очень важно, чтобы вся статистика по производству сохранялась, а в виду того, что люди фактически отсутствуют, в таких цехах важна сохранность и подлинность такой статистики, а также правомочность заданий, отданных роботам цеха. В этом случае тоже очень хорошо применим описываемый способ - каждый такой цех может быть представлен отдельным сабчейном. Более того, так как в составе роботов находится управляющая ЭВМ, она может использоваться дополнительно и как узел этого сабчейна. В такой структуре все действия внутри сабчейна не влияют на работу предприятия в целом. А само предприятие может горизонтально масштабировать систему управления, просто добавляя новые цеха такого же типа. An example for use in robotics production. Imagine an enterprise, some of whose workshops are 100% robotic. It is very important that all production statistics are preserved, and since people are virtually absent, the safety and authenticity of such statistics, as well as the competency of tasks given to the robots of the workshop, are important in such workshops. In this case, the described method is also very well applicable - each such workshop can be represented by a separate subchain. Moreover, since the control computer is part of the robots, it can be used additionally as a node of this subchain. In this structure, all actions within the subchain do not affect the operation of the enterprise as a whole. And the enterprise itself can horizontally scale the management system by simply adding new workshops of the same type.

Claims

Формула изобретения Claim
Способ масштабирования распределенной информационной системы, отличающийся тем, что содержит: этап, на котором определяют получателя, отправителя и ценность транзакции; A method of scaling a distributed information system, characterized in that it comprises: a stage in which the receiver, sender and transaction value are determined;
этап, на котором подписывают транзакции;  the stage at which transactions are signed;
этап, на котором подписанные транзакции направляют узлу сабчейна, причем на узле сабчейна транзакции разделяют на две секции, к первой из которых относят те подписанные транзакции, в которых получатель зарегистрирован в том же сабчейне, что и отправитель, а ко второй относят те подписанные транзакции, в которых получатель зарегистрирован в другом сабчейне, не в том сабчейне, в котором зарегистрирован отправитель;  the stage at which the signed transactions are sent to the subchain node, and on the subchain node, the transactions are divided into two sections, the first of which includes those signed transactions in which the recipient is registered in the same subchain as the sender, and the second includes those signed transactions, in which the recipient is registered in another subchain, not in the subchain in which the sender is registered;
этап, на котором на узле сабчейна создают новый блок данных, содержащий информацию о подписанных транзакциях, разделенных на секции на предыдущем этапе;  a stage in which a new data block is created on the subchain node containing information about signed transactions, divided into sections at the previous stage;
этап, на котором из секции транзакций в которых получатель зарегистрирован в другом сабчейне, не в том сабчейне, в котором зарегистрирован отправитель, на узле сабчейна формируют исходящие пакеты транзакций, причем каждый пакет транзакций содержит информацию о номере пакета транзакций, адрес сабчейна-получателя, заголовок нового блока данных, а также непосредственно подписанные транзакции;  the stage at which the transaction section from which the recipient is registered in another subchain, not in the subchain in which the sender is registered, outgoing transaction packets are generated on the subchain node, and each transaction packet contains information about the number of the transaction packet, address of the recipient recipient, header a new data block, as well as directly signed transactions;
этап, на котором с узла сабчейна отправителя направляют все сформированные пакеты транзакций по меньшей мере одному из узлов сабчейна получателя;  the stage at which all generated transaction packets are sent from the sender’s node to at least one of the recipient’s Sabchain nodes;
этап, на котором на узле сабчейна получателя получают направленные с узла сабчейна отправителя все сформированные пакеты транзакций и проверяют номер каждого пакета транзакций путем соотнесения номера полученного пакета с транзакциями с номером предыдущего полученного и зарегистрированного узлом сабчейна получателя пакета транзакций из сабчейна отправителя, и в том случае, если номер полученного в настоящее время пакета с транзакциями на 2 и более больше, чем номер предыдущего полученного и зарегистрированного в узле сабчейне получателя пакета транзакций, то узел сабчейна получателя направляет этот полученный в настоящее время пакет с транзакциями в очередь ожидания пропущенных пакетов транзакций, которые в свою очередь по мере поступления пропущенных пакетов транзакций переходят к следующему этапу, а в том случае, если номер полученного в настоящее время пакета с транзакциями не удовлетворяет условию“на 2 и более больше, чем номер предыдущего полученного и зарегистрированного в узле сабчейне получателя пакета транзакций”, то такой пакет с транзакциями не передается в очередь ожидания пропущенных пакетов транзакций; the stage at which all generated packets directed from the sender’s node of the sender receive on the recipient’s node transactions and check the number of each transaction package by correlating the number of the received package with the transactions with the number of the receiver of the transaction package received and registered by the sabchain node of the sender’s sabchain node, and if the number of the currently received transaction package is 2 or more than If the recipient of the transaction packet received and registered in the Sabchain node is the recipient, the recipient Sabchain node sends this currently received transaction packet to Waiting time for missed transaction packages, which in turn, proceeds to the next step as the missing transaction packages arrive, and if the number of the currently received transaction package does not satisfy the condition “2 or more than the number of the previous received and the recipient of the transaction packet registered in the Sabchain node ”, then such a transaction packet is not transferred to the waiting queue for missed transaction packets;
этап, на котором пакет с транзакциями со следующим после ранее полученного и зарегистрированного на узле сабчейна получателя номера пакета, валидируется узлами сабчейна-получателя путем валидации всех содержащихся в пакете с транзакциями транзакций;  the stage at which the package with transactions with the next one after the recipient of the package number previously received and registered on the recipient node of the Sabchain node is validated by the nodes of the recipient Sabchain by validating all transactions contained in the package with transactions;
этап, на котором валидированный пакет с транзакциями включается в новый блок сабчейна получателя, а балансы пользователей-получателей транзакций из пакета транзакций изменяются в соответствии с этими транзакциями;  the stage at which the validated transaction package is included in the new recipient subchain block, and the balances of the user-recipient transactions from the transaction package are changed in accordance with these transactions;
этап, на котором с узла сабчейна получателя направляют в узел сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя;  the stage at which from the recipient’s site of the recipient send information to the sender’s site about adding the received transaction package to the new data block of the recipient’s sub-chain;
этап, на котором на узле сабчейна отправителя ожидают информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, и в том случае, если за установленное время не получают на узле сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, заново направляют с узла сабчейна отправителя все сформированные пакеты транзакций по меньшей мере одному из узлов сабчейна получателя до тех пор, пока на узле сабчейна отправителя не получат информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя; the stage at which information is received on the sender’s Sabchain node about the introduction of the received transaction package into a new block the recipient’s Sabchain data, and if within a specified time they do not receive information on the sender’s Sabchain node about entering the received transaction packet into a new recipient’s Sabchain data block, all generated transaction packets are sent again from the sender’s Sabchain node to at least one of the recipient’s Sabchain nodes until the sender’s Sabchain node receives information about the inclusion of the received transaction package in a new data block of the recipient’s Sabchain;
этап, на котором на узле сабчейна отправителя получают информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, валидируют на узле сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя и вносят информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя в новый блок сабчейна отправителя.  the stage at which on the sender’s node the sender receives information about adding the received transaction package to the new data block of the recipient’s saber, validates on the sender’s node the sender’s information on adding the received transaction package to the new data block of the recipient’s sabchain and the information on adding the received transaction package to the new block is entered recipient sabchain data into a new sender sabchain block.
PCT/RU2019/000213 2018-04-14 2019-04-05 Method of scaling a distributed information system WO2019199205A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2018113535 2018-04-14
RU2018113535A RU2686818C1 (en) 2018-04-14 2018-04-14 Method for scaling distributed information system

Publications (1)

Publication Number Publication Date
WO2019199205A1 true WO2019199205A1 (en) 2019-10-17

Family

ID=66430607

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2019/000213 WO2019199205A1 (en) 2018-04-14 2019-04-05 Method of scaling a distributed information system

Country Status (2)

Country Link
RU (1) RU2686818C1 (en)
WO (1) WO2019199205A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113874876A (en) 2019-06-05 2021-12-31 万事达卡国际公司 Security model for distributed computing systems
CN111125131B (en) * 2019-12-16 2023-06-06 武汉大学 Two-stage consensus blockchain system with state buffering capability and deployment method

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
WO2017161417A1 (en) * 2016-03-21 2017-09-28 National Ict Australia Limited Business process execution on a blockchain platform
US20170337534A1 (en) * 2015-11-06 2017-11-23 Cable Television Laboratories, Inc Systems and methods for blockchain virtualization and scalability
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US20180129957A1 (en) * 2016-11-09 2018-05-10 Cognitive Scale, Inc. Cognitive Session Graphs Including Blockchains
US20180144114A1 (en) * 2011-08-09 2018-05-24 Michael Stephen Fiske Securing Blockchain Transactions Against Cyberattacks

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10490304B2 (en) * 2012-01-26 2019-11-26 Netspective Communications Llc Device-driven non-intermediated blockchain system over a social integrity network
US9398018B2 (en) * 2014-03-18 2016-07-19 nTrust Technology Solutions Corp. Virtual currency system
US20170264428A1 (en) * 2016-03-08 2017-09-14 Manifold Technology, Inc. Data storage system with blockchain technology
EP3455802A1 (en) * 2016-05-13 2019-03-20 De La Rue International Limited Methods and systems for processing assets
RU2649788C1 (en) * 2016-06-16 2018-04-04 Общество С Ограниченной Ответственностью "Яндекс" Method and system for transaction request processing in distributed data processing systems

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180144114A1 (en) * 2011-08-09 2018-05-24 Michael Stephen Fiske Securing Blockchain Transactions Against Cyberattacks
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US20170337534A1 (en) * 2015-11-06 2017-11-23 Cable Television Laboratories, Inc Systems and methods for blockchain virtualization and scalability
WO2017161417A1 (en) * 2016-03-21 2017-09-28 National Ict Australia Limited Business process execution on a blockchain platform
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US20180129957A1 (en) * 2016-11-09 2018-05-10 Cognitive Scale, Inc. Cognitive Session Graphs Including Blockchains

Also Published As

Publication number Publication date
RU2686818C1 (en) 2019-04-30

Similar Documents

Publication Publication Date Title
Huang et al. Drugledger: A practical blockchain system for drug traceability and regulation
US20230410215A1 (en) Cryptographic method and system for secure extraction of data from a blockchain
US20230421355A1 (en) Systems and methods for storage, generation and verification of tokens used to control access to a resource
US20220114564A1 (en) Method and system for efficient transfer of cryptocurrency associated with a payroll on a blockchain that leads to an automated payroll method and system based on smart contracts
US20230028606A1 (en) Method and apparatus for vertical federated learning
CN108615148B (en) A kind of preposition method of commerce of secured assets and system based on block chain technology
US11270030B2 (en) System and method for consensus management
CN108200208B (en) Logistics block chain consensus algorithm based on cloud computing
CN110766551B (en) Alliance chain based on improved Kafka consensus mechanism and transaction method
WO2021204044A1 (en) Correction of blockchain data
CN111754343A (en) Deadlock resolution for privacy protection
CN111327426B (en) Data sharing method and related device, equipment and system
CN113947394A (en) Block chain-based fair payment method for deletable duplicate data in cloud storage
CN115277122A (en) Cross-border data flow and supervision system based on block chain
Obushnyi et al. Blockchain as a transaction protocol for guaranteed transfer of values in cluster economic systems with digital twins
Garcia Bringas et al. BlockChain platforms in financial services: current perspective
WO2019199205A1 (en) Method of scaling a distributed information system
Kabulov et al. Systematic analysis of blockchain data storage and sharing technology
US20210374214A1 (en) Method and system for securing computer software using a distributed hash table and a blockchain
CN110727735A (en) Method, device and equipment for cooperatively completing task event based on block chain technology
CN115701078B (en) Cross-chain transaction processing method, device, electronic equipment and storage medium
Pupyshev et al. SuSy: A blockchain-agnostic cross-chain asset transfer gateway protocol based on gravity
Haga et al. IoT‐Based Autonomous Pay‐As‐You‐Go Payment System with the Contract Wallet
Sanjay et al. Insights on blockchain frameworks for decentralized application deployment
Zheng et al. A Survey on Cross-Chain Data Transfer

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19785043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19785043

Country of ref document: EP

Kind code of ref document: A1