RU2776826C2 - Способы и устройство для распределенной базы данных, которая позволяет удалять события - Google Patents

Abstract

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

Description

Перекрестная ссылка на родственные заявки на патенты

[1001] Настоящая заявка на патент испрашивает приоритет предварительной заявки на патент США № 62/436066, поданной 19 декабря 2016 г., под названием «METHODS AND APPARATUS FOR A DISTRIBUTED DATABASE THAT ENABLES DELETION OF EVENTS», которая включена в настоящий документ посредством ссылки во всей своей полноте.

Предпосылки изобретения

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

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

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

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

[1006] Другие распределенные базы данных спроектированы без наличия лидера, но являются неэффективными. Например, одна такая распределенная база данных основана на структуре данных «цепочка блоков», которая может достигать консенсуса. Однако такая система может быть ограничена малым количеством транзакций в секунду для всех участников вместе взятых (например, 7 транзакций в секунду), что недостаточно для крупномасштабной игры или для многих традиционных приложений баз данных. Кроме того, увеличение масштаба базы данных с течением времени может увеличить использование вычислительных ресурсов, например, ресурсы памяти могут стать неуправляемыми и/или недоиспользуемыми, когда в них хранят излишние или ненужные данные. Соответственно, существует необходимость в системе распределенной базы данных, которая достигает консенсуса без лидера, и которая эффективна в управлении вычислительными ресурсами.

Сущность изобретения

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

Краткое описание графических материалов

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

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

[1010] На фиг. 3–6 проиллюстрированы примеры хешграфа согласно варианту осуществления.

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

[1012] На фиг. 8 представлен пример хешграфа согласно варианту осуществления.

[1013] На фиг. 9 представлен пример хешграфа согласно варианту осуществления.

[1014] На фиг. 10A–10B проиллюстрирован примерный способ консенсуса для использования с хешграфом согласно варианту осуществления.

[1015] На фиг. 11A–11B проиллюстрирован примерный способ консенсуса для использования с хешграфом согласно варианту осуществления.

[1016] На фиг. 12A–12B проиллюстрирован примерный способ консенсуса для использования с хешграфом согласно другому варианту осуществления.

[1017] На фиг. 13 представлено изображение начального состояния распределенной базы данных согласно варианту осуществления.

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

[1019] На фиг. 15 представлена блок-схема, на которой проиллюстрированы принятие и отклонение событий на основе принятых раундов согласно варианту осуществления.

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

Подробное описание изобретения

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

[1022] В некоторых вариантах осуществления устройство содержит память, связанную с экземпляром распределенной базы данных на вычислительном устройстве, приспособленном для включения в группу вычислительных устройств, которые реализуют распределенную базу данных посредством сети, функционально соединенной с группой вычислительных устройств. Группа вычислительных устройств связана с первой конфигурацией протокола консенсуса событий, связанного с распределенной базой данных. Устройство содержит процессор, функционально соединенный с памятью. Процессор приспособлен для приема набора событий с набора вычислительных устройств из группы вычислительных устройств. Каждое событие из набора событий связано с (1) набором транзакций и (2) номером принятого раунда. Процессор приспособлен для определения порядка для каждого события из набора событий на основе: (1) первой конфигурации протокола консенсуса событий, когда номер принятого раунда, связанный с тем событием, не превышает порог номера принятого раунда, идентифицированный экземпляром распределенной базы данных, и (2) второй конфигурации протокола консенсуса событий, когда номер принятого раунда, связанный с тем событием, превышает порог номера принятого раунда. Процессор приспособлен для определения текущего состояния экземпляра распределенной базы данных на основе порядка, определенного для каждого события из набора событий. Процессор приспособлен для генерирования подписанного состояния, связанного с экземпляром распределенной базы данных на основе значения хеша, связанного с текущим состоянием. Значение хеша подписывают с помощью цифровой подписи с использованием закрытого ключа, связанного с первым вычислительным устройством. Процессор дополнительно приспособлен для отправки сигнала для внесения в экземпляр распределенной базы данных события, которое содержит транзакцию, указывающую на подписанное состояние.

[1023] В некоторых вариантах осуществления устройство содержит память, связанную с экземпляром распределенной базы данных на первом вычислительном устройстве, приспособленном для включения в группу вычислительных устройств, которые реализуют распределенную базу данных посредством сети, функционально соединенной с группой вычислительных устройств. Устройство содержит процессор, функционально соединенный с памятью. Процессор приспособлен для приема события со второго вычислительного устройства из группы вычислительных устройств. Событие представляет собой последовательность байтов, связанную с набором событий-родителей. Каждое событие-родитель из набора событий-родителей связано со (1) значением хеша и (2) значением созданного раунда. Процессор приспособлен для исключения принятого события из определения порядка событий, когда по меньшей мере один из первого критерия или второго критерия удовлетворен. Первый критерий удовлетворен, когда: (1) по меньшей мере одно событие-родитель из набора событий-родителей не имеет идентификатора в экземпляре распределенной базы данных, и (2) по меньшей мере одно событие-родитель связано со значением созданного раунда, которое превышает первый порог созданного раунда. Второй критерий удовлетворен, когда: (1) первый критерий не удовлетворен, и (2) каждое событие-родитель из набора событий-родителей связано со значением созданного раунда, которое меньше, чем второй порог созданного раунда. Процессор дополнительно приспособлен для сохранения события в экземпляре распределенной базы данных, когда событие не было исключено на основе первых критериев или вторых критериев.

[1024] В некоторых вариантах осуществления устройство содержит память, связанную с экземпляром распределенной базы данных на первом вычислительном устройстве, приспособленном для включения в группу вычислительных устройств, которые реализуют распределенную базу данных посредством сети, функционально соединенной с группой вычислительных устройств. Устройство содержит процессор, функционально соединенный с памятью. Процессор приспособлен для сохранения в памяти указания о первом наборе событий из группы событий, определенных вторым вычислительным устройством из группы вычислительных устройств. Каждое событие из группы событий содержит последовательность байтов, связанную с (1) порядковым значением и (2) упорядоченным набором транзакций. Процессор приспособлен для отправки запроса синхронизации на третье вычислительное устройство из множества вычислительных устройств. Запрос синхронизации содержит первый идентификатор и второй идентификатор. Первый идентификатор идентифицирует событие из первого набора событий, связанных с порядковым значением, которое меньше, чем порядковое значение, связанное с каждым из остальных событий из первого набора событий. Второй идентификатор идентифицирует событие из первого набора событий, связанных с порядковым значением, которое превышает порядковое значение, связанное с каждым из остальных событий из первого набора событий. Процессор приспособлен для приема с третьего вычислительного устройства в ответ на запрос синхронизации второго набора событий из группы событий, определенных вторым вычислительным устройством. Процессор приспособлен для сохранения в памяти указания о втором наборе событий. Каждое событие из второго набора событий не включено в первый набор событий. Процессор приспособлен для определения текущего состояния экземпляра распределенной базы данных на основе (1) протокола консенсуса событий, (2) первого набора событий и (3) второго набора событий. Процессор приспособлен для генерирования подписанного состояния экземпляра распределенной базы данных на основе значения хеша, связанного с текущим состоянием. Значение хеша подписывают с помощью цифровой подписи с использованием закрытого ключа, связанного с первым вычислительным устройством. Процессор приспособлен для отправки сигнала для внесения в экземпляр распределенной базы данных события, которое содержит транзакцию, указывающую на подписанное состояние. Процессор приспособлен для приема с набора вычислительных устройств из группы вычислительных устройств указания о согласии, которое связано с событием, которое содержит транзакцию, указывающую на подписанное состояние. Процессор дополнительно приспособлен для удаления из памяти, и на основе указания о согласии, указания о первом наборе событий и указания о втором наборе событий.

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

[1026] В некоторых случаях каждое событие из третьего набора событий связано с набором атрибутов (например, порядковый номер, номер поколения, номер раунда, принятый номер и/или метка времени и т.д.). Результат протокола может содержать значение для каждого атрибута из набора атрибутов для каждого события из третьего набора событий. Значение для первого атрибута из набора атрибутов может включать первое числовое значение, и значение для второго атрибута из набора атрибутов может включать двоичное значение, связанное с первым числовым значением. Двоичное значение для второго атрибута (например, значение приращения раунда) для события из третьего набора событий может быть основано на том, соответствует ли взаимосвязь между тем событием и четвертым набором событий, привязанным к тому событию, критерию (например, количеству событий, строго идентифицированных тем событием). Каждое событие из четвертого набора событий (1) является предком события из третьего набора событий и (2) связано с первым общим атрибутом, как и остальные события из четвертого набора событий (например, общим номером раунда, указанием о том, что представляет собой первое событие раунда R, и т.д.). Первый общий атрибут может являться указанием о первом случае, в котором событие, определенное каждым вычислительным устройством из набора вычислительных устройств, связано с первым конкретным значением (например, указанием о том, что представляет собой первое событие раунда R, и т.д.).

[1027] Значение для третьего атрибута (например, номера принятого раунда) из набора атрибутов может включать второе числовое значение, основанное на взаимосвязи между событием и пятым набором событий, привязанным к событию. Каждое событие из пятого набора событий является потомком события и связано со вторым общим атрибутом (например, является известным), как и остальные события из пятого набора событий. Второй общий атрибут может быть связан с (1) третьим общим атрибутом (например, указанием о том, что представляет собой первое событие раунда R или свидетеля), который является указанием о первом случае, в котором второе событие, определенное каждым вычислительным устройством из набора вычислительных устройств, связано со вторым конкретным значением, отличным от первого конкретного значения, и (2) результатом, основанным на наборе указаний. Каждое указание из набора указаний может быть связано с событием из шестого набора событий. Каждое событие из шестого набора событий может быть связано с четвертым общим атрибутом, который является указанием о первом случае, в котором третье событие, определенное каждым вычислительным устройством из набора вычислительных устройств, связано с третьим конкретным значением, отличным от первого конкретного значения и второго конкретного значения. В некоторых случаях первое конкретное значение является первым целым числом (например, первым номером раунда R), второе конкретное значение является вторым целым числом (например, вторым номером раунда, R+n), превышающим первое целое число, и третье конкретное значение является третьим целым числом (например, третьим номером раунда, R+n+m), превышающим второе целое число.

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

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

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

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

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

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

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

[1035] На фиг. 1 представлена структурная схема высокого уровня, на которой проиллюстрирована система 100 распределенной базы данных согласно варианту осуществления. На фиг. 1 проиллюстрирована распределенная база 100 данных, реализованная на четырех вычислительных устройствах (вычислительное устройство 110, вычислительное устройство 120, вычислительное устройство 130 и вычислительное устройство 140), но следует понимать, что распределенная база 100 данных может использовать набор из любого количества вычислительных устройств, содержащий вычислительные устройства, не показанные на фиг. 1. Сеть 105 может представлять собой сеть любого типа (например, локальную вычислительную сеть (LAN), глобальную вычислительную сеть (WAN), виртуальную сеть, телекоммуникационную сеть), реализованную в виде проводной сети и/или беспроводной сети и используемую для функционального соединения вычислительных устройств 110, 120, 130, 140. Как более подробно описано в настоящем документе, в некоторых вариантах осуществления, например, вычислительные устройства представляют собой персональные компьютеры, соединенные друг с другом посредством поставщика услуг Интернет (ISP) и Интернета (например, сети 105). В некоторых вариантах осуществления соединение может быть установлено посредством сети 105 между любыми двумя вычислительными устройствами 110, 120, 130, 140. Как показано на фиг. 1, например, соединение может быть установлено между вычислительным устройством 110 и любым из вычислительного устройства 120, вычислительного устройства 130 или вычислительного устройства 140.

[1036] В некоторых вариантах осуществления вычислительные устройства 110, 120, 130, 140 могут осуществлять связь друг с другом (например, отправлять данные на и/или принимать данные с) и с сетью посредством промежуточных сетей и/или альтернативных сетей (не показаны на фиг. 1). Такие промежуточные сети и/или альтернативные сети могут принадлежать к тому же типу и/или другому типу сети в сравнении с сетью 105.

[1037] Каждое вычислительное устройство 110, 120, 130, 140 может представлять собой устройство любого типа, приспособленное для отправки данных по сети 105, чтобы отправлять и/или принимать данные с одного или более других вычислительных устройств. Примеры вычислительных устройств показаны на фиг. 1. Вычислительное устройство 110 содержит память 112, процессор 111 и устройство 113 вывода. Память 112 может представлять собой, например, оперативное запоминающее устройство (RAM), буфер памяти, жесткий диск, базу данных, стираемое программируемое постоянное запоминающее устройство (EPROM), электрически стираемое постоянное запоминающее устройство (EEPROM), постоянное запоминающее устройство (ROM) и/или т.д. В некоторых вариантах осуществления память 112 вычислительного устройства 110 содержит данные, связанные с экземпляром распределенной базы данных (например, экземпляром 114 распределенной базы данных). В некоторых вариантах осуществления память 112 хранит инструкции, приводящие к исполнению процессором модулей, процессов и/или функций, связанных с отправкой на другой экземпляр и/или приемом с другого экземпляра распределенной базы данных (например, экземпляра 124 распределенной базы данных на вычислительном устройстве 120) записи события синхронизации, записи предыдущих событий синхронизации с другими вычислительными устройствами, порядка событий синхронизации, порядка транзакций в событиях, параметров, связанных с идентификацией порядка событий синхронизации и/или транзакций, значения для параметра (например, поля базы данных, количественно характеризующего транзакцию, поля базы данных, количественно характеризующего порядок, в котором происходят события, и/или любого другого подходящего поля, для которого значение может быть сохранено в базе данных).

[1038] Экземпляр 114 распределенной базы данных может, например, быть приспособлен для проведений операций с данными, включая сохранение, модификацию и/или удаление данных. В некоторых вариантах осуществления экземпляр 114 распределенной базы данных может представлять собой реляционную базу данных, объектную базу данных, постреляционную базу данных и/или базу данных или хранилище любого другого подходящего типа. Например, экземпляр 114 распределенной базы данных может хранить данные, относящиеся к любой конкретной функции и/или области. Например, экземпляр 114 распределенной базы данных может хранить финансовые транзакции (например, пользователя вычислительного устройства 110), включая значение и/или вектор значений, относящиеся к истории владения конкретным финансовым инструментом. В целом, вектор может представлять собой любой набор значений для параметра, и параметр может представлять собой любые объект данных и/или поле базы данных, которые могут принимать разные значения. Таким образом, экземпляр 114 распределенной базы данных может иметь ряд параметров и/или полей, каждое из которых связано с вектором значений. Вектор значений используется для определения фактического значения для параметра и/или поля в том экземпляре 114 базы данных. В некоторых случаях экземпляр 114 распределенной базы данных хранит запись события синхронизации, запись предыдущих событий синхронизации с другими вычислительными устройствами, порядок событий синхронизации, порядок транзакций в событиях, параметры и/или значения, связанные с идентификацией порядка событий синхронизации и/или транзакций (например, используемые при вычислении порядка с использованием способа консенсуса, как описано в настоящем документе), значение для параметра (например, поле базы данных, количественно характеризующее транзакцию, поле базы данных, количественно характеризующее порядок, в котором происходят события, и/или любое другое подходящее поле, для которого значение может быть сохранено в базе данных).

[1039] В некоторых случаях экземпляр 114 распределенной базы данных может также хранить переменную состояния базы данных и/или текущее состояние. Текущим состоянием могут быть состояние, баланс, условие и/или т.п., связанные с результатом транзакций. Подобным образом, состояние может включать структуру данных и/или переменные, модифицированные транзакциями. В других случаях текущее состояние можно хранить в отдельной базе данных и/или части памяти 112. В еще других случаях текущее состояние можно хранить в памяти вычислительного устройства, отличного от вычислительного устройства 110.

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

[1041] В некоторых случаях в систему 100 распределенной базы данных или в любой из экземпляров 114, 124, 134, 144 распределенной базы данных может быть отправлен запрос. Например, запрос может состоять из ключа, и результат, возвращаемый системой 100 распределенной базы данных или экземплярами 114, 124, 134, 144 распределенной базы данных, может представлять собой значение, связанное с ключом. В некоторых случаях система 100 распределенной базы данных или любой из экземпляров 114, 124, 134, 144 распределенной базы данных могут быть также модифицированы посредством транзакции. Например, транзакция для модификации базы данных может содержать цифровую подпись, выполненную стороной, авторизирующей транзакцию модификации.

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

[1043] В другом примере экземпляр 114 распределенной базы данных может хранить данные, относящиеся к массовым многопользовательским играм (MMG), такие как текущий статус и принадлежность игровых предметов. В некоторых случаях экземпляр 114 распределенной базы данных может быть реализован в вычислительном устройстве 110, как показано на фиг. 1. В других случаях вычислительное устройство может иметь доступ к экземпляру распределенной базы данных (например, по сети), но он не реализован в вычислительном устройстве (не показано на фиг. 1).

[1044] Процессор 111 вычислительного устройства 110 может представлять собой любое подходящее устройство обработки, приспособленное для запуска и/или исполнения экземпляра 114 распределенной базы данных. Например, процессор 111 может быть приспособлен для обновления экземпляра 114 распределенной базы данных в ответ на прием сигнала с вычислительного устройства 120 и/или вызова отправки сигнала на вычислительное устройство 120, как более подробно описано в настоящем документе. Более конкретно, как более подробно описано в настоящем документе, процессор 111 может быть приспособлен для исполнения модулей, функций и/или процессов для обновления экземпляра 114 распределенной базы данных в ответ на прием события синхронизации, связанного с транзакцией, с другого вычислительного устройства, записи, связанной с порядком событий синхронизации, и/или т.п. В других вариантах осуществления процессор 111 может быть приспособлен для исполнения модулей, функций и/или процессов для обновления экземпляра 114 распределенной базы данных в ответ на прием значения для параметра, сохраненного в другом экземпляре распределенной базы данных (например, экземпляре 124 распределенной базы данных на вычислительном устройстве 120), и/или вызова отправки значения для параметра, сохраненного в экземпляре 114 распределенной базы данных на вычислительном устройстве 110, на вычислительное устройство 120. В некоторых вариантах осуществления процессор 111 может представлять собой процессор общего назначения, программируемую пользователем вентильную матрицу (FPGA), интегральную схему специального назначения (ASIC), процессор цифровой обработки сигналов (DSP) и/или т.п.

[1045] Дисплей 113 может представлять собой любой подходящий дисплей, такой как, например, жидкокристаллический дисплей (LCD), дисплей на электронно-лучевой трубке (CRT) или т.п. В других вариантах осуществления любое из вычислительных устройств 110, 120, 130, 140 содержит другое устройство вывода вместо дисплеев 113, 123, 133, 143 или в дополнение к ним. Например, любое из вычислительных устройств 110, 120, 130, 140 может содержать звуковое устройство вывода (например, динамик), тактильное устройство вывода и/или т.п. В еще одних вариантах осуществления любое из вычислительных устройств 110, 120, 130, 140 содержит устройство ввода вместо дисплеев 113, 123, 133, 143 или в дополнение к ним. Например, любое из вычислительных устройств 110, 120, 130, 140 может содержать клавиатуру, мышь и/или т.п.

[1046] Вычислительное устройство 120 имеет процессор 121, память 122 и дисплей 123, которые могут быть конструктивно и/или функционально подобны процессору 111, памяти 112 и дисплею 113 соответственно. Также экземпляр 124 распределенной базы данных может быть структурно и/или функционально подобен экземпляру 114 распределенной базы данных.

[1047] Вычислительное устройство 130 имеет процессор 131, память 132 и дисплей 133, которые могут быть конструктивно и/или функционально подобны процессору 111, памяти 112 и дисплею 113 соответственно. Также экземпляр 134 распределенной базы данных может быть структурно и/или функционально подобен экземпляру 114 распределенной базы данных.

[1048] Вычислительное устройство 140 имеет процессор 141, память 142 и дисплей 143, которые могут быть конструктивно и/или функционально подобны процессору 111, памяти 112 и дисплею 113 соответственно. Также экземпляр 144 распределенной базы данных может быть структурно и/или функционально подобен экземпляру 114 распределенной базы данных.

[1049] Хотя вычислительные устройства 110, 120, 130, 140 показаны как подобные друг другу, каждое вычислительное устройство системы 100 распределенной базы данных может отличаться от других вычислительных устройств. Каждое вычислительное устройство 110, 120, 130, 140 системы 100 распределенной базы данных может представлять собой любое из, например, вычислительного элемента (например, персонального вычислительного устройства, такого как настольный компьютер, портативный компьютер и т.д.), мобильного телефона, карманного персонального компьютера (PDA) и т.д. Например, вычислительное устройство 110 может представлять собой настольный компьютер, вычислительное устройство 120 может представлять собой смартфон, и вычислительное устройство 130 может представлять собой сервер.

[1050] В некоторых вариантах осуществления одна или более частей вычислительных устройств 110, 120, 130, 140 могут включать аппаратный модуль (например, процессор цифровой обработки сигналов (DSP), программируемую пользователем вентильную матрицу (FPGA)) и/или программный модуль (например, модуль компьютерного кода, хранящегося в памяти и/или исполняемого на процессоре). В некоторых вариантах осуществления одна или более функций, связанных с вычислительными устройствами 110, 120, 130, 140 (например, функции, связанные с процессорами 111, 121, 131, 141), могут быть включены в один или более модулей (см., например, фиг. 2).

[1051] Свойства системы 100 распределенной базы данных, включая свойства вычислительных устройств (например, вычислительных устройств 110, 120, 130, 140), количество вычислительных устройств, и сеть 105 могут быть выбраны любыми способами. В некоторых случаях свойства системы 100 распределенной базы данных могут быть выбраны администратором системы 100 распределенной базы данных. В других случаях свойства системы 100 распределенной базы данных могут быть совместно выбраны пользователями системы 100 распределенной базы данных.

[1052] Поскольку используется система 100 распределенной базы данных, среди вычислительных устройств 110, 120, 130 и 140 не назначен лидер. В частности, ни одно из вычислительных устройств 110, 120, 130 или 140 не идентифицируется и/или не выбирается в качестве лидера для разрешения конфликтов между значениями, хранящимися в экземплярах 111, 12, 131, 141 распределенной базы данных вычислительных устройств 110, 120, 130, 140. Вместо этого, с использованием процессов синхронизации событий, процессов голосования и/или способов, описанных в настоящем документе, вычислительные устройства 110, 120, 130, 140 могут совместно согласовывать значение для параметра.

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

[1054] На фиг. 2 проиллюстрировано вычислительное устройство 200 системы распределенной базы данных (например, системы 100 распределенной базы данных) согласно варианту осуществления. В некоторых вариантах осуществления вычислительное устройство 200 может быть подобным вычислительным устройствам 110, 120, 130, 140, показанным и описанным в отношении фиг. 1. Вычислительное устройство 200 содержит процессор 210 и память 220. Процессор 210 и память 220 функционально соединены друг с другом. В некоторых вариантах осуществления процессор 210 и память 220 могут быть подобными процессору 111 и памяти 112 соответственно, подробно описанным в отношении фиг. 1. Как показано на фиг. 2, процессор 210 содержит модуль 211 конвергенции базы данных и модуль 210 связи, и память 220 содержит экземпляр 221 распределенной базы данных. Модуль 212 связи позволяет вычислительному устройству 200 осуществлять связь с другими вычислительными устройствами (например, отправлять данные на них и/или принимать данные с них). В некоторых вариантах осуществления модуль 212 связи (не показан на фиг. 1) позволяет вычислительному устройству 110 осуществлять связь с вычислительными устройствами 120, 130, 140. Модуль 210 связи может содержать и/или обеспечивать, например, контроллер сетевого интерфейса (NIC), беспроводное соединение, проводной порт и/или т.п. По существу, модуль 210 связи может устанавливать и/или поддерживать сеанс связи между вычислительным устройством 200 и другим устройством (например, посредством сети, такой как сеть 105, представленная на фиг. 1, или Интернет (не показано)). Подобным образом модуль 210 связи может позволять вычислительному устройству 200 отправлять данные на другое устройство и/или принимать данные с него.

[1055] В некоторых случаях модуль 211 конвергенции базы данных может обмениваться событиями и/или транзакциями с другими вычислительными устройствами, сохранять события и/или транзакции, которые принимает модуль 211 конвергенции базы данных, и вычислять упорядоченную последовательность событий и/или транзакций на основе частичного порядка, определенного схемой ссылок между событиями. Каждое событие может представлять собой запись, содержащую криптографический хеш двух более ранних событий (привязывающий то событие к двум более ранним событиями и их событиям-предкам и наоборот), данные полезной нагрузки (такие как транзакции, которые должны быть записаны), другую информацию, такую как текущее время, метка времени (например, дата и время по UTC), которую утвердил ее создатель, представляющая время, в которое событие было впервые определено, и/или т.п. В некоторых случаях первое событие, определенное участником, содержит хеш только одного события, определенного другим участником. В таких случаях участник еще не имеет предыдущего собственного хеша (например, хеша события, ранее определенного тем участником). В некоторых случаях первое событие в распределенной базе данных не содержит хеша никакого предыдущего события (поскольку отсутствует предыдущее событие для той распределенной базы данных).

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

[1057] В некоторых случаях набор событий и их взаимосвязей может формировать направленный ациклический граф (DAG). В некоторых случаях каждое событие в DAG ссылается на два более ранних события (привязывая то событие к двум более ранним событиям и их событиям-предкам и наоборот), и каждая ссылка осуществляется строго на более ранние события, так что циклов нет. В некоторых вариантах осуществления DAG основан на криптографических хешах, так что структура данных может называться хешграфом (также называется в настоящем документе «DAG на основе хешей»). Хешграф непосредственно кодирует частичный порядок, обозначая, что известно, что событие X происходит до события Y, если Y содержит хеш X, или если Y содержит хеш события, которое содержит хеш X, или для таких путей произвольной длины. Однако, если путь от X к Y или от Y к X отсутствует, то частичный порядок не определяет, какое событие произошло первым. Следовательно, модуль конвергенции базы данных может вычислять общий порядок из частичного порядка. Это может быть выполнено с помощью любой подходящей детерминированной функции, которая используется вычислительными устройствами, так что вычислительные устройства вычисляют один и тот же порядок. В некоторых вариантах осуществления каждый участник может повторно вычислять этот порядок после каждой синхронизации, и в итоге эти порядки могут сходиться таким образом, что возникает консенсус.

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

[1059] В некоторых случаях модуль конвергенции базы данных может использовать следующую функцию для вычисления общего порядка из частичного порядка в хешграфе. Для каждого из других вычислительных устройств (называемых «участниками») модуль конвергенции базы данных может изучать хешграф для установления порядка, в котором события (и/или указания о тех событиях) были приняты тем участником. Модуль конвергенции базы данных может затем выполнять вычисления таким образом, словно тот участник присвоил числовой «ранг» каждому событию, при этом ранг равен 1 для первого события, которое принял участник, 2 для второго события, которое принял участник, и так далее. Модуль конвергенции базы данных может выполнять это для каждого участника в хешграфе. Затем для каждого события модуль конвергенции базы данных может вычислять медиану присвоенных рангов и может сортировать события по их медианам. Сортировка может разрушать равенства детерминированным образом, например, сортируя два равных события по числовому порядку их хешей или некоторым другим способом, в котором модуль конвергенции базы данных каждого участника использует одинаковый способ. Результатом этой сортировки является общий порядок.

[1060] На фиг. 6 проиллюстрирован хешграф 640 одного примера для определения общего порядка. Хешграф 640 иллюстрирует два события (самый нижний круг с полосками и самый нижний круг с точками) и первый момент времени, когда каждый участник принимает указание на те события (остальные круги с полосками и точками). Имя каждого участника в верхней части окрашено согласно тому, какое событие является первым в их медленном порядке. Первоначальных голосов с полосками больше, чем с точками; следовательно, голоса консенсуса для каждого из участников имеют вид с полосками. Другими словами, участники в итоге приходят к согласию, что событие с полосками произошло до события с точками.

[1061] В этом примере участники (вычислительные устройства, обозначенные как Алиса, Боб, Кэрол, Дэйв и Эд) будут работать таким образом, чтобы достичь консенсуса относительно того, произошло ли первым событие 642 или событие 644. Каждый круг с полосками указывает на событие, когда участник впервые принял событие 644 (и/или указание о том событии 644). Подобным образом каждый круг с точками указывает на событие, когда участник впервые принял событие 642 (и/или указание о том событии 642). Как показано в хешграфе 640, каждый из Алисы, Боба и Кэрол принял событие 644 (и/или указание о событии 644) до события 642. Как Дэйв, так и Эд приняли событие 642 (и/или указание о событии 642) до события 644 (и/или указания о событии 644). Таким образом, поскольку большее количество участников приняли событие 644 до события 642, общий порядок может быть определен каждым участником для указания того, что событие 644 произошло до события 642.

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

[1063] В этом варианте осуществления fast(x,y) дает положение y в общем порядке событий по мнению creator(x) по существу сразу после создания и/или определения x. Если Q равно бесконечности, то вышеописанное вычисляет такой же общий порядок, как получается и в ранее описанном варианте осуществления. Если Q является конечным числом и все участники находятся в режиме онлайн, то вышеописанное вычисляет такой же общий порядок, как получается и в ранее описанном варианте осуществления. Если Q является конечным числом и меньшая часть участников находится в режиме онлайн в заданный момент времени, то эта функция позволяет находящимся онлайн участникам достигать консенсуса между собой, который будет сохраняться неизменным по мере постепенного, поочередного перехода в режим онлайн новых участников. Однако, если речь идет о разделе сети, то участники каждого раздела могут прийти к своему собственному консенсусу. Затем, когда раздел заполняется, участники меньшего раздела примут консенсус большего раздела.

[1064] В еще других случаях, как описано в отношении фиг. 8–12B, модуль конвергенции базы данных может использовать еще другую функцию для вычисления общего порядка из частичного порядка в хешграфе. Как показано на фиг. 8–9, каждый участник (Алиса, Боб, Кэрол, Дэйв и Эд) создает и/или определяет события (1401–1413, как показано на фиг. 8; 1501–1506, показанные на фиг. 9). При использовании функции и подфункций, описанных в отношении фиг. 8–12B, общий порядок для событий может быть вычислен посредством сортировки событий по их принятому раунду, с разрушением равенств по их принятой метке времени и разрушением тех равенств по их подписям, как более подробно описано в настоящем документе. В других случаях общий порядок для событий может быть вычислен посредством сортировки событий по их принятому раунду, с разрушением равенств по их принятому поколению (вместо их принятой метки времени) и с разрушением тех равенств по их подписям. В следующих абзацах подробно изложены функции, используемые для вычисления и/или определения принятого раунда и принятого поколения события для определения порядка для событий. Следующие термины используются и иллюстрируются в связи с фиг. 8–12B.

[1065] «Родитель» («Parent»): событие X является родителем события Y, если Y содержит хеш X. Например, на фиг. 8 родители события 1412 включают событие 1406 и событие 1408.

[1066] «Предок» («Ancestor»): предками события X являются X, его родители, родители его родителей и так далее. Например, как показано на фиг. 8, предками события 1412 являются события 1401, 1402, 1403, 1406, 1408 и 1412. Можно сказать, что предки события привязаны к тому событию и наоборот.

[1067] «Потомок» («Descendant»): потомками события X являются X, его дети, дети его детей и так далее. Например, как показано на фиг. 8, потомком события 1401 является каждое событие, показанное на фигуре. В качестве другого примера, потомками события 1403 являются события 1403, 1404, 1406, 1407, 1409, 1410, 1411, 1412 и 1413. Можно сказать, что потомки события привязаны к тому событию и наоборот.

[1068] «N»: общее количество участников в популяции. Например, как показано на фиг. 8, участники представляют собой вычислительные устройства, обозначенные как Алиса, Боб, Кэрол, Дэйв и Эд, и N равняется пяти.

[1069] «M»: наименьшее целое число, которое превышает определенную процентную долю N (например, превышает 2/3 от N). Например, как показано на фиг. 8, если процентная доля определена как 2/3, то M равняется четырем. В других случаях M может быть определено, например, как другая процентная доля N (например, 1/3, 1/2 и т.д.), конкретное предварительно определенное число и/или любым другим подходящим способом.

[1070] «Собственный родитель» («Self-parent»): собственным родителем события X является его событие-родитель Y, созданное и/или определенное тем же участником. Например, как показано на фиг. 8, собственным родителем события 1405 является 1401.

[1071] «Собственный предок» («Self-ancestor»): собственными предками события X являются X, его собственный родитель, собственный родитель его собственного родителя и так далее.

[1072] «Порядковый номер» («Sequence Number», или «SN») (также упоминаемый в настоящем документе как порядковое значение): целочисленный атрибут события, определенный как порядковый номер собственного родителя события плюс один. Например, как показано на фиг. 8, собственным родителем события 1405 является 1401. Поскольку порядковый номер события 1401 равен одному, порядковый номер события 1405 равен двум (т.е. один плюс один). В некоторых реализациях в начале нового раунда порядковые номера перезапускают или обнуляют. В других случаях порядковый номер и/или порядковое значение могут декрементировать, а не инкрементировать, могут быть алфавитно-цифровым показателем с лексикографическим порядком (например, A, B, C и т.д.) и/или т.п.

[1073] «Номер поколения» («Generation Number», или «GN»): целочисленный атрибут события, определенный как максимальное значение номеров поколений родителей события плюс один. Например, как показано на фиг. 8, событие 1412 имеет двух родителей, события 1406 и 1408, имеющих номера поколений четыре и два соответственно. Таким образом, номер поколения события 1412 равен пяти (т.е. четыре плюс один).

[1074] «Приращение раунда» («Round Increment», или «RI»): атрибут события, который может равняться либо нулю, либо единице.

[1075] «Номер раунда» («Round Number», или «RN», также упоминаемый в настоящем документе как «созданный раунд» («round created»)): целочисленный атрибут события. В некоторых случаях номер раунда может быть определен как максимальное значение номеров раундов родителей события плюс приращение раунда события. Например, как показано на фиг. 8, событие 1412 имеет двух родителей, события 1406 и 1408, которые оба имеют номер раунда, равный одному. Событие 1412 также имеет приращение раунда, равное одному. Таким образом, номер раунда события 1412 равняется двум (т.е. один плюс один). В других случаях событие может иметь номер раунда R, если R является минимальным целым числом, так что событие может строго видеть (как описано в настоящем документе) по меньшей мере M событий, определенных и/или созданных разными участниками, которые все имеют номер раунда R-1. Если такое целое число отсутствует, номер раунда для события может быть значением по умолчанию (например, 0, 1 и т.д.). В таких случаях номер раунда для события может быть вычислен без использования приращения раунда. Например, как показано на фиг. 8, если M определено как наименьшее целое число, превышающее N в 1/2 раза, то M равняется трем. Тогда событие 1412 строго видит M событий 1401, 1402 и 1408, каждое из которых было определено отличным участником и имеет номер раунда, равный 1. Событие 1412 не может строго видеть по меньшей мере M событий с номером раунда, равным 2, которые были определены отличными участниками. Следовательно, номер раунда для события 1412 равняется 2. В некоторых случаях первое событие в распределенной базе данных имеет номер раунда, равный 1. В других случаях первое событие в распределенной базе данных может иметь номер раунда, равный 0, или любой другой подходящий номер.

[1076] «Ответвление» («Forking»): событие X вместе с событием Y являются ответвлением, если они определены и/или созданы одним участником, и ни одно из них не является собственным предком другого. Например, как показано на фиг. 9, участник Дэйв создает ответвление, создавая и/или определяя события 1503 и 1504, оба из которых имеют одного собственного родителя (т.е. событие 1501), так что событие 1503 не является собственным предком события 1504, и событие 1504 не является собственным предком события 1503.

[1077] «Идентификация» («Identification») ответвления: ответвление может быть «идентифицировано» третьим событием, созданным и/или определенным после двух событий, которые вместе являются ответвлениями, если оба те два события являются предками третьего события. Например, как показано на фиг. 9, участник Дэйв создает ответвление, создавая события 1503 и 1504, ни одно из которых не является собственным предком другого. Это ответвление может быть идентифицировано более поздним событием 1506, поскольку оба события 1503 и 1504 являются предками события 1506. В некоторых случаях идентификация ответвления может указывать на то, что конкретный участник (например, Дэйв) мошенничает.

[1078] «Идентификация» («Identification») события: событие X «идентифицирует» или «видит» событие-предка Y, если X не имеет события-предка Z, которое является ответвлением вместе с Y. Например, как показано на фиг. 8, событие 1412 идентифицирует (то есть «видит») событие 1403, поскольку событие 1403 является предком события 1412, и событие 1412 не имеет событий-предков, которые являются ответвлениями вместе с событием 1403. В некоторых случаях событие X может идентифицировать событие Y, если X не идентифицирует ответвление до события Y. В таких случаях, даже если событие X идентифицирует ответвление, создаваемое участником, определяющим событие Y, после события Y, событие X может видеть событие Y. Событие X не идентифицирует события того участника после ответвления. Более того, если участник определяет два разных события, которые оба являются первыми событиями того участника в истории, событие X может идентифицировать ответвление и не идентифицировать никакое событие того участника.

[1079] «Строгая идентификация» («Strong identification», также называемая в настоящем документе «strongly seeing» или «строгое видение») события: событие X «строго идентифицирует» (или «строго видит») событие-предка Y, созданное и/или определенное тем же участником, что и X, если X идентифицирует Y. Событие X «строго идентифицирует» событие-предка Y, которое не было создано и/или определено тем же участником, что и X, если существует набор S событий, которые (1) включают как X, так и Y, и (2) являются предками события X, и (3) являются потомками события-предка Y, и (4) идентифицируются X, и (5) каждое из которых может идентифицировать Y, и которые (6) созданы и/или определены по меньшей мере M разными участниками. Например, как показано на фиг. 8, если M определено как наименьшее целое число, которое превышает 2/3 от N (т.е. M=1+floor(2N/3), что будет равно четырем в этом примере), то событие 1412 строго идентифицирует событие-предка 1401, поскольку набор событий 1401, 1402, 1406 и 1412 представляет собой набор из по меньшей мере четырех событий, которые являются предками события 1412 и потомками события 1401, и они созданы и/или определены четырьмя участниками Дэйвом, Кэрол, Бобом и Эдом соответственно, и событие 1412 идентифицирует каждое из событий 1401, 1402, 1406 и 1412, и каждое из событий 1401, 1402, 1406 и 1412 идентифицирует событие 1401. Подобным образом, событие X (например, событие 1412) может «строго видеть» событие Y (например, событие 1401), если X может видеть по меньшей мере M событий (например, события 1401, 1402, 1406 и 1412), созданных или определенных разными участниками, каждый из которых может видеть Y.

[1080] «Первое событие раунда R» (также называемое в настоящем документе «свидетелем», или «witness»): событие представляет собой «первое событие раунда R» (или «свидетеля»), если событие (1) имеет номер раунда R и (2) имеет собственного родителя, имеющего номер раунда, который меньше R, или не имеет собственного родителя. Например, как показано на фиг. 8, событие 1412 представляет собой «первое событие раунда 2», поскольку оно имеет номер раунда, равный двум, и его собственным родителем является событие 1408, которое имеет номер раунда, равный одному (т.е. меньше двух).

[1081] В некоторых случаях приращение раунда для события X определяют как 1, если и только если X «строго идентифицирует» по меньшей мере M «первых событий раунда R», где R является максимальным номером раунда его родителей. Например, как показано на фиг. 8, если M определено как наименьшее целое число, превышающее N в 1/2 раза, то M равняется трем. Тогда событие 1412 строго идентифицирует M событий 1401, 1402 и 1408, которые все являются первыми событиями раунда 1. Оба родителя события 1412 принадлежат к раунду 1, и 1412 строго идентифицирует по меньшей мере M первых событий раунда 1, следовательно, приращение раунда для 1412 равно одному. Каждое из событий на схеме с отметкой «RI=0» не может строго идентифицировать по меньшей мере M первых событий раунда 1, следовательно, их приращения раунда равны 0.

[1082] В некоторых случаях следующий способ может быть использован для определения того, может ли событие X строго идентифицировать событие-предка Y. Для каждого первого события-предка Y раунда R поддерживается массив A1 целых чисел, по одному на участника, который задает наименьший порядковый номер события X, где тот участник создал и/или определил событие X, и X может идентифицировать Y. Для каждого события Z поддерживается массив A2 целых чисел, по одному на участника, который задает наибольший порядковый номер события W, созданного и/или определенного тем участником, так что Z может идентифицировать W. Для определения того, может ли Z строго идентифицировать событие-предка Y, подсчитывается количество таких положений E элемента, что A1[E] <= A2[E]. Событие Z может строго идентифицировать Y, если и только если эта подсчитанная величина превышает M. Например, как показано на фиг. 8, участники Алиса, Боб, Кэрол, Дэйв и Эд каждый могут идентифицировать событие 1401, при этом самым ранним событием, которое может это сделать, является их событие {1404, 1403, 1402, 1401, 1408} соответственно. Эти события имеют порядковые номера A1={1,1,1,1,1}. Подобным образом, самым поздним событием каждого из них, которое идентифицируется событием 1412, является событие {ОТСУТСТВУЕТ, 1406, 1402, 1401, 1412}, где у Алисы указано «ОТСУТСТВУЕТ», поскольку 1412 не может идентифицировать ни одно из событий Алисы. Эти события имеют порядковые номера A2={0,2,1,1,2} соответственно, при этом все события имеют положительные порядковые номера, так что 0 означает, что у Алисы нет событий, которые идентифицируются событием 1412. При сравнении списка A1 со списком A2 получают результаты {1<=0, 1<=2, 1<=1, 1<=1, 1<=2}, что эквивалентно {ложь, истина, истина, истина, истина}, где имеется четыре значения, которые являются истинными. Следовательно, существует набор S из четырех событий, которые являются предками события 1412 и потомками события 1401. Четыре соответствует по меньшей мере M, следовательно, 1412 строго идентифицирует 1401.

[1083] Еще один вариант реализации способа определения с помощью A1 и A2 того, может ли событие X строго идентифицировать событие-предка Y, является следующим. Если целочисленные элементы в обоих массивах меньше 128, то можно сохранить каждый элемент в одном байте и упаковать 8 таких элементов в одно 64-битное слово, и допустить, что A1 и A2 являются массивами таких слов. Самый старший бит каждого байта в A1 может быть установлен в 0, и самый старший бит каждого байта в A2 может быть установлен в 1. Два соответствующих слова вычитают, затем выполняют побитовую операцию И с использованием маски для обнуления всего, кроме самых старших битов, затем выполняют сдвиг вправо на 7 битовых позиций для получения значения, которое выражается на языке программирования C как: ((A2[i] - A1[i]) & 0x8080808080808080) >> 7). Это может быть добавлено в регистровый стек S, который был инициализирован в нуль. После выполнения этого действия множество раз преобразуют регистр в счетчик посредством сдвига и добавления байтов для получения ((S & 0xff) + ((S >> 8) & 0xff) + ((S >> 16) & 0xff) + ((S >> 24) & 0xff) + ((S >> 32) & 0xff) + ((S >> 40) & 0xff) + ((S >> 48) & 0xff) + ((S >> 56) & 0xff)). В некоторых случаях эти вычисления могут быть выполнены на таких языках программирования, как C, Java и/или т.п. В других случаях вычисления могут быть выполнены с использованием специфических для процессора инструкций, таких как инструкции Advanced Vector Extensions (AVX), предоставленные Intel и AMD, или эквивалента в графическом процессоре (GPU) или графическом процессоре общего назначения (GPGPU). На некоторых архитектурах вычисления могут быть выполнены быстрее с использованием слов, которые длиннее 64 битов, например, длиной 128, 256, 512 или более битов.

[1084] «Известное» («Famous») событие: событие X раунда R является «известным», если (1) событие X является «первым событием раунда R» (или «свидетелем»), и (2) решение «ДА» достигается путем выполнения протокола византийского соглашения, описанного ниже. В некоторых вариантах осуществления протокол византийского соглашения может быть выполнен экземпляром распределенной базы данных (например, экземпляром 114 распределенной базы данных) и/или модулем конвергенции базы данных (например, модулем 211 конвергенции базы данных). Например, как показано на фиг. 8, показаны пять первых событий раунда 1: 1401, 1402, 1403, 1404 и 1408. Если M определено как наименьшее целое число, превышающее N в 1/2 раза, что равняется трем, то 1412 представляет собой первое событие раунда 2. Если протокол продолжается дальше, то хешграф будет расти вверх, и в итоге другие четыре участника будут также иметь первые события раунда 2 над верхней частью этой фигуры. Каждое первое событие раунда 2 будет иметь «голос» («vote») относительно того, является ли каждое из первых событий раунда 1 «известным». Событие 1412 будет голосовать ДА за то, что 1401, 1402 и 1403 являются известными, поскольку они являются первыми событиями раунда 1, которые оно может идентифицировать. Событие 1412 будет голосовать НЕТ против того, что 1404 является известным, поскольку 1412 не может идентифицировать 1404. Для заданного первого события раунда 1, такого как 1402, решение относительно того, является ли его статус «известным» или нет, будет принято на основе подсчета голосов каждого первого события раунда 2 относительно того, является оно известным или нет. Те голоса будут затем распространяться на первые события раунда 3, затем на первые события раунда 4 и так далее до тех пор, пока в итоге не будет достигнуто согласие относительно того, является ли 1402 известным. Подобный процесс повторяется для других первых событий.

[1085] Протокол византийского соглашения может собирать и использовать голоса и/или решения «первых событий раунда R» для идентификации «известных» событий. Например, «первое событие Y раунда R+1» будет голосовать «ДА», если Y может «идентифицировать» событие X, в ином случае оно проголосует «НЕТ». Голоса затем подсчитываются для каждого раунда G, для G = R+2, R+3, R+4 и т.д. до тех пор, пока не будет принято решение любым участником. Голоса подсчитываются для каждого раунда G до тех пор, пока не принято решение. Некоторые из тех раундов могут представлять собой «мажоритарные» раунды, тогда как некоторые из других раундов могут представлять собой раунды «с подбрасыванием монеты». В некоторых случаях, например, раунд R+2 является мажоритарным раундом, и будущие раунды определяются либо как мажоритарный раунд, либо как раунд с подбрасыванием монеты (например, согласно предварительно определенной схеме). Например, в некоторых случаях произвольно может быть определено, является ли будущий раунд мажоритарным раундом или раундом с подбрасыванием монеты, при условии что не может быть двух последовательных раундов с подбрасыванием монеты. Например, может быть предварительно определено, что будет пять мажоритарных раундов, затем один раунд с подбрасыванием монеты, затем пять мажоритарных раундов, затем один раунд с подбрасыванием монеты, с повторением до тех пор, пока не будет достигнуто согласие.

[1086] В некоторых случаях, если раунд G является мажоритарным раундом, голоса могут быть подсчитаны следующим образом. Если существует событие раунда G, которое строго идентифицирует по меньшей мере M первых событий раунда G-1, голосующих V (где V представляет собой либо «ДА», либо «НЕТ»), то согласованным решением является V, и протокол византийского соглашения завершается. В ином случае каждое первое событие раунда G вычисляет новый голос, представляющий собой решение большинства первых событий раунда G-1, которые каждое первое событие раунда G может строго идентифицировать. В случаях равенства голосов и отсутствия большинства решение может быть обозначено как «ДА».

[1087] Подобным образом, если X является свидетелем раунда R (или первым событием раунда R), то результаты голосования в раундах R+1, R+2 и так далее могут быть вычислены, при этом свидетели в каждом раунде голосуют относительно того, является ли X известным. В раунде R+1 каждый свидетель, который может видеть X, голосует ДА, а другие свидетели голосуют НЕТ. В раунде R+2 каждый свидетель голосует согласно большинству голосов свидетелей раунда R+1, которые он может строго видеть. Подобным образом, в раунде R+3 каждый свидетель голосует согласно большинству голосов свидетеля раунда R+2, которого он может строго видеть. Это может продолжаться несколько раундов. В случае равенства голосов голос может быть установлен в ДА. В других случаях равенство голосов может быть установлено в НЕТ или может быть установлено случайным образом. Если какой-либо раунд имеет по меньшей мере M свидетелей, голосующих НЕТ, то выборы завершаются, и X не является известным. Если какой-либо раунд имеет по меньшей мере M свидетелей, голосующих ДА, то выборы завершаются, и X является известным. Если ни ДА, ни НЕТ не имеет по меньшей мере M голосов, выборы переходят к следующему раунду.

[1088] В качестве примера, на фиг. 8 предполагается первое событие X некоторого раунда, которое находится ниже показанной фигуры. Тогда каждое первое событие раунда 1 будет иметь голос относительно того, является ли X известным. Событие 1412 может строго идентифицировать первые события 1401, 1402 и 1408 раунда 1. Таким образом, его голос будет основан на их голосах. Если это мажоритарный раунд, то 1412 будет проверять, имеют ли по меньшей мере M событий {1401, 1402, 1408} голос ДА. Если имеют, то решением является ДА, и согласие было достигнуто. Если по меньшей мере M из них голосует НЕТ, то решением является НЕТ, и согласие было достигнуто. Если количество голосов не составляет по меньшей мере M в любую из сторон, то 1412 получает голос, который представляет собой большинство голосов событий 1401, 1402 и 1408 (и разрушает равенство голосов посредством голосования ДА, если было равенство голосов). Тот голос затем будет использован в следующем раунде, продолжающемся до тех пор, пока не будет достигнуто согласие.

[1089] В некоторых случаях, если раунд G является раундом с подбрасыванием монеты, голоса могут быть подсчитаны следующим образом. Если событие X может идентифицировать по меньшей мере M первых событий раунда G-1, голосующих V (где V представляет собой либо «ДА», либо «НЕТ»), то событие X изменит свой голос на V. Иначе, если раунд G является раундом с подбрасыванием монеты, то каждое первое событие X раунда G меняет свой голос на результат псевдослучайного определения (подобно подбрасыванию монеты в некоторых случаях), который определяется как самый младший бит подписи события X.

[1090] Подобным образом, в таких случаях, если выборы достигают раунда R+K (раунда с подбрасыванием монеты), где K – определенный коэффициент (например, кратный числу, такому как 3, 6, 7, 8, 16, 32 или любому другому подходящему числу), то выборы не завершаются на том раунде. Если выборы достигают этого раунда, они могут продолжиться по меньшей мере на еще один раунд. В таком раунде, если событие Y является свидетелем раунда R+K, то, если оно может строго видеть по меньшей мере M свидетелей из раунда R+K-1, которые голосуют V, Y проголосует V. Иначе Y проголосует согласно случайному значению (например, согласно биту подписи события Y (например, самому младшему биту, самому старшему биту, случайно выбранному биту), где 1=ДА и 0=НЕТ или наоборот, согласно метке времени события Y, с использованием криптографического протокола «shared coin» и/или любого другого случайного определения). Это случайное определение является непредсказуемым до создания Y, и, таким образом, можно повысить безопасность событий и протокола консенсуса.

[1091] Например, как показано на фиг. 8, если раунд 2 является раундом с подбрасыванием монеты, и происходит голосование относительно того, было ли некоторое событие до раунда 1 известным, то событие 1412 будет сначала проверять, проголосовало ли по меньшей мере M событий {1401, 1402, 1408} ДА, или по меньшей мере M из них проголосовало НЕТ. Если это так, то 1412 проголосует так же. Если отсутствует по меньшей мере M голосов в любую из сторон, то 1412 будет иметь случайный или псевдослучайный голос (например, на основе самого младшего бита цифровой подписи, которую Эд создал для события 1412, когда он подписал его во время его создания и/или определения).

[1092] В некоторых случаях результат псевдослучайного определения может быть результатом криптографического протокола shared coin, который может быть, например, реализован как самый младший бит пороговой подписи номера раунда.

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

[1094] «Принятый раунд» («Received round»): событие X имеет «принятый раунд» R, если R является таким минимальным целым числом, что по меньшей мере половина известных первых событий раунда R (или известных свидетелей) с номером раунда R являются потомками X и/или могут видеть X. В других случаях может быть использована любая другая подходящая процентная доля. Например, в другом случае событие X имеет «принятый раунд» R, если R является таким минимальным целым числом, что по меньшей мере предопределенная процентная доля (например, 40%, 60%, 80% и т.д.) известных первых событий раунда R (или известных свидетелей) с номером раунда R являются потомками X и/или могут видеть X.

[1095] В некоторых случаях «принятое поколение» события X может быть вычислено следующим образом. Находят, какой участник создал и/или определил каждое первое событие раунда R, которое может идентифицировать событие X. Затем определяют номер поколения для самого раннего события того участника, которое может идентифицировать X. Затем определяют «принятое поколение» X как медиану того списка.

[1096] В некоторых случаях «принятая метка времени» T события X может быть медианой меток времени в событиях, которые включают первое событие каждого участника, которое идентифицирует и/или видит X. Например, принятая метка времени события 1401 может быть медианой значения меток времени для событий 1402, 1403, 1403 и 1408. В некоторых случаях метка времени для события 1401 может быть включена в вычисление медианы. В других случаях принятая метка времени для X может быть любым другим значением или комбинацией значений меток времени в событиях, которые являются первыми событиями каждого участника для идентификации или видения X. Например, принятая метка времени для X может быть основана на среднем значении меток времени, среднеквадратичном отклонении меток времени, модифицированном среднем значении (например, путем удаления из вычисления самой ранней и самой поздней меток времени) и/или т.п. В еще других случаях может быть использована расширенная медиана.

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

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

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

[1100] В некоторых случаях медианная метка времени может быть заменена «расширенной медианой». В таких случаях список меток времени может быть определен для каждого события, вместо одной принятой метки времени. Список меток времени для события X может включать первое событие каждого участника, которое идентифицирует и/или видит X. Например, как показано на фиг. 8, список меток времени для события 1401 может включать метки времени для событий 1402, 1403, 1403 и 1408. В некоторых случаях также может быть включена метка времени для события 1401. При разрушении равенства со списком меток времени (т.е. два события имеют один и тот же принятый раунд) могут быть сравнены средние метки времени списка каждого события (или предопределенные первая или вторая из двух средних меток времени, если длина четная). Если эти метки времени являются одинаковыми, могут быть сравнены метки времени непосредственно после средних меток времени. Если эти метки времени являются одинаковыми, могут быть сравнены метки времени непосредственно перед средними метками времени. Если эти метки времени также являются одинаковыми, сравнивают метки времени после трех уже сравненных меток времени. Это чередование может продолжаться до тех пор, пока равенство не будет разрушено. Подобно вышеизложенному обсуждению, если два списка идентичны, равенство может быть разрушено по подписям двух элементов.

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

[1102] Принятая медианная метка времени может быть потенциально использована для других целей в дополнение к вычислению общего порядка событий. Например, Боб мог подписать контракт, в котором говорится, что он берет на себя обязательства по соблюдению контракта, если и только если существует событие X, содержащее транзакцию, в которой Алиса подписывает тот же контракт, причем принятая метка времени для X соответствует определенному крайнему сроку или более раннему моменту времени. В том случае Боб не возьмет на себя обязательства по соблюдению контракта, если Алиса подпишет его после крайнего срока, указанного «принятой медианной меткой времени», как описано выше.

[1103] В некоторых случаях состояние распределенной базы данных может быть определено после достижения консенсуса. Например, если S(R) является набором событий, который могут видеть известные свидетели в раунде R, в итоге все события в S(R) будут иметь известные принятый раунд и принятую метку времени. На том этапе порядок консенсуса для событий в S(R) известен и меняться не будет. Когда этот этап достигнут, участник может вычислить и/или определить представление событий и их порядок. Например, участник может вычислить значение хеша событий в S(R) в их порядке консенсуса. Участник может затем подписать с помощью цифровой подписи значение хеша и включить значение хеша в следующее событие, которое определяет участник. Это может быть использовано для оповещения других участников о том, что тот участник определил, что события в S(R) имеют заданный порядок, который не будет меняться. После того как по меньшей мере M участников (или любое другое подходящее количество или процентная доля участников) подписали значение хеша для S(R) (и, таким образом, согласились с порядком, представленным значением хеша), тот список консенсуса событий вместе со списком подписей участников могут образовать один файл (или другую структуру данных), который может быть использован для доказательства того, что порядок консенсуса был таковым, как заявлено, для событий в S(R). В других случаях, если события содержат транзакции, которые обновляют состояние системы распределенной базы данных (как описано в настоящем документе), то значение хеша может представлять состояние системы распределенной базы данных после применения транзакций событий в S(R) в порядке консенсуса. Дополнительные подробности относительно состояния распределенной базы данных обсуждены со ссылкой на фиг. 13.

[1104] В некоторых случаях M (как описано выше) может быть основано на весовых значениях, присвоенных каждому участнику, нежели всего лишь на части, процентном отношении и/или значении количества всех участников. В таком случае каждый участник имеет долю, связанную с его заинтересованностью и/или влиянием в системе распределенной базы данных. Такая доля может представлять собой весовое значение. Можно сказать, что каждое событие, определенное тем участником, имеет весовое значение его определяющего участника. Тогда M может быть частью от общей доли всех участников. События, описанные выше как зависимые от M, будут происходить, когда набор участников с суммарным количеством долей по меньшей мере M придет к согласию. Таким образом, на основе своей доли определенные участники могут иметь большее влияние на систему и на то, каким образом получается порядок консенсуса. В некоторых случаях транзакция в событии может менять долю одного или более участников, добавлять новых участников и/или удалять участников. Если такая транзакция имеет принятый раунд R, то после вычисления принятого раунда события после свидетелей раунда R будут повторно вычислять свои номера раундов и другую информацию с использованием модифицированных долей и модифицированного списка участников. Голоса относительно того, являются ли события раунда R известными, будут использовать старые доли и список участников, но голоса относительно раундов после R будут использовать новые доли и список участников. Дополнительные подробности относительно использования весовых значений для определения консенсуса описаны в заявке на патент США № 15/387048, поданной 21 декабря 2016 г., под названием «Methods And Apparatus For A Distributed Database Within A Network», в настоящий момент являющейся патентом США № 9646029, которая включена в настоящий документ посредством ссылки во всей своей полноте.

[1105] Вышеизложенные термины, определения и алгоритмы используются для иллюстрации вариантов осуществления и концепций, описанных в отношении фиг. 8–12B. На фиг. 10A и фиг. 10B проиллюстрировано примерное применение способа и/или процесса достижения консенсуса, показанное в математической форме. На фиг. 11A и фиг. 11B проиллюстрировано второе примерное применение способа и/или процесса достижения консенсуса, показанное в математической форме, и на фиг. 12A и фиг. 12B проиллюстрировано третье примерное применение способа и/или процесса достижения консенсуса, показанное в математической форме.

[1106] На фиг. 2 модуль 211 конвергенции базы данных и модуль 212 связи показаны на фиг. 2 как реализованные в процессоре 210. В других вариантах осуществления модуль 211 конвергенции базы данных и/или модуль 212 связи могут быть реализованы в памяти 220. В еще других вариантах осуществления модуль 211 конвергенции базы данных и/или модуль 212 связи могут быть основаны на аппаратном обеспечении (например, ASIC, FPGA и т.д.). В некоторых вариантах осуществления экземпляр 221 распределенной базы данных может быть подобен экземплярам 114, 124, 134, 144 распределенной базы данных системы 100 распределенной базы данных, показанной на фиг. 1.

[1107] На фиг. 7 проиллюстрирована функциональная схема потока сигналов двух вычислительных устройств, синхронизирующих события, согласно варианту осуществления. В частности, в некоторых вариантах осуществления экземпляры 703 и 803 распределенной базы данных могут обмениваться событиями для достижения конвергенции. Вычислительное устройство 700 может выбирать синхронизацию с вычислительным устройством 800 случайным образом, на основе взаимосвязи с вычислительным устройством 700, на основе близости к вычислительному устройству 700, на основе упорядоченного списка, связанного с вычислительным устройством 700, и/или т.п. В некоторых вариантах осуществления, поскольку вычислительное устройство 800 может быть выбрано вычислительным устройством 700 из набора вычислительных устройств, относящихся к системе распределенной базы данных, вычислительное устройство 700 может выбирать вычислительное устройство 800 несколько раз подряд или может некоторое время не выбирать вычислительное устройство 800. В других вариантах осуществления указание о ранее выбранных вычислительных устройствах может быть сохранено на вычислительном устройстве 700. В таких вариантах осуществления вычислительное устройство 700 может находиться в ожидании, пока не будет осуществлено предопределенное количество выборов, перед тем, как получить возможность снова выбирать вычислительное устройство 800. Как поясняется выше, экземпляры 703 и 803 распределенной базы данных могут быть реализованы в памяти вычислительного устройства 700 и памяти вычислительного устройства 800 соответственно.

[1108] На фиг. 3–6 проиллюстрированы примеры хешграфа согласно варианту осуществления. Имеется пять участников, каждый из которых представлен темной вертикальной линией. Каждый круг представляет событие. Две нисходящие линии от события представляют хеши двух предыдущих событий. Каждое событие в этом примере имеет две нисходящие линии (одну темную линию к тому же участнику и одну светлую линию к другому участнику), за исключением первого события каждого участника. Время течет вверх. На фиг. 3–6 вычислительные устройства распределенной базы данных обозначены как Алиса, Боб, Кэрол, Дэйв и Эд. Следует понимать, что такие обозначения относятся к вычислительным устройствам, которые конструктивно и функционально подобны вычислительным устройствам 110, 120, 130 и 140, показанным и описанным в отношении фиг. 1.

[1109] Примерная система 1: если вычислительное устройство 700 называется Алиса, и вычислительное устройство 800 называется Боб, то синхронизация между ними может быть выполнена так, как проиллюстрировано на фиг. 7. Синхронизация между Алисой и Бобом может быть выполнена следующим образом:

[1110] - Алиса отправляет Бобу события, сохраненные в распределенной базе 703 данных.

[1111] - Боб создает и/или определяет новое событие, которое содержит:

[1112] -- хеш последнего события, которое создал и/или определил Боб;

[11113] -- хеш последнего события, которое создала и/или определила Алиса;

[1115] -- цифровую подпись вышеуказанного, поставленную Бобом.

[1116] - Боб отправляет Алисе события, сохраненные в распределенной базе 803 данных.

[1116] - Алиса создает и/или определяет новое событие.

[1117] - Алиса отправляет Бобу то событие.

[1118] – Алиса вычисляет общий порядок для событий как функцию хешграфа.

[1119] – Боб вычисляет общий порядок для событий как функцию хешграфа.

[1120] В любой заданный момент времени участник может сохранить принятые на данный момент события вместе с идентификатором, связанным с вычислительным устройством и/или экземпляром распределенной базы данных, которые создали и/или определили каждое событие. Каждое событие содержит хеши двух более ранних событий, за исключением первоначального события (которое не имеет родительских хешей) и первого события для каждого нового участника (которое имеет один хеш события-родителя, представляющий событие существующего участника, который пригласил их присоединиться). Для представления этого набора событий может быть нарисована схема. На ней могут быть показаны вертикальная линия для каждого участника и точка на той линии для каждого события, созданного и/или определенного тем участником. Диагональная линия нарисована между двумя точками в каждом случае, когда событие (расположенная выше точка) содержит хеш более раннего события (расположенная ниже точка). Можно сказать, что событие привязано к другому событию, если то событие может ссылаться на другое событие посредством хеша того события (либо непосредственно, либо через промежуточные события).

[1121] Например, на фиг. 3 проиллюстрирован пример хешграфа 600. Событие 602 создается и/или определяется Бобом в результате синхронизации с Кэрол и после нее. Событие 602 содержит хеш события 604 (предыдущего события, созданного и/или определенного Бобом) и хеш события 606 (предыдущего события, созданного и/или определенного Кэрол). В некоторых вариантах осуществления, например, хеш события 604, включенный в событие 602, содержит указатель на его непосредственные события-предки, события 608 и 610. По существу, Боб может использовать событие 602 для ссылки на события 608 и 610 и перестраивания хешграфа с использованием указателей на предыдущие события. В некоторых случаях можно сказать, что событие 602 привязано к другим событиям в хешграфе 600, поскольку событие 602 может ссылаться на каждое из событий в хешграфе 600 посредством более ранних событий-предков. Например, событие 602 привязано к событию 608 посредством события 604. В качестве другого примера, событие 602 привязано к событию 616 посредством событий 606 и события 612.

[1122] Примерная система 2: система на основе примерной системы 1, при этом событие также содержит данные «полезной нагрузки» транзакций или другую информацию для записи. Такие данные полезной нагрузки могут быть использованы для обновления событий с помощью любых транзакций и/или информации, которые произошли и/или были определены начиная с непосредственного предыдущего события вычислительного устройства. Например, событие 602 может содержать любые транзакции, выполненные Бобом, начиная с момента создания и/или определения события 604. Таким образом, во время синхронизации события 602 с другими вычислительными устройствами Боб может делиться этой информацией. Соответственно, транзакции, выполняемые Бобом, могут быть связаны с событием и предоставлены другим участникам с помощью событий.

[1123] Примерная система 3: система на основе примерной системы 1, при этом событие также содержит текущие время и/или дату, полезные для отладки, диагностики и/или других целей. Время и/или дата могут быть локальными временем и/или датой, фиксирующими, когда вычислительное устройство (например, Боб) создает и/или определяет событие. В таких вариантах осуществления такие локальные время и/или дата не синхронизируются с остальными устройствами. В других вариантах осуществления время и/или дата могут быть синхронизированы на всех устройствах (например, при обмене событиями). В еще других вариантах осуществления для определения времени и/или даты может быть использован глобальный таймер.

[1124] Примерная система 4: система на основе примерной системы 1, в которой Алиса не отправляет Бобу ни события, созданные и/или определенные Бобом, ни события-предки такого события. Событие x является предком события y, если y содержит хеш x или y содержит хеш события, которое является предком x. Подобным образом, в таких вариантах осуществления Боб отправляет Алисе события, еще не сохраненные Алисой, и не отправляет события, уже сохраненные Алисой.

[1125] Например, на фиг. 4 проиллюстрирован примерный хешграфа 620, иллюстрирующий события-предки (круги с точками) и события-потомки (круги с полосками) события 622 (черный круг). Линии устанавливают частичный порядок событий, в котором предки идут до события в виде черного круга, и потомки идут после события в виде черного круга. Частичный порядок не указывает, идут ли события в виде белых кругов до или после события в виде черного круга, так что для определения их последовательности используется общий порядок. В качестве другого примера, на фиг. 5 проиллюстрирован примерный хешграф, иллюстрирующий одно конкретное событие (закрашенный круг) и первый момент времени, в который каждый участник принимает указание о том событии (круги с полосками). Когда Кэрол синхронизируется с Дэйвом для создания и/или определения события 624, Дэйв не отправляет Кэрол события-предки события 622, поскольку Кэрол уже осведомлена о таких событиях и приняла их. Вместо этого Дэйв отправляет Кэрол события, которые Кэрол все еще должна принять и/или сохранить в экземпляре распределенной базы данных Кэрол. В некоторых вариантах осуществления Дэйв может идентифицировать, какие события следует отправлять Кэрол, на основе того, что хешграф Дэйва показывает о том, какие события Кэрол приняла ранее. Событие 622 является предком события 626. Следовательно, на момент события 626 Дэйв уже принял событие 622. На фиг. 4 показано, что Дэйв принял событие 622 от Эда, который принял событие 622 от Боба, который принял событие 622 от Кэрол. Кроме того, на момент события 624 событие 622 является последним событием, принятым Дэйвом, которое было создано и/или определено Кэрол. Следовательно, Дэйв может отправлять Кэрол события, которые Дэйв сохранил, отличающиеся от события 622 и его предков. Дополнительно после приема события 626 от Дэйва Кэрол может перестраивать хешграф на основе указателей в событиях, сохраненных в экземпляре распределенной базы данных Кэрол. В других вариантах осуществления Дэйв может идентифицировать, какие события следует отправлять Кэрол, на основе отправки Кэрол события 622 Дэйву (не показано на фиг. 4) и идентификации с использованием события 622 (и ссылок в нем) Дэйвом, чтобы идентифицировать события, которые Кэрол уже приняла.

[1126] Примерная система 5: система на основе примерной системы 1, в которой оба участника отправляют события друг другу в таком порядке, что событие отправляется только после того, как получатель примет и/или сохранит предков того события. Соответственно, отправитель отправляет события от самых старых к самым новым, так что получатель может проверить два хеша в каждом событии при приеме события посредством сравнения двух хешей с двумя событиями-предками, которые уже были приняты. Отправитель может идентифицировать, какие события следует отправлять получателю, на основе текущего состояния хешграфа отправителя (например, переменной состояния базы данных, определенной отправителем), а какие, как указывает тот хешграф, получатель уже принял. Ссылаясь на фиг. 3, например, когда Боб синхронизируется с Кэрол для определения события 602, Кэрол может идентифицировать, что событие 619 является последним событием, созданным и/или определенным Бобом, которое приняла Кэрол. Следовательно, Кэрол может определить, что Бобу известно о том событии и его предках. Таким образом, Кэрол может отправлять Бобу сначала событие 618 и событие 616 (т.е. самые старые события, которые Боб еще должен принять, которые Кэрол приняла). Кэрол может затем отправлять Бобу событие 612, а затем событие 606. Это позволяет Бобу легко привязать события друг к другу и перестроить хешграф Боба. Использование хешграфа Кэрол для идентификации того, какие события еще должен принять Боб, может повысить эффективность синхронизации и может уменьшить сетевой трафик, поскольку Боб не запрашивает события у Кэрол.

[1127] В других вариантах осуществления самое последнее событие может быть отправлено первым. Если получатель определяет (на основе хеша двух предыдущих событий в самом последнем событии и/или указателей на предыдущие события в самом последнем событии), что он еще не принял одно из двух предыдущих событий, получатель может запросить у отправителя отправку таких событий. Это может происходить до тех пор, пока получатель не примет и/или не сохранит предков самого последнего события. Ссылаясь на фиг. 3, в таких вариантах осуществления, например, когда Боб принимает событие 606 от Кэрол, Боб может идентифицировать хеш события 612 и события 614 в событии 606. Боб может определить, что событие 614 было ранее принято от Алисы при создании и/или определении события 604. Соответственно, Бобу не нужно запрашивать событие 614 у Кэрол. Боб может также определить, что событие 612 еще не было принято. Боб может затем запросить событие 612 у Кэрол. Боб может затем на основе хешей в событии 612 определить, что Боб не принял события 616 или 618, и может соответственно запросить эти события у Кэрол. На основе событий 616 и 618 Боб затем сможет определить, что он принял предков события 606.

[1128] Примерная система 6: система на основе примерной системы 5 с дополнительным ограничением, которое заключается в том, что, когда участник имеет выбор между несколькими событиями для отправки далее, событие выбирается таким образом, чтобы минимизировать общее количество отправленных на данный момент байтов, созданных и/или определенных тем участником. Например, если Алисе осталось отправить Бобу только два события, и одно из них имеет размер 100 байтов и было создано и/или определено Кэрол, а другое имеет размер 10 байтов и было создано и/или определено Дэйвом, и на данный момент в ходе этой синхронизации Алиса уже отправила 200 байтов событий Кэрол и 210 Дэйва, то Алисе следует сначала отправить событие Дэйву, а затем отправить событие Кэрол. Поскольку 210 + 10 < 100 + 200. Это может быть использовано для предотвращения атак, при которых один участник выдает либо одно огромное событие, либо поток мелких событий. В случае если трафик превышает ограничение по байтам большинства участников (как обсуждается в отношении примерной системы 7), способ согласно примерной системе 6 может обеспечивать, что игнорироваться будут события злоумышленника, а не события правомочных пользователей. Подобным образом, атаки могут быть ослаблены посредством отправки меньших событий перед большими событиями (для защиты от одного огромного события, забивающего канал связи). Более того, если участник не может отправить каждое из событий за одну синхронизацию (например, из-за ограничения сети, ограничений по байтам участника и т.д.), то тот участник может отправить несколько событий от каждого участника, вместо того, чтобы просто отправить события, определенные и/или созданные злоумышленником, и ни одного (из нескольких) события, созданного и/или определенного другими участниками.

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

[1130] Примерная система 8: система на основе примерной системы 1, в которой следующие этапы добавлены в начале процесса синхронизации:

[1131] - Алиса идентифицирует S, набор событий, которые она приняла и/или сохранила, пропуская события, которые были созданы и/или определены Бобом или которые являются предками событий, созданных и/или определенных Бобом.

[1132] - Алиса идентифицирует участников, которые создали и/или определили каждое событие в S, и отправляет Бобу список ID-номеров участников. Алиса также отправляет количество событий, которые были созданы и/или определены каждым участником, которые она уже приняла и/или сохранила.

[1133] - Боб отвечает списком того, сколько событий он принял, тех, которые были созданы и/или определены другими участниками.

[1134] - Алиса затем отправляет Бобу только события, которые он еще должен принять. Например, если Алиса указывает Бобу, что она приняла 100 событий, созданных и/или определенных Кэрол, и Боб отвечает, что он принял 95 событий, созданных и/или определенных Кэрол, то Алиса отправит только 5 самых последних событий, созданных и/или определенных Кэрол.

[1135] Примерная система 9: система на основе примерной системы 1 с дополнительным механизмом для идентификации и/или устранения мошенников. Каждое событие содержит два хеша, один от последнего события, созданного и/или определенного тем участником («собственный хеш»), и один от последнего события, созданного и/или определенного другим участником («чужой хеш»). Если участник создает и/или определяет два разных события с одним и тем же собственным хешем, то тот участник является «мошенником». Если Алиса устанавливает, что Дэйв является мошенником, посредством приема двух разных событий, созданных и/или определенных им с использованием одного и того же собственного хеша, то она сохраняет индикатор, указывающий на то, что он является мошенником, и избегает синхронизации с ним в будущем. Если она устанавливает, что он является мошенником, но все же синхронизируется с ним снова и создает и/или определяет новое событие, записывающее тот факт, то Алиса тоже становится мошенником, и другие участники, которые узнают, что Алиса впоследствии синхронизировалась с Дэйвом, перестают синхронизироваться с Алисой. В некоторых вариантах осуществления это влияет только на синхронизацию в одну сторону. Например, когда Алиса отправляет список идентификаторов и число событий, которые она приняла, для каждого участника, она не отправляет ID или количество для мошенника, так что Боб не ответит никаким соответствующим числом. Алиса затем отправляет Бобу события мошенника, которые она приняла и для которых она не приняла указание о том, что Боб принял такие события. После завершения той синхронизации Боб также сможет определить, что Дэйв является мошенником (если он еще не идентифицировал Дэйва как мошенника), и Боб также откажется от синхронизации с мошенником.

[1136] Примерная система 10: система на основе примерной системы 9 с тем дополнением, что Алиса начинает процесс синхронизации путем отправки Бобу списка мошенников, которых она идентифицировала и события которых она все еще хранит, и Боб отвечает сообщением с указанием любых мошенников, которых он идентифицировал, в дополнение к мошенникам, идентифицированным Алисой. Затем они продолжают работу в обычном режиме, но без подсчета мошенников при синхронизации друг с другом.

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

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

[1139] Примерная система 12: система на основе примерной системы 11, ускоренная за счет использования arrayList с «быстрым клонированием» для поддержания состояния (например, баланса банковских счетов, состояния игры и т.д.). ArrayList с быстрым клонированием представляет собой структуру данных, которая действует как массив с одной дополнительной особенностью: она поддерживает операцию «клонирования», которая представляет собой создание и/или определение нового объекта, который является копией оригинала. Клон действует так, как если бы это была точная копия, поскольку изменения, которым подвергается клон, не влияют на оригинал. Однако операция клонирования быстрее, чем создание точной копии, поскольку создание клона в действительности не включает копирования и/или обновления всего содержимого одного arrayList в другой. Вместо наличия двух клонов и/или копий оригинального списка могут быть использованы два небольших объекта, каждый с хеш-таблицей и указателем на оригинальный список. Когда производится запись в клон, хеш-таблица запоминает, какой элемент модифицирован, и новое значение. Когда выполняется считывание из позиции, сначала проверяется хеш-таблица, и, если тот элемент был модифицирован, возвращается новое значение из хеш-таблицы. Иначе тот элемент возвращается из оригинального arrayList. Таким образом, два «клона» изначально являются лишь указателями на оригинальный arrayList. Но поскольку каждый из них постоянно модифицируется, они расширяются настолько, что имеют большую хеш-таблицу, в которой хранятся отличия между ними и оригинальным списком. Клоны сами могут быть клонированы, что вызывает расширение структуры данных до дерева объектов, каждый из которых имеет свои собственные хеш-таблицу и указатель на своего родителя. Следовательно, считывание вызывает подъем по дереву до тех пор, пока не будет установлена вершина, которая имеет запрашиваемые данные, или не будет достигнут корень. Если вершина становится слишком большой или сложной, то она может быть заменена на точную копию родителя, изменения в хеш-таблице могут быть переведены в копию, а хеш-таблица удалена. Кроме того, если клон больше не нужен, то во время сборки мусора он может быть удален из дерева, и дерево может быть свернуто.

[1140] Примерная система 13: система на основе примерной системы 11, ускоренная за счет использования хеш-таблицы с «быстрым клонированием» для поддержания состояния (например, баланса банковских счетов, состояния игры и т.д.). Она подобна системе 12, за тем исключением, что корень дерева представляет собой хеш-таблицу, а не arrayList.

[1141] Примерная система 14: система на основе примерной системы 11, ускоренная за счет использования реляционной базы данных с «быстрым клонированием» для поддержания состояния (например, баланса банковских счетов, состояния игры и т.д.). Например, база данных с быстрым клонированием может быть использована для обеспечения двух копий состояния, как обсуждено в отношении примерной системы 11. Она представляет собой объект, который действует как обертка вокруг существующей системы управления реляционной базой данных (RDBMS). Каждый явный «клон» является фактически объектом с ID-номером и указателем на объект, содержащий базу данных. Когда пользовательский код пытается выполнить запрос на языке структурированных запросов (SQL) в базу данных, тот запрос сначала модифицируется, а затем отправляется в реальную базу данных. Реальная база данных идентична базе данных с точки зрения клиентского кода, за исключением того, что каждая таблица имеет одно дополнительное поле для ID клона. Например, предположим, что существует оригинальная база данных с ID клона, равным 1, а затем создают два клона базы данных с ID, равными 2 и 3 (например, используемых для поддержания двух копий состояния). Каждая строка в каждой таблице будет иметь значения 1, 2 или 3 в поле ID клона. Когда запрос поступает от пользовательского кода на клон 2, запрос модифицируется таким образом, что запрос будет считываться только из строк, которые имеют значения 2 или 1 в том поле. Подобным образом, запросы к клону 3 считывают строки с ID, равным 3 или 1. Если команда на языке структурированных запросов (SQL) поступает на клон 2 и указывает удалить строку, и та строка имеет 1, то команда должна просто изменить 1 на 3, что помечает строку как более не используемую совместно клонами 2 и 3, и теперь видимую только для 3. Если существуют несколько рабочих клонов, то несколько копий строки могут быть вставлены, и каждая из них может быть установлена на ID разного клона, так что новые строки являются видимыми для всех клонов, за исключением клона, который только что «удалил» строку. Подобным образом, если строка добавляется в клон 2, то строка добавляется в таблицу с ID, равным 2. Модификация строки эквивалентна удалению с последующей вставкой. Как и раньше, если несколько клонов удаляются во время сборки мусора, то дерево может быть упрощено. Структура того дерева будет сохранена в дополнительной таблице, недоступной клонам, но которая полностью используется на внутреннем уровне.

[1142] Примерная система 15: система на основе примерной системы 11, ускоренная за счет использования файловой системы с «быстрым клонированием» для поддержания состояния. Она представляет собой объект, который действует как обертка вокруг файловой системы. Файловая система построена поверх существующей файловой системы с использованием реляционной базы данных с быстрым клонированием для управления разными версиями файловой системы. Основная файловая система хранит большое количество файлов либо в одном каталоге, либо раздельно согласно имени файла (для поддержания малого размера каталогов). Дерево каталогов может храниться в базе данных и не предоставляться базовой файловой системе. Когда файл или каталог клонируются, «клон» представляет собой лишь объект с ID-номером, и база данных модифицируется таким образом, чтобы отражать, что этот клон теперь существует. Если файловая система с быстрым клонированием клонируется, она представляется пользователю такой, как если бы был создан и/или определен целый новый жесткий диск, инициализированный с использованием копии существующего жесткого диска. Изменения, которым подвергается одна копия, могут не влиять на другие копии. В действительности существует только одна копия каждого файла или каталога, и копирование происходит, когда файл модифицируется посредством одного клона.

[1143] Примерная система 16: система на основе примерной системы 15, в которой отдельный файл создается и/или определяется в базовой операционной системе для каждой N-байтной части файла в файловой системе с быстрым клонированием. N может представлять собой некоторый подходящий размер, такой как, например, 4096 или 1024. Таким образом, если один байт изменяется в большом файле, копируется и модифицируется только один блок большого файла. Это также повышает эффективность при сохранении множества файлов на диске, которые отличаются лишь несколькими байтами.

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

[1145] Примерная система 18: система на основе примерной системы 1, где операции, которые вычисляют медиану или большинство, заменяются взвешенной медианой или взвешенным большинством, причем участников взвешивают согласно их «доле». Доля представляет собой число, которое указывает на то, как много значит голос участника. Доля может представлять собой активы в криптовалюте или просто произвольное число, которое присваивается, когда участника впервые приглашают присоединиться, а затем разделяется среди новых участников, которых участник приглашает присоединиться. Старые события могут быть удалены, когда достаточное количество участников согласится с состоянием консенсуса, так что их общая доля является большей частью имеющейся доли. Если общий порядок вычисляется с использованием медианы рангов, вносимых участниками, то результатом является число, при котором половина участников имеет более высокий ранг, а половина имеет более низкий. С другой стороны, если общий порядок вычисляется с использованием взвешенной медианы, то результатом является число, при котором приблизительно половина общей доли связана с рангами ниже той, и половина выше. Взвешенные голосование и медианы могут быть полезны в предотвращении атаки Сивиллы, когда один участник приглашает присоединиться огромное количество «виртуальных» пользователей, каждый из которых является просто псевдонимом под управлением приглашающего участника. Если приглашающий участник вынужден делить свою долю с приглашенными, то виртуальные пользователи будут бесполезны для злоумышленника в попытках контролировать результаты консенсуса. Соответственно, доказательство доли владения может быть полезным в некоторых обстоятельствах.

[1146] Примерная система 19: система на основе примерной системы 1, в которой вместо одной распределенной базы данных имеется множество баз данных в иерархии. Например, может существовать одна база данных, пользователи которой являются ее участниками, а также несколько меньших баз данных или «блоков», каждый из которых имеет поднабор участников. Когда события происходят в блоке, они синхронизируются среди участников того блока, но не среди участников вне того блока. Затем периодически после принятия решения относительно порядка консенсуса в блоке полученное в результате состояние (или события со своим общим порядком консенсуса) может совместно использоваться всем составом участников большой базы данных.

[1147] Примерная система 20: система на основе примерной системы 11 с возможностью наличия события, которое обновляет программное обеспечение для обновления состояния (например, зафиксированного переменной состояния базы данных, определенной участником системы). Например, события X и Y могут содержать транзакции, которые модифицируют состояние согласно программному коду, который считывает транзакции в тех событиях, а затем обновляет состояние надлежащим образом. Тогда событие Z может содержать уведомление о том, что теперь доступна новая версия программного обеспечения. Если общий порядок говорит, что события происходят в порядке X, Z, Y, то состояние может быть обновлено посредством обработки транзакций в X с использованием старого программного обеспечения, а затем транзакций в Y с использованием нового программного обеспечения. Но если порядок консенсуса имел вид X, Y, Z, то как X, так и Y могут быть обновлены с использованием старого программного обеспечения, которое может дать другое конечное состояние. Следовательно, в таких вариантах осуществления уведомление об обновлении кода может появляться в событии, так что сообщество (например, участники в распределенной базе данных) может достигать консенсуса относительно того, когда следует перейти со старой версии на новую версию. Это гарантирует, что участники будут поддерживать синхронизированные состояния. Это также гарантирует, что система может оставаться работающей даже во время обновлений без необходимости перезагрузки или перезапуска процесса.

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

[1149] Примерная теорема 1: если событие x предшествует событию y в частичном порядке, то в знании заданного участника о других участниках в заданный момент времени каждый из других участников либо принял указание о x до y, либо еще не принял указание о y.

[1150] Доказательство: если событие x предшествует событию y в частичном порядке, то x является предком y. Когда участник принимает указание о y в первый раз, тот участник либо уже принял указание о x ранее (в случае чего он узнает о x раньше y), либо это будет случай, когда синхронизация предоставляет тому участнику как x, так и y (в случае чего он узнает о x раньше y во время той синхронизации, поскольку события, принимаемые во время одной синхронизации, полагают принимаемыми в порядке, согласующемся с взаимосвязями потомственности, как описано в отношении примерной системы 5). Что и требовалось доказать.

[1151] Примерная теорема 2: для любого заданного хешграфа, если x предшествует y в частичном порядке, то x будет предшествовать y в общем порядке, вычисленном для того хешграфа.

[1152] Доказательство: если x предшествует y в частичном порядке, то согласно теореме 1:

[1153] для всех i, rank(i,x) < rank(i,y),

[1154] где rank(i,x) представляет собой ранг, присвоенный участником i событию x, который равен 1, если x является первым событием, принятым участником i, 2, если вторым, и так далее. Допустим, что med(x) представляет собой медиану rank(i,x) для всех i, и аналогично для med(y).

[1155] Для заданного k выберем i1 и i2 таким образом, что rank(i1,x) является k-м наименьшим рангом x, а rank(i2,y) является k-м наименьшим рангом y. Тогда:

[1156] rank(i1,x) < rank(i2,y).

[1157] Это объясняется тем, что rank(i2,y) превышает или равняется k рангов y, каждый из которых строго превышает соответствующий ранг x. Следовательно, rank(i2,y) строго превышает по меньшей мере k рангов x, а значит строго превышает k-й наименьший ранг x. Этот аргумент справедлив для любого k.

[1158] Допустим, что n представляет собой количество участников (которое является количеством значений i). Тогда n должно быть либо нечетным, либо четным. Если n нечетное, то допустим, что k=(n+1)/2, и k-й наименьший ранг будет являться медианой. Следовательно, med(x) < med(y). Если n четное, то, когда k=n/2, k-й наименьший ранг x будет строго меньше, чем k-й наименьший ранг y, а также (k+1)-й наименьший ранг x будет строго меньше, чем (k+1)-й наименьший ранг y. Следовательно, среднее значение двух рангов x будет меньше, чем среднее значение двух рангов y. Следовательно, med(x) < med(y). Следовательно, в обоих случаях медиана рангов x строго меньше, чем медиана рангов y. Следовательно, если общий порядок определен посредством сортировки действий по медианному рангу, то событие x будет предшествовать событию y в общем порядке. Что и требовалось доказать.

[1159] Примерная теорема 3: если «период передачи» представляет собой количество времени, необходимое для распространения существующих событий посредством синхронизации всем участникам, то:

[1160] после 1 периода передачи: все участники приняли события,

[1161] после 2 периодов передачи: все участники приходят к согласию относительно порядка тех событий,

[1162] после 3 периодов передачи: все участники знают, что согласие было достигнуто,

[1163] после 4 периодов передачи: все участники получают цифровые подписи от всех остальных участников, одобряющие этот порядок консенсуса.

[1164] Доказательство: допустим, что S0 представляет собой набор событий, которые были созданы и/или определены к заданному моменту времени T0. Если каждый участник будет в итоге синхронизироваться с каждым из остальных участников бесконечное число раз, то с вероятностью, равной 1, в итоге будет существовать момент времени T1, к которому события в S0 распространятся каждому участнику, так что каждый участник будет осведомлен обо всех событиях. Это конец первого периода передачи. Допустим, что S1 представляет собой набор событий, которые существуют на момент времени T1 и которые еще не существовали на момент времени T0. Тогда с вероятностью, равной 1, в итоге будет существовать момент времени T2, к которому каждый участник примет каждое из событий в наборе S1, которое является существующим на момент времени T1. Это конец второго периода передачи. Подобным образом, T3 представляет собой момент времени, когда все события в S2, существующие к моменту времени T2, но не до момента времени T1, распространились всем участникам. Следует отметить, что каждый период передачи в итоге заканчивается с вероятностью, равной 1. В среднем каждый период будет продолжаться столько, сколько необходимо для выполнения log2(n) синхронизаций, если имеется n участников.

[1165] К моменту времени T1 каждый участник примет каждое событие в S0.

[1166] К моменту времени T2 заданный участник Алиса примет запись каждого из остальных участников, принимающих каждое событие в S0. Следовательно, Алиса может вычислить ранг для каждого действия в S0 для каждого участника (который представляет собой порядок, в котором тот участник принял то действие), а затем отсортировать события по медиане рангов. Полученный в результате общий порядок не меняется для событий в S0. Это объясняется тем, что полученный в результате порядок является функцией порядка, в котором каждый участник впервые принял указание о каждом из тех событий, который не меняется. Возможно, что порядок, вычисленный Алисой, будет иметь несколько событий из S1, рассеянных среди событий S0. Те события S1 могут все еще меняться, где они попадают в последовательность событий S0. Но относительный порядок событий в S0 не будет меняться.

[1167] К моменту времени T3 Алиса узнает общий порядок на объединении S0 и S1, и относительный порядок событий в том объединении меняться не будет. Кроме того, она может найти в этой последовательности самое раннее событие из S1 и может прийти к выводу, что последовательность событий до S1 не будет меняться, даже посредством вставки новых событий не из S0. Следовательно, к моменту времени T3 Алиса может определить, что консенсус был достигнут для порядка событий в истории до первого события S1. Она может подписать с помощью цифровой подписи хеш состояния (например, зафиксированного переменной состояния базы данных, определенной Алисой), являющийся результатом этих событий, происходящих в этом порядке, и отправить подпись в виде части следующего события, которое она создает и/или определяет.

[1168] К моменту времени T4 Алиса примет подобные подписи от других участников. На том этапе она может просто сохранить тот список подписей вместе с состоянием, свидетельством которого они являются, и она может удалить события, которые она сохранила до первого события S1. Что и требовалось доказать.

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

[1170] Другим примером является распределенная игра, которая действует подобно массовой многопользовательской онлайн-игре (MMO), в которую играют на сервере, но достигает того без применения центрального сервера. Консенсус может быть достигнут без какого-либо центрального сервера, осуществляющего управление.

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

[1172] Другим примером является система связи, используемая в реагировании на чрезвычайные ситуации для координирования различных служб, таких как полиция, пожарная охрана, служба медицинской помощи, военные части, национальная гвардия и/или Федеральное агентство по ликвидации чрезвычайных ситуаций (FEMA). Распределенная база данных может быть использована для формирования у членов каждой службы общей позиции в отношении ситуации, при этом каждая служба будет предоставлять информацию и иметь доступ к информации, полученной от других служб. Это обеспечит то, что различные участники будут иметь доступ к одной и той же информации, и то, что чрезвычайное происшествие или злоумышленник не сможет легко препятствовать работе сети, как положено. Единая база данных на центральном сервере, например, может быть повреждена осведомленным лицом или одним компьютером, зараженным вредоносной программой. Такая единая база данных на центральном сервере также может быть принудительно переведена в режим офлайн в результате совершения распределенной атаки типа «отказ в обслуживании» (DDoS), при которой она подвергается потоку межсетевых пакетов, поступающих с взломанных компьютеров (например, со всего мира). В качестве другого примера, такая единая база данных на центральном сервере также может перейти в режим офлайн по причине того, что во время чрезвычайного происшествия были повреждены провод связи или спутниковая станция. Однако распределенная база данных может обладать устойчивостью к таким проблемам. Кроме того, если распределенная база данных исполняет распределенно выполняемый код, обеспечивая соблюдение правил, то участники могут совместно обеспечивать то, что ни один из взломанных участников не сможет подвергнуть систему потоку дополнительных данных с целью переполнения системы и отключения системы изнутри. Этот случай примерного использования было бы затруднительным реализовать при использовании блокчейна, основанного на доказательстве выполнения работы, так как маловероятно, что службы по реагированию на чрезвычайные ситуации будут эксплуатировать мощные компьютеры, необходимые для такой неэффективной системы. Такой случай использования также не будет обладать устойчивостью, если он будет реализован с использованием системы консенсуса, основанной на лидерах, такой как Паксос или блокчейн с алгоритмом кругового обслуживания, так как DDoS-атака против одного компьютера за один раз может на длительное время отключить текущего лидера и перейти к совершению атаки на новый компьютер, когда сообщество переключится на нового лидера. Поэтому для решения проблем, связанных с блокчейном и системами консенсуса, основанными на лидере, с использованием системы распределенного консенсуса, такой как системы распределенной базы данных, описанные в настоящем документе, может быть реализована устойчивая распределенная база данных.

[1173] Аналогичным образом системы распределенной базы данных, описанные в настоящем документе, могут быть использованы для реализации устойчивой связи и совместного просмотра информации для военной операции. В еще одном примере системы распределенной базы данных, описанные в настоящем документе, могут быть использованы для реализации распределенной базы данных, используемой для контроля объектов Интернета вещей, или инфраструктуры диспетчерского управления и сбора данных (SCADA), или датчиков и устройств управления в «умном городе». Такие системы могут включать признаки и/или требования, аналогичные примерной реализации для ликвидации чрезвычайных происшествий, описанной выше.

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

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

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

[1177] Альтернативно вычислительные требования в такой системе могут быть снижены, например, следующим образом. Каждая пара участников может вначале провести переговоры относительно двух совместно используемых секретных ключей (по одному для каждого участника в паре), которые они используют для раздачи двух разных криптографически защищенных генераторов случайных чисел (CSPRNG) (по одному для каждого участника в паре). Если Алиса создала такой ключ с Бобом, то она использует свой CSPRNG для генерирования нового псевдослучайного числа каждый раз, когда она добавляет в базу данных сообщение, предназначенное Бобу, и она прилагает то число к зашифрованному сообщению. Затем Боб может быстро проверить число, приложенное к каждому сообщению в базе данных, чтобы проверить, указывает ли любое из таких чисел на сообщения, предназначенные ему. Так как Боб знает совместно используемый ключ, он поэтому знает последовательность чисел, которые будет генерировать Алиса, и, следовательно, он знает, какие числа следует искать при просмотре сообщений в отношении сообщений, адресованных ему Алисой. При нахождении им сообщений с такими приложенными числами он знает, что они являются сообщениями, отправленными ему Алисой, и он может расшифровать их. Посторонние сообщение, например, отправленные Дейву Кэрол, будут иметь отличающиеся приложенные числа, и Боб удалит их, не расшифровывая их. В некоторых реализациях Алиса и Боб могут периодически повторно проводить переговоры относительно их совместно используемых ключей и стирать свои старые ключи. Это обеспечивает передовую безопасность таким образом, что в будущем будет затруднительным для третьей стороны идентифицировать сообщения, которыми обменялись Алиса и Боб, даже если их ключи, в конечном итоге, взломаны.

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

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

[1180] Хоть события и описаны выше как содержащие хеши (или значения криптографических хешей) предыдущих событий, в других вариантах осуществления событие может быть создано и/или определено таким образом, чтобы содержать указатель, идентификатор и/или любую другую подходящую ссылку на предыдущие события. Например, событие может быть создано и/или определено таким образом, чтобы содержать серийный номер, связанный с предыдущим событием и используемый для его идентификации, таким образом привязывая события друг к другу. В некоторых вариантах осуществления такой серийный номер может включать, например, идентификатор (например, адрес управления доступом к среде (MAC), адрес интернет-протокола (IP-адрес), присвоенный адрес и/или т.п.), связанный с участником, который создал и/или определил событие, и порядком события, определенным тем участником. Например, если участник имеет идентификатор, равный 10, и событие является 15-ым событием, созданным и/или определенным тем участником, то он может присвоить тому событию идентификатор, равный 1015. В других вариантах осуществления любой другой подходящий формат может быть использован для присвоения идентификаторов событиям.

[1181] В других вариантах осуществления события могут содержать полные криптографические хеши, но только части тех хешей передаются во время синхронизации. Например, если Алиса отправляет Бобу событие, содержащее хеш H, и J является первыми 3 байтами H, и Алиса определяет, что из всех событий и хешей, которые она сохранила, H является единственным хешем, начинающимся с J, то она может отправить J вместо H во время синхронизации. Если Боб затем определяет, что у него есть другой хеш, начинающийся с J, то он может отправить ответное сообщение Алисе с запросом полного H. Таким образом хеши могут быть сжаты во время передачи.

[1182] На фиг. 13 представлено изображение начального состояния распределенной базы данных согласно варианту осуществления. В некоторых реализациях распределенная база данных может быть инициализирована участниками-учредителями, в этом примере Алисой, Бобом, Кэрол, Дейвом и Эдом. Каждый участник определяет пару ключей 1305 для участников. Каждая пара ключей для участников может включать уникальный закрытый ключ и уникальный открытый ключ, связанные с участником. Например, Алиса имеет A_Private_Key и A_Public_Key, тогда как Боб имеет B_Private_Key и B_Public_Key и так далее для Кэрол, Дейва и Эда, как показано в столбце 1305. Каждая пара открытого и закрытого ключа включает два уникальным образом связанных криптографических ключа (например, большие числа). Ниже приведен пример открытого ключа:

[1183] 3048 0241 00C9 18FA CF8D EB2D EFD5 FD37 89B9 E069 EA97 FC20 5E35 F577 EE31 C4FB C6E4 4811 7D86 BC8F BAFA 362F 922B F01B 2F40 C744 2654 C0DD 2881 D673 CA2B 4003 C266 E2CD CB02 0301 0001

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

[1185] В некоторых реализациях пары в столбце 1305 используют в качестве параметров для вычисления Уникального идентификатора 1309 распределенной базы данных (D2ID). Следует принимать во внимание, что D2ID 1309 в общем является сложным для дублирования, учитывая случайный характер параметров, предоставляемых каждым из участников-учредителей, и открытых ключей, что, таким образом, преимущественно обеспечивает высокие уровни безопасности для распределенной базы данных. Дополнительно для улучшения случайного характера каждая пара ключей для каждого участника может быть разной для каждой распределенной базы данных, в которой участвует тот участник. Более того, такие пары ключей могут быть случайным образом сгенерированы каждым участником. Таким образом, даже если те же самые участники определят вторую базу данных, D2ID второй распределенной базы данных будет отличаться от D2ID первой распределенной базы данных.

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

[1187] В некоторых реализациях составы 1303 участников могут быть реализованы в виде структуры данных или другого логически и/или физически реализованного контейнера, в котором записаны несколько списков составов участников, связанных с состояниями распределенной базы данных. В некоторых случаях составы 1303 участников содержат текущий список 1301 составов участников (CML), содержащий атрибуты участников, связанных с текущим состоянием распределенной базы данных. CML 1301 приспособлен для изменения при исполнении операций, исполняемых распределенной базой данных, например, добавления или удаления участников из базы данных, как обсуждено со ссылкой на фиг. 14. В начальном состоянии распределенной базы данных CML 1301 содержит атрибуты участников-учредителей распределенной базы данных, например, пары 1305 ключей состава участников и другие подходящие атрибуты, связанные с такими участниками-учредителями.

[1188] В некоторых случаях участники, содержащиеся в CML, и их связанные атрибуты меняются с течением времени, например, при добавлении участников в распределенную базу данных и/или их удалении. Таким образом, первый набор участников, содержащихся в CML, может реализовывать распределенную базу данных в течение первого периода времени, и второй набор участников, содержащихся в CML, может реализовывать распределенную базу данных в течение второго периода времени. В таком случае, прежде чем обновить CML 1301, копию CML 1301 сохраняют в предыдущих списках 1307 составов участников (PML) и затем обновляют CML 1301. PML 1307 может быть реализован в виде структуры данных или другого логически и/или физически реализованного контейнера. PML 1307 приспособлен для вмещения атрибутов участников, связанных с предыдущими состояниями распределенной базы данных.

[1189] Цифровую подпись генерируют для каждого участника-учредителя и, в конечном итоге, для участников, не являющихся учредителями, добавленных в распределенную базу данных. Каждый участник с помощью цифровой подписи подписывает D2ID с использованием своего закрытого ключа. Например, цифровая подпись Алисы является результатом Sign (A_Private_Key, D2ID), где A_Private_Key является закрытым ключом Алисы, и D2ID является наименованием или уникальным идентификатором распределенной базы данных. В других случаях Алиса генерирует пару с уникальным идентификатором Алисы и своей подписью, например, (A_ID, Sign(A_ID, A_Private_Key, D2ID)), где идентификатор A_ID может являться ее открытым ключом, именем, цифровым сертификатом или другим подходящим идентификатором.

[1190] В некоторых реализациях цифровые подписи используют для отправки подписанных сообщений между участниками. Соответственно, подписанное сообщение может содержать результат функции Sign (K, M), где K является закрытым ключом, например, «A_Private_Key», связанным с Алисой, а M является сообщением (MSG). В некоторых случаях сообщение «MSG» может являться функцией хешированных и сцепленных данных, например, MSG=hash(x,y,z), где x, y и z могут представлять собой любой тип данных, которыми обмениваются участники распределенной базы данных (например, события, состояния распределенной базы данных, операции и т.д.). Таким образом, участники могут отправлять подписанные сообщения в форме (MSG, Sign(K, MSG), указывающей на то, что сообщение MSG подписано, например, Алисой, когда K=A_Private_Key.

[1191] В некоторых случаях составы 1303 участников и данные 1308 распределенной базы данных представляют собой две логически независимые единицы или структуры данных (например, разные базы данных, разные логически разделенные части базы данных (например, таблицы), разные структуры данных внутри одной базы данных и т.д.). Например, составы 1303 участников включают текущих и предыдущих участников, связанных с D2ID 1309, тогда как данные 1308 распределенной базы данных включают данные, связанные с текущим состоянием 1311 распределенной базы данных, включая любые созданные и/или принятые события и транзакции или операции, включенные в такие события. В других случаях составы 1303 участников и данные 1308 распределенной базы данных могут быть частью одной логической единицы или структуры данных.

[1192] Другие структуры данных, связанные с состоянием распределенной базы данных, не показанные на фиг. 13, могут содержать, например, идентификаторы, полученные на основе операций, и/или результаты операций, выполняемых над распределенной базой данных, таких как обновления, добавление новых участников, удаление участников, и другие подходящие структуры данных и/или операции, выполняемые над распределенной базой данных с течением времени. В некоторых случаях такие операции могут предоставлять историю состояний и/или участников распределенной базы данных. Например, операция ADD может быть использована для добавления новых участников в распределенную базу данных. Это может составить список идентификаторов (например, закрытых ключей, открытых ключей и/или цифровых подписей) для новых участников, присоединившихся к распределенной базе данных. В качестве другого примера, операция REMOVE может удалять одного или более текущих участников из распределенной базы данных. Это может сделать недействительным или удалить набор идентификаторов (например, закрытых ключей, открытых ключей и/или цифровых подписей), связанных с участниками, удаленными из распределенной базы данных.

[1193] Как отмечалось выше, состояние распределенной базы данных может быть определено после достижения консенсуса. Например, как только идентифицированы и/или известны все известные свидетели в раунде R, можно вычислить набор S(R) событий, которые имеют принятый раунд R, и вычислить порядок их консенсуса и метки времени их консенсуса. Затем может быть вычислено состояние STATE(R), которое представляет собой состояние базы данных, являющееся результатом транзакций в событиях, которые имеют принятый раунд R или более ранний. На том этапе порядок консенсуса для событий в S(R) известен и меняться не будет. Соответственно, в момент времени T₁ начальное состояние состояния 1311 распределенной базы данных может быть STATE(R)=«STATE1» после T₁ и до T₂. В некоторых случаях это состояние может быть подписанным значением хеша, как обсуждено более подробно в настоящем документе.

[1194] Каждая операция над базой данных может быть инициирована транзакцией в заданном событии, сгенерированном на вычислительном устройстве, реализующем распределенную базу данных. Операции над распределенной базой данных связаны с номером принятого раунда R. Например, если транзакция в событии с принятым раундом R=3 инициирует операцию над базой данных (например, ADD, REMOVE или UPDATE), такая операция над базой данных связана с принятым раундом R=3 события. В некоторых реализациях, когда операция UPDATE запускается в транзакции в событии с принятым раундом, равным 3, получают новую конфигурацию распределенной базы данных. В некоторых случаях новая конфигурация распределенной базы данных вносит участников в распределенную базу данных на основе операций ADD, инициированных во время принятого раунда R=3, и исключает участников из распределенной базы данных на основе операций REMOVE, инициированных во время принятого раунда R=3. В таком примере принятый раунд R=3 может называться порогом номера принятого раунда. В таком случае процессы консенсуса и транзакции в событиях с номером принятого раунда, который меньше или равняется R=3, выполняют согласно более старым или предыдущим конфигурациям или состояниям распределенной базы данных. Кроме того, процессы консенсуса и транзакции в событиях с принятыми раундами, превышающими R=3, выполняют с новой конфигурацией распределенной базы данных. Например, понятие «строгое видение» (как описано выше) может быть результатом определения того, удовлетворены ли определенные условия более чем 2/3 популяции. Таким образом, необходимо подсчитать количество участников во всей популяции в заданном принятом раунде. Если, например, операция ADD, приспособленная для добавления нового участника Джона в распределенную базу данных, принята распределенной базой данных в принятом раунде R=3, Джон не будет учитываться распределенной базой данных при определении размера популяции для определений относительно строгого видения и известных свидетелей в созданном раунде R=3 или раньше. В таком случае предыдущий список составов участников (т.е. список составов участников в конфигурации базы данных более старой или предыдущей конфигурации распределенной базы данных) используют для вычисления номеров раунда свидетелей при голосах, находящихся в связи с консенсусом созданного раунда R=3 и раньше, и конвергенции. Новый список составов участников используют для вычисления номеров созданного раунда для событий после свидетелей созданного раунда R=3 и для связанных голосов и конвергенции. Тогда как в приведенном выше примере Джон не будет учитываться распределенной базой данных при определении размера популяции, его события могут быть использованы до принятого раунда R=3. Например, события Джона могут быть частью пути между событием и событием-предком, которое то событие видит. Таким образом, тогда как Джон и само событие Джона не могут быть использованы событием-потомком для достижения порога «строго видит» (описан выше), событие-потомок все еще может использовать события, которые он может видеть на основе пути через события Джона для достижения порога «строго видит».

[1195] Как отмечалось выше, после того как идентифицирован полный список известных свидетелей в созданном раунде R=3, операция ADD, инициированная для добавления Джона в распределенный массив данных с принятым раундом R=3, вступает в силу при операции UPDATE. Соответственно, генерируют новую конфигурацию для распределенной базы данных, в которую Джона включают в качестве участника. Операции ADD и REMOVE включают или исключают одного или более участников популяции, зарегистрированных в распределенной базе данных, что изменяет количество участников в списке участников (или величины доли), которое используют для определения того, удовлетворены ли один или более порогов (например, порог консенсуса, приспособленный для того, чтобы составлять «более чем 2/3 популяции»). Этот новый порог используют для повторного вычисления номеров раунда (т.е. созданных раундов) для событий, которые позже, чем свидетели в созданном раунде R=3 (например, порог номера принятого раунда), и для вычисления известности свидетелей в созданных раундах R=4 и позже. Соответственно, например, заданное событие может иметь один «созданный раунд» при вычислении известности свидетелей созданного раунда R=3, затем иметь отличный «созданный раунд» при вычислении известности свидетелей созданного раунда R=4.

[1196] В некоторых случаях операции ADD, REMOVE и/или UPDATE могут быть подтверждены пороговым количеством цифровых подписей участников (также называемым пороговым значением подписей). Например, определяют, что операция UPDATE является подлинной, если более чем 2/3 участников, которые были частью распределенной базы данных непосредственно перед приемом операции UPDATE, подпишут операцию. Дополнительные подробности относительно выполнения операций над распределенной базой данных обсуждены со ссылкой на фиг. 14.

[1197] Хоть в настоящем документе и описано, что реализация новой конфигурации осуществляется, когда выполняют операцию UPDATE, в других случаях новая конфигурация реализуется автоматически (т.е. без явной инструкции UPDATE). В частности, после того как были идентифицированы все события с конкретным принятым раундом R, для идентификации событий с принятым раундом R+1 на основе таких событий может быть реализована новая конфигурация. В частности, если событие, определенное как содержащее принятый раунд R, содержит инструкцию ADD или REMOVE, то конфигурация распределенной базы данных может автоматически измениться таким образом, чтобы вычислять принятые раунды, превышающие R (т.е. превышающие порог номера принятого раунда).

[1198] В некоторых случаях операции над базой данных, такие как ADD и REMOVE, изменяют один или более порогов голосования, используемых для достижения консенсуса относительно заданного состояния распределенной базы данных. Например, распределенная база данных вычислила принятые раунды с 1 по 10 (т.е. все известные свидетели, созданные в раунде 10 или до него известны, и все еще проводится голосование с целью определения того, известны ли некоторые из свидетелей созданного раунда 11). Может быть сгенерировано событие X с созданным раундом 5, для которого принятый раунд еще не может быть вычислен. В таком случае событие X не будет иметь принятый раунд менее 11, так как уже были идентифицированы известные свидетели, имеющие созданные раунды 10 и меньше. Если событие X содержит, например, транзакцию для добавления Фрэнка (исполнения операции ADD в отношении него) в текущий список составов участников распределенной базы данных, Фрэнк не будет учитываться в качестве участника во время голосования для определения известных свидетелей, связанных с созданным раундом 11, и события, определенные Фрэнком, не будут учитываться в качестве свидетелей, которые голосуют до позже созданного раунда, когда известность каждого свидетеля в созданном раунде 11 может быть идентифицирована. В таком случае все события, которые имеют принятый раунд 11, могут быть тогда определены. Если, например, определено, что событие X имеет принятый раунд 11, Фрэнк будет добавлен в текущий список составов участников.

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

[1200] В некоторых случаях участники распределенной базы данных определяют «подписанное состояние» распределенной базы данных в заданный момент времени (или в заданном принятом раунде). «Состояние» или «текущее состояние» содержит информацию, являющуюся результатом выполнения последовательности транзакций консенсуса в их порядке консенсуса (т.е. отсортированных согласно порядку консенсуса события, содержащего каждую транзакцию, и отсортированных в подгруппы согласно порядку, в котором транзакции включены в каждое событие). После того как участник вычислит порядок консенсуса для событий, связанных с принятыми раундами до R, такой участник может с помощью цифровой подписи подписать состояние или текущее состояние (или с помощью цифровой подписи подписать значение хеша, связанное с состоянием или текущим состоянием), являющиеся результатом транзакций в порядке консенсуса (например, с использованием закрытого ключа). Факультативно или альтернативно участники могут подписывать состояние только для подмножества принятых раундов. Например, участникам может быть поручено задание подписать состояние, связанное с номером принятого раунда R, когда R кратно заданному целому числу (например, для каждого 5-го раунда) или согласно порогу времени (например, каждую 1 секунду), назначенному каждому участнику распределенной базы данных.

[1201] В некоторых реализациях «подписанное состояние» для принятого раунда R содержит один или более следующих элементов: 1) номер принятого раунда R; 2) порядковый номер и значение хеша для последнего события, сгенерированные каждым участником, который был частью консенсуса, влияющего на подписанное состояние (т.е. события с принятым раундом R или раньше); 3) структуру данных, отражающая влияние транзакций в порядке консенсуса для принятых раундов вплоть до и включая R; 4) набор цифровых подписей (или другое указание о согласии) относительно более ранних состояний с подписями более чем 2/3 списка составов участников (в некоторых случаях может быть использован другой порог, такой как, например, более чем 1/2); и/или 5) «историю состава участников». В некоторых реализациях некоторые из тех элементов могут отсутствовать (например, номер 4). В некоторых реализациях, например, «состояние» может содержать хеш всего вышеперечисленного, за исключением истории состава участников и отдельного хеша истории состава участников. В такой реализации участники могут подписывать с помощью цифровой подписи (т.е. с помощью закрытого ключа) пару хешей для получения «подписанного состояния».

[1202] В некоторых реализациях, когда первый участник подписывает состояние, генерируются транзакция с цифровой подписью, хеш состояния и номер принятого раунда. Такая транзакция приспособлена для включения в следующее событие, созданное и/или определенное первым участником. Первый участник может затем сохранить и/или внести событие в распределенную базу данных. Затем другие участники, отличные от первого участника, распознают и записывают цифровую подпись первого участника. Когда второй участник принимает количество цифровых подписей от других участников, включая цифровую подпись первого участника и других участников, связанных с заданным состоянием, превышающее порог, второй участник может идентифицировать это как подписанное состояние консенсуса. Второй участник может определить, достигает ли количество цифровых подписей порогового значения подписей (например, если заданное состояние поддерживается цифровыми подписями более чем 2/3 участников в распределенной базе данных), или иначе принять указание о согласии от других участников распределенной базы данных. После того как количество цифровых подписей достигнет порогового значения подписей, то состояние становится «подписанным состоянием». В случае наличия у участника подписанного состояния он может удалить любые события, которые внесли свой вклад в то подписанное состояние, и удалить любые предыдущие подписанные состояния. Таким образом, можно освободить память, выделяемую для хранения таких событий и предыдущего подписанного состояния, уменьшив объем хранилища, используемого хешграфом. В некоторых реализациях старые события удаляют не сразу, а только после того, как определенное количество дополнительных принятых раундов станет частью консенсуса, и/или после предопределенного периода времени.

[1203] В некоторых случаях события могут быть определены с использованием следующих критериев: 1) «событие» имеет порядковый номер, который является номером, превышающим порядковый номер его собственного родителя (или 0, если собственного родителя не было) (как описано выше); 2) «событие» содержит «созданный раунд» для каждого родителя (соответственно, оно содержит не только хеш каждого родителя, оно также содержит созданный раунд, скопированный у того родителя); и 3) событие имеет «раунд родителя», который является самым большим из созданного раунда каждого родителя (соответственно, «созданный раунд» события равен раунду родителя события плюс либо 0, либо 1).

[1204] В некоторых случаях, чтобы определить, будет ли учитываться событие в процессе консенсуса или нет, для целей этого примера используют глобальную константу «возрастной порог», называемую «А». Например, с учетом того, что A=4, если событие имеет раунд родителя R, и принятый раунд события позже, чем R+A, то: 1) событие не будет являться частью порядка консенсуса; 2) транзакции события не будут приниматься во внимание и не будут влиять на состояние консенсуса; 3) событие может быть удалено любым участником, который знает, что оно не будет принято в раунде R+A или раньше; и 4) событие не будет предотвращать «видение» в раунде R+A или позже, даже если оно является частью ответвления. Например, если Алиса принимает событие X во время процесса синхронизации после того, как Алиса уже подсчитала известных свидетелей для раундов вплоть до по меньшей мере раунда R+A, без приема события X в любом из тех раундов, то Алиса может удалить событие X. В некоторых случаях событие X не будет удалено Алисой, если это приведет к тому, что набор событий, известных заданному создателю, будет иметь несмежные порядковые номера, как обсуждено более подробно ниже со ссылкой на фиг. 16.

[1205] Тогда как на фиг. 13 проиллюстрировано начальное состояние распределенной базы данных, на фиг. 14 представлена блок-схема, на которой проиллюстрированы примеры операций UPDATE, ADD и REMOVE, выполняемых в распределенной базе данных после определения начального состояния, согласно варианту осуществления. В некоторых случаях, после того как распределенная база данных была инициализирована, как показано на фиг. 13, в распределенной базе данных для изменения участников, включенных в распределенную базу данных, могут быть выполнены одна или более операций. Например, при предоставлении D2ID распределенной базы данных с STATE(R)=«SW1» (где SW1 является текущей конфигурацией распределенной базы данных, связанной с начальным хешграфом D2ID распределенной базы данных), при этом номер принятого раунда R является самым последним подсчитанным и/или идентифицированным принятым раундом, на этапе 1421 Джон, Дженис и Чед предусмотрены для добавления в качестве участников распределенной базы данных на этапе 1423 посредством инициированной функции ADD. Конфигурация SW1 включает конфигурацию протокола консенсуса событий (или порядка консенсуса), обсужденного выше, которая не включает Джона, Дженис и Чеда в момент определения порядка событий и/или конвергенции. В некоторых случаях функция ADD на этапе 1423 может принимать открытые ключи Джона, Дженис и Чеда в качестве параметров. В этом случае каждый из новых участников также имеет связанный закрытый ключ. Участники (например, Алиса) могут также быть удалены из распределенной базы данных, как показано на этапе 1425; в этом случае операцию REMOVE инициируют с помощью открытого ключа Алисы в качестве параметра. В некоторых случаях операции ADD и REMOVE могут быть приняты участником (на вычислительном устройстве), который реализует распределенную базу данных как транзакции в наборе событий. Операции ADD и REMOVE связаны с их номером принятого раунда таким образом, что он может быть определен, когда операция ADD и/или операция REMOVE были вызваны транзакцией в событии с установленным номером принятого раунда.

[1206] Во время операции UPDATE, связанной с принятым раундом R, например, операции UPDATE на этапе 1427 текущую конфигурацию SW1 распределенной базы данных (которая включает Алису и не включает Джона, Дженис и Чеда) сохраняют в переменной PrevSW, и участники распределенной базы данных, связанные с конфигурацией PrevSW, могут быть сохранены в предыдущем списке составов участников, связанном с номером принятого раунда R. В некоторых альтернативных реализациях PrevSW может представлять собой массив объектов, содержащий множество предыдущих конфигураций распределенной базы данных. Новая конфигурация SW2 распределенной базы данных может быть сгенерирована на основе выполнения операции UPDATE в принятом раунде R, то есть STATE(R)=«SW2». Таким образом, переменную CurrentSW обновляют таким образом, чтобы она содержала новую конфигурацию SW2 распределенной базы данных (которая использует новую конфигурацию для протокола консенсуса событий).

[1207] Конфигурация SW2 включает Джона, Дженис и Чеда, но не включает Алису, и, таким образом, Алиса не будет включена в определение порядков консенсуса или конвергенции, когда распределенная база данных использует конфигурацию SW2. Другими словами, обновленная конфигурация SW2 распределенной базы данных отражает изменения в текущем списке участников, приспособленном для того, чтобы отражать измененную конфигурацию распределенной базы данных (например, добавление новых участников Джона, Дженис и Чеда и удаление Алисы). В некоторых случаях обновленный набор пар ключей участников, включая новые пары ключей для Джона, Дженис и Чеда и исключая Алису, включен в текущую конфигурацию CurrentSW распределенной базы данных. В некоторых случаях состояние распределенной базы данных в этот момент времени может также включать операции, выполненные над распределенной базой данных до момента выполнения обновления, включая операции ADD, операции REMOVE, операции UPDATE и/или другие подходящие операции.

[1208] В некоторых случаях, когда участников текущего списка составов участников распределенной базы данных поменяли с помощью, например, операций ADD, REMOVE, UPDATE и/или других подходящих операций, события могут быть обработаны согласно различным конфигурациям распределенной базы данных. В примере, показанном на фиг. 14, когда событие принимают на этапе 1429, идентифицируют и/или подсчитывают принятый раунд R’, связанный с таким событием. Если, например, принятый раунд R’ события идентифицирован таким образом, что он меньше или равен принятому раунду, в котором функционирует распределенная база данных, R, как показано на этапе 1431, такое событие обрабатывают с помощью, например, предыдущего списка составов участников, связанного с предыдущей версией конфигурации распределенной базы данных (например, списка составов участников, сохраненного в предыдущих списках 1307 составов участников, обсужденных со ссылкой на фиг. 13). Другими словами, событие на этапе 1433 будет обработано для консенсуса или конвергенции с использованием, например, конфигурации SW1 распределенной базы данных со списком составов участников, включающим Алису, Боба, Кэрол, Дейва и Эда и не включающим Джона, Дженис и Чеда (как описано выше). В противоположном сценарии на этапе 1435, когда номер принятого раунда события превышает номер принятого раунда, в котором изменилась конфигурация (например, все известные свидетели, имеющие такие созданные раунды и меньше, уже были идентифицированы, и событие еще не увидело достаточное количество из них для того, чтобы уже быть принятым), такое событие обрабатывают с помощью обновленной версии распределенной базы данных. То есть с помощью конфигурации SW2 распределенной базы данных с текущим списком составов участников, включающим Боба, Кэрол, Дэйва, Эда, Джона, Дженис и Чеда, за исключением Алисы. Соответственно, в некоторых случаях порядок событий может быть определен на основе более чем одной конфигурации распределенной базы данных (или конфигурации протокола консенсуса событий) и, таким образом, новых состояний экземпляра распределенной базы данных. Как отмечалось выше, значение хеша может быть вычислено для состояния распределенной базы данных и подписано с использованием закрытых ключей участников распределенной базы данных. Участник, например, участник, который подписал состояние распределенной базы данных, может отправлять сигнал для внесения в экземпляр распределенной базы данных события, содержащего транзакцию, указывающую на новое подписанное состояние.

[1209] В некоторых случаях участник распределенной базы данных может сохранять и/или вносить в распределенную базу данных операцию UPDATE, ADD и/или REMOVE как транзакцию (или набор транзакций), включенную в одно или более событий. Это событие затем может быть отправлено другому участнику распределенной базы данных (например, как часть процесса синхронизации). Например, первый участник может принять операцию ADD для добавления нового участника в распределенную базу данных в транзакции, включенной в событие, отправленное вторым участником распределенной базы данных как часть процесса синхронизации. В качестве другого примера, первый участник может принять операцию REMOVE для удаления участника из распределенной базы данных в транзакции, включенной в событие, отправленное третьим участником как часть процесса синхронизации. Другими словами, каждый участник распределенной базы данных может определять события с транзакциями, включающими любую из операций UPDATE, ADD и/или REMOVE, и отправлять такие события другим участникам распределенной базы данных как часть процесса синхронизации.

[1210] Процесс, проиллюстрированный на фиг. 14, можно повторять и обновлять для событий в каждом новом принятом раунде. Таким образом, поскольку принятый раунд идентифицируют для каждого события, конфигурация распределенной базы данных (или конфигурация протокола консенсуса событий) может быть обновлена. Более того, хоть выше и было представлено описание в отношении двух конфигураций, последующая конфигурация распределенной базы данных с STATE(R)=«SW3» (и дополнительные будущие конфигурации) может быть определена аналогично тому, что было описано в отношении SW2. Таким образом, в некоторых случаях распределенная база данных может функционировать с использованием третьей конфигурации распределенной базы данных (например, которая использует третью конфигурацию для протокола консенсуса событий). Таким образом, распределенная база данных может продолжать определять и/или функционировать с новыми конфигурациями по мере того, как новые события с такими транзакциями вносятся в распределенную базу данных.

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

[1212] Процессы, проиллюстрированные на фиг. 15 и фиг. 16, могут быть выполнены во время синхронизации событий между двумя участниками распределенной базы данных. На фиг. 15 представлена блок-схема, на которой проиллюстрированы принятие и отклонение событий на основе принятых раундов. В некоторых случаях, например, во время синхронизации распределенных баз данных, связанных с различными участниками, событие может быть отклонено или принято на основе (1) самого последнего номера раунда R, в котором все известные свидетели были идентифицированы и/или в отношении них были приняты решения, (2) каждого из родителей event.Parent[i] относительно того, что событие включает в список то же, что и его родитель, и (3) каждого соответствующего event.ParentRoundCreated[i] относительно того, что событие включает в список то же, что и созданный раунд того родителя. Следует отметить, что фактический родитель может иметь созданный раунд, отличающийся от созданного раунда, включенного в список для того родителя в принятом событии-ребенке. Это объясняется тем, что созданный раунд события может изменяться по мере того, как добавляют или удаляют участников, следовательно, возможно, что родитель имел один принятый раунд, когда был создан ребенок, и другой раунд позже. Перед участниками ставят задачу быть как можно более точными при присвоении номеров ParentRoundCreated.

[1213] Вычислительная нагрузка и ресурсы памяти могут быть преимущественно снижены в некоторых случаях. Например, когда первый участник (например, первое вычислительное устройство) принимает событие на свой локальный экземпляр распределенной базы данных от второго участника (например, второго вычислительного устройства) распределенной базы данных на этапе 1551. Такое событие может содержать последовательность байтов, которые указывают на набор событий-родителей. Каждое событие-родитель из набора событий-родителей может находиться в логической связи со значением хеша и значением созданного раунда. Чтобы определить, удовлетворен ли первый критерий, первый участник определяет на этапе 1553, (1) отсутствует ли по меньшей мере один родитель принятого события (как указано в принятом событии) в экземпляре распределенной базы данных первого участника и (2) имеет ли родитель принятого события включенный в список созданный раунд в принятом событии, которое превышает R минус предопределенное пороговое значение (например, Threshold1). В некоторых случаях, когда событие отвечает этим условиям (т.е. удовлетворяет первому критерию), первый участник отклоняет или исключает событие на этапе 1559. Например, когда событие имеет родителя, который имеет включенный в список созданный раунд, который представляет собой R минус Threshold1 или меньше (т.е. меньше или равно первому порогу созданного раунда R-Threshold1), того родителя можно считать уже удаленным (например, достаточно старым для того, чтобы быть удаленным), следовательно, принятое событие потенциально может быть принято, несмотря на отсутствие родителя (в зависимости от этапа 1555, описанного ниже). Но в случае отсутствия родителя, который не является достаточно старым для того, чтобы быть удаленным, событие может быть отклонено на этапе 1559 по причине отсутствия его родителя. В некоторых реализациях, когда событие не отвечает условиям на этапе 1553, событие оценивают по второму критерию на этапе 1555, чтобы определить, имеет ли каждый родитель события включенный в список созданный раунд до R минус предопределенное пороговое значение (например, меньше, чем второй порог созданного раунда R-Threshold2). Если это так (т.е. если второй критерий удовлетворен), то событие отклоняют или исключают на этапе 1559, в противном случае его принимают на этапе 1557. Это решение позволяет удалять события, когда становится ясно, что они не будут использованы (например, для определения консенсуса и/или для оказания влияния на состояние распределенной базы данных). Например, если все включенные в список родители очень старые, то принятое событие будет само считаться достаточно старым для удаления, следовательно, оно может быть удалено, как только будет принято. В этих примерах принятые события принимают, если все родители присутствуют, за исключением очень старых событий (на основе Threshold1), и само событие не очень старое (на основе Threshold2). Первый участник (или первое вычислительное устройство) может сохранять в экземпляре распределенной базы данных события, принятые на этапе 1557 (т.е. события, которые не были отклонены или исключены на этапе 1559). В некоторых реализациях Threshold1 и/или Threshold2 могут быть предварительно определены участниками распределенной базы данных. В некоторых реализациях Threshold1 может иметь то же самое значение, что и Threshold2, или значение, отличное от него.

[1214] На фиг. 16 представлена блок-схема, на которой проиллюстрирован процесс верификации, выполняемый во время синхронизации события между двумя участниками распределенной базы данных. Первый участник или первое вычислительное устройство может отправлять запрос синхронизации другому участнику распределенной базы данных для начала процесса синхронизации. В некоторых реализациях синхронизацию между первым участником и вторым участником распределенной базы данных осуществляют, как описано ниже. Например, если первым участником является Боб, и вторым участником является Алиса, то синхронизация может быть выполнена на основе первого и последнего порядкового номеров и/или значений, которые Алиса приняла для каждого участника в заданной конфигурации распределенной базы данных. Такие порядковые номера и/или значения могут быть отправлены в составе запроса синхронизации между участниками, и участники могут обмениваться событиями, которые еще не приняты и/или сохранены другим участником. Таким образом, в некоторых случаях не осуществляется обмен событиями, уже принятыми и/или сохраненными, уменьшая полосу пропускания, используемую во время процесса синхронизации.

[1215] С точки зрения Алисы она может использовать первый и последний порядковые номера, которые она имеет для событий, созданных и/или определенных Бобом, Кэрол, Эдом и Дэйвом. Таким образом, например, Алиса может определить на основе событий, принятых на ее экземпляре распределенной базы данных (например, событий, созданных и/или определенных экземпляром Эда распределенной базы данных), что события, определенные Эдом, имеющие больший порядковый номер, чем последний порядковый номер для события, принятого на экземпляре Алисы распределенной базы данных для Эда, являются событиями, которые Алиса еще не приняла. Боб затем может отправлять те события Алисе. Аналогично Алиса может определить на основе событий, принятых на экземпляре Алисы распределенной базы данных, для заданного участника, например, Эда, что любое событие, сохраненное Бобом для того участника, имеющее порядковый номер, который меньше, чем первый порядковый номер для того участника, сохраненный на экземпляре Алисы распределенной базы данных, является событием, которое экземпляр Алисы распределенной базы данных отклонил или удалил (например, на основе подписанного состояния, как описано выше).

[1216] В некоторых реализациях Алиса (или любой другой участник) не удаляет или не отклоняет события, порядковый номер которых находится между первым и последним порядковыми номерами событий, сохраненных на экземпляре Алисы распределенной базы данных для заданного участника (например, Эда). В других случаях во время синхронизации экземпляр Алисы распределенной базы данных может удалять старые события, которые являются либо частью подписанного состояния, либо событиями, которые не будут иметь номер принятого раунда в диапазоне, определенном одним или более порогами, как обсуждено со ссылкой на фиг. 15.

[1217] Во время синхронизации локальный экземпляр распределенной базы данных, связанный с первым участником (например, Алисой), может отклонить событие от Боба, если такое событие содержит значение хеша событий-родителей, которые Алиса еще не приняла на своем локальном экземпляре распределенной базы данных. Однако в некоторых случаях локальный экземпляр распределенной базы данных, связанный с Алисой, может принимать такое событие, даже если родители события не включены в локальный экземпляр распределенной базы данных, связанный с Алисой, если, например, имеется указание, что Алиса должна была удалить родителей принятого события. Примеры событий, которые локальный экземпляр базы данных, связанный с Алисой, обычно удалил бы, включают события, имеющие родителей, связанных с номером принятого раунда, которые являются достаточно старыми, так что Алиса может определять, что событие может быть удалено, так как событие не оказывало бы никакого влияния на состояние распределенной базы данных, и/или его влияние уже включено в последнее подписанное состояние в локальном экземпляре распределенной базы данных, связанном с Алисой.

[1218] В некоторых случаях первый участник (например, Алиса) принимает на этапе 1601 на своем локальном экземпляре распределенной базы данных событие X с нелокального экземпляра распределенной базы данных, например, нелокального экземпляра, связанного с Бобом. После этого набор подписей может быть извлечен из события X на этапе 1603. На этапе 1605 процесс верификации подписи выполняют для определения того, проходит ли набор подписей, извлеченных из события X, процесс верификации. В некоторых случаях событие X не проходит процесс верификации, когда на основе подписи, извлеченной из события X (принятого Алисой), Алиса может определить, что событие X имеет, например, событие-родителя Y с заданным создателем (например, Эдом) и заданным порядковым номером (например, SN=3), и локальный экземпляр распределенной базы данных, связанный с Алисой, содержит событие Z с событием-родителем Y, тем же самым создателем (т.е. Эдом) и тем же самым порядковым номером (т.е. SN=3). Соответственно, процесс верификации не имеет успеха, когда имеется аномалия в распределенной базе данных, которая может быть вызвана экземпляром распределенной базы данных, определяющим ответвляющиеся события.

[1219] На этапе 1607, когда Алиса определяет, что событие X не прошло верификацию подписи на этапе 1605, локальный экземпляр распределенной базы данных Алисы отправляет сообщение с уведомлением о неудаче на нелокальный экземпляр распределенной базы данных Боба, указывающее на то, что событие X не прошло процесс верификации. После этого на этапе 1609 локальный экземпляр распределенной базы данных принимает значения хеша, связанные с событиями, которые являются родителями события X. Локальный экземпляр распределенной базы данных затем может сравнить принятые значения хеша, связанные с событиями, которые являются родителями события X, и определять, отсутствуют ли одно или более событий в нелокальном экземпляре распределенной базы данных, например, события, которые являются родителями события X. Соответственно, на этапе 1611 локальный экземпляр распределенной базы данных отправляет на нелокальный экземпляр распределенной базы данных хеши событий, которые отсутствуют в нелокальном экземпляре распределенной базы данных. Последовательность процесса продолжается в цикле, начинаясь на этапе 1601.

[1220] В некоторых случаях, когда событие, принятое локальным экземпляром распределенной базы данных (например, Алисой), проходит процесс верификации на этапе 1605, Алиса может определить, был ли идентифицирован вопрос ответвления во время процесса синхронизации (например, синхронизации событий между двумя участниками). Когда идентифицирован вопрос ответвления, локальный экземпляр распределенной базы данных (например, Алиса) отправляет на нелокальный экземпляр распределенной базы данных (например, Бобу) указатель (например, значение хеша) об одном или более событиях, которые являются предками (например, родителями) события X, которое было определено как включенное в и/или испытавшее влияние идентифицированного вопроса ответвления, и затем процесс завершается. В некоторых случаях, когда во время процесса синхронизации не было идентифицировано никаких вопросов ответвления, например, когда событие X, принятое на этапе 1601, проходит процесс верификации подписи на этапе 1605, процесс завершается.

[1221] В некоторых случаях событие X и событие Y вместе являются «ответвлениями», если они имеют одного и того же создателя и один и тот же созданный раунд, и ни один из них не является предком другого. Это является вариацией использования вопроса «ответвления», обсужденного выше со ссылкой на фиг. 9, с дополнительным ограничением, оговаривающим, что ответвляющиеся события X и Y имеют один и тот же принятый раунд. Более того, в некоторых случаях определение «видит» и «строго видит», как описано выше, может быть изменено на основе этого альтернативного определения «ответвления». Например, событие X может «видеть» событие Y, если и только если событие Y является предком события X, и ни одно событие Z не является предком события X и «ответвлением» события Y. Событие X может «строго видеть» событие Y, если и только если имеется набор S событий, созданных более чем M (например, 2/3) участниками распределенной базы данных таким образом, что событие X может видеть каждое событие в S, и каждое событие в S может видеть событие Y.

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

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

[1224] В некоторых случаях, когда два события, например, событие X и событие Y, которые синхронизируют, не являются находящимися в связи (т.е. ни одно не является прямым потомком другого), и если отправка события X будет означать, что глобальный лимит количества байтов (Bx), связанный с первым участником, достигнут во время текущего процесса синхронизации для событий, созданных создателем события X (и аналогично глобальный лимит для байтов, связанный со вторым участником (By), создателем события Y), то процесс синхронизации включает отправку события X до события Y, если Bx<By, и отправку события Y до события X, если By<Bx, и может отправлять их в любом порядке, если Bx=By. Это предотвращает управление большими событиями процессом синхронизации.

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

[1226] Несмотря на то, что примерные системы, показанные и описанные выше, описаны со ссылкой на другие системы, в других вариантах осуществления любая комбинация примерных систем и связанных с ними функциональных возможностей может быть реализована для создания и/или определения распределенной базы данных. Например, примерная система 1, примерная система 2 и примерная система 3 могут быть объединены для создания и/или определения распределенной базы данных. В качестве другого примера, в некоторых вариантах осуществления примерная система 10 может быть реализована вместе с примерной системой 1, но без примерной системы 9. В качестве еще одного примера, примерная система 7 может быть объединена и реализована вместе с примерной системой 6. В еще других вариантах осуществления могут быть реализованы любые другие подходящие комбинации примерных систем.

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

[1228] Некоторые варианты осуществления, описанные в настоящем документе, относятся к продукту в виде запоминающего устройства с энергонезависимым машиночитаемым носителем (который также может называться энергонезависимым считываемым процессором носителем), на котором хранятся инструкции или компьютерный код для выполнения различных реализуемых компьютером операций. Машиночитаемый носитель (или считываемый процессором носитель) является энергонезависимым в том смысле, что он по существу не содержит временно распространяющихся сигналов (например, распространяющейся электромагнитной волны, несущей информацию по передающей среде, такой как пространство или кабель). Носители и компьютерный код (который также может называться кодом) могут быть выполнены и созданы для конкретной цели или целей. Примеры энергонезависимых машиночитаемых носителей включают, помимо прочего: магнитные запоминающие устройства, такие как жесткие диски, гибкие диски и магнитная лента; оптические запоминающие устройства, такие как компакт-диск / цифровые видеодиски (CD/DVD), постоянные запоминающие устройства на компакт-дисках (CD-ROM) и голографические устройства; магнитооптические запоминающие устройства, такие как оптические диски; модули обработки сигнала несущей частоты; и аппаратные устройства, которые специально приспособлены для хранения и исполнения программного кода, такие как интегральные схемы специального назначения (ASIC), программируемые логические интегральные схемы (PLD), постоянные запоминающие устройства (ROM) и оперативные запоминающие устройства (RAM). Другие варианты осуществления, описанные в настоящем документе, относятся к компьютерному программному продукту, который может включать, например, инструкции и/или компьютерный код, обсуждаемые в настоящем документе.

[1229] Примеры компьютерного кода включают, помимо прочего, микрокод или микроинструкции, машинные инструкции, такие как созданные компилятором, код, используемый для создания веб-службы, и файлы, содержащие инструкции более высокого уровня, которые исполняются компьютером с использованием интерпретатора. Например, варианты осуществления могут быть реализованы с использованием императивных языков программирования (например, C, Fortran и т.д.), функциональных языков программирования (Haskell, Erlang и т.д.), логических языков программирования (например, Prolog), объектно-ориентированных языков программирования (например, Java, C++ и т.д.) или других подходящих языков программирования и/или инструментов разработки. Дополнительные примеры компьютерного кода включают, помимо прочего, сигналы управления, зашифрованный код и сжатый код.

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

Claims (54)

1. Устройство для реализации распределенной базы данных, содержащее:

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

процессор, функционально соединенный с памятью,

при этом процессор приспособлен для:

приема события со второго вычислительного устройства из множества вычислительных устройств, при этом событие представляет собой последовательность байтов, связанных с набором событий-родителей, при этом каждое событие-родитель из набора событий-родителей связано со (1) значением хеша и (2) значением созданного раунда,

исключения принятого события из определения порядка событий, когда по меньшей мере один из первого критерия или второго критерия удовлетворен, при этом первый критерий удовлетворен, когда:

(1) по меньшей мере одно событие-родитель из набора событий-родителей не имеет идентификатора в экземпляре распределенной базы данных, и

(2) по меньшей мере одно событие-родитель связано со значением созданного раунда, которое превышает первый порог созданного раунда, и

второй критерий удовлетворен, когда:

(1) первый критерий не удовлетворен, и

(2) каждое событие-родитель из набора событий-родителей связано со значением созданного раунда, которое меньше, чем второй порог созданного раунда, и

сохранения события в экземпляре распределенной базы данных, когда событие не исключено на основе первого критерия или второго критерия.

2. Устройство по п. 1, отличающееся тем, что первый порог созданного раунда основан на текущем номере принятого раунда, идентифицированном экземпляром распределенной базы данных.

3. Устройство по п. 1, отличающееся тем, что второй порог созданного раунда основан на текущем номере принятого раунда, идентифицированном экземпляром распределенной базы данных.

4. Устройство по п. 1, отличающееся тем, что первый порог созданного раунда соответствует второму порогу созданного раунда.

5. Устройство по п. 1, отличающееся тем, что первый порог созданного раунда отличается от второго порога созданного раунда.

6. Устройство по п. 1, отличающееся тем, что принятое событие содержит набор транзакций, при этом принятое событие исключают из определения порядка событий в первый момент времени, и набор транзакций выполняют во второй момент времени до первого момента времени.

7. Способ реализации распределенной базы данных, включающий:

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

отклонение события, когда по меньшей мере один из первого критерия или второго критерия удовлетворен, при этом первый критерий удовлетворен, когда:

(1) идентификатор для по меньшей мере одного события-родителя из набора событий-родителей не находится в экземпляре распределенной базы данных на первом вычислительном устройстве, и

(2) значение атрибута для по меньшей мере одного события-родителя больше, чем первый порог атрибута, и

второй критерий удовлетворен, когда:

(1) первый критерий не удовлетворен, и

(2) значение атрибута для каждого события-родителя из набора событий-родителей меньше, чем второй порог атрибута, и

сохранение события в экземпляре распределенной базы данных, когда событие не отклонено на основе первого критерия или второго критерия.

8. Способ по п. 7, отличающийся тем, что событие содержит значение атрибута для каждого события-родителя из набора событий-родителей.

9. Способ по п. 7, отличающийся тем, что событие содержит значение атрибута для каждого события-родителя из набора событий-родителей, причем значение атрибута представляет собой созданный раунд каждого события-родителя из набора событий-родителей, первый порог атрибута представляет собой первый порог созданного раунда, и второй порог атрибута представляет собой второй порог созданного раунда.

10. Способ по п. 7, отличающийся тем, что идентификатор каждого события-родителя из набора событий-родителей представляет собой значение хеша, связанное с этим событием-родителем из набора событий-родителей.

11. Способ по п. 7, отличающийся тем, что дополнительно включает:

вычисление с использованием протокола консенсуса порядка консенсуса множества событий на основе по меньшей мере частично события и идентификатора каждого события-родителя из набора событий-родителей, когда событие не отклонено на основе первого критерия или второго критерия.

12. Способ по п. 7, отличающийся тем, что дополнительно включает:

определение направленного ациклического графа (DAG) на основе по меньшей мере частично события и идентификатора каждого события-родителя из набора событий-родителей, когда событие не отклонено на основе первого критерия или второго критерия; и

вычисление порядка консенсуса множества событий на основе DAG.

13. Способ по п. 7, отличающийся тем, что первый порог атрибута соответствует второму порогу атрибута.

14. Способ по п. 7, отличающийся тем, что первый порог атрибута отличается от второго порога атрибута.

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

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

исключить событие из определения порядка событий, когда:

(1) идентификатор для по меньшей мере одного события-родителя из набора событий-родителей не находится в экземпляре распределенной базы данных на первом вычислительном устройстве, и

(2) значение атрибута для по меньшей мере одного события-родителя больше, чем порог атрибута; и

сохранить событие в экземпляре распределенной базы данных, когда событие не исключено.

16. Энергонезависимый считываемый процессором носитель по п. 15, отличающийся тем, что порог атрибута представляет собой первый порог атрибута, причем энергонезависимый считываемый процессором носитель дополнительно содержит код для предписывания процессору:

исключить событие из определения порядка событий, когда:

(1) идентификатор для по меньшей мере одного события-родителя из набора событий-родителей находится в экземпляре распределенной базы данных на первом вычислительном устройстве, или (2) значение атрибута для по меньшей мере одного события-родителя не превышает первый порог атрибута, и

значение атрибута для каждого события-родителя из набора событий-родителей меньше, чем второй порог атрибута.

17. Энергонезависимый считываемый процессором носитель по п. 15, отличающийся тем, что значение атрибута для каждого события-родителя из набора событий-родителей представляет собой значение созданного раунда для этого события-родителя.

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

19. Энергонезависимый считываемый процессором носитель по п. 15, отличающийся тем, что набор событий-родителей содержит множество событий-родителей.

20. Энергонезависимый считываемый процессором носитель по п. 15, отличающийся тем, что дополнительно содержит код для предписывания процессору:

определить направленный ациклический граф (DAG) на основе по меньшей мере частично события и идентификатора каждого события-родителя из набора событий-родителей, когда событие не исключено; и

вычислить порядок консенсуса множества событий на основе DAG.

21. Энергонезависимый считываемый процессором носитель по п. 15, отличающийся тем, что дополнительно содержит код для предписывания процессору:

вычислить, когда событие не исключено, и с использованием протокола консенсуса порядок консенсуса множества событий на основе по меньшей мере частично события и идентификатора каждого события-родителя из набора событий-родителей.

Images