09.06.2020
220.018.256b

ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
№ охранного документа
0002723072
Дата охранного документа
08.06.2020
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение относится к области технологий передачи данных в распределенных системах. Техническим результатом является расширение арсенала средств для увеличения эффективности достижения консенсуса между множеством сетевых узлов в цепочке блоков. Технический результат предложенного технического решения достигается за счет того, что выполняются этапы, на которых выполняют прием запроса транзакции первичным узлом, отправку первичным узлом некоторого количества первых сообщений резервным узлам, прием первичным узлом вторых сообщений от резервных узлов, восстановление запроса транзакции на основе данных во вторых сообщениях посредством первичного узла, отправку третьего сообщения резервным узлам посредством первичного узла и выполнение запроса транзакции в ответ на прием предопределенного количества третьих сообщений. 6 н. и 51 з.п. ф-лы, 17 ил.
Реферат Свернуть Развернуть

Уровень техники

[0001] Системы распределенного реестра (DLS), которые также могут называться консенсусными сетями и/или сетями цепочки блоков (блокчейн–сетями), позволяют участвующим объектам безопасно и неизменно хранить данные. DLS обычно называют сетями цепочек блоков без ссылки на какой–либо случай конкретного пользователя. Примеры сетей цепочек блоков могут включать в себя: общедоступные сети цепочек блоков, частные сети цепочек блоков и консорциумные сети цепочек блоков. Публичная сеть цепочек блоков открыта для всех объектов, чтобы использовать DLS и участвовать в процессе консенсуса. Для конкретного объекта предусмотрена частная сеть цепочек блоков, которая централизованно управляет разрешениями на считывание и запись. Консорциумная сеть цепочек блоков предоставляется для выбранной группы объектов, которые управляют процессом консенсуса, и включает в себя уровень управления доступом.

[0002] Механизмы консенсуса являются основным компонентом распределенных систем цепочек блоков. Механизм консенсуса – это процесс в вычислительной науке, который используется для достижения соглашения в отношении одного значения данных среди распределенных процессов или систем. Механизмы консенсуса предназначены для достижения надежности в сети, включающей в себя множественные ненадежные узлы. Решение этой проблемы, известной как проблема консенсуса, важно в распределенных вычислительных системах и системах с множественными агентами.

[0003] Цепочка блоков (блокчейн) полагается на механизмы консенсуса для достижения соглашения между узлами. Цепочка блоков – это децентрализованная база данных, которая администрируется распределенными компьютерами в одноранговой (P2P) сети. Каждый одноранговый узел поддерживает копию регистра, чтобы предотвратить одну точку отказа (SPOF). Обновления и проверки отражаются во всех копиях одновременно.

[0004] Хотя ряд существующих методов может использоваться для достижения консенсуса среди сетевых узлов системы цепочек блоков, было бы предпочтительным более эффективное решение для достижения консенсуса.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0005] Реализации настоящего описания включают в себя компьютерно–реализуемые способы для решения проблем консенсуса в распределенной системе (например, сети цепочек блоков). Более конкретно, реализации настоящего описания направлены на достижение консенсуса среди сетевых узлов в распределенной системе.

[0006] В некоторых реализациях действия включают в себя: прием запроса транзакции первичным узлом сети цепочек блоков; генерирование некоторого количества блоков кода стирания (EC) в соответствии с кодом EC первичным узлом с использованием запроса транзакции; отправку некоторого количества первых сообщений одному или нескольким резервным узлам сети цепочек блоков посредством первичного узла, причем каждое из количества первых сообщений включает в себя составное значение хэш–функции, связанное с количеством блоков EC; прием по меньшей мере одного второго сообщения первичным узлом от по меньшей мере одного из резервных узлов, при этом упомянутое по меньшей мере одно второе сообщение включает в себя одно из количества первых сообщений и подпись по меньшей мере одного из резервных узлов, ассоциированных с этим одним из количества первых сообщений; проверку первичным узлом, является ли по меньшей мере одно второе сообщение действительным, в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла; определение первичным узлом, превышает ли количество действительных вторых сообщений предопределенный порог; восстановление запроса транзакции первичным узлом на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; отправку третьего сообщения другим узлам сети первичным узлом в ответ на определение, что запрос транзакции был успешно восстановлен, при этом третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; прием по меньшей мере одного третьего сообщения первичным узлом от по меньшей мере одного из резервных узлов; и исполнение запроса транзакции первичным узлом в ответ на прием предварительно определенного количества третьих сообщений, которые являются идентичными.

[0007] Другие реализации включают в себя соответствующие системы, аппаратуру и компьютерные программы, сконфигурированные для выполнения действий способов, закодированных на компьютерных запоминающих устройствах.

[0008] Эти и другие реализации могут каждая необязательно включать в себя одну или несколько из следующих особенностей:

[0009] Первая особенность, комбинируемая с любой из следующих особенностей, в которой запрос транзакции связан с порядковым номером.

[0010] Вторая особенность, комбинируемая с любой из следующих особенностей, в которой первичный узел преобразует запрос транзакции в сообщение EC с использованием кода EC и делит сообщение EC на количество блоков EC.

[0011] Третья особенность, комбинируемая с любой из следующих особенностей, в которой составное хэш–значение номера блока EC генерируется с использованием хэш–дерева.

[0012] Четвертая особенность, комбинируемая с любой из следующих особенностей, в которой хэш–дерево включает в себя дерево Меркла.

[0013] Пятая особенность, комбинируемая с любой из следующих особенностей, в которой составное хэш–значение является корневым хэш–значением дерева Меркла.

[0014] Шестая особенность, комбинируемая с любой из следующих особенностей, в которой подпись по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений, включает в себя подпись закрытого ключа по меньшей мере одного из резервных узлов, ассоциированных с один из количества первых сообщений.

[0015] Седьмая особенность, комбинируемая с любой из следующих особенностей, в которой по меньшей мере одно второе сообщение дополнительно включает в себя по меньшей мере один из количества блоков EC.

[0016] Восьмая особенность, комбинируемая с любой из следующих особенностей, в которой первичный узел дополнительно генерирует восстановленное хэш–дерево, используя по меньшей мере один из количества блоков EC в по меньшей мере одном втором сообщении, определяет восстановленное составное хэш–значение восстановленного хэш–дерева, сравнивает восстановленное составное хэш–значение с составным хэш–значением в по меньшей мере одном втором сообщении и определяет, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями в, по меньшей мере, одном втором сообщении.

[0017] Девятая особенность, комбинируемая с любой из следующих особенностей, в которой первичный узел дополнительно определяет, что по меньшей мере одно второе сообщение является действительным, в ответ на определение, что восстановленное составное хэш–значение совпадает с составными хэш–значениями во вторых сообщениях.

[0018] Десятая особенность, комбинируемая с любой из следующих особенностей, в которой предопределенное количество третьих сообщений, которые являются идентичными, включает в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[0019] В некоторых реализациях действия включают в себя: прием, резервным узлом, первого сообщения от первичного узла, причем первое сообщение содержит составное хэш–значение, ассоциированное с множеством блоков EC, при этом множество блоков EC генерируются первичным узлом в соответствии с кодом EC с использованием запроса транзакции; в ответ на прием первого сообщения, отправку, резервным узлом, второго сообщения другим узлам сети, причем второе сообщение содержит первое сообщение и подпись резервного узла, ассоциированного с первым сообщением; прием, резервным узлом, по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла, отличного от упомянутого резервного узла; в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла, проверку, резервным узлом, является упомянутое по меньшей мере одно второе сообщение действительным; определение, резервным узлом, превышает ли количество действительных вторых сообщений предопределенный порог; в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог, восстановление, резервным узлом, запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC; в ответ на определение, что запрос транзакции был успешно восстановлен, отправку, резервным узлом, третьего сообщения другим сетевым узлам, причем третье сообщение содержит набор подписей, которые содержатся в действительных вторых сообщениях; прием, резервным узлом, по меньшей мере одного третьего сообщения от по меньшей мере одного из резервных узлов; и в ответ на прием предопределенного количества третьих сообщений, которые явялются идентичными, исполнение, резервным узлом, запроса транзакции.

[0020] Другие реализации включают в себя соответствующие системы, аппараты и компьютерные программы, выполненные с возможностью выполнения действий способов, закодированных на компьютерных устройствах хранения.

[0021] Эти и другие реализации могут каждая необязательно включать в себя одну или несколько из следующих особенностей:

[0022] Первая особенность, совместимая с любой из следующих особенностей, в которой генерирование множества блоков ЕС в соответствии с кодом ЕС включает в себя преобразование запроса транзакции в сообщение ЕС с использованием кода ЕС, разделяющего сообщение ЕС на множество блоков ЕС.

[0023] Вторая особенность, совместимая с любой из следующих особенностей, в которой составное хэш–значение множества блоков EC генерируется с помощью хэш–дерева.

[0024] Третья особенность, совместимая с любой из следующих особенностей, в которой хэш–дерево содержит дерево Меркла, и в которой составное хэш–значение является корневым хэш–значением дерева Меркла.

[0025] Четвертая особенность, совместимая с любой из следующих особенностей, в которой подпись резервного узла, ассоциированного с первым сообщением, включает в себя подпись закрытого ключа резервного узла, ассоциированного с первым сообщением.

[0026] Пятая особенность, совместимая с любой из следующих особенностей, в которой по меньшей мере одно второе сообщение дополнительно включает в себя по меньшей мере один из множества блоков ЕС.

[0027] Седьмая особенность, совместимая с любой из следующих особенностей, в которой проверка, посредством резервного узла, является ли по меньшей мере одно второе сообщение действительным, включает в себя генерирование, посредством резервного узла, восстановленного хэш–дерева, используя по меньшей мере один из множества блоков EC в по меньшей мере одном втором сообщении, определение, посредством резервного узла, восстановленного составного хэш–значения восстановленного хэш–дерева, сравнение, посредством резервного узла, восстановленного составного хэш–значения с составным хэш–значением в по меньшей мере одном втором сообщении, и определение, посредством резервного узла,, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями в упомянутом по меньшей мере одном втором сообщении.

[0028] Восьмая особенность, совместимая с любой из следующих особенностей, дополнительно включает в себя в ответ на определение, что восстановленное составное хэш–значение совпадает с составными хэш–значениями во вторых сообщениях, определение, резервным узлом, что по меньшей мере одно второе сообщение является действительным.

[0029] Девятая особенность, совместимая с любой из следующих особенностей, в которой предопределенное количество третьих сообщений, которые идентичны, включают в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[0030] Настоящее описание также предоставляет один или несколько невременных машиносчитываемых носителей хранения, подсоединенных к одному или нескольким процессорам и имеющих инструкции, хранящимися на них, которые, при исполнении одним или несколькими процессорами, вынуждают один или несколько процессоров выполнять операции в соответствии с реализациями предусмотренных в данном документе способов.

[0031] В настоящем описании дополнительно обеспечена система реализации способов, предусмотренных в настоящем документе. Система включает в себя один или несколько процессоров, и машиносчитываемый носитель хранения, подсоединенный к одному или нескольким процессорам, имеющий инструкции, хранящиеся на нем, которые при выполнении одним или несколькими процессорами вынуждают один или несколько процессоров выполнять операции в соответствии с реализациями способов, предусмотренных в данном документе.

[0032] В настоящем описании раскрыт усовершенствованный механизм консенсуса, включающий в себя методы достижения консенсуса между сетевыми узлами в распределенной системе, выполнения изменения первичного узла в распределенной системе и выполнения процесса восстановления для сетевого узла в распределенной системе. Описанные механизмы консенсуса могут достигать различных преимуществ в различных областях применения.

[0033] Например, процесс консенсуса, о котором говорится ниже, включает в себя множество особенностей, которые улучшают работу системы цепочек блоков и помогают устранять узкое место в сети. Например, описанный процесс консенсуса включает в себя преобразование запроса транзакции в некоторое количество блоков кода стирания (EC) в соответствии с кодом ЕС и отправку одного из блоков ЕС каждому из сетевых узлов. Блок EC меньше по размеру, чем исходный запрос транзакции. Соответственно, отправка блока ЕС вместо полного запроса транзакций в сетевые узлы уменьшает размер блоков данных, которые передаются между сетевыми узлами сети цепочек блоков, тем самым сохраняя пропускную способность сети и уменьшая нагрузку сети. Это дополнительно уменьшает размер данных, которые записываются и считываются из пространства памяти сетевых узлов, тем самым снижая нагрузку на пространство памяти сетевых узлов и повышая эффективность всей системы цепочек блоков.

[0034] Кроме того, в настоящем описании описывается процесс изменения эпохи, который включает в себя назначение соответствующих весовых коэффициентов множественным фазам процесса консенсуса, определение суммы весов на основе соответствующих весовых коэффициентов множественных фаз и определение нового первичного узла на основе суммы весов. Процесс изменения эпохи, основанный на сумме весов, а не на методе циклического перебора, может способствовать своевременному выбору нового первичного узла, который не является неисправным. В отличие от метода циклического перебора, процесс изменения эпохи в настоящем описании основывается на сумме весов для выбора нового первичного узла, что может уменьшить задержку или приостановку при поиске нового первичного узла, который не является неисправным. Это может дополнительно повысить эффективность всей системы цепочек блоков в предоставлении услуг цепочек блоков.

[0035] Кроме того, в настоящем описании обсуждается процесс восстановления, который включает в себя такие операции, как отправка сообщения запроса состояния сетевым узлом, который применяется как новый первичный узел, и получение ответных сообщений о состоянии от других сетевых узлов. Эти операции выполняются таким образом, что процесс восстановления неисправного сетевого узла не мешает нормальной работе процесса консенсуса среди других не неисправных сетевых узлов. Это облегчает сохранение вычислительных и сетевых ресурсов для восстановления неисправного сетевого узла за счет снижения сложности процесса восстановления.

[0036] Признано, что способы в соответствии с настоящим описанием могут включать в себя любую комбинацию аспектов и особенностей, описанных в данном документе. То есть способы в соответствии с настоящим описанием не ограничиваются комбинациями аспектов и особенностей (признаков), конкретно описанных здесь, но также включают в себя любую комбинацию предоставленных аспектов и особенностей.

[0037] Детали одной или нескольких реализаций настоящего описания изложены на прилагаемых чертежах и в описании ниже. Другие признаки и преимущества настоящего описания будут очевидны из описания и чертежей, а также из формулы изобретения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0038] Фиг. 1 изображает пример среды, которая может использоваться для выполнения реализаций настоящего описания.

[0039] Фиг.2 изображает пример концептуальной архитектуры в соответствии с реализациями настоящего описания.

[0040] Фиг. 3 изображает пример процесса консенсуса, который может выполняться в соответствии с реализациями настоящего описания.

[0041] Фиг.4 изображает пример процесса консенсуса, который может быть выполнен в соответствии с реализациями настоящего описания.

[0042] Фиг. 5 изображает пример хэш–дерева в соответствии с реализациями настоящего описания.

[0043] Фиг.6 изображает пример сообщений, которые передаются между узлами сети распределенной системы в соответствии с реализациями настоящего описания.

[0044] Фиг.7 изображает пример процесса выполнения изменения первичного узла в распределенной системе в соответствии с реализациями настоящего описания.

[0045] Фиг.8 изображает пример процесса выполнения изменения первичного узла в распределенной системе в соответствии с реализациями настоящего описания.

[0046] Фиг.9 изображает пример сообщений, которые передаются между сетевыми узлами распределенной системы в соответствии с реализациями настоящего описания.

[0047] Фиг. 10 изображает пример процесса выполнения процесса восстановления сетевого узла в распределенной системе в соответствии с реализациями настоящего описания.

[0048] Фиг. 11 изображает пример процесса выполнения процесса восстановления сетевого узла в распределенной системе в соответствии с реализациями настоящего описания.

[0049] Фиг. 12 изображает пример сообщений, которые передаются между сетевыми узлами распределенной системы в соответствии с реализациями настоящего описания.

[0050] Фиг. 13 изображает пример схемы, иллюстрирующей модули аппаратуры консенсуса в соответствии с реализацией настоящего описания.

[0051] Фиг. 14 изображает пример схемы, иллюстрирующей модули аппаратуры консенсуса в соответствии с реализацией настоящего описания.

[0052] Фиг. 15 изображает пример схемы, иллюстрирующей модули аппаратуры изменения первичного узла в соответствии с реализацией настоящего описания.

[0053] Фиг. 16 изображает пример схемы, иллюстрирующей модули аппаратуры изменения первичного узла, согласно реализации настоящего описания.

[0054] Фиг. 17 изображает пример схемы, иллюстрирующей модули аппаратуры восстановления в соответствии с реализацией настоящего описания.

[0055] Одинаковые условные обозначения на разных чертежах обозначают одинаковые элементы.

ПОДРОБНОЕ ОПИСАНИЕ

[0056] Реализации настоящего описания включают в себя машинореализуемые способы для решения проблем консенсуса в распределенной системе (например, сети цепочек блоков). Более конкретно, реализации настоящего описания направлены на достижение консенсуса среди сетевых узлов в распределенной системе.

[0057] В некоторых реализациях действия включают в себя: прием запроса транзакции первичным узлом сети цепочек блоков; генерирование некоторого количества блоков кода стирания (EC) в соответствии с кодом EC первичным узлом с использованием запроса транзакции; отправку некоторого количества первых сообщений одному или нескольким резервным узлам сети цепочек блоков посредством первичного узла, причем каждое из количества первых сообщений включает в себя составное хэш–значение, ассоциированное с количеством блоков EC; прием по меньшей мере одного второго сообщения первичным узлом от по меньшей мере одного из резервных узлов, при этом упомянутое по меньшей мере одно второе сообщение включает в себя одно из количества первых сообщений и подпись по меньшей мере одного из резервных узлов, ассоциированных с упомянутым одним из количества первых сообщений; проверку первичным узлом, является ли упомянутое по меньшей мере одно второе сообщение действительным в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла; определение первичным узлом, превышает ли количество действительных вторых сообщений предопределенный порог; восстановление запроса транзакции первичным узлом на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; отправку третьего сообщения другим сетевым узлам первичным узлом в ответ на определение, что запрос транзакции был успешно восстановлен, при этом третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; прием по меньшей мере одного третьего сообщения первичным узлом от по меньшей мере одного из резервных узлов; и выполнение запроса транзакции первичным узлом в ответ на прием предопределенного количества третьих сообщений, которые идентичны.

[0058] В некоторых реализациях действия включают в себя: прием, резервным узлом, первого сообщения от первичного узла, причем первое сообщение содержит составное хэш–значение, ассоциированное с множеством блоков EC, при этом множество блоков EC генерируется первичным узлом в соответствии с кодом EC с использованием запроса транзакции; в ответ на прием первого сообщения, отправку резервным узлом, второго сообщения другим сетевым узлам, причем второе сообщение содержит первое сообщение и подпись резервного узла, ассоциированного с первым сообщением; прием, резервным узлом, по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла, отличного от упомянутого резервного узла; в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла, проверку, резервным узлом, является ли по меньшей мере одно второе сообщение действительным; определение, резервным узлом, превышает ли количество действительных вторых сообщений предопределенный порог; в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог, восстановление, резервным узлом, запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC; в ответ на определение, что запрос транзакции был успешно восстановлен, отправку, резервным узлом, третьего сообщения другим сетевым узлам, причем третье сообщение содержит набор подписей, которые содержатся в действительных вторых сообщениях; прием, резервным узлом, по меньшей мере одного третьего сообщения от по меньшей мере одного из резервных узлов; и в ответ на прием предопределенного количества третьих сообщений, которые являются идентичными, выполнение, резервным узлом, запроса транзакции.

[0059] Для обеспечения дополнительного контекста для реализаций настоящего описания и как представлено выше, системы распределенного реестра (DLSs), которые также могут быть названы консенсусными сетями (например, состоящими из одноранговых узлов) или сетями цепочек блоков, позволяют участвующим объектам надежно и непреложно проводить транзакции и хранить данные. Термин цепочка блоков (блокчейн) используется в настоящем случае, чтобы в общем относиться к DLS без ссылки на какой–либо конкретный случай использования. Как было представлено выше, сеть цепочек блоков может быть предоставлена как публичная сеть цепочек блоков, частная сеть цепочек блоков или сеть консорциумная сеть цепочек блоков.

[0060] Цепочка блоков – это структура данных, которая хранит транзакции таким образом, чтобы можно было проверять будущие транзакции на соответствие всем предыдущим транзакциям, хранящимся в цепочке. Цепочка блоков включает в себя один или несколько блоков. Каждый блок в цепочке связан с предыдущим блоком непосредственно перед ним в цепочке, посредством включения криптографического хэша предыдущего блока. Каждый блок также включает в себя метку времени, свой собственный криптографический хэш и одну или несколько транзакций. Транзакции, которые уже были проверены узлами сети цепочек блоков, хэшируются и кодируются в дерево Меркла. Дерево Меркла – это структура данных, в которой хэшируются данные на листовых узлах дерева, и все хэш–значения в каждой ветви дерева конкатенируются в корне ветви. Этот процесс продолжается вверх по дереву до корня всего дерева, в котором хранится хэш–значение, которое является репрезентативным для всех данных в дереве. Хэш–значение, предназначенное для транзакции, хранящейся в дереве, может быть быстро проверено посредством определения, соответствует ли оно структуре дерева.

[0061] В то время как цепочка блоков является структурой данных для хранения транзакций, сеть цепочек данных представляет собой сеть вычислительных узлов, которые управляют, обновляют и поддерживают одну или несколько структур цепочек блоков. Как было представлено выше, сеть цепочек блоков может быть предоставлена как публичная сеть цепочек блоков, частная сеть цепочек блоков или консорциумная сеть цепочек блоков.

[0062] В публичной сети цепочек блоков процесс консенсуса управляется узлами сети консенсуса. Например, сотни, тысячи, даже миллионы объектов могут взаимодействовать в публичной сети цепочек блоков, каждый из которых управляет по меньшей мере одним узлом в публичной сети цепочек блоков. Соответственно, публичная сеть цепочек блоков может считаться публичной сетью по отношению к участвующим объектам. В некоторых примерах большинство объектов (узлов) должны подписать каждый блок для того, чтобы блок был действительным и добавлен в цепочку блоков (распределенный реестр) сети цепочек блоков. Пример публичных сетей цепочек блоков включает в себя конкретные одноранговые платежные сети, которые используют распределенный реестр, именуемый цепочкой блоков. Как отмечалось выше, термин цепочка блоков, однако, используется для общего обозначения распределенных реестров без конкретной ссылки на какую–либо конкретную сеть цепочек блоков.

[0063] В общем, публичная сеть цепочек блоков поддерживает публичные транзакции. Публичная транзакция совместно используется всеми из узлов в публичной сети цепочек блоков и хранится в глобальной цепочке блоков. Глобальная цепочка блоков– это цепочка блоков, которая реплицируется во всех узлах. То есть все узлы находятся в идеальном состоянии консенсуса по отношению к глобальной цепочке блоков. Для достижения консенсуса (например, согласия на добавление блока в цепочку блоков) в публичной сети цепочек блоков реализуется консенсусный протокол. Примеры консенсусных протоколов включают в себя, без ограничений, доказательство работы (POW), доказательство владения (POS), и доказательство полномочий (POA). Доказательство работы упоминается в настоящем документе как не ограничивающий пример.

[0064] В общем, частная сеть цепочек блоков обеспечивается для конкретного объекта, который централизованно управляет разрешениями на считывание и запись. Объект управляет тем, какие узлы могут участвовать в сети цепочек блоков, таким образом частные сети цепочек блоков обычно называются разрешенными сетями, которые накладывают ограничения на то, кому разрешено участвовать в сети, и на их уровень участия (например, только в некоторых транзакциях). Могут использоваться различные типы механизмов управления доступом (например, существующие участники голосуют за добавление новых объектов, регулирующий орган может контролировать допуск).

[0065] В общем, консорциумная сеть цепочек блоков является частной среди участвующих объектов. В консорциумной сети цепочек блоков процесс консенсуса управляется авторизованным набором узлов, одним или несколькими узлами, оперируемыми соответствующим объектом (например, финансовым учреждением, страховой компанией). Например, консорциум из десяти (10) объектов (например, финансовых учреждений, страховых компаний) может оперировать консорциумной сетью цепочек блоков, каждый из которых оперирует по меньшей мере одним узлом в консорциумной сети цепочек блоков. Соответственно, консорциумная сеть цепочек блоков может рассматриваться как частная сеть по отношению к участвующим объектам. В некоторых примерах каждый объект (узел) должен подписывать каждый блок, чтобы блок был действительным и был добавлен в цепочку блоков. В некоторых примерах, по меньшей мере, поднабор объектов (узлов) (например, по меньшей мере 7 объектов) должен подписать каждый блок, чтобы блок был действительным и был добавлен в цепочку блоков.

[0066] Реализации настоящего описания описаны более подробно в данном документе со ссылкой на консорциумную сеть цепочек блоков. Однако предполагается, что реализации настоящего описания могут быть реализованы в любом подходящем типе сети цепочек блоков.

[0067] Реализации настоящего описания описаны здесь более подробно с учетом вышеприведенного контекста. Более конкретно, и, как было показано выше, реализации настоящего описания направлены на выполнение процесса восстановления для сетевого узла в распределенной системе.

[0068] Цепочка блоков – это защищенный от несанкционированного доступа совместно используемый цифровой реестр, который записывает транзакции в публичной или частной одноранговой сети. Реестр распределяется по всем узлам–участникам в сети, а история транзакций активов, происходящих в сети, постоянно записывается в блок.

[0069] Механизмы консенсуса гарантируют, что все сетевые узлы в распределенной сети цепочек блоков выполняют транзакции в одном и том же порядке, а затем записывают в одни и те же реестры. Одной из задач, которую решают консенсусные модели, является преодоление византийских отказов необъяснимых ошибок. При византийском отказе компонент, такой как сервер или сетевой узел распределенной сети цепочек блоков, может противоречиво показывать и отказ и функционирование системе обнаружения отказов, представляя разные симптомы (признаки) разным наблюдателям. Другим сетевым узлам сложно объявить об его отказе и отключить его от сети, поскольку им необходимо сначала прийти к консенсусу относительно того, какой сетевой узел отказал в первую очередь.

[0070] В контексте распределенных систем византийская отказоустойчивость (BFT) – это способность распределенной вычислительной сети функционировать по своему усмотрению и правильно достигать достаточного консенсуса, несмотря на то, что вредоносные компоненты (то есть сетевые узлы сети цепочек блоков) системы отказывают или распространяют неверную информацию другим одноранговым узлам. Задача состоит в том, чтобы защититься от катастрофических отказов системы, уменьшив влияние, которое эти злонамеренные узлы оказывают на правильное функционирование сети и обеспечить правильный консенсус, достигнутый честными узлами в системе.

[0071] Однако существующие механизмы BFT оказались неэффективными во многих аспектах. Например, существующие механизмы BFT добавили сложность реализации в распределенную сеть цепочек блоков при попытке преодолеть византийские отказы, так что задержка увеличивается для связи между сетевыми узлами распределенной сети цепочек блоков. Практическая Византийская Отказоустойчивость (PBFT) является одной из оптимизаций, которая направлена на улучшение существующих механизмов консенсуса BFT. Модель PBFT фокусируется на предоставлении практической репликации византийского конечного автомата, который допускает византийские сбои (злонамеренные узлы), исходя из предположения о наличии отказов независимых узлов и манипулируемых сообщениях, которые распространяются конкретными, независимыми узлами.

[0072] В модели PBFT все узлы упорядочены в последовательности, причем один узел является первичным узлом (лидером), а другие называются резервными узлами. Все из узлов в системе обмениваются сообщениями друг с другом, и цель состоит в том, чтобы большинство честных узлов пришли к соглашению о состоянии системы. Узлы обмениваются данными друг с другом, и им нужно не только доказать, что сообщения поступили от конкретного однорангового узла, но и проверить, что сообщение не было изменено во время передачи.

[0073] Чтобы модель PBFT работала, предполагается, что количество вредоносных узлов в сети не может одновременно равняться или превышать 1/3 от общего количества узлов в системе в данном окне уязвимости. Чем больше узлов в системе, тем более математически маловероятно, чтобы количество узлов, приближающееся к 1/3 от общего количества узлов, были вредоносными. Алгоритм эффективно обеспечивает как жизнеспособность, так и безопасность, поскольку не более (n–1)/3 узлов являются вредоносными или неисправными одновременно, где n представляет общее количество узлов.

[0074] Каждый раунд консенсуса PBFT (так называемые просмотры) включает в себя 4 фазы:

(1) Клиент отправляет запрос в узел–лидер для вызова операции службы;

(2) Узел–лидер многоадресно передает запрос резервным узлам;

(3) Узлы выполняют запрос и затем отправляют ответ клиенту; и

(4) Клиент ожидает f+1 (f представляет максимальное количество узлов, которые могут быть неисправны) ответов от разных узлов с одинаковым результатом.

Окончательный результат заключается в том, что все честные узлы приходят к согласию о порядке записи и принимают или отклоняют ее. Узел–лидер изменяется в схеме циклического перебора во время каждого просмотра и может даже быть заменен протоколом, вызванным изменением просмотра, если конкретное количество времени прошло без многоадресной передачи запроса узлом–лидером. Большинство из честных узлов также могут решить, является ли лидер отказавшим, и заменить его следующим лидером в очереди.

[0075] Однако существуют некоторые ограничения для механизма консенсуса PBFT. Например, модель PBFT может хорошо работать в своей классической форме с относительно небольшими размерами консенсусных групп из–за громоздкого объема обмена данными, который требуется между узлами. Объемные данные блока, которые передаются между сетевыми узлами, вызывают проблему загрузки сети и приводят к узким местам («эффекту бутылочного горлышка») в сети. Кроме того, использование способа кодов аутентификации (MAC) в качестве формата для сообщений аутентификации в модели PBFT может быть неэффективным из–за объема обмена данными, необходимого между узлами в больших консенсусных группах, таких как сети криптовалюты, и с MAC. Может иметь место присущая неспособность доказать подлинность сообщений третьей стороне.

[0076] Более того, обнаружение последовательных вредоносных узлов при смене узла–лидера с использованием способа циклического перебора, используемого PBFT, влияет на службу цепочки блоков, вводя задержку или приостановку в поиске честного узла–лидера. Например, при выборе первого узла сети в качестве нового узла–лидера, первый узел сети может быть вредоносным узлом, следовательно, не может быть выбран в качестве нового узла–лидера. В способе циклического перебора второй сетевой узел в линии может быть выбран в качестве нового узла–лидера. Однако, если второй сетевой узел также является вредоносным узлом, другой сетевой узел в линии будет проверен на предмет пригодности быть узлом–лидером. Этот процесс продолжается до тех пор, пока не будет идентифицирован новый честный узел–лидер. Такое частое изменение узла–лидера вносит значительную задержку в сервисы цепочек блоков.

[0077] Кроме того, сетевые узлы в сети цепочек блоков могут в любой момент испытать византийский отказ или поломку. Например, сетевой узел может быть скомпрометирован кибер злоумышленником и вести себя ненадлежащим образом. Если скомпрометированные сетевые узлы не восстанавливаются быстро, злонамеренный кибер–злоумышленник может скомпрометировать сеть и службы цепочки блоков, повредив более 1/3 сетевых узлов сети без обнаружения.

[0078] Для решения вышеописанных проблем и задач, связанных с существующими механизмами консенсуса BFT и механизмом консенсуса PBFT, в настоящем описании раскрываются улучшенные механизмы консенсуса, включающие в себя методы для достижения консенсуса между сетевыми узлами в распределенной системе, выполнения изменения первичного узла в распределенной системе и выполнения процесса восстановления для сетевого узла в распределенной системе. Описанные механизмы консенсуса могут достигать различных преимуществ в разных приложениях.

[0079] Например, процесс консенсуса, как описано ниже, включает в себя множество особенностей, которые улучшают работу системы цепочек блоков и помогают устранить узкие места в сети. Например, описанный процесс консенсуса включает в себя преобразование запроса транзакции в количество блоков кода стирания (EC) в соответствии с кодом EC и отправку одного из блоков EC на каждый из сетевых узлов. Блок EC меньше по размеру, чем исходный запрос транзакции. Соответственно, отправка блока EC вместо полного запроса транзакции на сетевые узлы уменьшает размер блоков данных, которые передаются между сетевыми узлами сети цепочек блоков, тем самым сохраняя пропускную способность сети и уменьшая нагрузку на сеть. Это дополнительно уменьшает размер данных, которые записываются и считываются из пространства памяти сетевых узлов, тем самым снижая нагрузку на пространство памяти сетевых узлов и повышая эффективность всей системы цепочки блоков.

[0080] Кроме того, в настоящем описании описывается процесс изменения эпохи, который включает в себя назначение соответствующих весовых коэффициентов множественным фазам процесса консенсуса, определение суммы весов на основе соответствующих весовых коэффициентов множественных фаз и определение нового первичного узла на основе суммы весов. Процесс изменения эпохи, основанный на сумме весов, а не на способе циклического перебора, может способствовать своевременному выбору нового первичного узла, который не является неисправным. Первичный узел может быть узлом–лидером, который имеет полномочия инициировать раунд процесса консенсуса среди некоторого количества сетевых узлов, включая первичный узел. Другие сетевые узлы сети цепочек блоков могут называться резервными узлами. Процесс изменения эпохи может помочь решить проблему способа циклического перебора, который вызывает частую смену первичного узла, когда множественные сетевые узлы в линии для нового первичного узла неисправны. В отличие от способа циклического перебора, процесс изменения эпохи в настоящем описании основывается на сумме весов для выбора нового первичного узла, что может уменьшить задержку или приостановку при поиске нового первичного узла, который не является неисправным. Это может еще больше повысить эффективность всей системы цепочек блоков в предоставлении услуг цепочек блоков.

[0081] Кроме того, в настоящем описании обсуждается процесс восстановления, который включает в себя такие операции, как отправка сообщения запроса состояния сетевым узлом, который применяется как новый первичный узел, и получение ответных сообщений о состоянии от других сетевых узлов. Эти операции выполняются таким образом, что процесс восстановления неисправного сетевого узла не мешает нормальной работе процесса консенсуса между другими неисправными сетевыми узлами. Это облегчает сохранение вычислительных и сетевых ресурсов для восстановления неисправного сетевого узла за счет снижения сложности процесса восстановления.

[0082] Фиг. 1 изображает пример среды 100, которая может использоваться для выполнения реализаций настоящего описания. В некоторых примерах среда 100 позволяет объектам участвовать в консорциумной сети 102 цепочек блоков. Среда 100 включает в себя вычислительные устройства или системы 106, 108 и сеть 110. В некоторых примерах сеть 110 включает в себя локальную сеть (LAN), глобальную сеть (WAN), Интернет или их комбинацию и соединяет веб–сайты, пользовательские устройства (например, вычислительные устройства) и серверные системы. В некоторых примерах к сети 110 можно получить доступ по проводной и/или беспроводной линии связи. В некоторых примерах сеть 110 обеспечивает связь с и внутри консорциумной сети 102 цепочек блоков. В общем, сеть 110 представляет одну или несколько сетей связи. В некоторых случаях вычислительные устройства 106, 108 могут быть узлами облачных вычислительных систем (не показаны) или каждое вычислительное устройство 106, 108 может быть отдельной облачной вычислительной системой, включающей в себя множество компьютеров, соединенных сетью и функционирующих как распределенная система обработки.

[0083] В изображенном примере вычислительные системы 106, 108 каждая может включать в себя любую подходящую вычислительную систему, которая обеспечивает возможность участия в качестве узла в консорциумной сети 102 цепочек блоков. Примеры вычислительных устройств включают в себя, без ограничения, сервер, настольный компьютер, ноутбук, планшетное вычислительное устройство и смартфон. В некоторых примерах вычислительные системы 106, 108 хостируют одну или несколько реализованных на компьютере служб для взаимодействия с консорциумной сетью 102 цепочек блоков. Например, вычислительная система 106 может хостировать реализованные на компьютере услуги первого объекта (например, пользователя A), такие как система управления транзакциями, которую первый объект использует для управления своими транзакциями с одним или несколькими другими объектами (например, другими пользователями). Вычислительная система 108 может хостировать реализованные на компьютере услуги второго объекта (например, пользователя B), такие как система управления транзакциями, которую второй объект использует для управления своими транзакциями с одним или несколькими другими объектами (например, другими пользователями). В примере по Фиг. 1 консорциумная сеть 102 цепочек блоков представлена как одноранговая сеть узлов, а вычислительные системы 106, 108 предоставляют узлы первого объекта и второго объекта соответственно, которые участвуют в консорциумной сети 102 цепочек блоков.

[0084] Фиг.2 изображает пример концептуальной архитектуры 200 в соответствии с реализациями настоящего описания. Пример концептуальной архитектуры 200 включает в себя системы 202, 204, 206 участников, которые соответствуют Участнику A, Участнику B и Участнику C соответственно. Каждый участник (например, пользователь, предприятие) участвует в сети 212 цепочек блоков, предоставляемой в виде одноранговой сети, включающей в себя множество узлов 214, по меньшей мере, некоторые из которых неизменно записывают информацию в цепочке 216 блоков. Хотя одна цепочка 216 блоков схематически изображена в сети 212 цепочек блоков, обеспечиваются множественные копии цепочки 216 блоков 216, и поддерживаются в сети 212 цепочек блоков, как описано более подробно в данном документе.

[0085] В изображенном примере каждая система 202, 204, 206 участника предоставляется участником или от имени Участника A, Участника B и Участника C соответственно и функционирует как соответствующий узел 214 в сети цепочек блоков. Как используется в данном документе, узел в общем относится к отдельной системе (например, компьютеру, серверу), которая подключена к сети 212 цепочек блоков и позволяет соответствующему участнику участвовать в сети цепочек блоков. В примере по Фиг. 2, участник соответствует каждому узлу 214. Предполагается, однако, что участник может оперировать множественными узлами 214 в сети 212 цепочек блоков, и/или множественные участники могут совместно использовать узел 214. В некоторых примерах системы 202, 204, 206 участников обмениваются данными с или через сеть 212 цепочек блоков с использованием протокола (например, защищенного протокола передачи гипертекста (HTTPS)) и/или с использованием удаленных вызовов процедур (RPC).

[0086] Узлы 214 могут иметь различные степени участия в сети 212 цепочек блоков. Например, некоторые узлы 214 могут участвовать в процессе консенсуса (например, в качестве узлов–помощников, которые добавляют блоки в цепочку 216 блоков), в то время как другие узлы 214 не участвуют в процессе консенсуса. В качестве другого примера, некоторые узлы 214 хранят полную копию цепочки 216 блоков, тогда как другие узлы 214 хранят только копии частей цепочки 216 блоков. Например, привилегии доступа к данным могут ограничивать данные цепочек блоков, которые соответствующий участник хранит в своей соответствующей системе. В примере по Фиг. 2, системы 202, 204, 206 участников хранят соответствующие полные копии 216’, 216’’, 216’’’цепочки 216 блоков.

[0087] Цепочка блоков (например, цепочка 216 блоков на Фиг. 2) состоит из цепочки блоков, причем каждый блок хранит данные. Примеры данных включают в себя данные транзакции, представляющие транзакцию между двумя или более участниками. Хотя здесь используются транзакции в качестве неограничивающего примера, предполагается, что любые подходящие данные могут быть сохранены в цепочке блоков (например, документы, изображения, видео, аудио). Примеры транзакций могут включать в себя, без ограничения, обмен чем–либо ценным (например, активами, продуктами, услугами и валютой). Данные транзакции всегда хранятся в цепочке блоков. То есть данные транзакции не могут быть изменены.

[0088] Перед сохранением в блоке, данные транзакции хэшируются. Хэширование – это процесс преобразования данных транзакции (предоставляемых в виде строковых данных) в хэш–значение фиксированной длины (также предоставляемое в виде строковых данных). Невозможно обратно хэшировать хэш–значение для получения данных транзакции. Хэширование гарантирует, что даже небольшое изменение данных транзакции приведет к совершенно другому хэш–значению. Дополнительно, как отмечено выше, хэш–значение имеет фиксированную длину. То есть, независимо от размера данных транзакции, длина хэш–значения является фиксированной. Хэширование включает в себя обработку данных транзакции через хэш–функцию для генерирования хэш–значения. Примеры хэш–функции включают в себя, без ограничения, алгоритм безопасного хэширования (SHA)–256, который выводит 256–битные хэш–значения.

[0089] Данные транзакций нескольких транзакций хэшируются и сохраняются в блоке. Например, предоставляются значения хэш–функции двух транзакций, и они сами хэшируются для предоставления другого хэша. Этот процесс повторяется до тех пор, пока для всех транзакций, которые будут сохранены в блоке, не будет предоставлено одно хэш–значение. Это значение хэш–функции называется корневым хэшем Меркла и хранится в заголовке блока. Изменение в любой из транзакций приведет к изменению ее хэш–значения и, в конечном итоге, к изменению корневого хэша Меркла.

[0090] Блоки добавляются в цепочку блоков по протоколу консенсуса. Множественные узлы в сети цепочек блоков участвуют в протоколе консенсуса и конкурируют за добавление блока в цепочку блоков. Такие узлы называются майнерами (или миньерами). POW, представленное выше, используется в качестве неограничивающего примера.

[0091] Узлы–майнеры выполняют процесс консенсуса для добавления транзакций в цепочку блоков. Хотя в процессе согласования участвуют множество узлов–майнеров, только один узел–майнер может записать блок в цепочку блоков. Таким образом, узлы–майнеры конкурируют в процессе консенсуса за добавление своего блока в цепочку блоков. Более подробно, узел–майнер периодически собирает ожидающие транзакции из пула транзакций (например, до предопределенного предела на количество транзакций, которые могут быть включены в блок, если таковые имеются). Пул транзакций включает в себя сообщения транзакций от участников в сети цепочек блоков. Узел–майнер строит блок и добавляет транзакции в блок. Перед добавлением транзакций в блок узел–майнер проверяет, включены ли уже какие–либо из транзакций в блок цепочки блоков. Если транзакция уже включена в другой блок, транзакция отменяется.

[0092] Узел–майнер генерирует заголовок блока, хэширует все транзакции в блоке и комбинирует хэш–значение в парах для генерирования дополнительных хэш–значений до тех пор, пока для всех транзакций в блоке не будет обеспечено одно хэш–значение (корневой хэш Меркла). Это хэш–значение добавляется в заголовок блока. Майнер также определяет хэш–значение самого недавнего блока в цепочке блоков (т.е. последний блок, добавленный в цепочку блоков). Узел–майнер также добавляет одноразовое значение и метку времени к заголовку блока. В процессе майнинга узел–майнер пытается найти хэш–значение, которое соответствует требуемым параметрам. Узел–майнер продолжает изменять одноразовое значение до тех пор, пока не будет найдено хэш–значение, которое соответствует требуемым параметрам.

[0093] Каждый майнер в сети цепочек блоков пытается найти хэш–значение, которое соответствует требуемым параметрам, и, таким образом, конкурирует с другим майнером. В конце концов, один из узлов–майнеров находит хэш–значение, которое соответствует требуемым параметрам, и объявляет его всем остальным узлам–майнерам в сети цепочек блоков. Другие узлы–майнеры проверяют хэш–значение и, если оно определено как правильное, проверяют каждую транзакцию в блоке, принимают блок и присоединяют блок в свою копию цепочки блоков. Таким образом, глобальное состояние цепочки блоков согласованно для всех узлов–майнеров в сети цепочек блоков. Вышеописанный процесс является консенсусным протоколом POW.

[0094] Неограничивающий пример приведен со ссылкой на Aиг. 2. В этом примере Участник A хочет отправить сумму средств Участнику B. Участник A генерирует сообщение транзакции (например, включая поля От кого, Кому и Сумма) и отправляет сообщение транзакции в сеть цепочек блоков, которая добавляет сообщение транзакции в пул транзакций. Каждый узел–майнер в сети цепочки блоков создает блок и принимает все транзакции из пула транзакций (например, до предопределенного предела количества транзакций, которые могут быть добавлены в блок, если таковые имеются), и добавляет транзакции к блок. Таким образом, транзакция, опубликованная Участником A, добавляется в блоки узлов–майнеров.

[0095] В некоторых сетях цепочек блоков, криптография реализуется для обеспечения конфиденциальности транзакций. Например, если два узла хотят сохранить конфиденциальность транзакции, так чтобы другие узлы в сети цепочек блоков не смогли различить детали транзакции, узлы могут зашифровать данные транзакции. Примеры криптографических способов включают в себя, без ограничения, симметричное шифрование и асимметричное шифрование. Симметричное шифрование относится к процессу шифрования, который использует один ключ как для шифрования (генерируя зашифрованный текст из открытого текста), так и для дешифрования (генерируя открытый текст из зашифрованного текста). При симметричном шифровании один и тот же ключ доступен множественным узлам, поэтому каждый узел может зашифровать/дешифровать данные транзакции.

[0096] Асимметричное шифрование использует пары ключей, каждая из которых включает в себя закрытый ключ и открытый ключ, причем закрытый ключ известен только соответствующему узлу, а открытый ключ известен любому или всем другим узлам в сети цепочек блоков. Узел может использовать открытый ключ другого узла для шифрования данных, а зашифрованные данные могут быть расшифрованы с использованием закрытого ключа другого узла. Например, и снова ссылаясь на Фиг. 2, Участник A может использовать открытый ключ Участника B для шифрования данных и отправлять зашифрованные данные Участнику B. Участник B может использовать свой закрытый ключ для расшифровки зашифрованных данных (зашифрованного текста) и извлечения исходных данных (открытого текста). Сообщения, зашифрованные открытым ключом узла, могут быть расшифрованы только с помощью закрытого ключа упомянутого узла.

[0097] Асимметричное шифрование используется для предоставления цифровых подписей, что позволяет участникам транзакции подтверждать других участников транзакции, а также достоверность транзакции. Например, узел может подписать сообщение цифровой подписью, а другой узел может подтвердить, что сообщение было отправлено узлом на основе цифровой подписи Участника А. Цифровые подписи также могут использоваться для гарантии того, что сообщения не будут подделаны при передаче. Например, и снова ссылаясь на Фиг. 2, Участник A должен отправить сообщение Участнику B. Участник A генерирует хэш–значение сообщения, а затем, используя свой закрытый ключ, шифрует это хэш–значение, чтобы предоставить цифровую подпись в качестве зашифрованного хэш–значения. Участник A присоединяет цифровую подпись к сообщению и отправляет сообщение с цифровой подписью Участнику B. Участник B расшифровывает цифровую подпись, используя открытый ключ Участника A, и извлекает хэш–значение. Участник B хэширует сообщение и сравнивает хэш–значения. Если хэш–значения совпадают, Участник B может подтвердить, что сообщение действительно было от Участника A и не было подделано.

[0098] Фиг.3 изображает пример процесса 300 для достижения консенсуса между сетевыми узлами (например, узлом 214) распределенной системы (например, сети 102 и 212 цепочек блоков), который может быть выполнен в соответствии с реализациями настоящего описания. В частности, Фиг.3 иллюстрирует схему, представляющую примерный вариант осуществления способа 300 достижения консенсуса в обычном случае в соответствии с настоящим описанием. Как показано на Фиг. 3, процесс 300 консенсуса включает в себя три фазы или стадии 310, 320 и 330, как описано ниже.

[0099] На первой фазе 310 процесса 300 консенсуса, первичный узел (или узел–лидер) сети цепочек блоков отправляет первое сообщение другим сетевым узлам (то есть резервным узлам). Первое сообщение указывает, что первичный узел инициирует процесс консенсуса. Например, как показано на Фиг. 3, первичный узел R0 отправляет INITIAL сообщение другим сетевым узлам R1, R2 и R3 в сети цепочек блоков. Следует отметить, что процесс 300 иллюстрируется как включающий в себя четыре сетевых узла R0, R1, R2 и R3 только для иллюстративных целей, процесс 300 может включать в себя любое подходящее количество сетевых узлов. Первая фаза и формат INITIAL сообщения будут обсуждаться ниже более подробно со ссылкой на Фиг. 4–6.

[00100] На второй фазе 320 процесса 300 консенсуса каждый из резервных узлов принимает первое сообщение, которое отправлено первичным узлом, подготавливает второе сообщение в ответ на первое сообщение и многоадресно передает второе сообщение другому сетевому узлу. Второе сообщение указывает, что резервный узел принял первое сообщение от первичного узла и отправляет ответ в ответ на первое сообщение. Например, как показано на Фиг. 3, резервный узел R1 принимает INITIAL сообщение, которое отправляется первичным узлом R0, и отвечает первичному узлу R0 сообщением ECHO в качестве примера второго сообщения. Между тем, резервный узел R1 также многоадресно передает сообщение ECHO другим резервным узлам, таким как резервные узлы R2 и R3. Аналогично, каждый резервный узел R2 и R3 многоадресно передает сообщение ECHO другим сетевым узлам сети, в том числе первичному узлу R0.

[00101] Когда сетевой узел, например, такой как первичный узел или резервный узел, принимает сообщения ECHO от других сетевых узлов, сетевой узел может проверять информацию в сообщениях ECHO. Вторая фаза и формат сообщения ECHO будут обсуждаться ниже более подробно со ссылкой на Фиг. 4–6.

[00102] На третьей фазе 330 процесса 300 консенсуса, каждый из сетевых узлов многоадресно передает третье сообщение другим сетевым узлам. Третье сообщение указывает, что сетевой узел принял предопределенное количество вторых сообщений. В некоторых реализациях третье сообщение может указывать, что сетевой узел готов выполнить транзакцию. В некоторых реализациях третье сообщение может указывать, что транзакция была успешно восстановлена в сетевом узле. Например, как показано на Фиг. 3, первичный узел R0 многоадресно передает сообщение ACCEPT резервным узлам R1, R2 и R3. Аналогично, каждый из резервных узлов R1, R2 и R2 многоадресно передает сообщение ACCEPT другим сетевым узлам. В некоторых реализациях настоящего описания перед многоадресной передачей сообщения ACCEPT сетевой узел определяет, отправлено ли ACCEPT в соответствии с кодом стирания (EC), и информация в сообщениях ECHO принята на второй фазе. Третья фаза, код EC и формат сообщения ACCEPT будут обсуждаться ниже более подробно со ссылкой на Фиг. 4–6.

[00103] Когда сетевой узел принимает достаточно сообщений ACCEPT от других сетевых узлов, сетевой узел определяет, что консенсус достигнут. Например, если первичный узел R0 или резервные узлы R1, R2 или R3 получают кворум (например, 2f+1, где f представляет количество неисправных сетевых узлов) количества сообщений ACCEPT, консенсус достигается автоматически между сетевыми узлами.

[00104] Фиг.4 изображает пример процесса 400 для достижения консенсуса между сетевыми узлами (например, узлом 214 или узлами R0, R1, R2 и R3) распределенной системы (например, сети 102 или 212 цепочек блоков), которая может быть выполнена в соответствии с реализации настоящего описания. В некоторых реализациях процесс 400 может выполняться с использованием одной или нескольких компьютерно–исполняемых программ, исполняемых с использованием одного или нескольких вычислительных устройств. Для ясности изложения последующее описание в общем описывает способ 400 в контексте других фигур в этом описании. Понятно, что способ 400 может быть выполнен, например, любой подходящей системой, средой, программным обеспечением и аппаратным обеспечением или комбинацией систем, сред, программного обеспечения и аппаратного обеспечения, в зависимости от ситуации. В некоторых реализациях различные этапы способа 400 могут выполняться параллельно, в комбинации, в циклах или в любом порядке.

[00105] Вначале процесс 400 может быть реализован совместно с системой 100–300, как показано на Фиг. 1–3. В некоторых реализациях настоящего описания сеть 102 и/или 212 цепочек блоков включает в себя первичный узел 404 и один или несколько резервных узлов 406. Сеть 102 и/или 212 цепочек блоков осуществляет связь с вычислительной системой 106 и/или 108, такой как клиентские узлы 402, через сеть 110, чтобы предоставлять услуги цепочек блоков. Каждый из клиентского узла 402, первичного узла 404 и резервного узла 406 может быть специализированным компьютером или другим устройством обработки данных, сконфигурированным для выполнения процессов, обсуждаемых в данном документе. Например, клиентский узел 402 также может называться клиентским терминалом или клиентским устройством, которое взаимодействует с сетью цепочек блоков. Клиентский узел 402 может установить, например, клиентское приложение или комплект разработки клиентского программного обеспечения (SDK) в связи с сетью цепочек блоков для доступа и осуществления связи с сетью цепочек блоков. Первичный узел 404 и один или несколько резервных узлов 406 также могут упоминаться как согласованные узлы или сетевые узлы, которые достигают согласованности (консенсуса) и неизменно записывают информацию в сети цепочек блоков.

[00106] Процесс 400 начинается на этапе 408, где клиентский узел 402 генерирует запрос транзакции. В некоторых реализациях настоящего описания запрос транзакции может включать в себя запрос, запрашивающий услугу цепочек блоков из сети 102 и/или 212 цепочек блоков.

[00107] На этапе 410 клиентский узел 402 многоадресно передает запрос транзакции первичному узлу 404 сети 102 и/или 212 цепочек блоков. В некоторых реализациях настоящего описания первичный узел 404 назначает порядковый номер запросу транзакции для отслеживания запросов транзакции после приема запроса транзакции от клиентского узла 402.

[00108] На этапе 412 первичный узел 402 генерирует количество блоков EC после приема запроса транзакции от клиентского узла 402. В некоторых реализациях настоящего описания первичный узел 404 генерирует количество блоков EC в соответствии с кодом EC, используя запрос транзакции. Например, ссылаясь на Фиг. 5, первичный узел 404 применяет код 504 ЕС к запросу 502 транзакции и преобразует запрос 502 транзакции в сообщение 506 ЕС, используя код 504 ЕС. Код 504 ЕС является кодом прямого исправления ошибок (FEC) в предположении стирания битов. Код 504 ЕС преобразует исходный запрос 502 транзакции в более длинное сообщение 506 ЕС, так что исходный запрос 502 транзакции может быть восстановлен из части или фрагмента сообщения 506 ЕС.

[00109] В некоторых реализациях настоящего описания код 504 ЕС является почти оптимальным кодом стирания, таким как код Торнадо или код проверки на четность с низкой плотностью. В альтернативных реализациях настоящего описания код 504 ЕС является почти оптимальным исходным кодом, таким как исходный код, оперативный код, код преобразования Луби (LT) или код хищника. В альтернативных реализациях настоящего описания код 504 ЕС является оптимальным кодом стирания, таким как код четности, код Parchive, код Рида–Соломона или регенерирующий код. В некоторых реализациях настоящего описания код 504 ЕС может представлять собой любой подходящий тип кода стирания.

[00110] После преобразования запроса 502 транзакции в сообщение 506 ЕС, первичный узел 404 генерирует количество блоков 508 ЕС, используя сообщение 506 ЕС. Например, как показано на Фиг. 5, первичный узел 404 генерирует четыре блока 508 EC, блок A EC, блок B EC, блок C EC и блок D EC путем разделения сообщения 506 EC. Следует отметить, что блоки 508 ЕС показаны на Фиг. 5 как включающие в себя четыре блока для иллюстративной цели, при этом блоки 508 ЕС могут быть сгенерированы как включающие в себя любое подходящее количество блоков 508 ЕС. Блоки 508 ЕС будут отправлены в соответствующие резервные узлы 406 в сообщениях INITIAL.

[00111] В некоторых реализациях настоящего описания блоки 508 ЕС имеют одинаковый размер. Однако в альтернативных реализациях блоки 508 ЕС могут иметь размеры, которые отличаются друг от друга.

[00112] В некоторых реализациях настоящего описания первичный узел 404 генерирует хэш–дерево 500 (например, дерево Меркла) с использованием блоков 508 ЕС. Хэш–дерево 500 включает в себя некоторое количество листовых узлов, которые помечены хэшем блоков данных, и некоторое количество не листовых узлов, которые помечены криптографическим хэшем меток его дочерних узлов. Например, как показано на Фиг. 5, хэш–дерево 500 сконфигурировано так, что оно включает в себя четыре листовых узла 510, хэш–код A, хэш–код B, хэш–код C и хэш–код D, которые генерируются в качестве криптографического хэша их соответствующих блоков 508 EC, и четыре не листовых узла 512, которые генерируются в качестве хэша конкатенации их соответствующих дочерних узлов 510 и нелистового узла 514, который генерируется как хэш его дочерних узлов 512 и является корневым хэшем хэш–дерева 500.

[00113] Хэш–деревья 500 позволяют эффективно и безопасно проверять содержимое больших структур данных. Хэш–деревья 500 могут быть использованы для проверки любого вида данных, хранящихся, обрабатываемых и передаваемых в и между компьютерами. Они могут помочь гарантировать, что блоки данных, принятые от других одноранговых узлов в сети P2P, будут приняты неповрежденными и неизменными, и даже проверить, что другие одноранговые узлы не отправляют поддельные блоки. Проверка блоков данных с использованием хэш–дерева 500 будет более подробно рассмотрена ниже со ссылкой на следующие этапы процесса 400 консенсуса.

[00114] Возвращаясь к Фиг. 4, первичный узел 404 генерирует первое сообщение (например, сообщение INITIAL) после генерации блоков 508 ЕС и хэш–дерева 500. Первое сообщение указывает, что первичный узел инициирует процесс консенсуса. В некоторых реализациях INITIAL сообщение, как пример первого сообщения, генерируется с использованием информации в блоках 508 EC и хэш–дереве 500. В некоторых реализациях настоящего описания со ссылкой на Фиг. 6, INITIAL сообщение имеет формат < epoch, tx_root_hash, ec_block_hash, ec_block, seq, j > где epoch представляет раунд консенсуса, в котором отправляется сообщение, «tx_root_hash» представляет корневой хэш 514 в хэш–дереве 500, «ec_block_hash» представляет хэши 510 и/или 512 в хэш–дереве 500, «ec_block »представляет блоки 508 EC в хэш–дереве 500,«seq »представляет порядковый номер, ассоциированный с запросом 502 транзакции, а «j» представляет сетевой узел, который генерирует и отправляет INITIAL сообщение. В некоторых реализациях INITIAL сообщение может иметь другой формат, например, путем включения дополнительных или разных полей.

[00115] Возвращаясь к Фиг. 4, на этапе 416 на первой фазе процесса консенсуса, первичный узел 404 многоадресно отправляет INITIAL сообщение другим сетевым узлам (например, резервным узлам 406). В некоторых реализациях INITIAL сообщения, которые отправляются на резервные узлы 406, имеют формат <epoch, tx_root_hash, ec_block_hash, ec_block, seq, j>. Например, первичный узел 404 может отправлять первое INITIAL сообщение <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 0> на первый резервный узел 406 и второе INITIAL сообщение <epoch 1, Hash ABCD, {Hash A, Hash C, Hash D}, EC block B, 1, 0> на второй резервный узел 406 и так далее. Следует отметить, что информация в INITIAL сообщении, такая как «ec_block», может использоваться с «ec_block_hash» для восстановления хэш–дерева 500. Например, в первом INITIAL сообщении <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 0> блок 508 EC «блок A EC» может быть хэширован для генерирования криптографического хэша 510 «Хэш A», который дополнительно используется с другими хэшами 510 «{ Hash B, Hash C, Hash D }» для восстановления хэш–дерева 500. Восстановленное хэш–дерево 500 будет использоваться для проверки сообщений ECHO, как более подробно описано ниже со ссылкой на следующие этапы процесса консенсуса.

[00116] На этапе 418 каждый из резервных узлов 406 генерирует второе сообщение (например, сообщение ECHO) во второй фазе процесса консенсуса после приема INITIAL сообщения от первичного узла 404. Второе сообщение указывает, что резервный узел принял первое сообщение от первичного узла. Второе сообщение отправляется как ответ в ответ на первое сообщение. В некоторых реализациях настоящего описания сообщение ECHO генерируется резервным узлом 406 как включающее в себя сообщение INITIAL или часть сообщения INITIAL и подпись резервного узла 406, ассоциированного с сообщением INITIAL. Например, резервный узел 406 может генерировать подпись, подписывая INITIAL сообщение или дайджест INITIAL сообщения, используя закрытый ключ. Подпись закрытого ключа может использоваться другими сетевыми узлами, использующими открытый ключ в паре с закрытым ключом, для аутентификации сообщения ECHO, которое включает в себя подпись закрытого ключа.

[00117] В некоторых реализациях настоящего описания со ссылкой на Фиг. 6, сообщение ECHO имеет формат <epoch, tx_root_hash, ec_block_hash, ec_block, seq, sign_proof, j> где epoch представляет раунд консенсуса, в котором отправляется сообщение, «tx_root_hash» представляет корневой хэш 514 в хэш–дереве 500, «ec_block_hash» представляет хэши 510 и/или 512 в хэш–дереве 500, «ec_block »представляет блоки 508 EC в хэш–дереве 500, которые приняты соответствующими резервными узлами 406,«seq»представляет порядковый номер, ассоциированный с запросом 502 транзакции, «sign–proof» представляет подпись резервных узлов 406, ассоциированных с INITIAL сообщениями, а «j» представляет сетевой узел, который генерирует и отправляет сообщение ECHO. В некоторых реализациях сообщение ECHO может иметь другой формат, например, путем включения дополнительных или разных полей.

[00118] Возвращаясь к Фиг. 4, на этапе 420 резервные узлы 406 отправляют сообщения ECHO первичному узлу 404. На этапе 421 каждый из резервных узлов 406 отправляет сообщения ECHO другим резервным узлам 406. На этапе 423 каждый из резервных узлов 406 может принимать сообщения ECHO от других резервных узлов 406.

[00119] На 422 первичный узел 404 проверяет сообщения ECHO, которые отправляются резервными узлами 406. В некоторых реализациях настоящего описания первичный узел 404 проверяет, являются ли сообщения ECHO действительными согласно хэш–дереву 500. Например, первичный узел 404 может принять первое сообщение ECHO <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 1> от первого резервного узла 406. Первичный узел 404 может извлечь блок 508 ЕС «EC block A» из сообщения и хэшировать его, чтобы сгенерировать криптографический хэш 510 «Hash A». Первичный узел 404 дополнительно использует сгенерированный хэш510 «Hash A» с другими хэшами 510 «{Hash B, Hash C, Hash D}» в сообщении для восстановления хэш–дерева 500. Затем первичный узел 404 определяет корневой хэш 514 восстановленного хэш–дерева 500 и сравнивает его с корневым хэшем 514 в сообщении ECHO, таким как «Hash ABCD». Если два корневых хэша 514 совпадают, первичный узел 404 определяет, что сообщение ECHO является действительным. Первичный узел 404 может хранить действительные сообщения ECHO и отбрасывать сообщения ECHO, которые определены как недействительные.

[00120] На этапе 424 первичный узел 404 определяет, превышает ли количество действительных сообщений ECHO предопределенный порог. В некоторых реализациях настоящего описания первичный узел 404 определяет, достигает ли количество действительных сообщений ECHO количества кворума n–f или 2f+1, где n – общее количество узлов сети, а f – максимальное количество неисправных узлы, которые сеть может выдержать.

[00121] На этапе 426 первичный узел 404 восстанавливает запрос 502 транзакции в ответ на определение, что количество действительных сообщений ECHO достигает количества кворума. В некоторых реализациях настоящего описания первичный узел 404 восстанавливает запрос 502 транзакции на основе, по меньшей мере, поднабора действительных сообщений ECHO в соответствии с кодом EC. Например, первичный узел 404 может извлечь количество n–2f или f+1 из блоков 508 EC, которые находятся в количестве кворума (например, n–f или 2f+1) действительных сообщений ECHO, и использовать извлеченные блоки 508 EC, чтобы восстановить запрос 502 транзакции согласно коду 504 ЕС.

[00122] На этапе 428 на третьей фазе процесса консенсуса первичный узел 404 генерирует третье сообщение (например, сообщение ACCPET) в ответ на определение, что запрос 502 транзакции был успешно восстановлен. Третье сообщение указывает, что сетевой узел принял предопределенное количество вторых сообщений. В некоторых реализациях третье сообщение может указывать, что сетевой узел готов выполнить транзакцию. В некоторых реализациях третье сообщение может указывать, что транзакция была успешно восстановлена в сетевом узле. Например, сообщение ACCPET может использоваться для указания другим узлам сети, что запрос 502 транзакции был успешно восстановлен. Если первичному узлу 404 не удается восстановить запрос 502 транзакции, то первичный узел 404 может не генерировать сообщение ACCEPT.

[00123] В некоторых реализациях настоящего описания со ссылкой на Фиг. 6 сообщение ACCEPT имеет формат <epoch, tx_root_hash, seq, sign_proofs, j> где epoch представляет раунд консенсуса, в котором отправляется сообщение, «tx_root_hash» представляет корневой хэш 514 в хэш–дереве 500, «seq» представляет порядковый номер, ассоциированный с запросом 502 транзакции, «sign–proofs» представляет набор подписей в действительных сообщениях ECHO, а «j» представляет сетевой узел, который генерирует и отправляет сообщение ACCEPT. В некоторых реализациях сообщение ACCEPT может иметь другой формат, например, путем включения дополнительных или разных полей.

[00124] Возвращаясь к Фиг. 4, на этапе 430 первичный узел 404 отправляет сообщение ACCPET резервным узлам 406.

[00125] Подобно первичному узлу 404, каждый из резервных узлов 406 может восстанавливать запрос транзакции, например, выполняя этапы, аналогичные этапам 422–428 в качестве первичного узла 404. На этапе 432 каждый из резервных узлов 406 генерирует сообщение ACCEPT в ответ на определение, что запрос 502 транзакции был успешно восстановлен резервным узлом 406. В некоторых реализациях первичный узел 404 и резервный узел 406 могут выполнять этапы 422–428 параллельно, например, как указано на фиг. 3.

[00126] На этапе 434 резервные узлы 406 отправляют сообщения ACCEPT первичному узлу 404. Между тем каждый из резервных узлов 406 может отправлять сообщения ACCEPT другим резервным узлам 406.

[00127] На этапе 436 первичный узел 404 выполняет запрос 502 транзакции в ответ на определение, что количество сообщений ACCEPT превышает предопределенный порог. В некоторых реализациях настоящего описания первичный узел 404 определяет, идентичны ли принятые сообщения ACCEPT и достигает ли количество идентичных сообщений ACCEPT количества кворума (например, 2f+1). Если количество идентичных сообщений ACCEPT достигает количества кворума, первичный узел 404 определяет, что был достигнут консенсус среди всех сетевых узлов, а затем выполняет запрос 502 транзакции локально. В некоторых реализациях настоящего описания, если первичный узел 404 определяет, что количество идентичных сообщений ACCEPT не достигает количества кворума, первичный узел 404 определяет, что консенсус не достигнут среди всех сетевых узлов, и затем воздерживается от выполнения запроса 502 транзакции.

[00128] В некоторых реализациях настоящего описания каждый из резервных узлов 406 может выполнять те же операции, которые выполняются первичным узлом 404, как описано выше на этапе 436, перед выполнением запроса 502 транзакции. Если резервный узел 406 определяет, что принятые им сообщения ACCEPT превышают предопределенный порог, резервный узел 406 определяет, что достигнут консенсус среди сетевых узлов, и выполняет запрос 502 транзакции локально. В некоторых реализациях настоящего описания, если резервный узел 406 определяет, что количество идентичных сообщений ACCEPT не достигает количества кворума, резервный узел 406 определяет, что консенсус не достигнут среди всех сетевых узлов, и затем воздерживается от выполнения запроса 502 транзакции.

[00129] На этапе 438 первичный узел 404 отправляет результат транзакции клиентскому узлу 402 после выполнения запроса 502 транзакции. Резервные узлы 406, которые успешно выполнили запрос 502 транзакции локально, также могут отправлять свои соответствующие результаты транзакции клиентскому узлу 402.

[00130] Процесс консенсуса, как обсуждалось выше, включает в себя множество особенностей, которые улучшают работу всей системы цепочек блоков и помогают устранить узкие места в сети. Например, процесс консенсуса в настоящем описании включает в себя генерирование некоторого количества блоков EC в соответствии с кодом EC с использованием запроса транзакции и отправку одного из блоков EC в каждый из сетевых узлов. Блок EC меньше по размеру, чем исходный запрос транзакции. Следовательно, отправка блока EC вместо запроса транзакции сетевым узлам уменьшает размер блоков данных, которые передаются между сетевыми узлами сети цепочек блоков, тем самым сохраняя пропускную способность сети и уменьшая нагрузку на сеть. Это дополнительно уменьшает размер данных, которые записываются и считываются из пространства памяти сетевых узлов, тем самым снижая нагрузку на пространство памяти сетевых узлов и повышая эффективность всей системы цепочек блоков.

[00131] В процессе консенсуса резервные узлы ожидают запроса от первичного узла. Однако первичный узел может столкнуться с византийской ошибкой или поломкой, так что первичный узел не может передать запрос в течение предопределенного временного окна. Когда конкретное количество времени прошло без многоадресной передачи запроса первичным узлом, может потребоваться выбрать новый первичный узел, чтобы резервные узлы не ожидали выполнения запросов в течение неопределенного времени.

[00132] Фиг.7 изображает пример процесса 700 для выполнения изменения первичного узла (например, узла 214 или 404) распределенной системы (например, сети 102 и 212 цепочек блоков), который может исполняться в соответствии с реализациями настоящего описания. В частности, Фиг.7 иллюстрирует схему, представляющую примерный вариант осуществления способа 700 выполнения изменения первичного узла в соответствии с настоящим описанием. В некоторых реализациях первичный узел ассоциирован с эпохой, которая включает в себя процесс консенсуса с первичным узлом, являющимся лидером. Изменение первичного узла может привести к изменению эпохи.

[00133] В некоторых реализациях в ответ на определение, что первичный узел текущей эпохи должен быть изменен, резервный узел сети цепочек блоков отправляет первое сообщение другим сетевым узлам. Первое сообщение указывает, что резервный узел хотел бы быть новым первичным узлом в новую эпоху (новый период времени). Например, как показано на Фиг. 7, резервный узел R0 отправляет сообщение EPOCH_CHANGE другим сетевым узлам R1, R2 и R3 в сети цепочек блоков в ответ на то, что резервный узел R0 определяет, что текущий первичный узел неисправен и что необходимо выполнить изменение эпохи (периода времени). Сообщение EPOCH_CHANGE является примером первого сообщения, указывающего, что резервный узел R0 применяется в качестве нового первичного узла. Изменение эпохи может вызвать переход от текущей эпохи с текущим первичным узлом к новой эпохе с новым первичным узлом. Следует отметить, что процесс 700 иллюстрируется как реализованный совместно с четырьмя сетевыми узлами только для иллюстративных целей. Процесс 700 может быть реализован совместно с любым подходящим количеством сетевых узлов.

[00134] Затем каждый из сетевых узлов принимает первое сообщение, отправленное резервным узлом, подготавливает второе сообщение в ответ на первое сообщение и многоадресно передает второе сообщение другим сетевым узлам. Например, как показано на Фиг. 7, сетевой узел R1 принимает сообщение EPOCH_CHANGE, которое отправлено резервным узлом R0, и отвечает на резервный узел R0 сообщением NEW_EPOCH, указывающим подтверждение того, что резервный узел R0 может стать новым первичным узлом. Между тем, сетевой узел R1 также осуществляет многоадресную передачу сообщения NEW_EPOCH другим сетевым узлам, таким как сетевые узлы R2 и R3. Аналогично каждый сетевой узел R2 и R3 многоадресно передает сообщение NEW_EPOCH другим сетевым узлам.

[00135] Процесс изменения периода времени, как обсуждалось выше, формат сообщения EPOCH_CHANGE и формат сообщения NEW_EPOCH будут обсуждаться ниже более подробно со ссылкой на Фиг. 8–9.

[00136] Фиг.8 изображает пример процесса 800 для выполнения изменения первичного узла в распределенной системе (например, сети 102 или 212 цепочек блоков), который может быть выполнен в соответствии с реализациями настоящего описания. В некоторых реализациях примерный процесс 800 может выполняться с использованием одной или нескольких компьютерно–исполняемых программ, выполняемых с использованием одного или нескольких вычислительных устройств. Для ясности изложения последующее описание в общем описывает способ 800 в контексте других фигур в этом описании. Понятно, что способ 800 может выполняться, например, любой подходящей системой, средой, программным обеспечением и аппаратным обеспечением или комбинацией систем, сред, программного обеспечения и аппаратного обеспечения, в зависимости от ситуации. В некоторых реализациях различные этапы способа 800 могут выполняться параллельно, в комбинации, в циклах или в любом порядке.

[00137] Процесс 800 начинается на этапе 806, где резервный узел 802 определяет, что изменение периода времени должно быть выполнено. Изменение периода времени, обсуждаемое здесь, вызывает переход от текущего периода времени с текущим первичным узлом к новому периоду времени с новым первичным узлом. Примерный период времени может включать в себя процесс консенсуса (например, процесс согласования 300 или 400) для достижения консенсуса между некоторым количеством сетевых узлов, использующих первичный узел, как обсуждалось выше со ссылкой на Фиг. 3–6.

[00138] В некоторых реализациях настоящего описания резервный узел 802 определяет, что изменение периода времени должно быть выполнено в ответ на определение, что резервный узел 802 все еще ожидает запрос от текущего первичного узла после того, как конкретное количество времени прошло без приема запроса от текущего первичного узла. Например, текущий первичный узел может столкнуться с византийской ошибкой или поломкой, так что текущий первичный узел не может выполнить многоадресную передачу запроса в течение предопределенного временного окна. Следовательно, изменение периода времени инициируется тайм–аутами, которые не позволяют резервным узлам неопределенное время ожидать выполнения запросов. Процесс изменения периода времени, обсуждаемый в данном документе, обеспечивает жизнеспособность и уменьшает задержку в сети, позволяя системе добиваться прогресса при отказе первичного узла.

[00139] На этапе 808 резервный узел 802 определяет соответствующий вес резервного узла 802, ассоциированного с каждой из фаз процесса консенсуса в текущем периоде времени. В некоторых реализациях процесс консенсуса включает в себя три фазы, как описано выше со ссылкой на Фиг. 3–6. Вес является метрикой квалификации резервного узла 802, чтобы быть новым первичным узлом в новом периоде времени.

[00140] В некоторых реализациях настоящего описания резервный узел 802 определяет вес резервного узла 802 для первой фазы процесса консенсуса в текущем периоде времени, чтобы быть первым значением. Например, резервному узлу 802 может быть назначен начальный вес 10%, если резервный узел 802 вошел в первую фазу процесса консенсуса (например, первую фазу 310 процесса 300 консенсуса). В альтернативных реализациях настоящего описания резервный узел 802 может назначить любое подходящее значение веса резервному узлу 802 для первой фазы текущего процесса консенсуса.

[00141] В некоторых реализациях настоящего описания резервный узел 802 определяет вес резервного узла 802 для второй фазы процесса консенсуса (например, первой фазы 320 процесса 300 консенсуса) в текущем периоде времени на основе процесса проверки кворума. Процесс проверки кворума выполняется путем определения, принимает ли резервный узел 802 предопределенное количество (например, 2f+1) сообщений ECHO от других сетевых узлов во второй фазе процесса консенсуса.

[00142] В некоторых реализациях настоящего описания, если резервный узел 802 терпит неудачу при проверке кворума (например, резервный узел 802 принимает некоторое количество сообщений ECHO, которое меньше, чем предопределенный порог), то резервный узел 802 может определять вес резервного узла 802 для второй фазы процесса консенсуса, чтобы он стал первым значением. Если резервный узел 802 проходит проверку кворума (например, резервный узел 802 принимает количество сообщений ECHO, которое равно или превышает заранее определенный порог), то резервный узел 802 может определить вес резервного узла 802 для второй фазы процесс консенсуса, чтобы он стал вторым значением. В некоторых реализациях настоящего описания второе значение определяется как большее, чем первое значение. Например, если резервный узел 802 не проходит проверку кворума, резервному узлу 802 может быть назначено нулевое значение веса для второй фазы процесса консенсуса. Если резервный узел 802 проходит проверку кворума, резервному узлу 802 может быть назначено значение веса 45% для резервного узла 802 для второй фазы процесса консенсуса. Однако в альтернативных реализациях настоящего описания резервный узел 802 может назначить любое подходящее значение резервному узлу 802 для второй фазы процесса согласования в текущую эпоху.

[00143] В некоторых реализациях настоящего описания проверка кворума дополнительно включает в себя проверку, являются ли сообщения ECHO, которые резервный узел 802 принимает от других сетевых узлов во время второй фазы процесса консенсуса, действительными. Например, резервный узел 802 может аутентифицировать подписи секретного ключа в сообщениях ECHO, используя открытый ключ, чтобы определить, являются ли сообщения ECHO действительными.

[00144] Подобно определению веса для второй фазы, в некоторых реализациях, резервный узел 802 определяет вес резервного узла 802 для третьей фазы процесса согласования (например, третьей фазы 330 процесса 300 консенсуса) в текущем периоде времени, на основе процесса проверки кворума. Процесс проверки кворума выполняется путем определения, принимает ли резервный узел 802 предопределенное количество (например, 2f+1) сообщений о принятии от других сетевых узлов на третьей фазе процесса консенсуса в текущем периоде времени. Каждое из сообщений о принятии от других сетевых узлов сети указывает, что каждый из других сетевых узлов принял предопределенное количество сообщений ECHO. Сообщение о принятии может быть, например, сообщениями ACCEPT, описанными выше со ссылкой на третью фазу 330 процесса 300 консенсуса.

[00145] В некоторых реализациях настоящего описания, если резервный узел 802 терпит неудачу при проверке кворума (например, резервный узел 802 принимает количество сообщений ACCEPT, которое меньше, чем предопределенный порог), резервный узел 802 может определять вес резервного узла 802 для третьей фазы процесса консенсуса, чтобы быть первым значением. Если резервный узел 802 проходит проверку кворума (например, резервный узел 802 принимает количество сообщений ACCEPT, равное или превышающее предопределенный порог), резервный узел 802 может определить вес резервного узла 802 для третьей фазы процесс консенсуса, чтобы быть вторым значением. В некоторых реализациях второе значение определяется как большее, чем первое значение. Например, если резервный узел 802 терпит неудачу при проверке кворума, резервному узлу 802 может быть назначено нулевое значение веса для резервного узла 802 для второй фазы процесса согласования. Если резервный узел 802 проходит проверку кворума, резервному узлу 802 может быть назначено значение веса 45% для резервного узла 802 для второй фазы процесса согласования. Однако в альтернативных реализациях настоящей спецификации резервный узел 802 может назначить любое подходящее значение резервному узлу 802 для третьей фазы процесса консенсуса в текущем периоде времени.

[00146] На этапе 810 после определения соответствующих весов резервного узла 802 для фаз процесса консенсуса в текущем периоде времени, резервный узел 802 определяет сумму весов резервного узла 802 для процесса консенсуса на основе соответствующих весовых коэффициентов. В некоторых реализациях настоящего описания сумма весов представляет собой сумму соответствующих сумм резервных узлов, ассоциированных с каждой из фаз процесса консенсуса в текущем периоде времени. Например, если резервный узел 802 определил первое значение веса резервного узла 802 для первой фазы равным 10%, второе значение веса резервного узла 802 для второй фазы равным 45%, а третье значение веса резервного узла 802 для третьей фазы равным 45%, резервный узел 802 определяет сумму весов равной 100%. В качестве другого примера, если резервный узел 802 определил первое значение веса резервного узла 802 для первой фазы равным 10%, второе значение веса резервного узла 802 для второй фазы 45%, а третье значение веса резервного узла 802 для третьей фазы равным 0, резервный узел 802 определяет сумму весов, равную 55%.

[00147] На этапе 812 резервный узел 802 отправляет сообщение EPOCH_CHANGE другим сетевым узлам 804, если резервный узел 802 определяет, что сумма весов, которая была определена на этапе 810, достигает или превышает предопределенный порог. Например, резервный узел 802 может отправлять сообщение EPOCH_CHANGE другим сетевым узлам 804, если сумма весов, определенная на этапе 810, достигает 100%. Сообщение EPOCH_CHANGE указывает запрос на смену текущего периода времени с текущим первичным узлом на новый период времени с резервным узлом, являющимся новым первичным узлом.

[00148] В некоторых реализациях настоящего описания со ссылкой на Фиг. 9, сообщение EPOCH_CHANGE имеет формат <weight, epoch+1, ECHO{}, ACCEPT{}, j> где «weight» представляет сумму весов резервного узла 802, как определено ранее на этапе 810 для процесса консенсуса, «epoch+1» представляет раунд нового консенсуса (то есть нового периода времени), ассоциированного с новым первичным узлом, « ECHO {} »представляет набор сообщений ECHO, которые резервный узел 802 принимает во время второй фазы процесса консенсуса, «ACCEPT {}»представляет набор сообщений ACCEPT, которые резервный узел 802 принимает во время третьей фазы процесса консенсуса, и «j» представляет сетевой узел (например, резервный узел 802), который генерирует и отправляет сообщение EPOCH_CHANGE. В некоторых реализациях сообщение EPOCH_CHANGE может иметь другой формат, например, путем включения дополнительных или разных полей.

[00149] Возвращаясь к Фиг. 8, на этапе 814 сетевые узлы 804, отличные от резервного узла 802, проверяют сообщение EPOCH_CHANGE, которое отправлено резервным узлом 802. В некоторых реализациях каждый из сетевых узлов 804 проверяет, является ли сообщение EPOCH_CHANGE действительным, путем проверки, является ли сумма весов в сообщении EPOCH_CHANGE действительной. В некоторых реализациях проверка того, является ли сумма весов в сообщении EPOCH_CHANGE действительной, включает в себя проверку, является ли действительным набор подписей в сообщениях ECHO, включенных в сообщение EPOCH_CHANGE. Например, каждый из сетевых узлов 804 может аутентифицировать набор подписей закрытого ключа в сообщениях ECHO, включенных в сообщение EPOCH_CHANGE, с использованием открытого ключа.

[00150] На этапе 816 каждый из сетевых узлов 804 отправляет сообщение NEW_EPOCH в резервный узел 802 в ответ на проверку того, что сообщение EPOCH_CHANGE, отправленное резервным узлом 802, является действительным. Сообщение NEW_EPOCH указывает подтверждение резервного узла, чтобы быть новым первичным узлом. Например, сообщение NEW_EPOCH, отправленное сетевым узлом 804, включает в себя указание, что сетевой узел 804 подтверждает, что резервный узел 802 станет новым первичным узлом в новом периоде времени. Между тем каждый из сетевых узлов 804 также отправляет сообщение NEW_EPOCH другим сетевым узлам 804.

[00151] Ссылаясь на Фиг. 9, сообщение NEW_EPOCH генерируется как имеющее формат <epoch+1, i, j, seq, ec_digest> где «epoch+1» представляет раунд нового консенсуса (то есть новый периода времени), ассоциированного с новым первичным узлом, «i» представляет новый первичный узел в новом периоде времени, «j» представляет сетевой узел 804, который отправляет сообщение NEW_EPOCH, а «ec_digest» представляет дайджест сообщения EPOCH_CHANGE. В некоторых реализациях дайджест сообщения EPOCH_CHANGE включает в себя хэш–значение сообщения EPOCH_CHANGE. В некоторых реализациях сообщение NEW_EPOCH может иметь другой формат, например, путем включения дополнительных или разных полей.

[00152] Возвращаясь к Фиг. 8, на этапе 818 резервный узел 802 проверяет, являются ли сообщения NEW_EPOCH, отправленные сетевыми узлами 804, действительными. В некоторых реализациях резервный узел 802 проверяет сообщения NEW_EPOCH, проверяя, является ли дайджест сообщения EPOCH_CHANGE в сообщениях NEW_EPOCH действительным. Поскольку дайджест включает в себя информацию сообщения EPOCH_CHANGE, дайджест также включает в себя подписи в сообщении EPOCH_CHANGE. Резервный узел 802 может проверить дайджест сообщения EPOCH_CHANGE, проверив, действителен ли набор подписей в сообщении EPOCH_CHANGE.

[00153] На этапе 820 резервный узел 802 определяет, превышает ли количество действительных сообщений NEW_EPOCH, как определено на этапе 818, предопределенный порог. В некоторых реализациях предопределенный порог является количеством кворума (например, 2f+1).

[00154] На этапе 822 резервный узел 802 определяет резервный узел 802 как новый первичный узел в новый период времени в ответ на определение, что количество действительных сообщений NEW_EPOCH, как определено, превышает предопределенный порог. Следует отметить, что каждый из сетевых узлов 804 выполняет те же этапы 818–822, что и резервный узел 802, а сетевые узлы 804 и резервный узел 802 могут выполнять этапы 818–822 параллельно. Например, каждый из сетевых узлов 804 может проверять набор сообщений NEW_EPOCH, которые отправляются от других сетевых узлов 804, определять, превышает ли количество действительных сообщений NEW_EPOCH заранее определенный порог, и определять новый первичный узел.

[00155] Процесс изменения периода времени (например, процесс 700 или 800), как обсуждалось выше, включает в себя множество особенность, которые улучшают работу всей системы цепочек блоков и помогают устранить узкие места в сети. Например, процесс изменения периода времени в настоящем описании включает в себя назначение соответствующих весовых коэффициентов трем фазам процесса консенсуса, определение суммы весов на основе соответствующих весовых коэффициентов трех фаз и определение нового первичного узла на основе суммы весов. Процесс изменения периода времени, основанный на сумме весов, а не на способе циклического перебора, может способствовать своевременному выбору нового первичного узла, который не является неисправным. Способ циклического перебора может вызвать частую смену первичного узла, когда несколько сетевых узлов в линии для нового первичного узла неисправны. Это существенно влияет на службу цепочки блоков, вводя задержку или приостановку при поиске первичного узла, который не является неисправным. В отличие от способа циклического перебора, процесс изменения эпохи (периода времени) в настоящем описании основывается на сумме весов для выбора нового первичного узла, что может сократить время нахождения нового первичного узла, который не является неисправным. Это может еще больше повысить эффективность всей системы цепочек блоков в предоставлении услуг цепочек блоков.

[00156] Во время работы сети цепочек блоков скорость выполнения некоторых сетевых узлов может отставать от скорости большинства сетевых узлов из–за дрожания сети, внезапного сбоя питания, сбоя диска и тому подобного. В этом случае более 1/3 сетевых узлов в системе может выйти из строя. BFT обеспечивает безопасность и жизнеспособность, если в течение срока службы системы отказывает менее 1/3 сетевых узлов. Однако эти гарантии недостаточны для долгоживущих систем, поскольку верхняя граница, вероятно, будет превышена в сценарии, как описано выше. Следовательно, желателен процесс восстановления, который заставляет неисправные сетевые узлы снова вести себя корректно и продолжает участвовать в последующих согласованных процессах, чтобы позволить системе терпеть больше, чем f сбоев в течение своего срока службы. Кроме того, описанный процесс восстановления может восстанавливать один или несколько узлов сети, которые все еще выполняют процесс консенсуса (например, процесс 300 или 400 консенсуса), и не должны ждать, пока консенсус будет достигнут между всеми сетевыми узлами. Таким образом, описанный процесс восстановления может дополнительно уменьшить задержку системы и повысить эффективность сети цепочек блоков.

[00157] Фиг.10 изображает пример процесса 1000 для выполнения процесса восстановления сетевого узла (например, узла 214 или 404) распределенной системы (например, сети 102 и 212 цепочек блоков), который может быть выполнен в соответствии с реализациями настоящего описания. В частности, Фиг.10 иллюстрирует схему, представляющую примерный вариант осуществления способа 1000 выполнения процесса восстановления сетевого узла, в соответствии с настоящим описанием. Как показано на фиг. 10, процесс 1000 включает в себя несколько фаз и этапов.

[00158] На первой фазе 1010 сетевой узел (например, сетевой узел R0), который хотел бы восстановить целевую транзакцию с целевым порядковым номером R0, осуществляет многоадресную передачу сообщения запроса состояния (например, сообщения QUERY_STATE) другим узлам сети, указывающим, что сетевой узел должен быть восстановлен. Сообщение запроса состояния может включать в себя целевой порядковый номер, который сетевой узел R0 хотел бы восстановить. На второй фазе 1020 другие сетевые узлы принимают сообщение запроса состояния и отправляют сообщение ответа о состоянии (например, сообщение REPLY_STATE) на сетевой узел R0. На третьей фазе 1030 сетевой узел R0 отправляет запрашивающее сообщение (например, сообщение FETCH_ECHO) другим сетевым узлам, запрашивающее сообщение ECHO от каждого из других сетевых узлов. Сообщение ECHO может быть тем же сообщением ECHO, отправленным соответствующими другими сетевыми узлами во второй фазе 320 процесса 300 консенсуса, как описано выше со ссылкой на Фиг. 3–6. На четвертой фазе 1040 каждый из других сетевых узлов отправляет сообщение ECHO сетевому узлу R0 в ответ на сообщение FETCH_ECHO. На пятой фазе 1050 сетевой узел R0 проверяет сообщения ECHO и восстанавливает целевую транзакцию согласно коду EC, например, согласно примерным методам восстановления, как описано выше со ссылкой на Фиг. 4. На шестой фазе 1060 сетевой узел R0 отправляет сообщение ACCEPT другим сетевым узлам, указывающее, что сетевой узел был восстановлен.

[00159] Следует отметить, что процесс 1000 иллюстрируется как реализованный совместно с четырьмя сетевыми узлами только для иллюстративных целей. Процесс 1000 может быть реализован в сочетании с любым подходящим количеством сетевых узлов. Процесс 1000, формат сообщения QUERY_STATE и формат сообщения REPLY_STATE будут обсуждаться ниже более подробно со ссылкой на Фиг. 11–12.

[00160] Фиг.11 изображает пример процесса 1100 для выполнения процесса восстановления сетевого узла в распределенной системе (например, сети 102 или 212 цепочек блоков), который может быть выполнен в соответствии с реализациями настоящего описания. В некоторых реализациях процесс 1100 может выполняться с использованием одной или нескольких компьютерно–исполняемых программ, выполняемых с использованием одного или нескольких вычислительных устройств. Для ясности изложения последующее описание в общем описывает способ 1100 в контексте других фигур в этом описании. Понятно, что способ 1100 может быть выполнен, например, любой подходящей системой, средой, программным обеспечением и аппаратным обеспечением или комбинацией систем, сред, программного обеспечения и аппаратного обеспечения, в зависимости от ситуации. В некоторых реализациях различные этапы способа 1100 могут выполняться параллельно, в комбинации, в циклах или в любом порядке.

[00161] Процесс 1100 начинается на этапе 1106, где сетевой узел 1102 осуществляет многоадресную передачу сообщения запроса состояния другим сетевым узлам 1104. Сообщение запроса состояния включает в себя указание на то, что сетевой узел 1102 должен восстановить целевую транзакцию с целевым порядковым номером. Сетевой узел 1102 может быть первичным узлом или резервным узлом.

[00162] В некоторых реализациях настоящего описания со ссылкой на Фиг. 12, сообщение QUERY_STATE, как пример сообщения запроса состояния, имеет формат <j, seq> где «j» представляет сетевой узел 1102, который отправляет сообщение QUERY_STATE, а «seq» представляет наибольший порядковый номер или самый последний порядковый номер для сетевого узла 1102 в текущем процессе консенсуса. В некоторых реализациях сообщение QUERY_STATE может иметь другой формат, например, путем включения дополнительных или разных полей.

[00163] Посредством многоадресной передачи сообщения QUERY_STATE другим сетевым узлам 1104 сетевой узел 1102 запрашивает другие сетевые узлы 1104 отправить их самый последний порядковый номер сетевому узлу 1102, тем самым получая самую последнюю информацию о блоке системы цепочек блоков. А благодаря получению самой последней информации обо всей системе цепочек блоков, сетевой узел 1102 может быть в состоянии синхронизироваться с самым последним состоянием всей системы, восстанавливая тем самым себя и продолжая участвовать в процессе консенсуса.

[00164] Возвращаясь к Фиг. 11, на этапе 1108 каждый из других сетевых узлов 1104 отправляет сообщение ответа о состоянии (например, сообщение REPLY_STATE) в сетевой узел 1102 в ответ на получение сообщения запроса состояния. В некоторых реализациях сообщение ответа о состоянии включает в себя предыдущий порядковый номер, ассоциированный с сетевыми узлами 1104.

[00165] В некоторых реализациях, ссылаясь на Фиг. 12, сообщение REPLY_STATE, как пример сообщения воспроизведения состояния, имеет формат <j, last_seq> где «j» представляет сетевой узел 1104, который отправляет сообщение REPLY_STATE, а «last_seq» представляет предыдущий порядковый номер для сетевого узла 1104 в текущем процессе консенсуса. В некоторых реализациях сообщение REPLY_STATE может иметь другой формат, например, путем включения дополнительных или разных полей.

[00166] Возвращаясь к Фиг. 11, на этапе 1110 сетевой узел 1102 определяет, превышает ли количество принятых сообщений ответа о состоянии предопределенный порог. Например, сетевой узел 1102 может определить, превышает ли количество принятых сообщений REPLY_STATE количество кворума (например, 2f+1 или nf). В некоторых реализациях сетевой узел 1102 дополнительно определяет, включает ли в себя количество кворума принятых сообщений REPLY_STATE идентичный порядковый номер. То, что количество кворума принятых сообщений REPLY_STATE включает в себя идентичный порядковый номер, означает, что большинство сетевых узлов 1104 согласовывают общее состояние всей системы.

[00167] На этапе 1112 сетевой узел 1102 определяет целевой порядковый номер на основе идентичного порядкового номера, если сетевой узел 1102 определяет, что количество ответных сообщений о состоянии, включающих в себя идентичный порядковый номер, полученный от сетевых узлов 1104, превышает предопределенный порог. Например, сетевой узел 1102 может определять целевой порядковый номер как приращение (например, «last_seq+1») идентичного порядкового номера (например, «last_seq»).

[00168] На этапе 1114 сетевой узел 1102 отправляет запрашивающее сообщение (например, сообщение FETCH_ECHO) другим сетевым узлам 1104. Сообщение FETCH_ECHO отправляется сетевым узлом 1102 для запроса сообщения ECHO от каждого из других сетевых узлов 1104. Как обсуждалось выше со ссылкой на Фиг. 3–6, сообщение ECHO представляет собой сообщение, передаваемое сетевыми узлами 1104 для достижения консенсуса среди сетевых узлов 1104 по целевой транзакции. Сообщение ECHO включает в себя часть целевой транзакции (например, блок EC) и подпись сетевого узла 1104, который отправляет сообщение ECHO.

[00169] В некоторых реализациях, ссылаясь на Фиг. 12, сообщение FETCH_ECHO, как пример запрашивающего сообщения, имеет формат <j, last_seq+1> где «j» представляет сетевой узел 1102, который отправляет сообщение FETCH_ECHO, а «last_seq+1» представляет целевой порядковый номер, ассоциированный с сообщениями ECHO, которые сетевой узел 1102 запрашивает у других сетевых узлов 1104. В некоторых реализациях сообщение FETCH_ECHO может иметь другой формат, например, путем включения дополнительных или разных полей.

[00170] Сообщение FETCH_ECHO, как описано в данном документе, отправляется сетевым узлом 1102, чтобы запросить сообщения ECHO, включающие в себя самый последний порядковый номер или самый большой порядковый номер, от других сетевых узлов 1104. Собирая сообщения ECHO, включающие в себя самый последний порядковый номер или самый большой порядковый номер, от других сетевых узлов 1104, сетевой узел 1102 может быть в состоянии восстановить самое последнее состояние, ассоциированное с самым последним порядковым номером.

[00171] Возвращаясь к Фиг. 11, на этапе 1116 каждый из сетевых узлов 1104 отправляет сообщение ECHO сетевому узлу 1102 в ответ на прием сообщения FETCH_ECHO. В некоторых реализациях каждый из сетевых узлов 1104 проверяет сообщение FETCH_ECHO перед отправкой сообщения ECHO сетевому узлу 1102. В некоторых реализациях каждый из сетевых узлов 1104 проверяет сообщение FETCH_ECHO, определяя, превышает ли порядковый номер, включенный в сообщения FETCH_ECHO, самый последний порядковый номер, ассоциированный с сетевым узлом 1104. Если порядковый номер, включенный в сообщения FETCH_ECHO, равен самому последнему порядковому номеру, ассоциированному с сетевым узлом 1104, сетевой узел 1104 определяет, что сообщение FETCH_ECHO является действительным и что сообщение ECHO будет отправлено сетевому узлу 1102. Если порядковый номер, включенный в сообщения FETCH_ECHO, превышает самый последний порядковый номер, ассоциированный с сетевым узлом 1104, сетевой узел 1104 определяет, что сообщение FETCH_ECHO является недействительным и что сообщение ECHO не будет отправлено на сетевой узел 1102.

[00172] На этапе 1118 сетевой узел 1102 проверяет, являются ли сообщения ECHO, отправленные сетевыми узлами 1104, действительными. В некоторых реализациях сетевой узел 1102 проверяет сообщения ECHO, используя дерево Меркла. Например, сетевой узел 1102 может использовать данные, включенные в сообщение ECHO, для восстановления дерева Меркла и определения восстановленного корневого хэш–значения восстановленного дерева Меркла. Сетевой узел 1102 может затем сравнить восстановленное корневое хэш–значение с корневым хэш–значением, включенным в сообщение ECHO. Если восстановленное корневое хэш–значение совпадает с корневым хэш–значением, включенным в сообщение ECHO, сетевой узел 1102 определяет, что сообщение ECHO является действительным. Если восстановленное корневое хэш–значение не совпадает с корневым хэш–значением, включенным в сообщение ECHO, сетевой узел 1102 определяет, что сообщение ECHO является недействительным, и может отбрасывать недействительное сообщение ECHO.

[00173] В некоторых реализациях сетевой узел 1102 проверяет, является ли сообщение ECHO действительным, путем дополнительной проверки, является ли подпись в сообщении ECHO действительной. Например, сетевой узел 1102 может аутентифицировать подпись закрытого ключа в сообщении ECHO, используя открытый ключ в паре с закрытым ключом для проверки подписи.

[00174] На этапе 1120 сетевой узел 1102 определяет, превышает ли количество действительных сообщений ECHO, принятых от других сетевых узлов 1104, предопределенный порог. Например, сетевой узел 1102 может определять, превышает ли количество действительных сообщений ECHO, принятых от других сетевых узлов 1104, количество кворума (например, 2f+1).

[00175] На этапе 1122 сетевой узел 1102 восстанавливает целевую транзакцию с целевым порядковым номером в ответ на определение, что количество действительных сообщений ECHO превышает предопределенный порог. В некоторых реализациях сетевой узел 1102 восстанавливает целевую транзакцию, используя данные, включенные в количество действительных сообщений ECHO. Например, сетевой узел 1102 может извлекать поднабор блоков EC, включенных в сообщения ECHO, для восстановления целевой транзакции в соответствии с кодом EC.

[00176] На этапе 1124 сетевой узел 1102 многоадресно передает сообщение ACCEPT другим сетевым узлам 1104 после восстановления целевой транзакции. Например, сетевой узел 1102 может многоадресно передавать сообщение ACCEPT другим сетевым узлам 1104 после успешного восстановления целевой транзакции. В некоторых реализациях сообщение ACCEPT включает в себя набор подписей в сообщениях ECHO и целевой порядковый номер. Отправляя сообщение ACCEPT, включающее в себя подписи и целевой порядковый номер, в другие сетевые узлы 1104, сетевой узел 1102 указывает другим сетевым узлам 1104, что сетевой узел 1102 восстановлен и синхронизирован с самым последним состоянием системы.

[00177] Процесс восстановления, описанный выше в настоящем описании, включает в себя множество особенностей, которые улучшают работу компьютеров, которые реализуют процесс восстановления и помогают устранить узкие места в сети. Например, процесс восстановления в настоящем описании включает в себя операции, включающие в себя отправку сообщения запроса состояния сетевым узлом, который применяется как новый первичный узел, получение сообщений ответа о состоянии от других сетевых узлов и отправку сообщения FETCH_ECHO сетевым узлом, чтобы запрашивать сообщения ECHO от других сетевых узлов. Эти операции выполняются таким образом, что процесс восстановления неисправного сетевого узла не мешает нормальной работе процесса консенсуса среди других неисправных сетевых узлов. Это облегчает сохранение вычислительных и сетевых ресурсов для восстановления неисправного сетевого узла за счет снижения сложности процесса восстановления.

[00178] Ссылаясь на Фиг. 13, на Фиг.13 показана схема, иллюстрирующая модули аппаратуры 1300 консенсуса в соответствии с реализацией настоящего описания. Аппаратура 1300 для достижения консенсуса может быть применена к системе консенсуса, основанной на технологии (цепочек блоков). Например, аппаратура 1300 может соответствовать реализациям, показанным на Фиг. 1–6. Аппаратура 1300 может быть реализована в первичном узле в сети цепочек блоков. Аппаратура 1300 включает в себя следующее: приемник или приемный блок 1302, сконфигурированный для приема запроса транзакции; блок 1304 генерирования, сконфигурированный для генерации некоторого количества блоков кода стирания (EC) в соответствии с кодом EC с использованием запроса транзакции; передатчик или передающий блок 1306, сконфигурированный для отправки некоторого количества первых сообщений одному или нескольким резервным узлам соответственно, причем каждое из количества первых сообщений включает в себя составное хэш–значение, связанное с количеством блоков EC; приемник или приемный блок 1302, дополнительно сконфигурированный для приема по меньшей мере одного второго сообщения от по меньшей мере одного из резервных узлов, при этом по меньшей мере одно второе сообщение включает в себя одно из количества первых сообщений и подпись по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений; блок 1306 проверки, сконфигурированный для проверки, является ли по меньшей мере одно второе сообщение действительным в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного из резервных узлов; блок 1310 определения, сконфигурированный для определения, превышает ли количество действительных вторых сообщений предопределенный порог; блок 1312 восстановления, выполненный с возможностью восстановления запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; передатчик или передающий блок 1306, дополнительно сконфигурированный для отправки третьего сообщения другим сетевым узлам в ответ на определение, что запрос транзакции был успешно восстановлен, причем третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; приемник или приемный блок 1302, дополнительно сконфигурированный для приема по меньшей мере одного третьего сообщения от по меньшей мере одного из резервных узлов; и исполняющий модуль 1314, сконфигурированный для выполнения запроса транзакции в ответ на прием предопределенного количества третьих сообщений, которые являются идентичными.

[00179] В необязательной реализации запрос транзакции ассоциирован с порядковым номером.

[00180] В необязательной реализации генерирование множества блоков EC в соответствии с кодом EC включает в себя следующее: преобразование запроса транзакции в сообщение EC с использованием кода EC и деление сообщения EC на количество блоков EC.

[00181] В необязательной реализации составное хэш–значение упомянутого количества блоков EC генерируется с использованием хэш–дерева.

[00182] В необязательной реализации хэш–дерево включает в себя дерево Меркла, и при этом составное хэш–значение является корневым хэш–значением дерева Меркла.

[00183] В необязательной реализации подпись по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений, включает в себя подпись закрытого ключа по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений.

[00184] В необязательной реализации, по меньшей мере одно второе сообщение дополнительно включает в себя по меньшей мере один из количества блоков EC.

[00185] В необязательной реализации проверка действительности по меньшей мере одного второго сообщения включает в себя следующее: генерирование восстановленного хэш–дерева с использованием по меньшей мере одного из количества блоков EC в по меньшей мере одном втором сообщении; определение восстановленного составного хэш–значения восстановленного хэш–дерева; и определение, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями в по меньшей мере одном втором сообщении.

[00186] В необязательной реализации блок 1310 определения дополнительно сконфигурирован для определения, что по меньшей мере одно второе сообщение является действительным в ответ на определение, что восстановленное составное хэш–значение совпадает с составным хэш–значениями во вторых сообщениях.

[00187] В необязательной реализации предопределенное количество третьих сообщений, которые являются идентичными, включает в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[00188] Фиг. 13 является принципиальной схемой, иллюстрирующей внутренний функциональный модуль и структуру аппаратуры 1300 консенсуса. По существу, исполнительный орган может быть электронным устройством, и электронное устройство включает в себя следующее: по меньшей мере один процессор; и память, сконфигурированную для хранения исполняемой команды по меньшей мере одного процессора.

[00189] По меньшей мере один процессор сконфигурирован для приема запроса транзакции; генерирования некоторого количества блоков кода стирания (EC) в соответствии с кодом EC, используя запрос транзакции; отправки некоторого количества первых сообщений одному или нескольким резервным узлам соответственно, причем каждое из количества первых сообщений включает в себя составное хэш–значение, ассоциированное с количеством блоков EC; приема по меньшей мере одного второго сообщения по меньшей мере от одного из резервных узлов, причем по меньшей мере одно второе сообщение включает в себя одно из количества первых сообщений и подпись по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений; проверки, является ли по меньшей мере одно второе сообщение действительным в ответ на прием по меньшей мере одного второго сообщения по меньшей мере от одного резервного узла; определения, превышает ли количество действительных вторых сообщений предопределенный порог; восстановления запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; отправки третьего сообщения другим сетевым узлам сети в ответ на определение, что запрос транзакции был успешно восстановлен, причем третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; получения по крайней мере одного третьего сообщения от по меньшей мере одного из резервных узлов; и выполнения запроса транзакции в ответ на прием предопределенного количества третьих сообщений, которые являются идентичными.

[00190] Необязательно, запрос транзакции ассоциирован с порядковым номером.

[00191] Необязательно, генерирование множества блоков EC в соответствии с кодом EC включает в себя следующее: преобразование запроса транзакции в сообщение EC с использованием кода EC и деление сообщения EC на количество блоков EC.

[00192] Необязательно составное хэш–значение номера блока EC генерируется с использованием хэш–дерева.

[00193] Необязательно, хэш–дерево включает в себя дерево Меркла, и при этом составное хэш–значение является корневым хэш–значением дерева Меркла.

[00194] Необязательно, подпись по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений, включает в себя подпись закрытого ключа по меньшей мере одного из резервных узлов, ассоциированных с одним из количества первых сообщений.

[00195] Необязательно, по меньшей мере одно второе сообщение дополнительно включает в себя по меньшей мере один из количества блоков EC.

[00196] Необязательно, проверка, является ли по меньшей мере одно второе сообщение действительным, включает в себя следующее: генерирование восстановленного хэш–дерева с использованием по меньшей мере одного из количества блоков EC в по меньшей мере одном втором сообщении; определение восстановленного составного хэш–значения восстановленного хэш–дерева; и определение, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями по меньшей мере в одном втором сообщении.

[00197] Необязательно, по меньшей мере, один процессор дополнительно сконфигурирован для определения, что по меньшей мере одно второе сообщение является действительным в ответ на определение, что восстановленное составное хэш–значение совпадает с составными хэш–значениями во вторых сообщениях.

[00198] Необязательно, предопределенное количество третьих сообщений, которые являются идентичными, включают в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[00199] Ссылаясь на Фиг. 14, на Фиг.14 показана схема, иллюстрирующая модули аппаратуры 1400 консенсуса в соответствии с реализацией настоящего описания. Аппаратура 1400 для достижения консенсуса может быть применена к системе консенсуса, основанной на технологии цепочек блоков. Аппаратура 1400 может соответствовать реализациям, показанным на Фиг. 1–6. Например, аппаратура 1400 может быть реализована в резервном узле сети цепочек блоков. Аппаратура 1400 включает в себя следующее: приемник или приемный блок 1402, сконфигурированный для приема первого сообщения от первичного узла, причем первое сообщение включает в себя составное хэш–значение, ассоциированное с количеством блоков EC, при этом генерируется количество блоков EC первичным узлом в соответствии с кодом EC с использованием запроса транзакции; передатчик или передающий блок 1404, сконфигурированный для отправки резервным узлом второго сообщения другим узлам сети в ответ на прием первого сообщения, причем второе сообщение включает в себя первое сообщение и подпись резервного узла, ассоциированного с первым сообщением; приемник или приемный блок 1402, дополнительно сконфигурированный для приема по меньшей мере одного второго сообщения по меньшей мере от одного резервного узла, отличного от упомянутого резервного узла; блок 1406 проверки, сконфигурированный для проверки, является ли по меньшей мере одно второе сообщение действительным в ответ на прием по меньшей мере одного второго сообщения от по меньшей мере одного резервного узла; блок 1408 определения, сконфигурированный для определения, превышает ли количество действительных вторых сообщений предопределенный порог; блок 1410 восстановления, сконфигурированный для восстановления запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; передатчик или передающий блок 1404 , сконфигурированный для отправки третьего сообщения другим сетевым узлам в ответ на определение, что запрос транзакции был успешно восстановлен, при этом третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; приемник или приемный блок 1402, дополнительно сконфигурированный для приема по меньшей мере одного третьего сообщения по меньшей мере от одного из резервных узлов; и исполнительный блок 1412, сконфигурированный для выполнения запроса транзакции в ответ на прием предопределенного количества третьих сообщений, которые являются идентичными.

[00200] В необязательной реализации, генерирование множества блоков EC в соответствии с кодом EC включает в себя следующее: преобразование запроса транзакции в сообщение EC с использованием кода EC; и деление сообщения ЕС на количество блоков ЕС.

[00201] В необязательной реализации составное хэш–значение множества EC–блоков генерируется с использованием хэш–дерева.

[00202] В необязательной реализации, хэш–дерево включает в себя дерево Меркла, а составное хэш–значение является корневым хэш–значением дерева Меркла.

[00203] В необязательной реализации подпись резервного узла, ассоциированного с первым сообщением, включает в себя подпись закрытого ключа резервного узла, ассоциированного с первым сообщением.

[00204] В необязательной реализации, по меньшей мере, одно второе сообщение дополнительно включает в себя, по меньшей мере, один из количества блоков EC.

[00205] В необязательной реализации проверка действительности по меньшей мере одного второго сообщения включает в себя следующее: генерирование восстановленного хэш–дерева с использованием по меньшей мере одного из количества блоков EC в по меньшей мере одном втором сообщении; определение восстановленного составного хэш–значения восстановленного хэш–дерева; сравнение восстановленного составного хэш–значения с составным хэш–значением в по меньшей мере одном втором сообщении; и определение, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями, по меньшей мере, в одном втором сообщении.

[00206] В необязательной реализации блок 1408 определения дополнительно сконфигурирован для определения, что по меньшей мере одно второе сообщение является действительным в ответ на определение, что восстановленное составное хэш–значение совпадает с составными хэш–значениями во вторых сообщениях.

[00207] В необязательной реализации предопределенное количество третьих сообщений, которые являются идентичными, включает в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[00208] Фиг. 14 является принципиальной схемой, иллюстрирующей внутренний функциональный модуль и структуру аппаратуры 1400 консенсуса. По существу, исполнительный орган может быть электронным устройством, и электронное устройство включает в себя следующее: по меньшей мере, один процессор; и память, сконфигурированную для хранения исполняемой команды по меньшей мере одного процессора.

[00209] По меньшей мере один процессор сконфигурирован для приема первого сообщения от первичного узла, причем первое сообщение включает в себя составное хэш–значение, ассоциированное с количеством блоков EC, при этом количество блоков EC генерируется первичным узлом согласно коду EC с использованием запроса транзакции; отправки резервным узлом второго сообщения другим сетевым узлам в ответ на прием первого сообщения, причем второе сообщение включает в себя первое сообщение и подпись резервного узла, ассоциированного с первым сообщением; приема по меньшей мере одного второго сообщения по меньшей мере от одного резервного узла, отличного от упомянутого резервного узла; проверки, является ли по меньшей мере одно второе сообщение действительным в ответ на прием по меньшей мере одного второго сообщения по меньшей мере от одного резервного узла; определения, превышает ли количество действительных вторых сообщений предопределенный порог; восстановления запроса транзакции на основе поднабора из количества действительных вторых сообщений в соответствии с кодом EC в ответ на определение, что количество действительных вторых сообщений превышает предопределенный порог; отправки третьего сообщения другим узлам сети в ответ на определение, что запрос транзакции был успешно восстановлен, при этом третье сообщение включает в себя набор подписей, которые содержатся в действительных вторых сообщениях; приема по меньшей мере одного третьего сообщения по меньшей мере от одного из резервных узлов; и выполнения запроса транзакции в ответ на прием предопределенного количества третьих сообщений, которые являются идентичными.

[00210] Необязательно, генерирование множества блоков EC в соответствии с кодом EC включает в себя следующее: преобразование запроса транзакции в сообщение EC с использованием кода EC; и деление сообщения ЕС на количество блоков ЕС.

[00211] Необязательно, составное хэш–значение множества блоков EC генерируется с использованием хэш–дерева.

[00212] Необязательно, хэш–дерево включает в себя дерево Меркла, а составное хэш–значение является корневым хэш–значением дерева Меркла.

[00213] Необязательно, подпись резервного узла, ассоциированного с первым сообщением, включает в себя подпись закрытого ключа резервного узла, ассоциированного с первым сообщением.

[00214] Необязательно, по меньшей мере одно второе сообщение дополнительно включает в себя по меньшей мере один из количества блоков EC.

[00215] Необязательно, проверка того, является ли по меньшей мере одно второе сообщение действительным, включает в себя следующее: генерирование восстановленного хэш–дерева с использованием по меньшей мере одного из количества блоков EC в по меньшей мере одном втором сообщении; определение восстановленного составного хэш–значения восстановленного хэш–дерева; сравнение восстановленного составного хэш–значения с составным хэш–значением в по меньшей мере одном втором сообщении; и определение, совпадает ли восстановленное составное хэш–значение с составными хэш–значениями, по меньшей мере, в одном втором сообщении.

[00216] Необязательно, по меньшей мере один процессор дополнительно сконфигурирован для определения, что по меньшей мере одно второе сообщение является действительным в ответ на определение, что восстановленное составное хэш–значение совпадает с составными хэш–значениями во вторых сообщениях.

[00217] Необязательно, предопределенное количество третьих сообщений, которые являются идентичными, включает в себя предопределенное количество третьих сообщений, имеющих идентичный набор подписей.

[00218] На фиг. 15 показана схема, иллюстрирующая модули аппаратуры 1500 изменения первичного узла в соответствии с реализацией настоящего описания. Аппаратура 1500 для изменения первичного узла может быть применена к системе консенсуса на основании технологии цепочек блоков. Аппаратура 1500 может соответствовать реализациям, показанным на Фиг. 7–9. Например, аппаратура 1500 может быть реализована в резервном узле сети с цепочек блоков. Аппаратура 1500 включает в себя следующее: блок 1502 определения, сконфигурированный для определения, что изменение периода времени должно быть выполнено, причем изменение периода времени вызывает изменение от текущего периода времени с текущим первичным узлом к новому периоду времени с новым первичным узлом, при этом текущий период времени содержит процесс консенсуса для достижения консенсуса между упомянутым количеством узлов сети, использующих первичный узел, причем процесс консенсуса включает в себя три фазы: блок 1502 определения, дополнительно сконфигурирован для определения соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущий период времени, причем вес является метрикой квалификации резервного узла, чтобы быть новым первичным узлом; блок 1502 определения, дополнительно сконфигурирован для определения суммы весов для резервного узла на основе соответствующего веса резервного узла, ассоциированного с каждой из трех фаз в текущем периоде времени; передатчик или передающий блок 1504 , сконфигурированный для отправки сообщения EPOCH_CHANGE на количество сетевых узлов, отличных от сетевого узла, в ответ на определение, что сумма весов достигает первого предопределенного порогового значения, при этом сообщение EPOCH_CHANGE указывает запрос на изменение от текущего периода времени с текущим первичным узлом к новому периоду времени с резервным узлом, являющимся новым первичным узлом, и сообщение EPOCH_CHANGE включает в себя сумму весов резервного узла; приемник или приемный блок 1506, сконфигурированный для приема по меньшей мере одного сообщения NEW_EPOCH по меньшей мере от одного из количества сетевых узлов, отличных от резервного узла, причем сообщение NEW_EPOCH указывает подтверждение того, что резервный узел является новым первичным узлом; блок 1508 проверки, сконфигурированный для проверки, является ли по меньшей мере одно сообщение NEW_EPOCH действительным; блок 1502 определения дополнительно сконфигурирован для определения, превышает ли количество действительных сообщений NEW_EPOCH, из по меньшей мере одного сообщения NEW_EPOCH, второй предопределенный порог; и блок 1502 определения дополнительно сконфигурированный для определения резервного узла, который будет новым первичным узлом в новом периоде времени, в ответ на определение того, что количество действительных сообщений NEW_EPOCH превышает второй предопределенный порог.

[00219] В необязательной реализации определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя определение веса резервного узла для первой фазы процесса консенсуса, который должен быть первым значением.

[00220] В необязательной реализации определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя следующее: в ответ на определение сбоя проверки кворума во второй фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для второй фазы процесса консенсуса, чтобы быть первым значением; и в ответ на определение успеха проверки кворума на второй фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для второй фазы процесса консенсуса, чтобы быть вторым значением, причем первое значение меньше, чем второе значение.

[00221] В необязательной реализации проверка кворума на второй фазе для сетевого узла включает в себя прием предопределенного количества сообщений ECHO от других сетевых узлов.

[00222] В необязательной реализации определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя следующее: в ответ на определение сбоя проверки кворума в третьей фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для третьей фазы процесса консенсуса, чтобы быть третьим значением; и в ответ на определение успеха проверки кворума на третьей фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для третьей фазы процесса консенсуса, чтобы быть четвертым значением, причем третье значение меньше четвертого значения.

[00223] В необязательной реализации проверка кворума на третьей фазе для сетевого узла включает в себя прием предопределенного количества сообщений о принятии от других узлов сети, причем каждое из сообщений о принятии от других узлов сети указывает, что каждый из других сетевых узлов принял предопределенное количество сообщений ECHO.

[00224] В необязательной реализации сообщение EPOCH_CHANGE дополнительно включает в себя набор подписей, ассоциированных с набором сетевых узлов, из количества сетевых узлов, причем сообщение NEW_EPOCH содержит дайджест сообщения EPOCH_CHANGE.

[00225] В необязательной реализации проверка, является ли по меньшей мере одно действительное сообщение NEW_EPOCH действительным, включает в себя проверку, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действительным, и проверку, является ли дайджест сообщения EPOCH_CHANGE, по меньшей мере, одно сообщение NEW_EPOCH является действительным и включает в себя проверку действительности набора подписей в сообщении EPOCH_CHANGE.

[00226] В необязательной реализации определение, что изменение периода времени должно быть выполнено, включает в себя определение, что изменение периода времени необходимо выполнить в ответ на определение, что консенсус не был достигнут в старом периоду времени в течение предопределенного периода времени.

[00227] В необязательной реализации аппаратура 1500 изменения первичного узла дополнительно включает в себя следующее: операционный блок 1510, сконфигурированный для работы в новом периоде времени с новым первичным узлом, причем новый период времени содержит процесс консенсуса для достижения консенсуса среди множества сетевых узлов, использующих новый первичный узел.

[00228] Фиг. 15 является принципиальной схемой, иллюстрирующей внутренний функциональный модуль и структуру аппаратуры 1500 изменения первичного узла. По существу, исполнительный орган может быть электронным устройством, и при этом электронное устройство включает в себя следующее: по меньшей мере один процессор; и память, сконфигурированную для хранения исполняемой команды по меньшей мере одного процессора.

[00229] По меньшей мере один процессор сконфигурирован для определения, что изменение периода времени должно быть выполнено, причем изменение периода времени вызывает изменение от текущего периода времени с текущим первичным узлом к новому периоду времени с новым первичным узлом, где текущий период времени содержит процесс консенсуса для достижения консенсуса между количеством узлов сети, использующих первичный узел, процесс консенсуса включает в себя три фазы; определения соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, причем вес является метрикой квалификации резервного узла, чтобы быть новым основным узлом; определения суммы весов для резервного узла на основе соответствующего веса резервного узла, ассоциированного с каждой из трех фаз в текущем периоде времени; отправки сообщения EPOCH_CHANGE на количество сетевых узлов, отличных от сетевого узла, в ответ на определение, что сумма весов достигает первого предопределенного порога, при этом сообщение EPOCH_CHANGE указывает запрос на изменение текущего периода времени с текущим первичным узлом на новый период времени с резервным узлом, являющимся новым первичным узлом, и сообщение EPOCH_CHANGE включает в себя сумму весов резервного узла; приема по меньшей мере одного сообщения NEW_EPOCH по меньшей мере от одного из количества сетевых узлов, отличных от резервного узла, причем сообщение NEW_EPOCH указывает подтверждение того, что резервный узел является новым первичным узлом; проверки, является ли хотя бы одно сообщение NEW_EPOCH действительным; определения, превышает ли количество действительных сообщений NEW_EPOCH, из по меньшей мере одного сообщения NEW_EPOCH, второй предопределенный порог; и определения резервного узла, который будет новым первичным узлом в новый период времени, в ответ на определение, что количество действительных сообщений NEW_EPOCH превышает второй предопределенный порог.

[00230] Необязательно, определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя определение веса резервного узла для первой фазы процесса консенсуса, который должен быть первым значением.

[00231] Необязательно, определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя следующее: в ответ на определение сбоя проверки кворума во второй фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для второй фазы процесса консенсуса, чтобы быть первым значением; и в ответ на определение успеха проверки кворума на второй фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для второй фазы процесса консенсуса, чтобы быть вторым значением, причем первое значение меньше, чем второе значение.

[00232] Необязательно, проверка кворума на второй фазе для сетевого узла включает в себя прием предопределенного количества сообщений ECHO от других сетевых узлов.

[00233] Необязательно, определение соответствующего веса резервного узла, ассоциированного с каждой из трех фаз процесса консенсуса в текущем периоде времени, включает в себя следующее: в ответ на определение сбоя проверки кворума на третьей фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для третьей фазы процесса консенсуса, чтобы быть третьим значением; и в ответ на определение успеха проверки кворума на третьей фазе процесса консенсуса в текущем периоде времени, определение веса резервного узла для третьей фазы процесса консенсуса, чтобы быть четвертым значением, причем третье значение меньше четвертого значения.

[00234] Необязательно, проверка кворума на третьей фазе для сетевого узла включает в себя прием предопределенного количества сообщений о принятии от других сетевых узлов, причем каждое из сообщений о принятии от других сетевых узлов указывает, что каждый из других сетевых узлов принял предопределенное количество сообщений ECHO.

[00235] Необязательно, сообщение EPOCH_CHANGE дополнительно включает в себя набор подписей, ассоциированных с набором сетевых узлов, из количества сетевых узлов, причем сообщение NEW_EPOCH содержит дайджест сообщения EPOCH_CHANGE.

[00236] Необязательно, проверка того, является ли по меньшей мере одно действительное сообщение NEW_EPOCH действительным, включает в себя проверку, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действительным, и проверка, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действительным, включает в себя проверку действительности набора подписей в сообщении EPOCH_CHANGE.

[00237] Необязательно, определение того, что изменение периода времени должно быть выполнено, включает в себя определение, что изменение периода времени необходимо выполнить в ответ на определение, что консенсус не был достигнут в старом периоде времени в течение предопределенного периода времени.

[00238] Необязательно, по меньшей мере один процессор дополнительно сконфигурирован для работы в новом периоде времени с новым первичным узлом, причем новый период времени содержит процесс консенсуса для достижения консенсуса среди множества сетевых узлов, использующих новый первичный узел.

[00239] Ссылаясь на Фиг. 16, Фиг. 16 является схемой, иллюстрирующей модули аппаратуры 1600 изменения первичного узла, согласно реализации настоящего описания. Аппаратура 1600 для изменения первичного узла может быть применена к системе консенсуса, основанной на технологии цепочек блоков. Аппаратура 1600 соответствует реализациям, показанным на Фиг. 7–9. Например, аппаратура 1400 может быть реализована в сетевом узле сети цепочек блоков. Аппаратура 1600 включает в себя следующее: приемник или приемный блок 1602, сконфигурированный для приема сообщения EPCOH_CHANGE от резервного узла, отличного от сетевого узла, причем сообщение EPOCH_CHANGE включает в себя указание на то, что необходимо выполнить изменение периода времени, причем изменение периода времени вызывает изменение от текущего периода времени с текущим первичным узлом к новому периоду времени с новым первичным узлом; блок 1604 проверки, сконфигурированный для проверки, является ли сообщение EPOCH_CHANGE действительным; передатчик или передающий блок 1606, сконфигурированный для отправки сообщения NEW_EPOCH другим сетевым узлам в ответ на проверку, что сообщение EPOCH_CHANGE является действительным, при этом сообщение NEW_EPOCH содержит дайджест сообщения EPOCH_CHANGE; приемник или приемный блок 1602, дополнительно сконфигурированный для приема по меньшей мере одного сообщения NEW_EPOCH по меньшей мере от одного из количества сетевых узлов, отличных от упомянутого сетевого узла; блок 1604 проверки, дополнительно сконфигурированный для проверки, является ли по меньшей мере одно сообщение NEW_EPOCH действительным; блок 1608 определения, сконфигурированный для определения, превышает ли количество действительных сообщений NEW_EPOCH из, по меньшей мере, одного сообщения NEW_EPOCH предопределенный порог; и модуль 1608 определения, дополнительно сконфигурированный для определения резервного узла, который будет новым первичным узлом в новой периоду времени, в ответ на определение того, что количество действительных сообщений NEW_EPOCH превышает предопределенный порог.

[00240] В необязательной реализации сообщение EPOCH_CHANGE включает в себя сумму весов, связанную с резервным узлом, и набор подписей, ассоциированных с набором сетевых узлов, из количества сетевых узлов.

[00241] В необязательной реализации проверка, является ли сообщение EPOCH_CHANGE действительным, включает в себя проверку, является ли сумма весов в сообщении EPOCH_CHANGE действительной, и проверка, является ли сумма весов в сообщении EPOCH_CHANGE действительной, включает в себя проверку, является ли набор подписей действительными.

[00242] В необязательной реализации проверка того, является ли по меньшей мере одно сообщение NEW_EPOCH действительным, включает в себя проверку, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действтельным, и проверка, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действительным включает в себя проверку действительности набора подписей в сообщении EPOCH_CHANGE.

[00243] Фиг. 16 является принципиальной схемой, иллюстрирующей внутренний функциональный модуль и структуру аппаратуры 1600 изменения первичного узла. По существу, исполнительный орган может быть электронным устройством, и электронное устройство включает в себя следующее: по меньшей мере один процессор; и память, сконфигурированную для хранения исполняемой команды по меньшей мере одного процессора.

[00244] По меньшей мере один процессор сконфигурирован для приема сообщения EPCOH_CHANGE от резервного узла, отличного от сетевого узла, причем сообщение EPOCH_CHANGE включает в себя указание на то, что изменение периода времени необходимо выполнить, причем изменение периода времени вызывает изменение с текущего периода времени с текущим первичным узлом на новый период времени с новым первичным узлом; проверки, является ли сообщение EPOCH_CHANGE действительным; отправки сообщения NEW_EPOCH другим сетевым узлам в ответ на проверку того, что сообщение EPOCH_CHANGE является действительным, причем сообщение NEW_EPOCH содержит дайджест сообщения EPOCH_CHANGE; приема по меньшей мере одного сообщения NEW_EPOCH по меньшей мере от одного из количества сетевых узлов, отличных от сетевого узла; проверки, является ли хотя бы одно сообщение NEW_EPOCH действительным; определения, превышает ли количество действительных сообщений NEW_EPOCH из, по меньшей мере, одного сообщения NEW_EPOCH, предопределенный порог; и определения резервного узла, который будет новым первичным узлом в новом периоде времени, в ответ на определение, что количество действительных сообщений NEW_EPOCH превышает предопределенный порог.

[00245] Необязательно, сообщение EPOCH_CHANGE включает в себя сумму весов, ассоциированную с резервным узлом, и набор подписей, ассоциированных с набором сетевых узлов, из количества сетевых узлов.

[00246] Необязательно, проверка, является ли сообщение EPOCH_CHANGE действительным, включает в себя проверку, является ли сумма весов в сообщении EPOCH_CHANGE действительной, и проверка, является ли сумма весов в сообщении EPOCH_CHANGE действительной, включает в себя проверку, является ли набор подписей действительными.

[00247] Необязательно, проверка, является ли по меньшей мере одно сообщение NEW_EPOCH действительным, включает в себя проверку, является ли дайджест сообщения EPOCH_CHANGE по меньшей мере в одном сообщении NEW_EPOCH действительным, и проверка, является ли дайджест сообщения EPOCH_CHANGE в по меньшей мере одном сообщении NEW_EPOCH действительным, включает в себя проверку действительности набора подписей в сообщении EPOCH_CHANGE.

[00248] Ссылаясь на Фиг. 17, Фиг. 17 является схемой, иллюстрирующей модули аппаратуры 1700 восстановления в соответствии с реализацией настоящего описания. Аппаратура 1700 для восстановления может быть применена к системе консенсуса, основанной на технологии цепочек блоков. Аппаратура 1700 может соответствовать реализациям, показанным на Фиг. 10–12. Например, аппаратура 1700 может быть реализована в сетевом узле сети цепочек блоков. Аппаратура 1700 включает в себя следующее: блок 1702 многоадресной передачи, сконфигурированный для многоадресной передачи, сетевым узлом сети цепочек блоков, сообщения запроса о состоянии количества других сетевых узлов сети цепочек блоков, причем сетевой узел должен восстановить целевую транзакцию целевого порядкового номера; приемник 1704 или приемный блок 1704, сконфигурированный для приема некоторого количества сообщений ответа о состоянии от упомянутого количества других сетевых узлов, причем каждое из количества сообщений ответа о состоянии включает в себя порядковый номер; блок 1706 идентификации, сконфигурированный для идентификации целевого порядкового номера на основе того же порядкового номера в ответ на определение, что количество сообщений ответа о состоянии превышает предопределенный порог, причем каждое из количества сообщений о состоянии содержит один и тот же порядковый номер; передатчик 1708 или передающий блок 1708, сконфигурированный для отправки запрашивающего сообщения на количество других сетевых узлов, причем запрашивающее сообщение запрашивает сообщение ECHO от каждого из количества других сетевых узлов, причем сообщение ECHO представляет собой сообщение, переданное посредством каждого из количества других сетевых узлов для достижения консенсуса между упомянутым количеством других сетевых узлов в целевой транзакции, имеющей целевой порядковый номер, и сообщение ECHO включает в себя часть целевой транзакции и подпись каждого из количества других сетевых узлов; приемник 1704 или приемный блок 1704, дополнительно сконфигурированный для приема некоторого количества сообщений ECHO от упомянутого количества других сетевых узлов; блок 1710 определения, сконфигурированный для определения количества действительных сообщений ECHO из количества сообщений ECHO, при этом каждое из количества действительных сообщений ECHO включает в себя целевой порядковый номер; модуль 1712 восстановления, сконфигурированный для восстановления целевой транзакции, имеющей тот же порядковый номер в сетевом узле, на основе количества действительных сообщений ECHO в ответ на определение, что количество действительных сообщений ECHO превышает предопределенный порог; и передатчик 1708, дополнительно сконфигурированный для отправки сообщения на упомянутое количество других сетевых узлов, указывающего, что сетевой узел был восстановлен.

[00249] В необязательной реализации количество сетевых узлов включает в себя первичный узел и один или несколько резервных узлов.

[00250] В необязательной реализации сетевой узел является первичным или резервным узлом.

[00251] В необязательной реализации запрашивающее сообщение включает в себя целевой порядковый номер.

[00252] В необязательной реализации аппаратура 1700 восстановления дополнительно включает в себя следующее: блок 1714 проверки, сконфигурированный для проверки каждым из количества других сетевых узлов, отличных от сетевого узла, запрашивающего сообщения перед отправкой сообщений ECHO на сетевой узел,

[00253] В необязательной реализации блок 1714 проверки дополнительно сконфигурирован для проверки, является ли каждое из сообщений ECHO действительным, при этом проверка, является ли каждое из сообщений ECHO действительным, включает в себя проверку, является ли каждое из сообщений ECHO действительным с использованием дерева Меркла.

[00254] В необязательной реализации проверка, является ли каждое сообщение ECHO действительным, дополнительно включает в себя проверку, является ли подпись в сообщении ECHO действительной.

[00255] В необязательной реализации каждое из сообщений ECHO дополнительно включает в себя, по меньшей мере, один из нескольких блоков кода стирания (EC), ассоциированных с целевой транзакцией, причем количество блоков EC генерируется в соответствии с кодом EC с использованием целевой транзакции.

[00256] В необязательной реализации восстановление целевой транзакции, имеющей один и тот же порядковый номер в сетевом узле на основе количества действительных сообщений ECHO, содержит восстановление целевой транзакции с использованием поднабора из множества блоков EC, которые находятся в упомянутом количестве действительных сообщений ECHO.

[00257] В необязательной реализации сообщение для упомянутого количества других сетевых узлов, указывающее, что сетевой узел был восстановлен, включает в себя набор подписей в упомянутом количестве действительных сообщений ECHO и целевом порядковом номере.

[00258] Система, аппаратура, модуль или блок, проиллюстрированные в предыдущих реализациях, могут быть реализованы с использованием компьютерного чипа или объекта или могут быть реализованы с использованием продукта, имеющего некоторую функцию. Типичным устройством реализации является компьютер, и компьютер может представлять собой персональный компьютер, ноутбук, сотовый телефон, телефон с камерой, смартфон, персональный цифровой помощник, медиаплеер, навигационное устройство, устройство приема и отправки электронной почты, игровая приставка, планшетный компьютер, носимое устройство или любая комбинация этих устройств.

[00259] Для процесса реализации функций и ролей каждого блока в аппаратуре могут быть сделаны ссылки на процесс реализации соответствующих этапов в предыдущем способе. Детали опущены здесь для простоты.

[00260] Поскольку реализация аппаратуры в основном соответствует реализации способа, для связанных частей могут быть сделаны ссылки на связанные описания в реализации метода. Ранее описанная реализация аппаратуры является просто примером. Блоки, описанные как отдельные части, могут быть или не быть физически отдельными, и части, отображаемые как блоки, могут быть или не быть физическими единицами, могут быть расположены в одной позиции или могут быть распределены по множеству сетевых блоков. Некоторые или все модули могут быть выбраны на основе фактических требований для достижения целей решений настоящего описания. Специалист в данной области техники может понять и реализовать реализации настоящей заявки без творческих усилий.

[00261] Фиг. 17 является схематической диаграммой, иллюстрирующей внутренний функциональный модуль и структуру аппаратуры 1700 восстановления. По существу, исполнительный орган может быть электронным устройством, и электронное устройство включает в себя следующее: по меньшей мере, один процессор; и память, сконфигурированную для хранения исполняемой команды по меньшей мере одного процессора.

[00262] По меньшей мере один процессор сконфигурирован для многоадресной передачи, сетевым узлом сети цепочек блоков, сообщения запроса состояния некоторому количеству других сетевых узлов сети цепочек блоков, причем сетевой узел должен восстановить целевую транзакцию с целевым порядковым номером; принимать некоторое количество ответных сообщений о состоянии от упомянутого количества других сетевых узлов, причем каждое из количества ответных сообщений о состоянии включает в себя порядковый номер; идентифицировать целевой порядковый номер на основе того же порядкового номера в ответ на определение, что количество ответных сообщений о состоянии превышает предопределенный порог, причем каждое из количества сообщений о состоянии содержит один и тот же порядковый номер; отправлять запрашивающее сообщение на количество других сетевых узлов, причем запрашивающее сообщение запрашивает сообщение ECHO от каждого из количества других сетевых узлов, причем сообщение ECHO представляет собой сообщение, передаваемое каждым из упомянутого количества других сетевых узлов, для достижения консенсуса между количеством других сетевых узлов в целевой транзакции, имеющей целевой порядковый номер, и сообщение ECHO включает в себя часть целевой транзакции и подпись каждого из количества других сетевых узлов; принимать некоторое количество сообщений ECHO от множества других сетевых узлов; определять количество действительных сообщений ECHO из количества сообщений ECHO, при этом каждое из количества действительных сообщений ECHO включает в себя целевой порядковый номер; восстанавливать целевую транзакцию, имеющую тот же порядковый номер в сетевом узле, на основе количества действительных сообщений ECHO в ответ на определение, что количество действительных сообщений ECHO превышает предопределенный порог; и отправлять сообщение на количество других сетевых узлов, указывающее, что сетевой узел был восстановлен.

[00263] Необязательно, количество сетевых узлов включает в себя первичный узел и один или несколько резервных узлов.

[00264] Необязательно, сетевой узел является первичным или резервным узлом.

[00265] Необязательно, запрашивающее сообщение включает в себя целевой порядковый номер.

[00266] Необязательно, по меньшей мере один процессор дополнительно сконфигурирован для проверки каждым из количества других сетевых узлов, отличных от сетевого узла, запрашивающего сообщения перед отправкой сообщений ECHO на сетевой узел.

[00267] Необязательно, по меньшей мере один процессор дополнительно сконфигурирован для проверки, является ли каждое из сообщений ECHO действительным, при этом проверка, является ли каждое из сообщений ECHO действительным, включает в себя проверку того, является ли каждое из сообщений ECHO действительным, с использованием дерева Меркла.

[00268] Необязательно, проверка того, является ли каждое сообщение ECHO действительным, дополнительно включает в себя проверку, является ли подпись в сообщении ECHO действительной.

[00269] Необязательно, каждое из сообщений ECHO дополнительно включает в себя по меньшей мере один из нескольких блоков кода стирания (EC), ассоциированных с целевой транзакцией, причем количество блоков EC генерируется в соответствии с кодом EC с использованием целевой транзакции.

[00270] Необязательно, восстановление целевой транзакции, имеющей тот же порядковый номер в сетевом узле, на основе количества действительных сообщений ECHO, включает в себя восстановление целевой транзакции с использованием поднабора из количества блоков EC, которые находятся в упомянутом количестве действительных сообщений ECHO.

[00271] Необязательно, сообщение для упомянутого количества других сетевых узлов, указывающее, что сетевой узел был восстановлен, включает в себя набор подписей в упомянутом количестве действительных сообщений ECHO и целевой порядковый номер.

[00272] Реализации сущности изобретения и действий и операций, описанных в этом описании, могут быть реализованы в цифровых электронных схемах, в материально–воплощенном компьютерном программном обеспечении или встроенном программном обеспечении, в компьютерном оборудовании, включая структуры, раскрытые в этом описании, и их структурные эквиваленты или в комбинациях одного или нескольких из них. Реализации сущности изобретения, описанной в этом описании, могут быть реализованы в виде одной или нескольких компьютерных программ, например, одного или нескольких модулей инструкций компьютерной программы, закодированных на носителе компьютерной программы, для выполнения или для управления аппаратурой обработки данных. Носителем может быть материальный невременный компьютерный носитель данных. Альтернативно или в дополнение, носитель может быть искусственно сгенерированным распространяемым сигналом, например, сгенерированным машиной электрическим, оптическим или электромагнитным сигналом, который генерируется для кодирования информации для передачи в подходящее приемное устройство для исполнения аппаратурой обработки данных. Компьютерный носитель данных может быть или быть частью машиночитаемого запоминающего устройства, машиночитаемой подложкой запоминающего устройства, устройством памяти с произвольным или последовательным доступом или комбинацией одного или нескольких из них. Носитель данных компьютера не является распространяемым сигналом.

[00273] Термин «аппаратура обработки данных» охватывает все виды аппаратур, устройств и машин для обработки данных, включая, например, программируемый процессор, компьютер или несколько процессоров или компьютеров. Аппаратура обработки данных может включать в себя логические схемы специального назначения, например, FPGA (программируемая пользователем вентильная матрица), ASIC (специализированная интегральная схема) или GPU (графический процессор). Аппаратура может также включать в себя, помимо аппаратного обеспечения, код, который создает среду выполнения для компьютерных программ, например код, который составляет микропрограммное обеспечение процессора, стек протоколов, систему управления базой данных, операционную систему или комбинацию одного или нескольких из их.

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

[00275] Компьютерная программа может, но не обязательно, соответствовать файлу в файловой системе. Компьютерная программа может храниться в части файла, которая содержит другие программы или данные, например, в одном или нескольких сценариях, хранящихся в документе на языке разметки, в одном файле, выделенном для рассматриваемой программы, или в нескольких скоординированных файлах, например файлах, в которых хранится один или несколько модулей, подпрограмм или частей кода.

[00276] Процессы и логические потоки, описанные в этой спецификации, могут выполняться одним или несколькими компьютерами, выполняющими одну или несколько компьютерных программ для выполнения операций, работая с входными данными и генерируя выходные данные. Процессы и логические потоки также могут выполняться с помощью логических схем специального назначения, например FPGA, ASIC или GPU, или с помощью комбинации логических схем специального назначения и одного или нескольких программируемых компьютеров.

[00277] Компьютеры, подходящие для выполнения компьютерной программы, могут быть основаны на общих или специализированных микропроцессорах или на тех и других, или на любом другом типе центрального процессора. Как правило, центральный процессор будет получать инструкции и данные из постоянной памяти или из оперативной памяти или из той и другой. Элементы компьютера могут включать в себя центральный процессор для выполнения инструкций и одно или несколько запоминающих устройств для хранения инструкций и данных. Центральный процессор и память могут быть добавлены или включены в логические схемы специального назначения.

[00278] Как правило, компьютер будет подключен по меньшей мере к одному постоянному машиночитаемому носителю информации (также называемому машиночитаемым запоминающим устройством). Носитель данных, подключенный к компьютеру, может быть внутренним компонентом компьютера (например, встроенным жестким диском) или внешним компонентом (например, жестким диском с универсальной последовательной шиной (USB) или системой хранения, доступ к которой осуществляется через сеть). Примерами носителей данных могут быть, например, магнитные, магнитооптические или оптические диски, твердотельные накопители, сетевые ресурсы хранения, такие как облачные системы хранения, или другие типы носителей данных. Однако компьютеру не нужно иметь такие устройства. Кроме того, компьютер может быть встроен в другое устройство, например мобильный телефон, персональный цифровой помощник (PDA), мобильный аудио– или видеоплеер, игровую приставку, приемник глобальной системы позиционирования (GPS) или портативное запоминающее устройство, например, флэш–накопитель с универсальной последовательной шиной (USB), и это лишь некоторые из них.

[00279] Чтобы обеспечить взаимодействие с пользователем, реализации сущности изобретения, описанного в этом описании, могут быть реализованы или сконфигурированы для связи с компьютером, имеющим устройство отображения, например монитор ЖК (жидкокристаллический дисплей), для отображения информации для пользователь и устройство ввода, с помощью которого пользователь может обеспечить ввод в компьютер, например клавиатуру и указательное устройство, например мышь, трекбол или панель касания. Другие виды устройств также могут быть использованы для обеспечения взаимодействия с пользователем. Например, обратная связь, предоставляемая пользователю, может быть любой формой сенсорной обратной связи, например, визуальной обратной связью, слуховой обратной связью или тактильной обратной связью, и ввод от пользователя может быть получен в любой форме, включая акустический, речевой или тактильный ввод. Кроме того, компьютер может взаимодействовать с пользователем, отправляя документы и принимая документы с устройства, которое используется пользователем, например, путем отправки веб–страниц в веб–браузер на устройстве пользователя в ответ на запросы, принятые из веб–браузера, или путем взаимодействия с приложением, запущенным на пользовательском устройстве, например смартфоном или электронным планшетом. Кроме того, компьютер может взаимодействовать с пользователем, отправляя текстовые сообщения или другие формы сообщений на персональное устройство, например смартфон, на котором запущено приложение обмена сообщениями, и принимая ответные сообщения от пользователя в ответ.

[00280] В данном описании используется термин «сконфигурированный для» в связи с системами, аппаратурой и компонентами компьютерной программы. Для системы из одного или нескольких компьютеров, которая должна быть сконфигурирована для выполнения конкретных операций или действий, это означает, что система установила на него программное обеспечение, встроенное программное обеспечение, аппаратное обеспечение или их комбинацию, которые при работе заставляют систему выполнять операции или действия. Для одной или нескольких компьютерных программ, которые должны быть сконфигурированы для выполнения определенных операций или действий, это означает, что одна или несколько программ включают в себя инструкции, которые при выполнении аппаратурой обработки данных заставляют аппаратуру выполнять операции или действия. Если логические схемы специального назначения должны быть сконфигурированы для выполнения конкретных операций или действий, это означает, что схема имеет электронную логику, которая выполняет операции или действия.

[00281] Хотя это описание содержит много конкретных деталей реализации, их не следует истолковывать как ограничения объема заявленной сущности изобретения, который определяется самими пунктами формулы изобретения, а скорее как описания особенностей, которые могут быть специфическими для конкретных реализаций. Некоторые особенности, которые описаны в этом описании в контексте отдельных реализаций, также могут быть реализованы в комбинации в одной реализации. И наоборот, различные особенности, которые описаны в контексте отдельных реализаций, также могут быть реализованы в множественных реализациях отдельно или в любой подходящей субкомбинации. Более того, хотя особенности могут быть описаны выше как действующие в некоторых комбинациях и даже первоначально заявлены как таковые, одна или несколько особенностей из заявленной комбинации могут в некоторых случаях быть исключены из комбинации, и формула может быть направлена на субкомбинацию или вариацию субкомбинации.

[00282] Аналогично, хотя операции изображены на чертежах и изложены в формуле изобретения в конкретном порядке, это не следует понимать как требование, чтобы такие операции выполнялись в конкретном показанном порядке или в последовательном порядке, или чтобы выполнялись все проиллюстрированные операции, чтобы достичь желаемых результатов. В некоторых обстоятельствах многозадачность и параллельная обработка могут быть выгодными. Кроме того, разделение различных системных модулей и компонентов в реализациях, описанных выше, не следует понимать как требующее такого разделения во всех реализациях, и следует понимать, что описанные программные компоненты и системы обычно могут быть объединены вместе в одном программном продукте или упакованы в несколько программных продуктов.

[00283] Конкретные реализации сущности изобретения были описаны. Другие реализации находятся в пределах объема следующей формулы изобретения. Например, действия, изложенные в формуле изобретения, могут выполняться в другом порядке и при этом достигать желаемых результатов. В качестве одного примера, процессы, изображенные на прилагаемых фигурах, не обязательно требуют определенного показанного порядка или последовательного порядка для достижения желаемых результатов. В некоторых случаях многозадачность и параллельная обработка могут быть полезными.


ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
ДОСТИЖЕНИЕ КОНСЕНУСА МЕЖДУ СЕТЕВЫВЫМИ УЗЛАМИ В РАСПРЕДЕЛЕННОЙ СИСТЕМЕ
Источник поступления информации: Роспатент

Всего документов: 65
Всего документов: 4

Похожие РИД в системе



Похожие не найдены