СПОСОБ И ОБОРУДОВАНИЕ БИЗНЕС-ВЕРИФИКАЦИИ

Притязание на приоритет

Данная заявка притязает на приоритет заявки на патент (Китай) номер 201710096987.5, поданной 22 февраля 2017 года, содержимое которой полностью содержится в данном документе по ссылке.

Область техники

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

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

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

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

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

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

Например, предполагается, что полная консенсусная сеть имеет три узла цепочки блоков: A, B и C. Узел A цепочки блоков сохраняет пять бизнес–запросов: #1, #2, #3, #4 и #5. Узел B цепочки блоков сохраняет четыре бизнес–запроса: #1, #2, #3 и #4. Узел C цепочки блоков сохраняет три бизнес–запроса: #1, #2 и #3. Бизнес–запросы сохраняются в запоминающих устройствах для бизнес–операций, соответствующих узлам цепочки блоков. Когда узел A цепочки блоков пакетирует пять бизнес–запросов #1, #2, #3, #4 и #5 в предварительно обработанный блок и широковещательно передает предварительно обработанный блок в другие два узла цепочки блоков, чтобы выполнять консенсусную верификацию для пяти бизнес–запросов, поскольку узлы B и C цепочки блоков не имеют части пяти бизнес–запросов, узлы B и C цепочки блоков могут непосредственно рассматривать блок предварительной обработки, включающий в себя пять бизнес–запросов, как сбойный в консенсусной верификации. В этом случае, поскольку более половины узлов цепочки блоков в полной консенсусной сети рассматривают предварительно обработанный блок как сбойный в консенсусной верификации, пять бизнес–запросов, включенных в предварительно обработанный блок, не должны иметь возможность проходить консенсусную верификацию полной консенсусной сети. Пять бизнес–запросов в таком случае не должны записываться в цепочках блоков полной консенсусной сети.

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

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

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

Варианты осуществления настоящей заявки предоставляют способ бизнес–верификации, включающий в себя:

– прием, посредством первого узла цепочки блоков, бизнес–запроса, отправленного посредством терминала;

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

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

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

Варианты осуществления настоящей заявки предоставляют оборудование бизнес–верификации, включающее в себя:

– приемный модуль, выполненный с возможностью принимать бизнес–запрос, отправленный посредством терминала;

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

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

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

Варианты осуществления настоящей заявки предоставляют способ бизнес–верификации, включающий в себя:

– прием, посредством второго узла цепочки блоков, бизнес–запроса, широковещательно передаваемого посредством первого узла цепочки блоков;

– сохранение бизнес–запроса в запоминающем устройстве для бизнес–операций, соответствующем второму узлу цепочки блоков;

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

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

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

Варианты осуществления настоящей заявки предоставляют оборудование бизнес–верификации, включающее в себя:

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

– модуль хранения запросов, выполненный с возможностью сохранять бизнес–запрос в запоминающем устройстве для бизнес–операций, соответствующем оборудованию;

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

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

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

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

Краткое описание чертежей

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

Фиг. 1 является принципиальной схемой процесса обеспечения бизнес–эффективности согласно варианту осуществления настоящей заявки;

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

Фиг. 3 является принципиальной схемой определения подлежащего верификации общего характеристического значения согласно варианту осуществления настоящей заявки;

Фиг. 4 является принципиальной схемой установления консенсуса посредством консенсусной сети для предварительно обработанного блока, отправленного посредством первого узла цепочки блоков согласно варианту осуществления настоящей заявки;

Фиг. 5 является принципиальной схемой оборудования бизнес–верификации согласно варианту осуществления настоящей заявки; и

Фиг. 6 является принципиальной схемой другого оборудования бизнес–верификации согласно варианту осуществления настоящей заявки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S101. Первый узел цепочки блоков принимает бизнес–запрос, отправленный посредством терминала.

В варианте осуществления настоящей заявки, во время бизнес–обработки, пользователь может заполнять соответствующий контент бизнес–обработки в пользовательском терминале, удерживаемом пользователем. Терминал формирует соответствующий бизнес–запрос согласно контенту бизнес–обработки, заполненному пользователем, и отправляет бизнес–запрос в первый узел цепочки блоков в полной консенсусной сети. Терминал, упомянутый здесь, может представлять собой такое устройство, как компьютер или смартфон. Определенно, пользователь также может отправлять бизнес–запрос в первый узел цепочки блоков посредством использования клиентского терминала, установленного в терминале. Таким образом, пользователь заполняет соответствующий контент бизнес–обработки в интерфейсе, представленном в клиентском терминале, на терминале. Клиентский терминал формирует соответствующий бизнес–запрос согласно контенту бизнес–обработки, заполненному пользователем в интерфейсе, и дополнительно отправляет бизнес–запрос в первый узел цепочки блоков посредством использования терминала.

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

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

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

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

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

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

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

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

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

В варианте осуществления настоящей заявки, передача данных между узлами цепочки блоков и запоминающими устройствами для бизнес–операций в полной консенсусной сети может реализовываться посредством использования предварительно установленного распределенного промежуточного программного обеспечения. Таким образом, после приема бизнес–запроса, отправленного посредством терминала, первый узел цепочки блоков может отправлять бизнес–запрос в распределенное промежуточное программное обеспечение. Распределенное промежуточное программное обеспечение может отправлять, согласно идентификатору узла первого узла цепочки блоков, бизнес–запрос в запоминающее устройство для бизнес–операций, соответствующее первому узлу цепочки блоков для хранения. Аналогично, после приема бизнес–запроса, широковещательно передаваемого посредством первого узла цепочки блоков, второй узел цепочки блоков может отправлять бизнес–запрос в распределенное промежуточное программное обеспечение. Распределенное промежуточное программное обеспечение также может отправлять, согласно идентификатору узла второго узла цепочки блоков, бизнес–запрос в запоминающее устройство для бизнес–операций, соответствующее второму узлу цепочки блоков для хранения, как показано на фиг. 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подлежащее верификации характеристическое значение уникально соответствует бизнес–запросам в целом. Таким образом, когда контент бизнес–запроса из числа бизнес–запросов изменяется, подлежащее верификации характеристическое значение должно изменяться. Способ определения подлежащего верификации характеристического значения посредством первого узла цепочки блоков является таким, как показано на фиг. 3.

Фиг. 3 является принципиальной схемой определения подлежащего верификации характеристического значения согласно варианту осуществления настоящей заявки.

На фиг. 3, правило определения характеристических значений, используемое посредством первого узла цепочки блоков, представляет собой хэш–алгоритм. Допустим, что первый узел цепочки блоков получает заданное число (которое равно 4) бизнес–запросов из запоминающего устройства для бизнес–операций, соответствующего ему. Компоновка четырех бизнес–запросов в бизнес–очереди является такой, как показано на фиг. 3. После определения четырех хэш–значений, соответствующих четырем бизнес–запросам, соответственно, первый узел цепочки блоков может размещать четыре хэш–значения на четырех концевых узлах дерева Меркла слева направо согласно рангам четырех бизнес–запросов в бизнес–очереди и определять неконцевые узлы и корневой узел дерева Меркла, соответственно. Первый узел цепочки блоков затем может определять корневой узел "Хэш 7" дерева Меркла в качестве подлежащего верификации характеристического значения, уникально соответствующего четырем бизнес–запросам.

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

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

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

Фиг. 4 является принципиальной схемой установления консенсуса посредством консенсусной сети для предварительно обработанного блока, отправленного посредством первого узла цепочки блоков согласно варианту осуществления настоящей заявки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выше описывается способ бизнес–верификации, предоставленный в варианте осуществления настоящей заявки, и на основе идентичной идеи, варианты осуществления настоящей заявки дополнительно предоставляют два типа оборудования бизнес–верификации, как показано на фиг. 5 и фиг. 6.

Фиг. 5 является принципиальной схемой оборудования бизнес–верификации согласно варианту осуществления настоящей заявки, в частности, включающего в себя:

– приемный модуль 501, выполненный с возможностью принимать бизнес–запрос, отправленный посредством терминала;

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

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

Запоминающее устройство для бизнес–операций представляет собой базу данных, которая сохраняет бизнес–запросы.

Модуль 502 хранения данных выполнен с возможностью сохранять бизнес–запрос в запоминающем устройстве для бизнес–операций посредством использования предварительно установленного распределенного промежуточного программного обеспечения.

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

Модуль 502 хранения данных выполнен с возможностью сохранять бизнес–запрос в запоминающем устройстве для бизнес–операций согласно бизнес–типу бизнес–запроса и предварительно установленной последовательности приоритетов бизнес–типов.

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

Фиг. 6 является принципиальной схемой другого оборудования бизнес–верификации согласно варианту осуществления настоящей заявки, в частности, включающего в себя:

– модуль 601 приема запросов, выполненный с возможностью принимать бизнес–запрос, широковещательно передаваемый посредством первого узла цепочки блоков;

– модуль 602 хранения запросов, выполненный с возможностью сохранять бизнес–запрос в запоминающем устройстве для бизнес–операций, соответствующем оборудованию;

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

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

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

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

В 1990–х годах, улучшение технологии может явно различаться как улучшение в аппаратных средствах (например, улучшение в схемной структуре, такой как диод, транзистор и коммутатор) или улучшение в программном обеспечении (улучшение в процедуре способа). Тем не менее, с разработкой технологий, улучшения многих процедур способа в настоящее время могут рассматриваться как прямые улучшения в аппаратных схемных структурах. Почти все разработчики программируют усовершенствованные процедуры способа в аппаратные схемы, чтобы получать соответствующие аппаратные схемные структуры. Следовательно, нецелесообразно предполагать, что улучшение процедуры способа не может реализовываться посредством использования аппаратного объектного модуля. Например, программируемое логическое устройство (PLD) (например, программируемая пользователем вентильная матрица (FPGA)) представляет собой такую интегральную схему, логические функции которой определяются посредством устройств, программируемых пользователем. Разработчики программируют самостоятельно, чтобы "интегрировать" цифровую систему во фрагмент PLD, без необходимости запрашивать от изготовителя микросхемы конструировать и изготавливать микросхему со специализированными интегральными схемами. Кроме того, в настоящее время, программирование главным образом реализуется посредством использования программного обеспечения логического компилятора вместо изготовления вручную микросхемы с интегральными схемами. Программное обеспечение логического компилятора является аналогичным программному компилятору, используемому для разработки и написания программы, и исходный код до компиляции также должны быть написан посредством использования конкретного языка программирования, который упоминается как язык описания аппаратных средств (HDL). Предусмотрено множество типов HDL, к примеру, усовершенствованный язык булевых выражений (ABEL), язык описания аппаратных средств фирмы Altera (AHDL), Confluence, язык программирования Корнелльского университета (CUPL), HDCal, язык описания аппаратных средств по технологии Java (JHDL), Lava, Lola, MyHDL, PALASM и язык описания аппаратных средств по технологии Ruby (RHDL), из которых язык описания аппаратного обеспечения на быстродействующих интегральных схемах (VHDL) и Verilog, как правило, используются в настоящее время. Специалисты в данной области техники также должны знать, что аппаратная схема для реализации логической процедуры способа может легко получаться посредством незначительного логического программирования процедуры способа с использованием вышеуказанных нескольких языков описания аппаратных средств и ее программирования в интегральную схему.

Контроллер может реализовываться любым подходящим способом. Например, контроллер может иметь форму, например, микропроцессора или процессора и машиночитаемого носителя, сохраняющего машиночитаемый программный код (например, программное обеспечение или микропрограммное обеспечение), выполняемый посредством (микро–)процессора, логического вентиля, коммутатора, специализированной интегральной схемы (ASIC), программируемого логического контроллера и встроенного микроконтроллера. Примеры контроллера включают в себя, но не только, следующие микроконтроллеры: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 и Silicone Labs C8051F320. Контроллер запоминающего устройства также может реализовываться как часть управляющей логики запоминающего устройства. Специалисты в данной области техники также знают, что контроллер может реализовываться посредством использования чистого машиночитаемого программного кода, и помимо этого, этапы способа могут логически программироваться, чтобы обеспечивать возможность контроллеру реализовывать идентичную функцию в форме логического вентиля, коммутатора, специализированной интегральной схемы, программируемого логического контроллера и встроенного микроконтроллера. Следовательно, этот тип контроллера может рассматриваться как аппаратный компонент, и оборудование, включенное в него для реализации различных функций, также может рассматриваться как структуры в аппаратном компоненте. Альтернативно, оборудование, используемое для реализации различных функций, может рассматриваться даже и как программные модули для реализации способа, и как структуры в аппаратном компоненте.

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

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

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

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

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

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

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

Запоминающее устройство может включать в себя машиночитаемые носители, такие как энергозависимое запоминающее устройство, оперативное запоминающее устройство (RAM) и/или энергонезависимое запоминающее устройство, например, постоянное запоминающее устройство (ROM) или флэш–RAM. Запоминающее устройство представляет собой пример машиночитаемого носителя.

Машиночитаемый носитель включает в себя энергонезависимые и энергозависимые носители, а также перемещаемые и неперемещаемые носители и может реализовывать хранение информации посредством любого способа или технологии. Информация может представлять собой машиночитаемую инструкцию, структуру данных и модуль программы либо другие данные. Носитель хранения данных компьютера включает в себя, например, но не только, запоминающее устройство на фазовых переходах (PRAM), статическое оперативное запоминающее устройство (SRAM), динамическое оперативное запоминающее устройство (DRAM), другие типы RAM, ROM, электрически стираемое программируемое постоянное запоминающее устройство (EEPROM), флэш–память или другие технологии запоминающих устройств, постоянное запоминающее устройство на компакт–дисках (CD–ROM), универсальной цифровой диск (DVD) или другие оптические устройства хранения данных, кассетную ленту, устройство хранения данных на магнитных лентах/магнитных дисках или другие магнитные устройства хранения данных либо любой другой носитель, отличный от среды передачи, и может использоваться для того, чтобы сохранять информацию, к которой осуществляется доступ посредством вычислительного устройства. Согласно определению этого текста, машиночитаемый носитель не включает в себя энергозависимые среды, такие как модулированный сигнал данных и несущая.

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

Специалисты в данной области техники должны понимать, что варианты осуществления настоящей заявки могут предоставляться в качестве способа, системы или компьютерного программного продукта. Следовательно, настоящая заявка может реализовываться как полностью аппаратный вариант осуществления, полностью программный вариант осуществления либо вариант осуществления, комбинирующий программное обеспечение и аппаратные средства. Кроме того, настоящая заявка может иметь форму компьютерного программного продукта, реализованного на одном или более машиноприменимых носителей хранения данных (в том числе, но не только, в запоминающем устройстве на магнитных дисках, на CD–ROM, в оптическом запоминающем устройстве и т.п.), включающих в себя машиноприменимый программный код.

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

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

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