Способ и устройство консенсуса на основе блокчейна
Группа изобретений относится к средствам, обеспечивающим консенсус данных на основе блокчейна. Технический результат заключается в повышении вероятности соответствия данных при осуществлении процедуры консенсуса, тем самым повышая эффективность обработки услуги блокчейна. Один узел блокчейна включает в себя первый сервер, второй сервер и по меньшей мере одну базу данных. В способе осуществляют хранение в базе данных данных консенсуса, необходимых для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса; получение вторым сервером вместо первого сервера данных консенсуса из базы данных, и исполнение процедуры консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса; и сохранение вторым сервером результата консенсуса в базе данных. В соответствии с реализацией настоящей заявки исправный сервер в узле может получать, вместо неисправного сервера, данные консенсуса из базы данных, чтобы исполнять процедуру консенсуса. 2 н. и 9 з.п. ф-лы, 8 ил.
ОБЛАСТЬ ТЕХНИКИ
[0001] Настоящая заявка относится к области компьютерных технологий и, в частности, к способу и устройству консенсуса на основе блокчейна.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
[0002] В настоящее время, технология блокчейна широко применяется, и ее децентрализованный режим гарантирует, что данные не просто фальсифицировать, тем самым улучшая безопасность.
[0003] В практическом сценарии применения, блокчейн может обеспечить соответствующую услугу для клиента, и узел блокчейна может обрабатывать запрос услуги пользователя и формировать соответствующий результат обработки. Однако блокчейн может содержать злонамеренный узел или неисправный узел. Он, несомненно, оказывает влияние на услугу, получаемую клиентом. Поэтому, например, процедура консенсуса, основанная на Practical Byzantine Fault Tolerance (PBFT, практическая устойчивость к византийской проблеме), может выполняться между узлами в блокчейне, так что узлы могут достигать соглашения по корректному результату обработки.
[0004] Процедура консенсуса на основе PBFT используется в качестве примера. Как показано на фиг. 1, процедура консенсуса на основе PBFT включает в себя стадию пред-подготовки (pre-prepare), стадию подготовки (prepare) и стадию фиксации (commit). Узел (узел, пронумерованный 0 на фиг. 1), который принимает запрос услуги от клиента (представлен как С на фиг. 1), отправляет запрос услуги на другие узлы (например, узлы, пронумерованные как 1, 2 и 3) для выполнения процедуры консенсуса. На каждой стадии, узлы отправляют сообщение консенсуса друг другу, так что узлы выполняют процедуру консенсуса. После трехэтапной процедуры консенсуса, может считаться, что консенсус достигнут. В этом случае, узлы отдельно обрабатывают запрос услуги, и каждый возвращает результат обработки клиенту.
[0005] В некоторых сценариях в существующей технологии, чтобы обрабатывать большое количество процедур консенсуса, обычно множество серверов располагается в каждом узле в вышеописанном блокчейне, и различные серверы могут отдельно участвовать в различных процедурах консенсуса, чтобы улучшить объем обработки и эффективность обработки блокчейна.
[0006] Однако, на практике, сервер в узле может быть неисправен, например, может находиться в состоянии офлайн или перезапускаться. Например, в процедуре консенсуса на основе PBFT, как только сервер становится неисправным, сервер не может продолжать участвовать в консенсусе и оказывает влияние на вероятность достижения консенсуса. Если консенсус не достигнут в некотором раунде (цикле), консенсус требуется повторно инициировать со стадии пред-подготовки, независимо от стадии консенсуса, на которой в текущее время находится блокчейн. Очевидно, это явно влияет на эффективность консенсуса блокчейна, а также влияет на эффективность обработки услуги блокчейна.
КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
[0007] Реализации настоящей заявки обеспечивают способ и устройство консенсуса на основе блокчейна, чтобы разрешить существующую проблему, состоящую в том, что эффективность консенсуса относительно низка, когда сервер в узле является неисправным.
[0008] Реализация настоящей заявки обеспечивает способ консенсуса на основе блокчейна. Один узел блокчейна включает в себя первый сервер, второй сервер и по меньшей мере одну базу данных. Способ включает в себя: хранение, базой данных, данных консенсуса, необходимых для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса; получение, вторым сервером вместо первого сервера, данных консенсуса из базы данных, и исполнение процедуры консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса; и сохранение, вторым сервером, результата консенсуса в базе данных.
[0009] Реализация настоящей заявки обеспечивает устройство консенсуса на основе блокчейна, причем один узел блокчейна включает в себя первый сервер, второй сервер и по меньшей мере одну базу данных; база данных хранит данные консенсуса, необходимые для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса; первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса; и устройство включает в себя: модуль получения, сконфигурированный, чтобы получать данные консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса; модуль исполнения консенсуса, сконфигурированный, чтобы исполнять процедуру консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса; и модуль хранения, сконфигурированный, чтобы сохранять сообщение консенсуса и результат консенсуса в базе данных.
[0010] В соответствии со способом консенсуса на основе блокчейна и устройством, обеспеченным в реализациях настоящей заявки, для каждого сервера в узле блокчейна, сервер, участвующий в определенной процедуре консенсуса "публично" сохраняет сообщения консенсуса на различных стадиях консенсуса или результат консенсуса, сформированный сервером на текущей стадии. Иными словами, сервер сохраняет, в базе данных в узле блокчейна, сообщения консенсуса на различных стадиях консенсуса или результат консенсуса, сформированный сервером на текущей стадии, и база данных может быть использована для всех серверов в узле блокчейна. По существу, если сервер, участвующий в некотором раунде консенсуса, неисправен, например, находится в состоянии офлайн или перезапускается, данные консенсуса сервера могут быть использованы другим сервером в узле блокчейна, и другой сервер может продолжить исполнение соответствующей процедуры консенсуса вместо неисправного сервера.
[0011] Очевидно, что по сравнению существующей технологией, в способе, когда каждый сервер в узле блокчейна сохраняет данные консенсуса в базе данных в узле блокчейна, даже когда определенный сервер неисправен, нормально работающий сервер может получить соответствующие данные консенсуса из базы данных и завершить консенсус вместо неисправного сервера. Это гарантирует нормальное исполнение процедуры консенсуса и может повысить вероятность успеха процедуры консенсуса в определенной степени, в то время как число раз повторного инициирования консенсуса сокращается, тем самым повышая эффективность обработки услуги блокчейна.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0012] Прилагаемые чертежи, описанные здесь, предназначены для обеспечения дополнительного понимания настоящей заявки и составляют часть настоящей заявки. Иллюстративные реализации настоящей заявки и описания реализаций предназначены для описания настоящей заявки и не налагают ограничений на настоящую заявку. На прилагаемых чертежах:
[0013] Фиг. 1 иллюстрирует процедуру консенсуса на основе PBFT в существующей технологией;
[0014] Фиг. 2a иллюстрирует архитектуру блокчейна в процедуре консенсуса на основе блокчейна, в соответствии с реализацией настоящей заявки;
[0015] Фиг. 2b иллюстрирует архитектуру узла блокчейна в процедуре консенсуса на основе блокчейна, в соответствии с реализацией настоящей заявки;
[0016] Фиг. 2c иллюстрирует процедуру консенсуса на основе блокчейна на стороне сервера, в соответствии с реализацией настоящей заявки;
[0017] Фиг. 2d иллюстрирует архитектуру другого типа узла блокчейна, в соответствии с реализацией настоящей заявки;
[0018] Фиг. 3a и фиг. 3b являются схематичными диаграммами, иллюстрирующими процесс смены сервера в той же самой процедуре консенсуса, в соответствии с реализацией настоящей заявки; и
[0019] Фиг. 4 является схематичной структурной диаграммой, иллюстрирующей устройство консенсуса на основе блокчейна на стороне сервера, в соответствии с реализацией настоящей заявки.
ОПИСАНИЕ РЕАЛИЗАЦИЙ
[0020] Для пояснения задач, технических решений и преимуществ настоящей заявки, последующее описание ясно и полностью характеризует технические решения настоящей заявки со ссылкой на конкретные реализации и соответствующие прилагаемые чертежи настоящей заявки. Очевидно, описанные реализации представляют собой только некоторые, но не все из реализаций настоящей заявки. Все другие реализации, полученные специалистом в данной области техники на основе реализаций настоящей заявки без приложения творческих усилий, должны соответствовать объему защиты настоящей заявки.
[0021] Как описано выше, в течение любого времени консенсуса, исполняемого среди узлов в блокчейне, сервер, участвующий в текущее время консенсуса в любом узле, может стать неисправным, например, может оказаться офлайн или перезапускаться, и, следовательно, сервер не может продолжать участие в консенсусе. Поэтому вероятность успеха консенсуса может быть снижена. В частности, в случае консенсуса на основе PBFT, определенное число неуспехов консенсуса может запустить механизм сборки мусора (очистки памяти) при PBFT, чтобы очистить данные консенсуса в каждом сервере. Очевидно, что это явно оказывает влияние на обработку услуги блокчейна.
[0022] На основе предшествующих описаний, реализации настоящей заявки обеспечивают способ консенсуса на основе блокчейна. В способе, данные консенсуса сохраняются в базе данных в узле блокчейна, так что когда сервер становится неисправным (офлайн или перезапускается), нормально работающий сервер в узле блокчейна может также считывать данные консенсуса, которые сохранены в базе данных, и продолжать исполнение процедуры консенсуса вместо неисправного сервера. Конечно, способ консенсуса на основе блокчейна в реализации настоящей заявки не ограничен только процедурой консенсуса на основе PBFT и может дополнительно использоваться в процедуре консенсуса, которая основана на алгоритме консенсуса, таком как Paxos.
[0023] Следует отметить, что, в реализации настоящей заявки, архитектура, используемая в способе консенсуса на основе блокчейна, показана на фиг. 2a. Можно видеть из фиг. 2a, что блокчейн включает в себя множество узлов блокчейна. Для простоты последующего описания, узел блокчейна кратко упоминается ниже как узел.
[0024] Множество клиентов могут выполнять взаимодействие услуги с блокчейном. Блокчейн может быть консорциумным блокчейном и/или частным блокчейном, который обеспечивает услугу для пользователя. Клиент может включать в себя браузер, приложение и т.д. Клиент может работать в терминале, сервере, базе данных и т.д. Реализации здесь конкретно не ограничены.
[0025] На основе архитектуры, показанной на фиг. 2a, архитектура любого узла может быть показана на фиг. 2b. Можно видеть из фиг. 2b, что узел включает в себя n серверов и одну базу данных, совместно используемую серверами. Различные серверы могут участвовать в различных процедурах консенсуса, и серверы могут работать независимо друг от друга. База данных сконфигурирована, чтобы обеспечивать услугу хранения данных для серверов в узле. Иными словами, каждый сервер может сохранять соответствующие данные консенсуса в базе данных в процедуре консенсуса. Конечно, число баз данных в узле, показанном на фиг. 2b, является просто типичным числом. На практике, число баз данных в узле может корректироваться на основе реальной потребности. Кроме того, в некоторых сценариях, сервер в узле может быть заменен устройством, которое имеет функцию обработки вычислений, таким как компьютер.
[0026] Кроме того, следует отметить, что, для простоты описания, в дальнейшем описании, сервер, который может стать неисправным во время работы, упоминается как первый сервер, а сервер, который может нормально работать, упоминается как второй сервер. Поэтому в архитектуре, показанной на фиг. 2b, можно считать, что архитектура включает в себя два типа серверов: первый сервер и второй сервер. Вышеизложенное описание не должно толковаться как ограничение настоящей заявки.
[0027] На основе архитектуры отношений, показанной на фиг. 2b, реализация настоящей заявки обеспечивает процедуру консенсуса на основе блокчейна. Как показано на фиг. 2c, процедура конкретно включает в себя следующие этапы.
[0028] S201. База данных хранит данные консенсуса, необходимые для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса.
[0029] На основе архитектуры на фиг. 2b, база данных находится в узле, в котором расположены серверы, и совместно используется всеми серверами в узле. После приема сообщения консенсуса или формирования результата консенсуса, любой сервер в узле сохраняет сообщение консенсуса или результат консенсуса в базе данных. Затем сервер может получить, из базы данных, данные консенсуса, необходимые для выполнения процедуры консенсуса. Данные консенсуса могут включать в себя сообщение консенсуса, которое принято сервером от сервера в другом узле, результат консенсуса, сформированный сервером, запрос услуги, который отправлен клиентом и который может запустить процедуру консенсуса, и т.д.
[0030] Следует отметить, что сохранение данных консенсуса в базе данных гарантирует, что данные консенсуса доступны всем серверам в узле. То есть, если первый сервер неисправен, то хотя первый сервер не может продолжать участвовать в консенсусе, второй сервер в узле может исполнить консенсус вместо неисправного сервер на основе данных консенсуса, сохраненных в базе данных.
[0031] S202. Второй сервер получает, вместо первого сервера, данные консенсуса из базы данных и исполняет процедуру консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса.
[0032] Во время практической работы, первый сервер, участвующий в консенсусе, может оказаться неисправным (например, может выйти из строя или перезапуститься), и сбой может произойти случайным образом, но реализация процедуры консенсуса подвергается влиянию независимо от того, становится ли первый сервер неисправным перед процедурой консенсуса или во время процедуры консенсуса. В этом случае, чтобы гарантировать, что процедура консенсуса не будет подвергаться влиянию, нормально работающий второй сервер в узле блокчейна может исполнить консенсус вместо неисправного первого сервера.
[0033] Так как первый сервер неисправен, он не может продолжать исполнение консенсуса. Поэтому второй сервер может принять сообщение консенсуса вместо первого сервера и участвовать в процедуре консенсуса, в которой первоначально участвовал первый сервер.
[0034] Как описано выше, любой сервер в узле сохраняет данные консенсуса в базе данных, так что второй сервер может выполнить поиск в базе данных и получить данные консенсуса, необходимые в процедуре консенсуса, чтобы исполнять консенсус вместо неисправного первого сервера, и далее формировать соответствующий результат консенсуса.
[0035] Очевидно, нормально работающий сервер исполняет консенсус вместо неисправного сервер, так что гарантируется, что на процедуру консенсуса не будет оказано влияние.
[0036] S203. Второй сервер сохраняет результат консенсуса в базе данных.
[0037] В этой реализации настоящей заявки, второй сервер, который исполняет консенсус вместо первого сервера, также сохраняет результат консенсуса в базе данных как тип данных консенсуса на основе механизма хранения данных в настоящей заявке.
[0038] В соответствии с вышеописанными этапами, для каждого сервера в узле блокчейна, сервер, участвующий в определенной процедуре консенсуса, "публично" сохраняет сообщения консенсуса на различных стадиях консенсуса или результат консенсуса, сформированный сервером на текущей стадии. Иными словами, сервер сохраняет, в базе данных в узле блокчейна, сообщения консенсуса на различных стадиях консенсуса или результат консенсуса, сформированный сервером на текущей стадии, и база данных может быть использована для всех серверов в узле блокчейна. По существу, если сервер, участвующий в некотором раунде консенсуса, неисправен, например, находится в состоянии офлайн или перезапускается, данные консенсуса сервера могут быть использованы другим сервером в узле блокчейна, и другой сервер может продолжить исполнение соответствующей процедуры консенсуса вместо неисправного сервера.
[0039] Очевидно, что по сравнению существующей технологией, в способе, когда каждый сервер в узле сохраняет данные консенсуса в базе данных в узле, даже когда определенный сервер неисправен, нормально работающий сервер может получить соответствующие данные консенсуса из базы данных и завершить консенсус вместо неисправного сервера. Это гарантирует нормальное исполнение процедуры консенсуса и может повысить вероятность успеха процедуры консенсуса в определенной степени, в то время как число раз повторного инициирования консенсуса сокращается, тем самым повышая эффективность обработки услуги блокчейна.
[0040] Следует отметить здесь, что во время процедуры консенсуса, любой сервер в узле принимает сообщение консенсуса, которое отправлено другим устройством, участвующим в той же самой процедуре консенсуса. Другое устройство включает в себя, но без ограничения, другой узел и/или клиент, участвующий в процедуре консенсуса. Сообщение консенсуса может включать в себя запрос услуги, который отправлен клиентом и который может запускать консенсус, или может включать в себя данные консенсуса, отправленные другим узлом в процедуре консенсуса.
[0041] Очевидно, для определенной процедуры консенсуса, если первый сервер неисправен, второй сервер принимает сообщение консенсуса вместо первого сервера, чтобы участвовать в процедуре консенсуса первого сервера.
[0042] Поэтому, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса, то, что второй сервер получает, вместо первого сервера, данные консенсуса из базы данных, может включать в себя: прием, вторым сервером вместо первого сервера, сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, и получение данных консенсуса, соответствующих сообщению консенсуса из базы данных, на основе сообщения консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса.
[0043] Кроме того, в этой реализации настоящей заявки, имеется механизм повторной попытки. Конкретно, после того как другое устройство, которое участвует в процедуре консенсуса, отправляет определенное сообщение консенсуса или запрос услуги, другое устройство повторно отправляет то же самое сообщение консенсуса или запрос услуги, если другое устройство не принимает ответа от однорангового узла в течение заданного времени. Можно понять, что если первый сервер неисправен во время процедуры консенсуса, первый сервер не может ответить другому устройству в заданное время.
[0044] Поэтому, в ответ на определение, что первый сервер неисправен во время процедуры консенсуса, второй сервер принимает, вместо первого сервера, сообщение консенсуса, которое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, и получает данных консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса.
[0045] Второй сервер обычно получает данных консенсуса из базы данных на основе соответствующего идентификатора в сообщении консенсуса. Далее описан процесс получения данных консенсуса из базы данных.
[0046] Во время процедуры консенсуса на основе PBFT, один запрос услуги соответствует одной процедуре консенсуса, и узел (также упоминаемый как основной узел), который принимает запрос услуги от клиента, нумерует (например, индексирует) запрос услуги. Иными словами, номер, ассоциированный с запросом услуги, может уникально соответствовать одной процедуре консенсуса.
[0047] Конкретно, в определенной процедуре консенсуса, в которой участвует любой сервер в узле, номер (а именно, идентификатор запроса услуги) запроса услуги в процедуре консенсуса может уникально идентифицировать одну процедуру консенсуса. Номер, ассоциированный с запросом услуги, может быть использован, чтобы различать процедуру консенсуса от процедуры консенсуса, в которой участвует другой сервер в узле. Поэтому, если сервер принимает сообщение консенсуса, которое переносит номер, ассоциированный с определенным запросом услуги, сервер может получать данные консенсуса (полученные данные консенсуса и сообщение консенсуса принадлежат той же самой процедуре консенсуса), которые имеют тот же самый номер запроса услуги, из базы данных на основе номера запроса услуги.
[0048] Например, в процедуре консенсуса, формат сообщения консенсуса может представлять собой: <идентификатор стадии консенсуса, номер вида (представления), номер запроса услуги и дайджест запроса услуги>. Предполагается, что сервер принимает определенное сообщение консенсуса <commit, v, n, D(m)>, где commit (фиксация) указывает, что узел вошел в стадию фиксации, v указывает номер представления, n указывает номер, ассоциированный с запросом услуги, и D(m) указывает сигнатуру (подпись) узла, отправляющего сообщение уведомления, для запроса услуги. В этом случае, сервер может искать в базе данных все данные консенсуса, соответствующие номеру "n", на основе номера "n".
[0049] На основе приведенных выше описаний, процесс получения, вторым сервером из базы данных, данных консенсуса, соответствующих сообщению консенсуса, является следующим: Второй сервер выполняет поиск, на основе идентификатора запроса услуги, включенного в сообщение консенсуса, в базе данных и получает данные консенсуса, соответствующие идентификатору.
[0050] В дополнение к предыдущему содержанию, на практике, чтобы предотвратить то, что сообщение консенсуса отправляется на неисправный первый сервер, в этой реализации настоящей заявки, сообщение консенсуса может планироваться с использованием шлюза в узле. То есть, узел блокчейна дополнительно включает в себя шлюз. В этом случае, архитектура узла может быть такой, как показано на фиг. 2d. Можно видеть, что шлюз отвечает за планирование сообщения консенсуса для сервера в узле. Когда первый сервер неисправен, шлюз не отправляет сообщение консенсуса на неисправный первый сервер; вместо этого, он отправляет сообщение консенсуса на нормально работающий второй сервер.
[0051] Поэтому, конкретно, для второго сервера, процесс приема сообщения консенсуса может быть следующим:
[0052] Шлюз пересылает, на нормально работающий второй сервер, принятое сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, когда шлюз определяет, что первый сервер неисправен перед процедурой консенсуса. В этом случае, второй сервер принимает сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса и которое переслано шлюзом.
[0053] Кроме того, шлюз пересылает на нормально работающий второй сервер, принятое сообщение консенсуса, которое повторно пытается отправить другое устройство, участвующее в процедуре консенсуса, когда шлюз определяет, что первый сервер неисправен во время процедуры консенсуса. Соответственно, второй сервер принимает сообщение консенсуса, которое повторно пытается отправить другое устройство, участвующее в процедуре консенсуса, и которое переслано шлюзом.
[0054] Можно понять, что в этой реализации настоящей заявки, шлюз пересылает сообщение консенсуса на нормальный второй сервер в узле. Иными словами, шлюзу необходимо знать неисправный сервер и сервер, который поддерживает нормальную работу в узле.
[0055] В этой реализации настоящей заявки, каждый сервер в узле может осуществлять связь со шлюзом с использованием механизма периодического диагностического сигнала (пульса), так что шлюз может знать статус операции каждого сервера. То есть, шлюз определяет статус операции первого сервера и статус операции второго сервера следующим способом: прием, шлюзом, сообщений статуса операции, которые отправлены первым сервером и вторым сервером на шлюз, на основе заранее определенного периода; и определение, шлюзом, статуса операции первого сервера и статуса операции второго сервера на основе сообщений статуса операции.
[0056] То есть, если шлюз может принять периодическое сообщение статуса операции, шлюз может определить, что сервер, который отправляет сообщение статуса операции, работает нормально; и если шлюз не принимает никакого сообщения статуса операции от определенного сервера в течение определенного времени, шлюз может определить, что сервер неисправен.
[0057] Следующее описание использует пример приложения для описания.
[0058] Например, как показано на фиг. 3a, предполагается, что как сервер 11 в узле 1, так и сервер 21 в узле 2 принимают участие в определенной процедуре консенсуса (фиг. 3a показывает, серым цветом, что два сервера находятся в той же самой процедуре консенсуса). Кроме того, предполагается, что сервер 21 находится в состоянии офлайн (то есть, в узле 2, сервер 21 является первым сервером). В этом случае, сервер 11 отправляет определенное сообщение консенсуса на сервер 21. Очевидно, поскольку сервер 21 находится в состоянии офлайн, сервер 21 не обеспечивает никакой обратной связи. В этом случае, после ожидания в течение конкретного периода времени, сервер 11 инициирует повторную попытку (повторная попытка может также рассматриваться как повторная попытка, инициированная узлом 1), иными словами, повторно отправляет сообщение консенсуса. После того как шлюз в узле 2 принимает сообщение консенсуса, которое узел 1 повторно пытается отправить, шлюз выбирает определенный сервер, который работает нормально внутри узла 2, чтобы обрабатывать повторную попытку узла 1. Как показано на фиг. 3b, в этом примере, сервер 22 выбран в узле 2 (то есть, сервер 22 является вторым сервером). То есть, шлюз направляет, на сервер 22, сообщение консенсуса, которое узел 1 повторно пытается отправить, и сервер 22 исполняет процедуру консенсуса вместо сервера 21.
[0059] Кроме того, для процесса сохранения, вторым сервером, данных консенсуса на сервере, в способе в этой реализации настоящей заявки, второй сервер может сохранить принятое сообщение консенсуса (сообщение консенсуса может рассматриваться как некоторый тип данных консенсуса) в базе данных непосредственно после приема сообщения консенсуса и сохранить результат консенсуса (результат консенсуса может также рассматриваться как некоторый тип данных консенсуса), соответствующий сообщению консенсуса, в базе данных после формирования результата консенсуса посредством процедуры консенсуса.
[0060] Кроме того, в другом способе в этой реализации настоящей заявки, после приема сообщения консенсуса, второй сервер ожидает формирования результата консенсуса посредством вышеописанного процесса и затем сохраняет сообщение консенсуса вместе с результатом консенсуса в базе данных.
[0061] Предшествующие два способа сохранения не накладывают никакого ограничения на настоящую заявку.
[0062] Способ консенсуса на основе блокчейна, обеспеченный в реализации настоящей заявки, описан выше. На основе той же самой идеи, как показано на фиг. 4, реализация настоящей заявки дополнительно обеспечивает устройство консенсуса на основе блокчейна. Один узел блокчейна включает в себя множество серверов и по меньшей мере одну базу данных. База данных хранит данные консенсуса, необходимые для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса.
[0063] Первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса.
[0064] Устройство консенсуса на основе блокчейна включает в себя по меньшей мере модуль 401 приема, модуль 402 получения, модуль 403 исполнения консенсуса и модуль 404 хранения.
[0065] Модуль 402 получения сконфигурирован, чтобы получать данные консенсуса из базы данных.
[0066] Модуль 403 исполнения консенсуса сконфигурирован, чтобы исполнять процедуру консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса.
[0067] Модуль 404 хранения сконфигурирован, чтобы сохранять результат консенсуса в базе данных.
[0068] Модуль 401 приема сконфигурирован, чтобы принимать сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, и модуль получения сконфигурирован, чтобы получать данных консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса, в ответ на определение, что первый сервер неисправен, перед процедурой консенсуса.
[0069] Модуль 401 приема сконфигурирован, чтобы принимать сообщение консенсуса, которое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, и модуль получения сконфигурирован, чтобы получать данные консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса, в ответ на определение, что первый сервер неисправен во время процедуры консенсуса.
[0070] Другое устройство повторно пытается отправить сообщение консенсуса, когда другое устройство отправляет сообщение консенсуса, но не принимает ответа спустя заданное время.
[0071] Сообщение консенсуса включает в себя идентификатор запроса услуги. Модуль 402 получения сконфигурирован, чтобы осуществлять поиск, на основе идентификатора запроса услуги, включенного в сообщение консенсуса, в базе данных и получать данные консенсуса, соответствующие идентификатору.
[0072] Кроме того, узел блокчейна может дополнительно включать в себя шлюз. В этом случае, устройство дополнительно включает в себя по меньшей мере модуль 405 приема шлюза, модуль 406 определения статуса операции и модуль 407 пересылки.
[0073] Модуль 407 пересылки сконфигурирован, чтобы пересылать, на нормально работающий второй сервер, принятое сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, когда модуль 406 определения статуса операции определяет, что первый сервер неисправен перед процедурой консенсуса.
[0074] Модуль 407 пересылки сконфигурирован, чтобы пересылать, на нормально работающий второй сервер, принятое сообщение консенсуса, которое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, когда модуль 406 определения статуса операции определяет, что первый сервер неисправен во время процедуры консенсуса.
[0075] Модуль 405 приема шлюза сконфигурирован, чтобы принимать сообщения статуса операции, которые отправлены первым сервером и вторым сервером на шлюз, на основе заранее определенного периода.
[0076] Модуль 406 определения статуса операции сконфигурирован, чтобы определять статус операции первого сервера и статус операции второго сервера на основе сообщений статуса операции.
[0077] Следует отметить, что в 1990-х, может явно различаться то, является ли совершенствование технологии совершенствованием аппаратных средств (например, улучшением структуры схемы, такой как диод, транзистор или переключатель) или совершенствованием программного обеспечения (улучшением процедуры способа). Однако с развитием технологий, современные улучшения многих процедур способа могут рассматриваться как непосредственные улучшения структур схем аппаратных средств. Почти все разработчики программируют усовершенствованную процедуру способа в схему аппаратных средств, чтобы получить соответствующую структуру схемы аппаратных средств. Поэтому, процедура способа может быть усовершенствована с использованием модуля аппаратных средств. Например, программируемое логическое устройство (PLD) (например, программируемая вентильная матрица (FPGA)) является такой интегральной схемой, и логическая функция PLD определяется пользователем посредством программирования устройства. Разработчик выполняет программирование, чтобы ʺинтегрироватьʺ цифровую систему в PLD, без запрашивания производителя чипов проектировать и производить чип специализированной интегральной схемы. Кроме того, в настоящее время, такое программирование часто реализуется с использованием программного обеспечения ʺлогического компилятораʺ, а не путем ручного производства чипа интегральной схемы. Программное обеспечение ʺлогического компилятораʺ аналогично компилятору программного обеспечения, используемому для разработки и написания программы. Первоначальный код должен быть написан на конкретном языке программирования для компиляции. Этот язык упоминается как язык описания аппаратных средств (HDL). Существует множество HDL, таких как усовершенствованный язык булевых выражений (ABEL), язык описания аппаратных средств Altera (AHDL), Confluence, язык программирования Корнеллского университета (CUPL), HDCal, язык описания аппаратных средств Java (JHDL), Lava, Lola, MyHDL, PALASM и язык описания аппаратных средств Ruby (RHDL). Наиболее часто используются язык описания аппаратных средств на быстродействующих интегральных схемах (VHDL) и Verilog. Специалист в данной области техники должен также понимать, что аппаратная схема, которая реализует логическую процедуру способа, может быть легко получена, когда процедура способа логически запрограммирована с использованием вышеупомянутых различных языков описания аппаратных средств и запрограммирована в интегральную схему.
[0078] Контроллер может быть реализован любым подходящим способом. Например, контроллер может представлять собой микропроцессор или процессор или считываемый компьютером носитель, который хранит считываемый компьютером программный код (такой как программное обеспечение или прошивка), который может исполняться микропроцессором или процессором, логической схемой, переключателем, специализированной интегральной схемой (ASIC), программируемым логическим контроллером или встроенным микропроцессором. Примеры контроллера включают в себя, но без ограничения, следующие микропроцессоры: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 и Silicone Labs C8051F320. Контроллер памяти может также быть реализован как часть управляющей логики памяти. Специалист в данной области техники также знает, что, в дополнение к реализации контроллера с использованием считываемого компьютером программного кода, этапы способа могут логически программироваться, чтобы позволить контроллеру реализовывать ту же самую функцию в форме логической схемы, переключателя, специализированной интегральной схемы, программируемого логического контроллера, встроенного микроконтроллера и т.д. Поэтому контроллер может рассматриваться как компонент аппаратных средств, и устройство, которое включено в контроллер и сконфигурировано, чтобы реализовывать различные функции в контроллере, может также рассматриваться как структура в компоненте аппаратных средств. Альтернативно, устройство, сконфигурированное, чтобы реализовывать различные функции, может даже рассматриваться как модуль программного обеспечения, реализующий способ, и структура в компоненте аппаратных средств.
[0079] Система, устройство, модуль или блок, проиллюстрированные в вышеописанных реализациях, могут быть осуществлены с использованием компьютерного чипа или объекта или могут быть осуществлены с использованием продукта, имеющего определенную функцию. Типовым устройством реализации является компьютер. Компьютер может быть, например, персональным компьютером, ноутбуком, сотовым телефоном, камерофоном, смартфоном, персональным цифровым ассистентом, медиа-плеером, устройством навигации, устройством электронной почты, игровой консолью, планшетным компьютером, носимым устройством или комбинацией любых из этих устройств.
[0080] Для простоты описания, устройство выше описано путем разделения функций на различные модули. Разумеется, при реализации настоящей заявки, функции модулей могут быть реализованы в одной или нескольких частях программного обеспечения и/или аппаратных средств.
[0081] Специалист в данной области техники должен понимать, что реализации настоящего раскрытия могут быть обеспечены как способ, система или компьютерный программный продукт. Поэтому, настоящая заявка может использовать форму реализаций только в аппаратных средствах, реализаций только в программном обеспечении или реализаций с комбинацией программного обеспечения и аппаратных средств. Кроме того, настоящее раскрытие может использовать форму компьютерного программного продукта, который реализован на одном или нескольких используемых компьютером носителях хранения (включая, но без ограничения, память на магнитном диске, CD-ROM, оптическую память и т.д.), которые включают в себя используемый компьютером программный код.
[0082] Настоящее раскрытие описано со ссылкой на блок-схемы последовательности операций и/или блок-схемы способа, устройства (системы) и компьютерного программного продукта в соответствии с реализациями настоящего раскрытия. Следует отметить, что компьютерные программные инструкции могут использоваться для реализации каждого процесса и/или каждого блока в блок-схемах последовательности операций и/или блок-схемах устройства и комбинации процессов и/или блоков в блок-схемах последовательности операций и/или блок-схемах устройства. Эти компьютерные программные инструкции могут быть обеспечены для универсального компьютера, специализированного компьютера, встроенного процессора или процессора другого программируемого устройства обработки данных, чтобы формировать машину, так что инструкции, исполняемые компьютером или процессором другого программируемого устройства обработки данных, формируют устройство для реализации конкретной функции в одном или нескольких процессах в блок-схемах последовательности операций и/или в одном или нескольких блоках в блок-схемах устройства.
[0083] Эти компьютерные программные инструкции могут альтернативно храниться в считываемой компьютером памяти и могут инструктировать компьютер или другое программируемое устройство обработки данных работать конкретным образом, так что инструкции, хранящиеся в считываемой компьютером памяти, формируют артефакт, который включает в себя устройство инструкций. Устройство инструкций реализует конкретную функцию в одном или нескольких процессах в блок-схемах последовательности операций и/или в одном или нескольких блоках в блок-схемах устройств.
[0084] Эти компьютерные программные инструкции альтернативно могут быть загружены на компьютер или другое программируемое устройство обработки данных, так что последовательность операций и этапы выполняются на компьютере или другом программируемом устройстве, тем самым формируя реализуемую компьютером обработку. Поэтому, инструкции, исполняемые на компьютере или другом программируемом устройстве, обеспечивают этапы для реализации конкретной функции в одном или нескольких процессах в блок-схемах последовательности операций и/или в одном или нескольких блоках в блок-схемах устройств.
[0085] В типовой конфигурации, вычислительное устройство включает в себя один или несколько процессоров (CPU), один или несколько интерфейсов ввода/вывода, один или несколько сетевых интерфейсов и одно или несколько устройств памяти.
[0086] Память может включать в себя непостоянную память, память с произвольным доступом (RAM), энергонезависимую память и/или другую форму памяти в считываемых компьютером носителях, например, постоянную память (ROM) или флэш-память (флэш-RAM). Память представляет собой пример считываемого компьютером носителя.
[0087] Считываемый компьютером носитель включает в себя постоянные, непостоянные, перемещаемые и неперемещаемые носители, которые обеспечивают хранение информации с использованием любого способа или технологии. Информация может представлять собой считываемую компьютером инструкцию, структуру данных, программный модуль или другие данные. Примеры компьютерного носителя хранения включают в себя, но без ограничения, параметрическую память с произвольным доступом (PRAM), статическую память с произвольным доступом (SRAM), динамическую память с произвольным доступом (DRAM), другой тип памяти с произвольным доступом (RAM), постоянную память (ROM), электрически стираемую программируемую постоянную память (EEPROM), флэш-память или другую технологию памяти, постоянную память на компакт-диске (CD-ROM), цифровой универсальный диск (DVD) или другое оптическое хранилище, магнитную кассету, магнитную ленту, память на магнитном диске или другое магнитное устройство хранения или любой другой не относящийся к среде передачи носитель, который может использоваться для хранения информации, доступ к которой может осуществляться вычислительным устройством. На основе определения в настоящего описания, считываемый компьютером носитель не включает в себя переходные считываемые компьютером носители (переходные среды), такие как модулированный сигнал данных и несущая.
[0088] Следует дополнительно отметить, что термины ʺсодержатьʺ, ʺвключать в себяʺ или любой другой вариант этих терминов предназначены, чтобы охватывать не исключающее включение, так что процесс, способ, продукт или устройство, которые включают в себя перечень элементов, не только содержат эти элементы, но также содержат другие элементы, которые не перечислены явно, или дополнительно содержат элементы, присущие такому процессу, способу, продукту или устройству. Элемент, которому предшествует ʺвключает в себя …ʺ, не препятствует, без дополнительных ограничений, существованию дополнительных идентичных элементов в процессе, способе, продукте или устройстве, которые содержат этот элемент.
[0089] Специалист в данной области техники должен понимать, что реализации настоящей заявки могут быть обеспечены как способ, система или компьютерный программный продукт. Поэтому настоящая заявка может использовать форму реализаций только в аппаратных средствах, реализаций только в программном обеспечении или реализаций с комбинацией программного обеспечения и аппаратных средств. Кроме того, настоящая заявка может использовать форму компьютерного программного продукта, который реализован на одном или нескольких используемых компьютером носителях хранения (включая, но без ограничения, память на магнитном диске, CD-ROM, оптическую память и т.д.), которые включают в себя используемый компьютером программный код.
[0090] Настоящая заявка может быть описана в общем контексте компьютерно-исполняемых инструкций, исполняемых компьютером, например, программного модуля. Обычно, программный модуль включает в себя подпрограмму, программу, объект, компонент, структуру данных и т.д., для исполнения конкретной задачи или реализации конкретного типа абстрактных данных. Настоящая заявка альтернативно может быть реализована в распределенных вычислительных средах. В этих распределенных вычислительных средах, задачи выполняются удаленными устройствами обработки, которые соединены через сеть связи. В распределенных вычислительных средах, программный модуль может быть расположен как в локальных, так и в удаленных компьютерных носителях хранения, включающих в себя устройства хранения.
[0091] Реализации настоящего описания описаны постепенным образом. Для одних и тех же или аналогичных частей реализаций, могут даваться взаимные ссылки на реализации. Каждая реализация фокусируется на отличии от других реализаций. В частности, реализация системы в основном аналогична реализации способа и поэтому описана кратко. Для связанных частей, ссылки могут даваться на некоторые описания в реализации способа.
[0092] Предыдущие описания представляют собой только реализации настоящей заявки и не предназначены для ограничения настоящей заявки. Специалист в данной области техники может осуществлять различные модификации и изменения в настоящей заявке. Любая модификация, эквивалентная замена или усовершенствование и т.д., выполненное без отклонения от сущности и принципа настоящей заявки, должно соответствовать объему формулы изобретения в настоящей заявке.
1. Способ консенсуса на основе блокчейна, содержащий:
хранение базой данных узла блокчейна данных консенсуса, необходимых для выполнения процедуры консенсуса, причем данные консенсуса вызываются первым сервером и вторым сервером во время процедуры консенсуса, причем узел блокчейна включен в блокчейн и содержит первый сервер, второй сервер и базу данных;
прием вторым сервером вместо первого сервера и от другого устройства сообщения консенсуса, которое отправлено упомянутым другим устройством, участвующим в процедуре консенсуса;
в ответ на определение, что первый сервер неисправен, получение вторым сервером вместо первого сервера и на основе сообщения консенсуса данных консенсуса из базы данных, причем данные консенсуса соответствуют сообщению консенсуса;
исполнение процедуры консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса или во время процедуры консенсуса; и
сохранение вторым сервером результата консенсуса в базе данных.
2. Способ по п. 1, в котором определение, что первый сервер неисправен перед или во время процедуры консенсуса, содержит определение того, что первый сервер был перезапущен.
3. Способ по п. 1, в котором упомянутое другое устройство повторно пытается отправить сообщение консенсуса, когда упомянутое другое устройство отправляет сообщение консенсуса, но не принимает ответа спустя заданное время.
4. Способ по п. 1, в котором сообщение консенсуса содержит идентификатор запроса услуги.
5. Способ по п. 4, в котором получение данных консенсуса, соответствующих сообщению консенсуса, из базы данных на основе сообщения консенсуса, в частности, содержит:
поиск вторым сервером на основе идентификатора запроса услуги, содержащегося в сообщении консенсуса, в базе данных и получение данных консенсуса, соответствующих идентификатору.
6. Способ по п. 1, в котором узел блокчейна дополнительно содержит шлюз.
7. Способ по п. 6, в котором прием сообщения консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, содержит:
пересылку шлюзом на второй сервер, который работает нормально, сообщения консенсуса, которое отправлено упомянутым другим устройством, участвующим в процедуре консенсуса, в ответ на определение, что первый сервер неисправен перед процедурой консенсуса; и
прием вторым сервером сообщения консенсуса, которое отправлено упомянутым другим устройством, участвующим в процедуре консенсуса, и которое переслано шлюзом.
8. Способ по п. 7, в котором прием сообщения консенсуса, которое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, содержит:
пересылку шлюзом на второй сервер, который работает нормально, сообщения консенсуса, которое упомянутое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, в ответ на определение, что первый сервер неисправен во время процедуры консенсуса; и
прием вторым сервером сообщения консенсуса, которое упомянутое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить и которое переслано шлюзом.
9. Способ по п. 8, в котором шлюз определяет статус операции первого сервера и статус операции второго сервера посредством выполнения операций, содержащих:
прием шлюзом сообщений статуса операции, которые отправлены первым сервером и вторым сервером на шлюз, на основе заранее определенного периода; и
определение шлюзом статуса операции первого сервера и статуса операции второго сервера на основе сообщений статуса операции.
10. Способ по п.1, в котором блокчейн содержит по меньшей мере одно из консорциумного блокчейна и частного блокчейна.
11. Устройство для консенсуса на основе блокчейна, содержащее модуль приема, модуль получения, модуль исполнения консенсуса и модуль хранения, причем:
модуль получения выполнен с возможностью получать данные консенсуса из базы данных;
модуль исполнения консенсуса выполнен с возможностью исполнять процедуру консенсуса на основе данных консенсуса, чтобы формировать результат консенсуса;
модуль хранения выполнен с возможностью сохранять результат консенсуса в базе данных;
модуль приема выполнен с возможностью принимать сообщение консенсуса, которое отправлено другим устройством, участвующим в процедуре консенсуса, и модуль получения выполнен с возможностью получать данные консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса, в ответ на определение, что первый сервер неисправен, перед процедурой консенсуса;
модуль приема выполнен с возможностью принимать сообщение консенсуса, которое другое устройство, участвующее в процедуре консенсуса, повторно пытается отправить, и модуль получения выполнен с возможностью получать данные консенсуса, соответствующие сообщению консенсуса, из базы данных на основе сообщения консенсуса, в ответ на определение, что первый сервер неисправен во время процедуры консенсуса.
