WO2020085946A1 - Способ масштабирования обработки данных в распределительной системе - Google Patents
Способ масштабирования обработки данных в распределительной системе Download PDFInfo
- Publication number
- WO2020085946A1 WO2020085946A1 PCT/RU2019/000725 RU2019000725W WO2020085946A1 WO 2020085946 A1 WO2020085946 A1 WO 2020085946A1 RU 2019000725 W RU2019000725 W RU 2019000725W WO 2020085946 A1 WO2020085946 A1 WO 2020085946A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- group
- transactions
- computers
- groups
- list
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/82—Architectures of general purpose stored program computers data or demand driven
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
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.
- Blockchain is a type of distributed system in which all nodes (computers) of a system agree on a round-up new state of the system (agree on a general decision on the list of allowed transactions in the system), while all nodes (computers) of the system store the current state of the system as well as the previous ones states in the form of interconnected data blocks, where data blocks are a set of transactions, the processing of which transfers one state of the system to another. Thanks to the applied technology of storage and transfer of blocks in such a distributed system, data verification processes during the interaction of nodes (computers) of the system are greatly simplified.
- a known model of the interaction between parallel operation of blockchains [application for invention US 20160330034 A1, publ. 11/10/2016], later called a sidechain, which reveals new methods of interaction between two blockchains for transferring digital values from one blockchain, called the main or parent, to another blockchain, called the sidechain, with the possibility of subsequent return of these values and with protection against double spending as when values are found inside the sidechain, or during the transfer process to the sidechain or from the sidechain.
- it is possible to create a lot of parallel 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.
- a scheme with multi-level sidechains is also possible when the top-level sidechain acts as the parent blockchain for another sidechain.
- the advantages of the well-known model include the following indicators:
- the disadvantages of the known model include the fact that it’s not possible to realize the possibility of scaling and increasing productivity described earlier as a positive result, since this model is based on the method of simplified payment verification (SPV), which leads to the existence of a significant period expectations of 1-2 days during the transition and return of values between the parent blockchain and sidechain (paragraph [0042] US 20160330034 A1).
- SPV simplified payment verification
- the advantages of the method used in the Cosmos project include the fact that, unlike the model described in the application for the invention US 20160330034 A1, instead of a simplified payment verification (SPY), inter-block Inter-blockchain Communication (IBC), which significantly reduces the time for transferring transactions between the Cosmos HUB and the zones. As a result, system bandwidth can be scaled.
- SPY simplified payment verification
- IBC inter-block Inter-blockchain Communication
- 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.
- 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 the Cosmos HUB, part of the inter-zone transactions will wait for the queue.
- the Cosmos HUB bandwidth limit also limits the bandwidth of the entire system.
- the nodes of any sidechain are independent of the nodes of other sidechains, therefore, if an attacker captures most of the sidechain nodes, he monopolizes the right to work in this sidechain. From the point of view of the operation of the entire system, this will not harm all other participants, as the illegal actions of the captured sidechain will not be missed by Cosmos HUB. However, users of the captured sidechain will not be able to work in it without the permission of the invader.
- the Zilliqa project offers another approach to creating a distributed system with linear scaling [Electronic resource. Resource access mode: https://docs.zilliqa.com/whitepaper.pdf - free).
- This project proposes that all nodes of the system are equitable, but are organized in separate blockchains.
- the project has two types of blockchains - “DS committee” and “shard”. Each epoch (a significant time period, the Zilliqa project proposes an interval of 20 hours) from among all the nodes, a small number of nodes are selected that are part of the blockchain - “DS committee”, then the participants of the “DS committee” distribute the remaining nodes of the system to many parallel blockchains “Shard”.
- the advantages of the Zilliqa project interaction system include the fact that, unlike the sidechain system, two steps are required to register an interchain transaction: register in the “world block” and then register in the “final block”.
- a system with sidechains - registration in the sending sidechain, the root blockchain and the destination sidechain. If a separate “shard” is captured, then at the end of the “era” all nodes will be shuffled, which will seriously reduce the likelihood of a repeat capture.
- users of the system perceive the entire blockchain system as one platforme. Unlike, for example, the sidechain system, where each sidechain and root blockchain are separate entities, and when working with such a system, you need to know the differences between them.
- the disadvantages of the Zilliqa project include the long registration time of any transaction, since it consists of the registration time in the “micro block” of the “shard” blockchain and the time of registration of the “final block” in the “DS committee” blockchain. Moreover, in the documentation, it is proposed to set the time of registration of the “final block” in the “DS committee” blockchain to 2 minutes.
- each node belongs to one of the blockchains of the system, therefore only its data from one blockchain chain is stored in its database.
- all nodes change their belonging to specific blockchains every era, therefore, data on all blockchain chains must be stored on each node of the system.
- the technical problem to which the present invention is directed is the need to create such a distributed system that would simultaneously have high network bandwidth (transaction speed), scalability, versatility, network and data security, and low latency.
- the technical result of the proposed method for scaling data processing in a distributed system is to reduce the time between registering an intergroup transaction in the sending group and registering an intergroup transaction in the destination group while maintaining transaction security.
- the specified technical result is achieved due to the fact that in the method of scaling data processing in a distributed system, namely, that
- computers are interconnected by a common data exchange network, forming a distributed system
- each computer in its group at the beginning of the process of developing a common managerial decision, each computer in its group, if at that time there is at least one managerial transaction registered in this group, by a joint decision of the group transfers all available managerial transactions approved in the group to the presenter by the general managerial decision the group of this round, which, after receiving from the other groups a list of management transactions for processing, excludes invalid transactions, makes up all directed from the group list management transactions, which is a legitimate candidate for the list of administrative transactions of this round and approved by a given number of computers and sends it to confirm all groups
- each group having received the mentioned candidate list from the leading group of this round, coordinates it with each computer included in this group, and sends the coordination result, which is the number of computers that agreed on this list, back to the leading group,
- this candidate list becomes a legitimate list of managerial transactions of this round, and the leading group sends it together with the collected confirmations to all computers, each of which, having received this list, saves it and carries out changes in the general system settings lists in accordance with the list sent.
- the status of the leading group passes between all groups of the system in turn, starting from the first group in the list of system groups that is available on each computer, taking into account the fact that if the leading group in the round was the last in the list, then to the next round the leading group will be the first on the list;
- the sequence of changing the status of the leading group is set to the next specified number of rounds, while the interval of the next setting of the sequence of changing the sequence of the specified status of the leading group is also set;
- the security of the system is maintained, since in the event of failure or exposure to the destructive program code of most computers of the same group, which can lead to the creation and sending of invalid transactions, the system will quickly respond by accepting a joint management decision to disband this group and withdraw the computers involved in the creation of invalid transactions from the system.
- FIG. 1 presents a block diagram of the proposed method according to p. 1 of the formula.
- FIG. 2 presents a block diagram of the proposed method according to p. 6 formulas.
- the method of scaling data processing in a distributed system includes the following steps.
- existing computers (K1 ... Kp + 1) are interconnected by a common data exchange network, forming a distributed system. This can be realized in the form of connecting all computers to the Internet, or to a single local communication system, or to a single data bus.
- these computers are distributed in logical groups (G1 ... Gt) and carry out transactions directly from one group to another, processing them in groups independently of other groups.
- the preferred option is to distribute computers into at least three groups, because if one group fails from three groups, the two remaining ones will be enough to continue working and restore the number of groups by adding a new one. If initially there are two groups, then in case of failure of one of the groups, one group will not be able to legitimately add a new group to restore the full the health of the system, you will have to wait for the restoration of the health of the failed group.
- the rules for the initial distribution of computers into logical groups are introduced by developers into these computers before starting the system. After starting the system, the computers themselves are distributed according to the given rules into the initial groups.
- Making settings on computers is possible, for example, in two ways.
- the first involves entering data into each computer manually, i.e. when the commissioner has direct access to each computer, for example, by connecting a data storage device to them with the database of system settings available on it.
- the second method is applicable for the formation of a distributed system from completely independent computers and involves the creation of a start-up algorithm so that the computers themselves exchange data. In that In this case, all computers are connected to a common server containing the settings database and receive the necessary settings from it.
- each computer in its group if at that time there is at least one management transaction registered in this group by a joint decision of the group, transfers all available management transactions approved in the group to the leading group of this round previously assigned by the general management decision .
- a leading group is a group that additionally performs in the current round the function of a compiler of all the legitimate lists sent from groups of management transactions approved by a given number of management transaction computers.
- the way of assigning the status of a leading group is developed during the adoption of an agreed management decision.
- the status of a leading group can go between all groups of the system in turn, starting from the first group in the list of system groups that is available on each computer, taking into account the fact that if the leading group in the round was the last in the list, then to the next round the leading group will be the first on the list.
- the sequence of changes in the status of the leading group can be set to the next specified number of rounds, while the interval is also set the next establishment of the sequence for changing the given status of the leading group, for example, setting the order for XX rounds ahead and repeating the sequence setting every XX / 10 rounds.
- the status of the leading group can also be set by the specified function of assigning the leading group, by which, knowing the number of the round, you can calculate the number of the leading group.
- the leading group after receiving at a set time from other groups a list of management transactions for processing, excludes invalid transactions, compiles from all management transactions sent from groups a list that is a candidate for a legitimate list of management transactions of this round and approved by a given number of computers, and sends it to confirm to all groups.
- each group having received the mentioned candidate list from the leading group of this round, reconciles it with each computer included in this group, and sends the coordination result, which is the number of computers that agreed this list, back to the leading group.
- this candidate list becomes a legitimate list of managerial transactions of this round.
- the set number of more than half of the computers is most preferable, which will provide an additional increase in transaction security.
- the leading group sends it along with the collected confirmations to all computers, each of which, having received this list, saves it and carries out changes in the general system settings lists in accordance with the list sent.
- verification of these transactions can be carried out by computers of the validation group (VG), which is assigned by the general management decision for each group and which includes computers from among those not included in the tested group (Fig. 2).
- the verification of transactions is carried out by each computer from the validation group according to the same rules that apply in the group being verified, and the result of the verification is sent to the computers of the transaction destination group.
- transactions from the checked group can be processed in the destination group only after obtaining approval from a given number of computers of the validation group.
- Verification of these transactions can also be carried out by all other computers in the system. In this case, verification of transactions is carried out by each computer according to the same rules that apply in the group being checked, and the result of the verification is sent to the computers of the transaction destination group. Moreover, transactions from the checked group can be processed in the destination group only after obtaining approval from a given number of system computers.
- a variant is possible when the verification of these transactions is carried out by the remaining groups of the system.
- the verification of transactions is carried out by each computer from the checking group according to the same rules that apply in the checked group, and the result of the verification is sent to the computers of the transaction destination group.
- transactions from the checked group can be processed in the destination group only after obtaining approval from a given number of other groups in the system.
- Example 1 For testing, the system software was deployed on 900 computers. Then these computers were connected to the Internet. Cryptographic keys were generated on each computer for identification during messaging. After that, the rule of distribution into groups was formulated, in which data on preference were entered group size of 9 computers. Then this rule, all Internet addresses of computers, their cryptographic keys were collected in one database and replicated to all computers participating in the test. Thus, the initial system settings are made. When the network started, in accordance with the rule introduced, computers were divided into 100 groups of 9 computers.
- Example 2 Creating a distributed logistics management system in an enterprise.
- the rule of distribution into groups was formulated, which included data on the preference for the size of the group of 5 computers and the correspondence of 2 computers in the group to one location. Then data on the location of computers, the rule of distribution in groups, the addresses of computers on the local network and their cryptographic keys were collected in one database and replicated to all 15 computers.
- computers were divided into three groups and began to process and record movement data within their responsibility and created intergroup transactions when moving goods between the departments of reception, warehouse and shipment.
Abstract
Изобретение относится к области обработки цифровых данных. При осуществлении способа образуют распределенную систему, компьютеры распределяют в логические группы и осуществляют транзакции от одной группы к другой, обрабатывая их в группах независимо от других групп, каждый компьютер в составе своей группы, совместным решением группы передает все имеющиеся одобренные в группе управленческие транзакции предварительно назначенной общим управленческим решением ведущей группе этого раунда, которая после получения от других групп списка управленческих транзакций для обработки, исключает невалидные транзакции, составляет из всех направленных от групп управленческих транзакций список, являющийся кандидатом на легитимный список управленческих транзакций этого раунда и одобренный заданным количеством компьютеров, и рассылает его для подтверждения всем группам, затем каждая группа, отправляет результат согласования, обратно в ведущую группу, как только ведущая группа получит от групп ответы и если общее количество компьютеров, согласовавших список-кандидат в этих ответах, составит заданное количество компьютеров в системе, то этот список-кандидат становится легитимным списком управленческих транзакций этого раунда, и ведущая группа рассылает его вместе с собранными подтверждениями по всем компьютерам. Изобретение позволяет уменьшить время между регистрацией межгрупповой транзакции в группе отправления и регистрации межгрупповой транзакции в группе назначения при сохранении безопасности транзакций.
Description
Способ масштабирования обработки данных в распределенной системе
Изобретение относится к области обработки цифровых данных с помощью электрических устройств, в частности к методам цифровых вычислений или обработки данных, предназначенных для специфических функций, в том числе информационного поиска, а также структурирования баз данных для этой цели.
В настоящее время способы прямого ускорения работы распределенных систем практически исчерпаны, и большинство разработчиков переключились на разработку систем их параллельного выполнения, что позволило бы добиться линейного ускорения при добавления новых участников системы.
Под распределенной системой принято понимать совокупность компьютеров, объединенную в общую сеть обмена данными.
Блокчейн - это вид распределенной системы, в которой все узлы (компьютеры) системы согласуют пораундово новое состояние системы (согласуют общее решение по перечню допущенных транзакций в систему), при этом все узлы (компьютеры) системы хранят одинаково как текущее состояние системы, так и предыдущие состояния в виде связанных между собой блоков данных, где блоки данных - это набор транзакций, обработка которых переводит одно состояние системы в другое. Благодаря применяемой технологии хранения и передачи блоков в такой распределенной системе серьезно упрощаются процессы проверки данных при взаимодействии узлов (компьютеров) системы.
Известна модель взаимодействия между параллельной работой блокчейнов [заявка на изобретение US 20160330034 А1, опубл. 10.11.2016], названная впоследствии сайдчейн, которая раскрывает новые методы взаимодействия двух блокчейнов по переносу цифровых ценностей из одного блокчейна, названного основным или родительским, в другой блокчейн, названный сайдчейном, с возможностью последующего возврата этих ценностей и с защитой от появления двойной траты как при нахождении ценностей внутри сайдчейна, так и в процессе передачи как в сайдчейн, так и из сайдчейна. Таким образом реализована возможность создания вокруг родительского блокчейна множество паралельно работающих сайдчейнов, которые, работая независимо друг от друга, могут передавать ценности, созданные внутри родительского блокчейна между собой, через родительский блокчейн. Также возможна схема с многоуровневыми сайдченами, когда сайдчейн верхнего уровня выступает родительским блокчейном для другого сайдчейна.
К достоинствам известной модели можно отнести следующие показатели:
- осуществляется безопасный перенос ценности из родительского блокчейна в сайдчейны и обратно, в частности благодаря тому, что исключена возможность возникновения двойной траты при переносе ценностей;
- если несколько транзакций были совершены внутри сайдчейна, они производятся без нагрузки на родительский блокчейн, следовательно такой способ теоретически позволяет добиться большей производительности, чем обычный блокчейн, и, следовательно, позволяет масштабировать модель.
К недостаткам известной модели можно отнести то, что реализовать описанную ранее в качестве положительного результата возможность масштабирования и повышения производительности на практике не представляется возможным, так как данная модель основывается на методе упрощенной проверке платежа (simplified payment verification - SPV), что обуславливает наличие существенного периода ожидания в 1-2 дня при переходе и возврате ценностей между родительским блокчейном и сайдчейном (пункт [0042] US 20160330034 А1).
Впоследствии описанную выше модель с использованием похожих связей между блокчейнами для масштабирования развили в способе масштабирования проекта Cosmos [Электронный ресурс. Режим доступа к ресурсу: https://cosmos.network/whitepaper - свободный]. Все основные действия происходят в сайдчейнах, названных в этом проекте "зонами". Родительский блокчейн (в этом способе назван Cosmos hub) используется в большинстве своем только как гарант по переносу транзакций (как ценностных, так и иных) между зонами. Проблема заключается в том, что при захвате большинства узлов в блокчейн-сети, у лица, имеющего доступ к большинству узлов в блокчейн-сети, возникает возможность производить двойные траты. Суть способа использования сайдчейнов, предлагаемая в указанном техническом решении, основывается на том, что центральный (главный родительский) блокчейн имеет гораздо большую защищенность по сравнению с сайдчейнами в силу большей децентрализованности. Таким образом, сайдчены, которые не могут“доверять” друг другу из-за проблем с безопасностью в силу низкой децентрализованности, могут“доверять” центральному блокчейну и используют его как надежную среду для передачи ценностей.
К достоинствам способа, используемого в проекте Cosmos, можно отнести, тот факт, что в отличии от модели, описанной в заявке на изобретение US 20160330034 А1, вместо упрощенной проверки платежа (SPY) применяется межблокчейновое
взаимодействие (Inter-blockchain Communication - IBC), что существенно уменьшает время на передачу транзакций между Cosmos HUB и зонами. В результате возможно масштабирование пропускной способности системы.
Недостатками данного способа является то, что любая межзонная транзакция должна пройти через Cosmos HUB, что в несколько раз увеличивает время межзонных транзакций относительно внутризональных. Время межзонной транзакции будет равно сумме времен регистрации транзакции в зоне источнике, регистрации факта транзакции в Cosmos HUB, регистрации в зоне получателя. Существует верхний предел пропускной способности по обработке транзакций у Cosmos HUB, связанный с тем, что Cosmos HUB представляет собой обычный блокчейн. При увеличении количества зон, вероятность появления межзонных транзакций увеличивается. Все межзонные транзакции проходят через Cosmos HUB. В случае если количество межзонных транзакций в единицу времени превысят пропускную способность Cosmos HUB, часть межзонных транзакций будет ожидать очереди. Таким образом предел пропускной способности Cosmos HUB ограничивает и пропускную способность всей системы. Узлы любого сайдчейна независимы от узлов других сайдчейнов, поэтому в случае захвата злоумышленником большинства узлов сайдчейна, он монополизирует право работы в этом сайдчейне. С точки зрения работы всей системы это не нанесет вред всем остальным участникам, так как неправомерные действия захваченного сайдчейна не будут пропущены Cosmos HUB. Однако пользователи захваченного сайдчейна не смогут работать в нем без разрешения захватчика.
Проект Zilliqa предлагает еще один поход к созданию распределенной системы с линейным масштабированием [Электронный ресурс. Режим доступа к ресурсу: https://docs.zilliqa.com/whitepaper.pdf - свободный). В этом проекте предлагается, что все узлы системы равноправны, но организуются в отдельные блокчейны. В проекте присутсвует два вида блокчейнов - “DS committee” и “shard”. Каждую эпоху (значительный временной промежуток, в проекте Zilliqa предложен промежуток в 20 часов) из числа всех узлов выбирается небольшое количество узлов, которые входят в блокчейн -“DS committee”, затем участники“DS committee” распределяют оставшиеся узлы системы на множество параллельно выполняющихся блокчейнов“shard”.
Работа по проведению транзакции между блокчейнами “shard” немного отличается от модели сайдчейнов, описанной выше. Внутри блокчейна“shard” все транзакции обрабатываются и складываются в “микро блоки” с довольно малой периодичностью (в документации не указано время создания“микро блока”). Затем все
подготовленные “микро блоки” всех “shard” направляются для включения в “окончательный блок” (“final block”) в блокчейн“DS committee”. Каждые раунд“DS committee” (в документации указано, что раунд“DS committee” длится 2 минуты) узлы “DS committee” проверяют все поступившие “микро блоки” и формируют блок, включающий в себя проверенные “микро блоки”. Таким образом “окончательный блок” содержит в себе все данные для изменения состояния из прошлого блока к новому. Этот “окончательный блок” рассылается всем узлам всех “shard” для включения в их локальную блокчейн цепочку.
К преимуществам системы взаимодействий проекта Zilliqa можно отнести то, что в отличие от системы сайдчейнов необходимо два действия для регистрации межчейновой транзакции: регистрация в “мирко блоке”, а затем регистрация в “окончательном блоке”. В системе с сайдчейнами - регистрация в сайдчейне отправки, корневом блокчейне и сайдчейне назначения. Если будет произведен захват отдельного “shard”, то в конце “эпохи” все узлы будут перетасованы, что серьезно снизит вероятность повторение захвата. При этом пользователи системы воспринимают всю систему блокчейнов как одну плафторму. В отличие, например, от системы сайдчейнов, где каждый сайдчейн и корневой блокчейн - это отдельные сущности и при работе с такой системой необходимо знать различия между ними.
К недостаткам проекта Zilliqa относится длительное время регистрации любой транзакции, так как оно складывается из времени регистрации в “микро блоке” блокчейна“shard” и времени регистрации“окончательного блока” в блокчейне“DS committee”. При этом в документации время регистрации“окончательного блока” в блокчейне“DS committee” предложено установить в 2 минуты. В системе сайдчейнов, каждый узел принадлежит одному из блокчейнов системы, следовательно в его базе данных хранится только данные одной блокчейн цепочки. В проекте Zilliqa все узлы каждую эпоху меняют принадлежность к конкретным блокчейнам, поэтому на каждом узле системы необходимо хранение данных всех блокчейн цепочек.
Техническая проблема, на решение которой направлено настоящее изобретение, заключается в необходимости создания такой распределенной системы, которая бы одновременно обладала высокой пропускной способностью сети (скоростью транзакций), масштабируемостью, универсальностью, защищенностью сети и данных, а также низкой латентностью.
Технический результат заявляемого способа масштабирования обработки данных в распределенной системе заключается в уменьшении времени между
регистрацией межгрупповой транзакции в группе отправления и регистрации межгрупповой транзакции в группе назначения при сохранении безопасности транзакций.
Указанный технический результат достигается за счет того, что в способе масштабирования обработки данных в распределенной системе, заключающемся в том, что
- первоначально компьютеры связывают между собой общей сетью обмена данными, образуя распределенную систему,
- затем эти компьютеры распределяют в логические группы
- и осуществляют транзакции от одной группы к другой, обрабатывая их в группах независимо от других групп,
согласно настоящему изобретению,
- первоначально во все компьютеры вносят настройки системы
- и запускают постоянно повторяемый раундами процесс выработки общего управленческого решения по всем управленческим запросам, не обработанным ранее,
- при этом в начале процесса выработки общего управленческого решения каждый компьютер в составе своей группы, при наличии к этому времени в этой группе зарегистрированной по меньшей мере одной управленческой транзакции, совместным решением группы передает все имеющиеся одобренные в группе управленческие транзакции предварительно назначенной общим управленческим решением ведущей группе этого раунда, которая после получения от других групп списка управленческих транзакций для обработки исключает невалидные транзакции, составляет из всех направленных от групп управленческих транзакций список, являющийся кандидатом на легитимный список управленческих транзакций этого раунда и одобренный заданным количеством компьютеров, и рассылает его для подтверждения всем группам,
- затем каждая группа, получив упомянутый список-кандидат от ведущей группы этого раунда, согласовывает его с каждым компьютером, входящим в эту группу, и отправляет результат согласования, представляющий собой количество компьютеров, согласовавших этот список, обратно в ведущую группу,
- как только ведущая группа получит от групп ответы с результатами согласования и если общее количество компьютеров, согласовавших список-кандидат в этих ответах, составит заданное количество компьютеров в системе, то этот список- кандидат становится легитимным списком управленческих транзакций этого раунда, и
ведущая группа рассылает его вместе с собранными подтверждениями по всем компьютерам, каждый из которых, получив этот список, сохраняет его у себя и выполняет изменения в общих списках настройки системы в соответствии с присланным списком.
Возможны варианты развития основного технического решения, заключающиеся в том, что:
- статус ведущей группы переходит между всеми группами системы по очереди, начиная от первой группы в списке групп системы, который имеется на каждом компьютере, с учётом того, что в случае если в раунде ведущей группой была последняя в списке, то в следующий раунд ведущей группой будет первая в списке;
- очередность смены статуса ведущей группы устанавливается на следующее заданное количество раундов, при этом также устанавливается интервал следующего установления очередности смены заданного статуса ведущей группы;
- статус ведущей группы устанавливается по заданной функции назначения ведущей группы;
- .при передаче транзакции от одной группы к другой осуществляется проверка этих транзакций;
- проверка этих транзакций осуществляется компьютерами валидационной группы, которая назначается общим управленческим решением для каждой группы и в которую входят компьютеры из числа, не входящих в проверяемую группу, при этом проверка транзакций проводится каждым компьютером из валидационной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отправляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров валидационной группы;
- проверка этих транзакций осуществляется всеми остальными компьютерами системы, при этом проверка транзакций проводится каждым компьютером по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров системы;
- проверка этих транзакций осуществляется остальными группами системы, при этом проверка транзакций проводится каждым компьютером из проверяющей группы по тем же правилам, что применяются в проверяемой группе, и результат проверки
отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества остальных групп системы;
- проверка этих транзакций осуществляется назначенными группами системы, которые назначаются общим управленческим решением для каждой группы, при этом проверка транзакций проводится каждым компьютером из назначенной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров назначенных групп.
Таким образом, за счет указанной совокупности существенных признаков удалось существенно уменьшить время между регистрацией межгрупповой транзакции в группе отправления и регистрации межгрупповой транзакции в группе назначения, по сравнению с аналогами. Это стало возможным благодаря разделению компьютеров системы на уровни, что позволило создать многоуровневую систему принятия решений, т.к. все группы участвуют в принятии управленческих решений многостадийным образом. При этом по сравнению с аналогами уменьшено количество взаимодействий при масштабировании, поскольку транзакции передаются от группы к группе непосредственно, т.е. напрямую, без использования единой подсистемы проверки межгрупповых транзакций, в отличие от проекта Zilliqa в котором такие транзакции сначала передаются группе“DS commitee”, затем в ней обрабатываются, а затем рассылаются во все группы, а так как обработка транзакций в группе“DS commitee” занимает две минуты, то и доставка транзакций между группами занимает не менее двух минут. Благодаря тому, что сразу после начала работы все группы могут обрабатывать транзакции пользователей независимо друг от друга и совершать передачу межгрупповых транзакций между собой, достигается увеличение скорости обработки относительно одиночной группы. На основании совокупности существенных признаков реализован механизм создания новых групп и распределения компьютеров системы в эти новые группы для того, чтобы система могла масштабироваться далее автоматически и непрерывно.
Одновременно с этим сохранена безопасность системы, поскольку в случае выхода из строя или попадания под воздействие деструктивного программного кода большинства компьютеров одной группы, что может привести к созданию и отправке невалидных транзакций - система быстро отреагирует, приняв совместное
управленческое решение о расформировании этой группы и вывода компьютеров, участвовавших в создании невалидных транзакций, из системы.
При этом введение дополнительных этапов проверки транзакций лишь дополнительно усиливает и так обеспеченный должный уровень безопасности, поскольку позволяет выполнить проверку во время передачи транзакции между группами, не дожидаясь принятия более долгого управленческого решения. Так как во время дополнительного этапа проверки безопасности компьютерам, участвующим в проверке, нет необходимости достигать совместное решение по результатам проверки, а все они принимают решения независимо и параллельно, то время такой проверки даже меньше выработки совместного решения группы по регистрации проверяемой транзакции, что позволяет выполнять этап дополнительной проверки в течение нескольких секунд. Таким образом, дополнительный этап проверки увеличивает время между регистрацией межгрупповой транзакции в группе отправления и регистрации межгрупповой транзакции в группе назначения на несколько секунд, что гораздо меньше, чем этот же период у проекта Zilliqa - две минуты.
Сущность заявляемого способа поясняется нижеследующим описанием и фигурами.
На Фиг. 1 представлена блок схема заявляемого способа по п. 1 формулы.
На Фиг. 2 представлена блок схема заявляемого способа по п. 6 формулы.
Способ масштабирования обработки данных в распределенной системе (Фиг. 1) включает следующие этапы.
Первоначально имеющиеся компьютеры (К1...Кп+1) связывают между собой общей сетью обмена данными, образуя распределенную систему. Это может быть реализовано в виде подключения всех компьютеров к сети интернет, или к единой локальной системе связи, или к единой шине данных.
Затем эти компьютеры распределяют в логические группы (Г1...Гт) и осуществляют транзакции непосредственно от одной группы к другой, обрабатывая их в группах независимо от других групп. Предпочтительным вариантом является распределение компьютеров по меньшей мере в три группы, поскольку в случае если из трех групп выйдет из строя одна группа, двух оставшихся будет достаточно для того, чтобы продолжить работу и восстановить численность групп, добавив новую. Если изначально группы две, то в случае выхода из строя одной из групп, одна группа не сможет легитимно добавить новую группу, для восстановления полной
работоспособности системы, придется дожидаться восстановления работоспособности вышедшей из строя группы.
Правила начального распределения компьютеров в логические группы вносятся разработчиками в эти компьютеры перед запуском системы. После запуска системы, компьютеры сами в соответствии с заданными правилами распределяются по начальным группам.
При этом при начальном разделении на группы можно руководствоваться равномерным распределением по количеству компьютеров в каждой группе. В процессе работы системы управленческим решением может быть принято то, что появляется новая группа, в которую входят компьютеры, которые ранее входили в другие группы.
При этом во все компьютеры вносят настройки системы и запускают постоянно повторяемый раундами процесс выработки общего управленческого решения по всем управленческим запросам, не обработанным ранее.
Под настройками системы понимается совокупность данных о сетевых адресах всех компьютеров, их принадлежность к группам, а также их публичные ключи для идентификации в сообщениях и др. При этом благодаря тому, что в начале работы они одинаковы на всех компьютерах и в процессе выработки общего управленческого решения все изменения в них вносятся одинаковые, то на всех работающих компьютерах системы постоянно имеется одинаковый набор настроек системы. Все эти данные единообразно хранятся на каждом компьютере в виде списков. Например, в одном списке указаны пронумерованные группы. В другом - перечислены все компьютеры, принадлежность к группе, адрес для связи и публичный ключ.
В начале работы в настройки системы вносятся также и параметры, которые учитываются при работе сети. Эти параметры называются "заданными". Но в процессе работы системы управленческим решением эти параметры могут изменяться.
Внесение настроек в компьютеры возможно, например, двумя способами. Первый подразумевает внесение данных в каждый компьютер вручную, т.е. при непосредственном доступе пусконаладчика к каждому компьютеру, например, с помощью подключения к ним накопителя данных с имеющейся на нем базой данных настроек системы. Второй способ применим для формирования распределенной системы из совершенно независимых компьютеров и подразумевает создание алгоритма пуска для того, чтобы компьютеры сами обменялись данными. В этом
случае все компьютеры подключаются к общему серверу, содержащему базу данных настроек, и получают от него необходимый настройки.
В начале процесса выработки общего управленческого решения каждый компьютер в составе своей группы, при наличии к этому времени в этой группе зарегистрированной по меньшей мере одной управленческой транзакции, совместным решением группы передает все имеющиеся одобренные в группе управленческие транзакции предварительно назначенной общим управленческим решением ведущей группе этого раунда.
Причем в каждый период времени все компьютеры системы кроме обработки транзакций пользователей участвуют в формировании общей позицию по управлению для принятия управленческих решений по добавлению удалению компьютеров в/из системы, создания новых групп для масштабирования работы системы, удаления сбойных групп, распределения компьютеров по группам и другими вопросами, затрагивающими работу всей системы.
Для своевременного принятия общих управленческих решений в процессе работы системы прямо с момента начала работы системы выполняется постоянно повторяемый процесс выработки общего управленческого решения по всем управленческим запросам, не обработанным до этого. Время от начала работы процесса выработки общего управленческого решения до его окончания называется раундом.
Ведущей группой называется группа, дополнительно выполняющая в текущем раунде функцию составителя из всех направленных от групп управленческих транзакций одного легитимного списка одобренных заданным количеством компьютеров управленческих транзакций.
Каждый раунд для работы процесса выработки общего управленческого решения необходимо, чтобы все компьютеры системы знали, какая группа является ведущей в этом раунде.
Способ назначения статуса ведущей группы вырабатывается в ходе принятия согласованного управленческого решения. Возможно несколько вариантов реализации такого назначения. Статус ведущей группы может переходить между всеми группами системы по очереди, начиная от первой группы в списке групп системы, который имеется на каждом компьютере, с учётом того, что в случае если в раунде ведущей группой была последняя в списке, то в следующий раунд ведущей группой будет первая в списке. Очередность смены статуса ведущей группы может устанавливаться на следующее заданное количество раундов, при этом также устанавливается интервал
следующего установления очередности смены заданного статуса ведущей группы, например, установить очередность на XX раундов вперед и через каждые XX/ 10 раундов повторять установку очередности. Статус ведущей группы также может устанавливаться по заданной функции назначения ведущей группы, по которой, зная номер раунда, можно вычислить номер ведущий группы.
Далее ведущая группа после получения в установленное время от других групп списка управленческих транзакций для обработки исключает невалидные транзакции, составляет из всех направленных от групп управленческих транзакций список, являющийся кандидатом на легитимный список управленческих транзакций этого раунда и одобренный заданным количеством компьютеров, и рассылает его для подтверждения всем группам.
Затем каждая группа, получив упомянутый список-кандидат от ведущей группы этого раунда, согласовывает его с каждым компьютером, входящим в эту группу, и отправляет результат согласования, представляющий собой количество компьютеров, согласовавших этот список, обратно в ведущую группу.
Как только ведущая группа получит от групп ответы с результатами согласования и если общее количество компьютеров, согласовавших список-кандидат в этих ответах, составит заданное количество компьютеров в системе, то этот список- кандидат становится легитимным списком управленческих транзакций этого раунда. Здесь наиболее предпочтительным является заданное количество больше половины компьютеров, что позволит обеспечить дополнительное повышение безопасности транзакции.
Теперь ведущая группа рассылает его вместе с собранными подтверждениями по всем компьютерам, каждый из которых, получив этот список, сохраняет его у себя и выполняет изменения в общих списках настройки системы в соответствии с присланным списком.
В случае выхода из строя во время раунда ведущей группы легитимный список одобренных управленческих транзакций не составляется, а продолжает свое составление в следующем раунде со следующей ведущей группой.
При передаче транзакции от одной группы к другой дополнительно может осуществляться выборочная или постоянная проверка этих транзакций различными вариантами.
Например, проверка этих транзакций может осуществляться компьютерами валидационной группы (ВГ), которая назначается общим управленческим решением
для каждой группы и в которую входят компьютеры из числа, не входящих в проверяемую группу (Фиг. 2). При этом проверка транзакций проводится каждым компьютером из валидационной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции. Причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров валидационной группы.
Проверка этих транзакций также может осуществляться всеми остальными компьютерами системы. При этом проверка транзакций проводится каждым компьютером по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции. Причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров системы.
Возможен вариант, когда проверка этих транзакций осуществляется остальными группами системы. При этом проверка транзакций проводится каждым компьютером из проверяющей группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции. Причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества остальных групп системы.
Возможен другой вариант, когда проверка этих транзакций осуществляется назначенными группами системы, которые назначаются общим управленческим решением для каждой группы. При этом проверка транзакций проводится каждым компьютером из назначенной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции. Причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров назначенных групп.
Примеры осуществления заявляемого способа.
Пример 1. Для тестирования было развернуто программное обеспечение системы на 900 компьютерах. Затем эти компьютеры были подключены к сети Интернет. На каждом компьютере были сгенерированы криптографические ключи для идентификации в процессе обмена сообщениями. После этого было сформулировано правило распределения на группы, в которое были занесены данные о предпочтении
размера группы в 9 компьютеров. Затем это правило, все Интернет адреса компьютеров, их криптографические ключи были собраны в одну базу данных и реплицированы на все компьютеры, участвующие в тесте. Таким образом, внесены первоначальные настройки системы. При начале работы сети в соответствии с внесенным правилом компьютеры разделились на 100 групп по 9 компьютеров.
Затем на компьютеры системы подавался поток сгенерированных транзакций, содержащий как внутригрупповые, так и межгрупповые транзакции. При этом средняя нагрузка на каждую группу составляла две тысячи транзакций в секунду. В результате продолжительного теста среднее время регистрации внутригрупповых и межгрупповых транзакций составило 1 и 2 секунды, соответственно.
Пример 2. Создание распределенной системы управления логистикой на предприятии.
Для работы системы было выделено 15 компьютеров. Их разместили по 2 компьютера в отделе приемки, выдачи и складе. И 9 компьютеров разместили в других помещениях организации с более строгим допуском. Эти компьютеры связывали локальной сетью организации.
После этого было сформулировано правило распределения на группы, в которое были занесены данные о предпочтении размера группы в 5 компьютеров и соответствия 2 компьютеров в группе одному месту расположения. Затем данные о расположении компьютеров, правило распределения в группы, адреса компьютеров в локальной сети и их криптографические ключи были собраны в одну базу данных и реплицированы на все 15 компьютеров.
После начала работы, компьютеры распределились на три группы и начали обрабатывать и регистрировали данные перемещения в пределах своей ответственности и создавали межгрупповые транзакции при перемещении товаров между отделами приемки, склада и отгрузки.
В процессе работы были произведены замеры времени регистрации транзакций. В результате было зафиксировано среднее время регистрации транзакции внутри группы 0.3 секунды, а между группами 1 секунду.
Claims
1. Способ масштабирования обработки данных в распределенной системе, заключающийся в том, что первоначально компьютеры связывают между собой общей сетью обмена данными, образуя распределенную систему, затем эти компьютеры распределяют в логические группы и осуществляют транзакции от одной группы к другой, обрабатывая их в группах независимо от других групп, отличающийся тем, что первоначально во все компьютеры вносят настройки системы и запускают постоянно повторяемый раундами процесс выработки общего управленческого решения по всем управленческим запросам, не обработанным ранее, при этом в начале процесса выработки общего управленческого решения каждый компьютер в составе своей группы, при наличии к этому времени в этой группе зарегистрированной по меньшей мере одной управленческой транзакции, совместным решением группы передает все имеющиеся одобренные в группе управленческие транзакции предварительно назначенной общим управленческим решением ведущей группе этого раунда, которая после получения от других групп списка управленческих транзакций для обработки исключает невалидные транзакции, составляет из всех направленных от групп управленческих транзакций список, являющийся кандидатом на легитимный список управленческих транзакций этого раунда и одобренный заданным количеством компьютеров, и рассылает его для подтверждения всем группам, затем каждая группа, получив упомянутый список-кандидат от ведущей группы этого раунда, согласовывает его с каждым компьютером, входящим в эту группу, и отправляет результат согласования, представляющий собой количество компьютеров, согласовавших этот список, обратно в ведущую группу, как только ведущая группа получит от групп ответы с результатами согласования и если общее количество компьютеров, согласовавших список-кандидат в этих ответах, составит заданное количество компьютеров в системе, то этот список-кандидат становится легитимным списком управленческих транзакций этого раунда, и ведущая группа рассылает его вместе с собранными подтверждениями по всем компьютерам, каждый из которых, получив этот список, сохраняет его у себя и выполняет изменения в общих списках настройки системы в соответствии с присланным списком.
2. Способ масштабирования обработки данных в распределенной системе по п. 1, отличающийся тем, что статус ведущей группы переходит между всеми группами системы по очереди, начиная от первой группы в списке групп системы, который имеется на каждом компьютере, с учётом того, что в случае если в раунде ведущей
группой была последняя в списке, то в следующий раунд ведущей группой будет первая в списке.
3. Способ масштабирования обработки данных в распределенной системе по п. 1, отличающийся тем, что очередность смены статуса ведущей группы устанавливается на следующее заданное количество раундов, при этом также устанавливается интервал следующего установления очередности смены заданного статуса ведущей группы.
4. Способ масштабирования обработки данных в распределенной системе по п. 1, отличающийся тем, что статус ведущей группы устанавливается по заданной функции назначения ведущей группы.
5. Способ масштабирования обработки данных в распределенной системе по п. 1, отличающийся тем, что при передаче транзакции от одной группы к другой осуществляется проверка этих транзакций.
6. Способ масштабирования обработки данных в распределенной системе по п. 5, отличающийся тем, что проверка этих транзакций осуществляется компьютерами валидационной группы, которая назначается общим управленческим решением для каждой группы и в которую входят компьютеры из числа, не входящих в проверяемую группу, при этом проверка транзакций проводится каждым компьютером из валидационной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров валидационной группы.
7. Способ масштабирования обработки данных в распределенной системе по п. 5, отличающийся тем, что проверка этих транзакций осуществляется всеми остальными компьютерами системы, при этом проверка транзакций проводится каждым компьютером по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров системы.
8. Способ масштабирования обработки данных в распределенной системе по п. 5, отличающийся тем, что проверка этих транзакций осуществляется остальными группами системы, при этом проверка транзакций проводится каждым компьютером из проверяющей группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем,
транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества остальных групп системы.
9. Способ масштабирования обработки данных в распределенной системе по п. 5, отличающийся тем, что проверка этих транзакций осуществляется назначенными группами системы, которые назначаются общим управленческим решением для каждой группы, при этом проверка транзакций проводится каждым компьютером из назначенной группы по тем же правилам, что применяются в проверяемой группе, и результат проверки отравляется компьютерам группы назначения транзакции, причем, транзакции от проверяемой группы могут быть обработаны в группе назначения только после получения одобрения от заданного количества компьютеров назначенных групп.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2018137611A RU2695976C1 (ru) | 2018-10-24 | 2018-10-24 | Способ масштабирования обработки данных в распределенной системе |
| RU2018137611 | 2018-10-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2020085946A1 true WO2020085946A1 (ru) | 2020-04-30 |
Family
ID=67586813
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/RU2019/000725 WO2020085946A1 (ru) | 2018-10-24 | 2019-10-14 | Способ масштабирования обработки данных в распределительной системе |
Country Status (2)
| Country | Link |
|---|---|
| RU (1) | RU2695976C1 (ru) |
| WO (1) | WO2020085946A1 (ru) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080020826A1 (en) * | 1995-02-21 | 2008-01-24 | Oneida Indian Nation | Cashless computerized video game system and method |
| RU2480830C2 (ru) * | 2011-04-26 | 2013-04-27 | Закрытое акционерное общество "Торговый Дом "ПЕРЕКРЕСТОК" | Способ автоматизированной обработки данных для принятия управленческих решений по проекту и портфелю проектов |
| US20160330034A1 (en) * | 2015-05-07 | 2016-11-10 | Blockstream Corporation | Transferring ledger assets between blockchains via pegged sidechains |
| US20170330174A1 (en) * | 2016-05-11 | 2017-11-16 | Nasdaq, Inc. | Application framework using blockchain-based asset ownership |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9985964B2 (en) * | 2016-03-28 | 2018-05-29 | Black Gold Coin, Inc. | Systems and methods for providing block chain-based multifactor personal identity verification |
| RU181439U1 (ru) * | 2018-04-06 | 2018-07-13 | Оксана Валерьевна Кириченко | Децентрализованная технологическая платформа хранения и обмена данными транзакций в распределенной вычислительной сети |
-
2018
- 2018-10-24 RU RU2018137611A patent/RU2695976C1/ru active
-
2019
- 2019-10-14 WO PCT/RU2019/000725 patent/WO2020085946A1/ru active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080020826A1 (en) * | 1995-02-21 | 2008-01-24 | Oneida Indian Nation | Cashless computerized video game system and method |
| RU2480830C2 (ru) * | 2011-04-26 | 2013-04-27 | Закрытое акционерное общество "Торговый Дом "ПЕРЕКРЕСТОК" | Способ автоматизированной обработки данных для принятия управленческих решений по проекту и портфелю проектов |
| US20160330034A1 (en) * | 2015-05-07 | 2016-11-10 | Blockstream Corporation | Transferring ledger assets between blockchains via pegged sidechains |
| US20170330174A1 (en) * | 2016-05-11 | 2017-11-16 | Nasdaq, Inc. | Application framework using blockchain-based asset ownership |
Also Published As
| Publication number | Publication date |
|---|---|
| RU2695976C1 (ru) | 2019-07-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Guerraoui et al. | The consensus number of a cryptocurrency | |
| Robinson et al. | Atomic crosschain transactions for ethereum private sidechains | |
| Golle et al. | Secure distributed computing in a commercial environment | |
| CN110602217B (zh) | 基于区块链的联盟管理方法、装置、设备及存储介质 | |
| US20230283473A1 (en) | Computer-implemented systems and methods relating to a binary blockchain comprising a pair of coupled blockchains | |
| CN102904927A (zh) | 具有时间相关证书的分布式计算机系统 | |
| CN111291060A (zh) | 一种管理区块链节点的方法、装置及计算机可读介质 | |
| JP2020524932A (ja) | ブロックチェーンネットワークにおける整合性のある分散型メモリプールのための方法及びシステム | |
| CN110808839B (zh) | 一种区块链异常数据的处理方法、装置、设备和介质 | |
| CN113940032A (zh) | 用于在区块链网络中记录工作历史并证明声誉的方法和装置 | |
| US11403281B2 (en) | Parallel blockchain processing | |
| CN112291372B (zh) | 区块链的异步落账方法、装置、介质及电子设备 | |
| CN111047316A (zh) | 一种反篡改的智能区块链系统及实现方法 | |
| US20220058549A1 (en) | Systems and methods for distributed resource allocation | |
| WO2020082213A1 (zh) | 一种网络可扩展性区块链实现方法 | |
| WO2023040453A1 (zh) | 一种交易信息处理方法及装置 | |
| CN111478795A (zh) | 一种基于混合拜占庭容错的联盟区块链网络共识方法 | |
| Schmid et al. | Tangle ledger for decentralized learning | |
| WO2021045829A1 (en) | Byzantine consensus without centralized ordering | |
| CN110278246B (zh) | 一种针对联盟链的存证业务转移方法、装置及设备 | |
| Yuan et al. | Lightweight and reliable decentralized reward system using blockchain | |
| RU2695976C1 (ru) | Способ масштабирования обработки данных в распределенной системе | |
| CN112039893B (zh) | 私密交易处理方法、装置、电子设备及可读存储介质 | |
| Camaioni et al. | Chop chop: Byzantine atomic broadcast to the network limit | |
| CN111882415A (zh) | 一种质量检测模型的训练方法和相关装置 |
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: 19875928 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 200821) |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 19875928 Country of ref document: EP Kind code of ref document: A1 |