RU2686818C1 - Способ масштабирования распределенной информационной системы - Google Patents

Способ масштабирования распределенной информационной системы Download PDF

Info

Publication number
RU2686818C1
RU2686818C1 RU2018113535A RU2018113535A RU2686818C1 RU 2686818 C1 RU2686818 C1 RU 2686818C1 RU 2018113535 A RU2018113535 A RU 2018113535A RU 2018113535 A RU2018113535 A RU 2018113535A RU 2686818 C1 RU2686818 C1 RU 2686818C1
Authority
RU
Russia
Prior art keywords
subchain
transaction
sender
recipient
transactions
Prior art date
Application number
RU2018113535A
Other languages
English (en)
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 Максим Михайлович Михайленко
Priority to RU2018113535A priority Critical patent/RU2686818C1/ru
Priority to PCT/RU2019/000213 priority patent/WO2019199205A1/ru
Application granted granted Critical
Publication of RU2686818C1 publication Critical patent/RU2686818C1/ru

Links

Images

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

Abstract

Изобретение относится к области обработки цифровых данных с помощью электрических устройств. Технический результат заключается в обеспечении возможности формирования многоуровневых структур из равноправно взаимодействующих блокчейн сетей, выступающих в качестве отдельных ячеек для сетей следующего уровня. Технический результат достигается за счет этапа, на котором определяют получателя, подписания транзакций, этапа, на котором подписанные транзакции направляют узлу сабчейна, этапа, на котором на узле сабчейна создают новый блок данных, этапа, на котором из секции транзакций, в которых получатель зарегистрирован в другом сабчейне, этапа, на котором на узле сабчейна получателя получают направленные с узла сабчейна отправителя все сформированные пакеты транзакций, этапа, на котором пакет с транзакциями со следующим после ранее полученного и зарегистрированного на узле сабчейна получателя номера пакета валидируется узлами сабчейна-получателя путем валидации, этапа, на котором валидированный пакет включается в новый блок сабчейна получателя, этапа, на котором с узла сабчейна получателя направляют в узел сабчейна отправителя информацию, этапа, на котором на узле сабчейна отправителя ожидают информацию о внесении полученного пакета в новый блок данных сабчейна получателя, этапа, на котором на узле сабчейна отправителя получают информацию. 4 ил.

Description

Область техники, к которой относится изобретение
Изобретение относится к области обработки цифровых данных с помощью электрических устройств, в частности к методам цифровых вычислений или обработки данных, предназначенных для специфических функций, в том числе информационного поиска, а также структурирования баз данных для этой цели.
Глоссарий
С целью обеспечения достаточности раскрытия изобретения и обеспечения возможности проведения информационного поиска в отношении заявляемого технического решения ниже приведен перечень терминов, используемых в настоящем описании.
Хеш - последовательность символов, формируемая с помощью применения математической функции, заключающейся в преобразовании входных данных произвольной длины в (выходную) строку установленной, меньшей длины. При любом изменении входных данных хеш этих данных будет отличаться от хеша неизменных входных данных.
Блокчейн — структура данных, состоящая из блоков данных, в которой в каждом блоке (кроме первого) имеется хеш созданного предыдущим блока. Создается некая “цепочка” блоков где каждый следующий блок “связан” (имеет ссылку на хеш) с предыдущим блоком. Такая структура гарантирует, что при изменении даже одного бита в блоке данных изменится его хеш, а значит, ссылка на измененный блок в следующем блоке не будет совпадать с новым хешем. Произойдет разрыв цепочки, что легко находится при простой проверке. (тут почти везде можно картинки вставлять)
Блокчейн сеть - множество узлов с одинаковой программной реализацией блокчейна, имеющие еще одно одинаковое программное обеспечение позволяющее им связываться между собой через каналы связи, обмениваться блоками и создавать новые блоки.
Сабчейн — блокчейн сеть, программное обеспечение которой предусматривает возможность взаимодействия с другими блокчейн сетями через каналы связи, имеющими такое же программное обеспечение.
Сайдчейн — блокчейн сеть, программное обеспечение которой предусматривает возможность взаимодействия с основной (родительской) блокчейн сетью.
Модель Сайдчейн — модель взаимодействия между блокчейн сетями -основной (родительской) блокчейн сетью и сайдчейнами.
Узел — ЭВМ, имеющая средства связи с другими ЭВМ, на которой исполняется программное обеспечение с каким-либо вариантом блокчейн.
MTP - подтверждение дерева Меркла (Merkle Tree Proof). Деревом Меркла называют полное двоичное дерево, в листовые вершины которого помещены хеши от блоков данных, а внутренние вершины содержат хеши от сложения значений в дочерних вершинах. Подтверждение дерева Меркла, это одна ветка полного дерева Меркла блока, в котором есть информация только об одной транзакции (подтверждение которой и формируется), а все остальные вершины содержат лишь хеши от соседних веток. При предоставлении MTP, в случае верности всех хешей узлов и совпадении корневых хешей MTP и блока можно однозначно утверждать, что MTP является частью блока.
Валидация — имеет два значения: 1. Способ проверки, с помощью которого узел подтверждает, что созданный блок не содержит ошибок или подлога.
2. Способы проверки, в результате которых можно однозначно подтвердить, что рассматриваемые данные не содержат ошибок или подлога. Как частный случай рассмотрим способ проверки транзакции уже внесенной в блок по её MTP. Сначала проверяется соответствие информации содержащейся в транзакции подписи пользователя, затем вычисляется хеш транзакции и проверяется соответствует ли он тому что указан в MTP, затем вычисляется все следующие пары хешей и проверяется их соответствие с данными в MTP, вплоть до корневого хеша блока. Затем проверяется валидность хеша блока.
Валидность блока (валидность хеша блока ) — способ проверки хеша блока, подтверждающий, что это блок принадлежит блокчейну соотвествующего сачбейна и создан в процессу консенсуса этого сабчейна. Для проверки достаточно проверить все представленные узлами сабчейна цифровые подписи хеша блока. Если все подписи принадлежат узлам, в то время участвовавшим в консенсусе по созданию этого блока, то хеш блока прошел проверку.
Цифровая подпись — небольшая последовательность символов, которая с помощью криптографических преобразований однозначно позволяет определить то, что для ее создания использовалась подписываемая информация и закрытый ключ пользователя, подписывающий эту информацию.
Консенсус — способ взаимодействий узлов в блокчейн-сети (участников), в результате которого создается новый блок.
Цифровая ценность — запись с данными в блокчейн, которая имеет владельца. Владение такими данными легко проверяется с помощью программного обеспечения, реализующего возможность работы с блокчейном, в котором возможно владение цифровыми ценностями.
Двойная трата — действия злоумышленника, при которой в новый блок блокчейна предлагается для записи информация о передаче цифровой ценности, уже переданной ранее. В случае создания блока с такой записью в блокчейне появляется новый объем необеспеченных ценностей.
Масштабируемость - способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов. Различают вертикальное и горизонтальное масштабирование.
Вертикальное масштабирование - увеличение общей производительности путем замены одного из составляющих системы на более производительный аналог. Однако в любой момент времени у такого масштабирования есть ограничения, так как после замены всех частей на наиболее мощные, нет возможности дальнейшего улучшения.
Горизонтальное масштабирование - увеличение общей производительности создания новых копий объектов системы (добавление серверов, процессоров). Этот способ увеличения производительности сильно зависит от модели взаимодействия объектов системы. Чем более удачная модель принята, тем больший эффект достигается при добавлении новых копий.
Децентрализация — процесс передачи прав принятия решений от единой структуры принятия решения к более многочисленным рассеянным или распределенным структурам. В случае информационных систем, о которых говорится в данном способе, при единичном узле принятия решений децентрализованность системы максимально низкая, такую систему называют централизованной. При добавлении таких узлов в систему, выход которых из строя не приводит к прекращению работы системы, происходит процесс децентрализации. Чем больше независимых друг от друга узлов в системе, тем выше её децентрализованность. Например, у системы bitcoin в настоящее время более 10 тысяч независимых узлов.
Транзакция — в рамках данного способа это информация, сформированная пользователем для записи в блокчейне. В частном случае может содержать поручение на перерегистрацию ценности от одного владельца к другому. Подлинность поручения обеспечивает подписание пользователем этой информации цифровой подписью пользователя
Балансы пользователя — совокупность всех транзакций, обеспечивающих изменение ценностей в блокчейне, в которых принимал участие пользователь (его адрес). Так как таких транзакций может быть много, отслеживается только результат расходных и природных транзакций по каждому виду цифровых ценностей.
Адрес пользователя — небольшая последовательность символов, которая напрямую связана с открытым ключом пользователя. Эта связь может быть создана как с помощью криптографических функций, так и иных действий (например, адрес пользователя может быть просто открытым ключом пользователя). Способ, которым связан адрес пользователя, должен быть легко проверяем. Например, хеш открытого ключа - один из способов такой связи. Легко установить, что при смене даже одного бита в открытом ключе изменится и адрес.
Единое пространство адресов пользователей — требование к сабчейнам. Реализуется с помощью следующих особенностей: все сабчейны используют одинаковый способ связи между адресом пользователя и его открытым ключом; сабчейны имеют способ поиска и нахождения сабчейна пользователя при условии, что известен адрес пользователя.
p2p структура — это структура сети связей ЭВМ, основанная на равноправии участников. В такой структуре каждая ЭВМ является одновременно и клиентом (получает данные для своих нужд от серверов) и сервером (отправляет данные другим пользователям). В отличие от классической архитектуры клиент-сервера, такая структура позволяет сохранять работоспособность сети связи при любом количестве и любом сочетании доступных узлов.
SPV — упрощенная проверка платежа (simplified payment verification) структура данных в блокчейне, описанная в патенте US20160330034A1, применяется для подтверждения факта блокировки цифровых ценностей в одной блокчейн сети для последующего их перевода в другую блокчейн сеть.
IBC — Межблокчейновое взаимодействие (Inter-blockchain Communication) — протокол, с помощью которого происходит перемещение пакета данных из одной блокчейн сети в другую через Cosmos Hub в проекте Cosmos.
Уровень техники
Впервые модель взаимодействия между двумя блокчейнами, названная впоследствии сайдчейн, была описана в статье “Enabling Blockchain Innovations with Pegged Sidechains” от 2014-10-22. Позже был выдан патент US20160330034A1 отражающий способ, описанный в этой статье.
Данный патент раскрывает новые методы взаимодействия двух блокчейнов по переносу цифровых ценностей из одного блокчейна (названного основным или родительским) в другой (названный сайдчейном), с возможностью последующего возврата этих ценностей и с защитой от появления двойной траты, как при нахождении ценностей внутри сайдчейна, так и в процессе передачи как в сайдчейн, так и из сайдчейна.
Таким образом, описанная система позволяет создавать вокруг родительского блокчейна множество сайдчейнов, которые, работая независимо друг от друга, могут передавать ценности, созданные внутри родительского блокчейна, между собой, через родительский блокчейн (фиг.1).
Также возможна схема с многоуровневыми сайдченами, когда сайдчейн верхнего уровня выступает родительским блокчейном для другого сайдчейна, однако, насколько нам известно, такой способ пока не был нигде использован.
К достоинствам способа, раскрытого в патенте US20160330034A1, можно отнести следующие показатели:
1. С помощью данного способа можно безопасно переносить ценности из родительского блокчейна в сайдчейны и обратно, в частности, при осуществлении данного способа невозможно возникновение двойной траты при переносе ценностей.
2. Если несколько транзакций были совершены внутри сайдчейна, они производятся без нагрузки на родительский блокчейн, следовательно, такой способ теоретически позволяет добиться большей производительности, чем обычный блокчейн, и, следовательно, позволяет масштабировать модель.
Тем не менее, данный способ имеет следующие недостатки:
1. Метод описывает только перенос ценностей из родительского блокчейна в сайдчейн и потом возвращение этих ценностей обратно. Способ не предусматривает работу с нефинансовыми транзакциями. Также не предусматривается возможность сайдчейнов передавать свои ценности в родительский блокчейн или другие сайдчейны.
2. Реализовать описанную ранее в качестве положительного результата возможность масштабирования и повышения производительности рассматриваемого способа на практике не представляется возможным, так как данный способ основывается на методе SPV, что обуславливает наличие существенного периода ожидания в 1-2 дня (пункт [0042] в патенте US20160330034A1) при переходе и возврате ценностей между родительским блокчейном и сайдчейном.
Впоследствии идею, указанную в патенте US20160330034A1, развили до способа использования этой модели с похожими связями между блокчейнами для масштабирования (https://cosmos.network/whitepaper).
Указанный способ также использует модель, представленную на фиг. 1, но использует ее, в первую очередь, для масштабирования:
1. Все основные действия происходят в сайдчейнах, названных в этом проекте «зонами».
2. Родительский блокчейн (в этом способе назван Cosmos hub) используется в большинстве своем только как гарант по переносу транзакций (как ценностных, так и иных) между зонами (фиг.2). (https://raw.githubusercontent.com/gnuclear/atom-whitepaper/master/images/hub_and_zones.png - рисунок из проекта). Проблема заключается в том, что при захвате большинства узлов в блокчейн-сети, у лица, имеющего доступ к большинству узлов в блокчейн-сети, возникает возможность производить двойные траты. Суть способа использования сайдчейнов, предлагаемая в указанном техническом решении, основывается на том, что центральный (главный родительский) блокчейн имеет гораздо большую защищенность по сравнению с сайдчейнами в силу большей децентрализованности. Таким образом, сайдчены, которые не могут «доверять» друг другу из-за проблем с безопасностью в силу низкой децентрализованности, могут «доверять» центральному блокчейну и используют его как надежную среду для передачи ценностей.
К достоинствам способа, раскрытого в патенте US20160330034A1, можно отнести, тот факт, что в отличии от способа, описанного в патенте US20160330034A1, вместо SPV применяется IBC, что существенно уменьшает время на передачу транзакций между Cosmos HUB и зонами. В результате возможно масштабирование пропускной способности системы.
Недостатками данного способа является то, что любая межзонная транзакция должна пройти через Cosmos HUB, что в несколько раз увеличивает время межзонных транзакций относительно внутризональных. Время межзонной транзакции будет равно сумме времен регистрации транзакции в зоне источнике, регистрации факта транзакции в Cosmos HUB, регистрации в зоне получателя.
Существует верхний предел пропускной способности по обработке транзакций у Cosmos HUB, связанный с тем, что Cosmos HUB представляет собой обычный блокчейн. При увеличении количества зон, вероятность появления межзонных транзакций увеличивается. Все межзонные транзакции проходят через Cosmos HUB. В случае если количество межзонных транзакций в единицу времени превысят пропускную способность Cosmos HUB, часть межзонных транзакций будет ожидать очереди. Таким образом, предел пропускной способности Cosmos HUB ограничивает и пропускную способность всей системы.
Настоящее изобретение предназначено для решения технической задачи по обеспечению возможности горизонтального масштабирования распределенной информационной системы, состоящей из блокчейн сетей, за счет увеличения общей производительности данной системы с помощью добавления неограниченного количества блокчейн сетей в систему.
Технический результат заключается в обеспечении возможности формирования многоуровневых структур из равноправно взаимодействующих блокчейн сетей, выступающих в качестве отдельных ячеек для сетей следующего уровня.
Указанный технический результат при использовании заявляемого способа достигается за счет применения взаимодействующих между собой раскрытым в настоящей заявительной документации способом сабчейнов.
Раскрытие изобретения
Для увеличения производительности блокчейн системы количество узлов, участвующих в консенсусе по созданию новых блоков должно быть ограничено. Чем больше узлов участвует в консенсусе, тем больше тратится времени на согласование. Поэтому в целом для увеличения производительности блокчейн системы необходимо создавать отдельные блокчейны, а потом их каким-либо образом связывать.
Для обеспечения возможности взаимодействия блокчейнов между собой к каждому такому блокчейну предъявляются стандартизированные требования. Блокчейны, которые поддерживают такие требования, мы называем сабчейнами.
Стандартные требования, которые в заявленном способе предъявляются к сабчейнам:
1. Алгоритм валидации блока одинаков во всех сабчейнах (во-первых, это позволяет относительно быстро и максимально достоверно валидировать блок из другого сабчейна, за счет единого для всех сабчейнов унифицированного алгоритма валидации блоков; во-вторых позволяет узлам выходить из состава одного сабчейна и входить в состав другого сабчейна путем удаления с узла блокчейна всего старого сабчейна и загрузки на узел другого блокчейна всего нового сабчейна; в-третьих, позволяет узлам объединяться для создания нового сабчейна);
2. Каждый узел сабчейна имеет полное представление о структуре всех остальных сабчейнов за счет того, что каждый узел сабчейна содержит информацию об адресах всех остальных узлов и их принадлежности к сабчейнам. Это позволяет любому узлу легко проводить валидацию полученного блока или пакета с данными от других сабчейнов. Также каждый узел имеет одинаковый механизм получения информации об изменении в этих структурах;
3. Во всех сабчейнах одно общее пространство адресов пользователей (все сабчейны работают с одними и теми же адресами, что и все остальные), в сабчейне присутствует стандартная для настоящего способа система передачи транзакции из сабчейна источника в сабчейн приемника.
Сабчейны, благодаря выполнению требований из пункта 3, могут объединятся в двухуровневую p2p структуру (фиг. 1). При этом общая пропускная способность такой структуры будет равна сумме пропускных способностей всех участвующих сабчейнов.
Связи между сабчейнами (фиг. 3) представляет из себя два типа. Первый тип — это передача транзакций из одного сабчейна в другой по стандартному для настоящего способа протоколу (пункт 3), второй тип взаимодействия - это ведение обобщенного реестра всех узлов (блокчейн сабчейнов) и их организации в сабчейны. Для ведения этого реестра используется тот же самый способ консенсуса, что и в блокчейн сети, только в качестве участников консенсуса используются сабчейны (при этом для того, чтобы сабчейн подал голос за валидацию блока для консенсуса между сабчейнами, необходимо предоставить подтверждение того, что внутри сабчейна подтверждение голоса было записано в блоке этого сабчейна и валидировано узлами входящими в него).
В случае двухуровневой модели сабчейнов (фиг. 3) возможно появление большого числа сабчейнов, что приведет к снижению общей производительности системы ведения реестра всех узлов (фиг. 3). Для предотвращения таких проблем предлагается использовать многоуровневую структуру, показанную на фиг. 4.
В многоуровневой системе сабчейнов транзакции от одного сабчейна 1-го уровня также напрямую передаются к получателю сабчейну 1-го уровня, при этом согласование реестра узлов проходит многоуровневую валидацию. Количество узлов в сабчейне может быть любым, но должно соблюдаться правило, по которому снижать количество узлов можно только до безопасного минимума. Для каждой конкретной ситуации, в зависимости от сферы деятельности предприятия, для которого используется заявляемый способ, безопасный минимум может быть разным. Однако необходимо соблюдать баланс между децентрализацией, эффективностью и ответственностью узлов.
Сущность заявляемого на регистрацию в настоящей заявке способа заключается в следующем:
Пользователь-отправитель транзакции подписывает транзакцию путем применения криптографической функции к транзакции и собственному приватному ключу (механизм аналогичный работе электронно-цифровой подписи), в результате чего получается подпись транзакции. После этого пользователь-отправитель транзакции направляет транзакцию и подпись транзакции узлу сабчейна через канал связи (например, через сеть Интернет).
Узел сабчейна по каналам связи с другими узлами сабчейна передает полученные им транзакции и подписи транзакции пользователей-отправителей транзакций другим узлам сабчейна для включения узлами сабчейна отправленных этим узлом сабчейна транзакций и подписей транзакций пользователей-отправителей транзакций в новый блок данных. При формировании нового блока данных все транзакции, где пользователь-получатель транзакций зарегистрирован не в том сабчейне, в котором зарегистрирован пользователь-отправитель транзакции, выделяются в отдельную секцию нового блока данных. Таким образом, в новом блоке данных создаются две секции:
1. секция нового блока данных, содержащих транзакции, у которых пользователь-получатель транзакции зарегистрирован в том же сабчейне, что и пользователь-отправитель транзакции;
2. секция нового блока данных, содержащих транзакции, у которых пользователь-получатель транзакции не зарегистрирован в том сабчейне, в котором зарегистрирован пользователь-отправитель транзакции, а пользователь-получатель транзакции зарегистрирован в другом сабчейне.
После включения нового блока в блокчейн сабчейна-отправителя, узлы извлекают из 2-й секции этого блока все транзакции с их MTP. Затем узел формирует исходящие пакеты транзакций с их MTP для каждого сабчейна-получателя. Каждый пакет транзакций с их MTP содержит номер пакета для сабчейна-получателя, адрес сабчейна-получателя, заголовок нового блока данных, а также транзакции с их MTP.
Затем узлы, входящие в сабчейн отправителя, передают по каналам связи все сформированные пакеты по меньшей мере в один из узлов сабчейнов получателей.
При получении узлами сабчейнов-получателей пакетов с транзакциями с их MTP от сабчейна-отправителя, узлы сабчейнов-получателей пакетов с транзакциями с их MTP в первую очередь проверяют номер каждого пакета транзакций с их MTP путем соотнесения номера полученного пакета с транзакциями с их MTP с номером предыдущего зарегистрированного пакета транзакций с их MTP, и в том случае, если номер полученного пакета с транзакциями с их MTP на 2 и более больше, чем номер предыдущего зарегистрированного в сабчейне получателя пакета транзакций с их MTP, узлы сабчейнов-получателей направляют эти полученные пакеты с транзакциями с их MTP в очередь ожидания пропущенных пакетов транзакций с их MTP, которые в свою очередь по мере поступления пропущенных пакетов транзакций с их MTP переходят к следующему этапу.
Пакет со следующим после ранее зарегистрированного в сабчейне получателя номера пакета, валидируется узлами сабчейна-получателя путем валидации всех содержащихся в пакете транзакций с их MTP.
После валидации пакет транзакций с их MTP включается в новый блок сабчейна получателя, а балансы пользователей-получателей транзакций из пакета транзакций с их MTP изменяются в соответствии с этими транзакциями.
После включения блока с пакетом транзакций с их MTP в блокчейн сабчейна получателя, сабчейн получателя отправляет по каналам связи в сабчейн отправителя информацию о внесении пакета транзакций с их MTP в новый блок данных сабчейна получателя с MTP пакета транзакций с их MTP.
После получения через каналы связи узлом сабчейна отправителя от узла сабчейна получателя информации о внесении пакета транзакций с их MTP в новый блок данных сабчейна получателя с MTP пакета транзакций с их MTP, узел сабчейна отправителя валидирует MTP пакета транзакций с их MTP. Если валидация осуществлена узлом сабчейна отправителя, информация о внесении пакета транзакций с их MTP в новый блок данных сабчейна получателя с MTP пакета транзакций с их MTP вносится в новый блок сабчейна отправителя. На этом работа по регистрации транзакции пользователя закончена.
В случае если узел сабчейна отправителя не получил по каналам связи за предусмотренное настройками блокчейн сети время информацию о внесении пакета транзакций с их MTP в новый блок данных сабчейна получателя с MTP пакета транзакций с их MTP, узел сабчейна отправителя повторно отправляет по каналам связи пакет транзакций с их MTP в адрес узла сабчейна получателя. Это продолжается до тех пор, пока узел сабчейна отправителя не получит по каналам связи информацию о внесении пакета транзакций с их MTP в новый блок данных сабчейна получателя с MTP пакета транзакций с их MTP.
Так, например, описанный способ поможет в индустрии логистики. Возьмем компанию, имеющую несколько складов. Для предотвращения случаев подмены грузов или изменения данных о поставках задним числом руководством было принято решение использовать блокчейн. Применяя способ, все склады можно представить сабчейнами. В этих сабчейнах происходит фиксация всего, что происходит внутри соответствующих им складов. А логистические движения между складами оформляются в виде межсабчейновых транзакций.
Пример для применения при роботизации производств. Представим предприятие, часть цехов которого на 100% роботизировано. Очень важно, чтобы вся статистика по производству сохранялась, а в виду того, что люди фактически отсутствуют, в таких цехах важна сохранность и подлинность такой статистики, а также правомочность заданий, отданных роботам цеха. В этом случае тоже очень хорошо применим описываемый способ - каждый такой цех может быть представлен отдельным сабчейном. Более того, так как в составе роботов находится управляющая ЭВМ, она может использоваться дополнительно и как узел этого сабчейна. В такой структуре все действия внутри сабчейна не влияют на работу предприятия в целом. А само предприятие может горизонтально масштабировать систему управления, просто добавляя новые цеха такого же типа.

Claims (13)

  1. Способ масштабирования распределенной информационной системы, отличающийся тем, что содержит:
  2. этап, на котором определяют получателя, отправителя и ценность транзакции;
  3. этап, на котором подписывают транзакции;
  4. этап, на котором подписанные транзакции направляют узлу сабчейна, причем на узле сабчейна транзакции разделяют на две секции, к первой из которых относят те подписанные транзакции, в которых получатель зарегистрирован в том же сабчейне, что и отправитель, а ко второй относят те подписанные транзакции, в которых получатель зарегистрирован в другом сабчейне, не в том сабчейне, в котором зарегистрирован отправитель;
  5. этап, на котором на узле сабчейна создают новый блок данных, содержащий информацию о подписанных транзакциях, разделенных на секции на предыдущем этапе;
  6. этап, на котором из секции транзакций, в которых получатель зарегистрирован в другом сабчейне, не в том сабчейне, в котором зарегистрирован отправитель, на узле сабчейна формируют исходящие пакеты транзакций, причем каждый пакет транзакций содержит информацию о номере пакета транзакций, адрес сабчейна-получателя, заголовок нового блока данных, а также непосредственно подписанные транзакции;
  7. этап, на котором с узла сабчейна отправителя направляют все сформированные пакеты транзакций по меньшей мере одному из узлов сабчейна получателя;
  8. этап, на котором на узле сабчейна получателя получают направленные с узла сабчейна отправителя все сформированные пакеты транзакций и проверяют номер каждого пакета транзакций путем соотнесения номера полученного пакета с транзакциями с номером предыдущего полученного и зарегистрированного узлом сабчейна получателя пакета транзакций из сабчейна отправителя, и в том случае, если номер полученного в настоящее время пакета с транзакциями на 2 и более больше, чем номер предыдущего полученного и зарегистрированного в узле сабчейне получателя пакета транзакций, то узел сабчейна получателя направляет этот полученный в настоящее время пакет с транзакциями в очередь ожидания пропущенных пакетов транзакций, которые, в свою очередь, по мере поступления пропущенных пакетов транзакций переходят к следующему этапу, а в том случае, если номер полученного в настоящее время пакета с транзакциями не удовлетворяет условию “на 2 и более больше, чем номер предыдущего полученного и зарегистрированного в узле сабчейне получателя пакета транзакций”, то такой пакет с транзакциями не передается в очередь ожидания пропущенных пакетов транзакций;
  9. этап, на котором пакет с транзакциями со следующим после ранее полученного и зарегистрированного на узле сабчейна получателя номера пакета валидируется узлами сабчейна-получателя путем валидации всех содержащихся в пакете с транзакциями транзакций;
  10. этап, на котором валидированный пакет с транзакциями включается в новый блок сабчейна получателя, а балансы пользователей-получателей транзакций из пакета транзакций изменяются в соответствии с этими транзакциями;
  11. этап, на котором с узла сабчейна получателя направляют в узел сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя;
  12. этап, на котором на узле сабчейна отправителя ожидают информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, и в том случае, если за установленное время не получают на узле сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, заново направляют с узла сабчейна отправителя все сформированные пакеты транзакций по меньшей мере одному из узлов сабчейна получателя до тех пор, пока на узле сабчейна отправителя не получат информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя;
  13. этап, на котором на узле сабчейна отправителя получают информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя, валидируют на узле сабчейна отправителя информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя и вносят информацию о внесении полученного пакета транзакций в новый блок данных сабчейна получателя в новый блок сабчейна отправителя.
RU2018113535A 2018-04-14 2018-04-14 Способ масштабирования распределенной информационной системы RU2686818C1 (ru)

Priority Applications (2)

Application Number Priority Date Filing Date Title
RU2018113535A RU2686818C1 (ru) 2018-04-14 2018-04-14 Способ масштабирования распределенной информационной системы
PCT/RU2019/000213 WO2019199205A1 (ru) 2018-04-14 2019-04-05 Способ масштабирования распределенной информационной системы

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
RU2018113535A RU2686818C1 (ru) 2018-04-14 2018-04-14 Способ масштабирования распределенной информационной системы

Publications (1)

Publication Number Publication Date
RU2686818C1 true RU2686818C1 (ru) 2019-04-30

Family

ID=66430607

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2018113535A RU2686818C1 (ru) 2018-04-14 2018-04-14 Способ масштабирования распределенной информационной системы

Country Status (2)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111125131A (zh) * 2019-12-16 2020-05-08 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法
RU2790181C1 (ru) * 2019-08-01 2023-02-15 Блум Текнолоджи, Инк. Система верифицируемого отсечения реестров

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150271183A1 (en) * 2014-03-18 2015-09-24 nTrust Technology Solutions Corp. Virtual currency system
US20170091397A1 (en) * 2012-01-26 2017-03-30 Netspective Communications Llc Device-driven non-intermediated blockchain system over a social integrity network
US20170264428A1 (en) * 2016-03-08 2017-09-14 Manifold Technology, Inc. Data storage system with blockchain technology
WO2017194976A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets
RU2649788C1 (ru) * 2016-06-16 2018-04-04 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки запроса на транзакцию в распределенных системах обработки данных

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9858401B2 (en) * 2011-08-09 2018-01-02 Biogy, Inc. Securing transactions against cyberattacks
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US11941588B2 (en) * 2015-11-06 2024-03-26 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
US10417217B2 (en) * 2016-08-05 2019-09-17 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US10621233B2 (en) * 2016-11-09 2020-04-14 Cognitive Scale, Inc. Cognitive session graphs including blockchains

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170091397A1 (en) * 2012-01-26 2017-03-30 Netspective Communications Llc Device-driven non-intermediated blockchain system over a social integrity network
US20150271183A1 (en) * 2014-03-18 2015-09-24 nTrust Technology Solutions Corp. Virtual currency system
US20170264428A1 (en) * 2016-03-08 2017-09-14 Manifold Technology, Inc. Data storage system with blockchain technology
WO2017194976A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets
RU2649788C1 (ru) * 2016-06-16 2018-04-04 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки запроса на транзакцию в распределенных системах обработки данных

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2796046C1 (ru) * 2019-06-05 2023-05-16 Мастеркард Интернэшнл Инкорпорейтед Управление учетными данными в распределенной вычислительной системе
RU2790181C1 (ru) * 2019-08-01 2023-02-15 Блум Текнолоджи, Инк. Система верифицируемого отсечения реестров
CN111125131A (zh) * 2019-12-16 2020-05-08 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法
CN111125131B (zh) * 2019-12-16 2023-06-06 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法

Also Published As

Publication number Publication date
WO2019199205A1 (ru) 2019-10-17

Similar Documents

Publication Publication Date Title
JP7292365B2 (ja) ブロックチェーンからのデータのセキュアな抽出のための暗号方法及びシステム
US11917051B2 (en) Systems and methods for storage, generation and verification of tokens used to control access to a resource
Fernández-Caramés et al. A Review on the Use of Blockchain for the Internet of Things
WO2021179661A1 (zh) 跨区块链的数据互存方法、装置、设备及存储介质
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
US20230153769A1 (en) Method and system of mining blockchain transactions provided by a validator node
CN106899698B (zh) 一种区块链之间的跨链互操作方法
EP4209980A1 (en) Computer-implemented system and method for managing a large distributed memory pool in a blockchain network
Robinson et al. Atomic crosschain transactions for ethereum private sidechains
US20230028606A1 (en) Method and apparatus for vertical federated learning
CN108200208B (zh) 基于云计算的物流区块链共识算法
CN111327426B (zh) 数据共享方法及相关装置、设备及系统
CN110766551B (zh) 一种基于改进Kafka共识机制的联盟链及交易方法
EP3869376B1 (en) System and method for blockchain based decentralized storage with dynamic data operations
US20200202349A1 (en) Multiple asset transactions
Obushnyi et al. Blockchain as a transaction protocol for guaranteed transfer of values in cluster economic systems with digital twins
Kabulov et al. Systematic analysis of blockchain data storage and sharing technology
US20200202344A1 (en) Private asset transactions
RU2686818C1 (ru) Способ масштабирования распределенной информационной системы
EP4035305A1 (en) Partitioning a request into transactions for a blockchain
Das et al. Data privacy in IoT network using blockchain technology
Sharma et al. Blockchain Revolution: Adaptability in Business World and Challenges in Implementation
Sisodiya et al. A comprehensive study of Blockchain and its various Applications
Singh et al. IoT–Blockchain Integration-Based Applications Challenges and Opportunities
CN113839768A (zh) 一种基于卫星链中继的跨链通信方法