СИСТЕМА БЛОКЧЕЙНА И СПОСОБ И УСТРОЙСТВО ХРАНЕНИЯ ДАННЫХ Российский патент 2020 года по МПК H04L29/06 G06F21/64 

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

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

Предшествующий уровень техники

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

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

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

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

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

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

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

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

Краткое описание сущности изобретения

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

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

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

подсистема вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса;

узел вне консенсуса отправляет запрос транзакции в центр распределения;

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

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

Способ хранения данных в соответствии с вариантами осуществления настоящей заявки, причем система блокчейна содержит центр распределения, подсистему вне консенсуса и множество подсистем консенсуса, подсистема вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса, причем способ содержит:

прием, подсистемой консенсуса, запроса транзакции, пересланного центром распределения, запрос транзакции содержит данные транзакции;

отправку запроса транзакции во все узлы консенсуса в подсистеме консенсуса для подтверждения консенсуса;

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

Способ хранения данных в соответствии с вариантами осуществления настоящей заявки, причем система блокчейна содержит центр распределения, подсистему вне консенсуса и множество подсистем консенсуса, подсистема вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса, причем способ содержит:

прием, центром распределения, запроса транзакции, отправленного подсистемой вне консенсуса, запрос транзакции содержит данные транзакции;

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

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

Способ хранения данных в соответствии с вариантами осуществления настоящей заявки, причем система блокчейна содержит центр распределения, подсистему вне консенсуса и множество подсистем консенсуса, подсистема вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса, причем способ содержит:

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

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

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

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

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

Устройство хранения данных в соответствии с вариантами осуществления настоящей заявки, причем система блокчейна содержит устройство, подсистему вне консенсуса и множество подсистем консенсуса, подсистема вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса, причем устройство содержит:

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

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

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

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

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

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

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

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

Фиг. 1a-b представляют собой схематичные диаграммы системы блокчейна в соответствии с некоторыми вариантами осуществления настоящей заявки;

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

Фиг. 3-5 представляют собой схематичные диаграммы трех устройств хранения данных в соответствии с некоторыми вариантами осуществления настоящей заявки.

Подробное описание

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

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

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

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

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

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

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

Фиг. 1a представляет собой схематичную диаграмму системы блокчейна в соответствии с некоторыми вариантами осуществления настоящей заявки. Как показано на фиг. 2, система блокчейна содержит центр распределения, подсистему вне консенсуса и множество подсистем консенсуса, причем подсистема вне консенсуса может соответствовать не-узловым субъектам, и не-узловые субъекты могут служить как узлы вне консенсуса в подсистеме вне консенсуса. Альтернативно, подсистема вне консенсуса может также соответствовать сети общедоступного блокчейна, и узлы вне консенсуса в подсистеме вне консенсуса в действительности представляют собой узлы в сети общедоступного блокчейна, но узлы вне консенсуса не имеют функции участвовать в подтверждении консенсуса и могут только предоставлять запросы транзакции. С другой стороны, каждая из подсистем консенсуса эквивалентна сети блокчейна консорциума, и узлы консенсуса в каждой из подсистем консенсуса в действительности представляют собой узлы в сети блокчейна консорциума, соответствующей подсистеме консенсуса; запросы транзакции, инициированные узлами вне консенсуса, распределяются центром распределения единообразным образом, и центр распределения пересылает запросы транзакций, соответствующие разным областям транзакций, на соответствующие подсистемы консенсуса (т.е., эквивалентно пересылке запросов транзакций на соответствующие сети блокчейна консорциума).

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

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

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

подсистему 101 вне консенсуса, центр 102 распределения и множество подсистем 103 консенсуса;

подсистема 101 вне консенсуса содержит множество узлов вне консенсуса, и каждая из подсистем консенсуса содержит множество узлов консенсуса;

узел вне консенсуса отправляет запрос транзакции в центр 102 распределения;

центр 102 распределения принимает запрос транзакции от подсистемы вне консенсуса, определяет подсистему консенсуса, соответствующую запросу транзакции, на основе данных транзакции, содержащихся в запросе транзакции, и пересылает запрос транзакции в определенную подсистему 103 консенсуса; и

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

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

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

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

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

Подсистема 101 вне консенсуса дополнительно содержит:

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

Браузер 1011 данных получает, в соответствии с разрешением поиска, данные транзакции, соответствующие разрешению поиска, от подсистемы 103 консенсуса, соответствующей запросу поиска, и возвращает полученные данные транзакции в узел вне консенсуса.

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

Здесь, данные транзакции представляют собой данные транзакции, сгенерированный узлом или не-узловым субъектом, и содержат цифровую подпись, идентификатор, адрес счета и т.д. узла или не-узлового субъекта и дополнительно содержат предметы, подлежащие верифицированию, как запрошено узлом или не-узловым субъектом. Эти предметы, подлежащие верифицированию, варьируются в зависимости от разных областей транзакции. Например, узел A переводит 500 юаней в узел B. Для того чтобы узел B был уверен, что перевод был осуществлен, узел A должен предоставить запрос транзакции, и запрос транзакции содержит следующие данные транзакции: адрес счета узла A, адрес счета узла B, и ʺA переводит 500 юаней на Bʺ. Затем, узлы в сети блокчейна должны верифицировать, произведен ли вычет 500 юаней со счета узла A, и добавлены ли 500 юаней со счета узла A на счет B.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S201: отправка, подсистемой вне консенсуса, запроса транзакции в центр распределения.

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

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

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

S203: пересылка, центром распределения, запроса транзакции в определенную подсистему консенсуса.

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

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

S204: выполнение, подсистемой консенсуса, подтверждения консенсуса в отношении запроса транзакции.

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

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

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

S206: отправка, подсистемой консенсуса, блока, соответствующего запросу транзакции, и сводки транзакции в подсистему вне консенсуса.

S207: сохранение, подсистемой вне консенсуса, блока в соответствующий общедоступный блокчейн.

S208: отправка, подсистемой вне консенсуса, запроса получения для данных транзакции в подсистему консенсуса.

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

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

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

S209: возвращение данных транзакции, соответствующих запросу получения, в подсистему вне консенсуса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешение поиска узла вне консенсуса может быть определено следующим образом:

для каждого узла вне консенсуса, определение типа узла вне консенсуса; и

в соответствии с типом узла вне консенсуса, назначение разрешения поиска узлу вне консенсуса.

Модуль 504 поиска получает, в соответствии с разрешением поиска, данные транзакции, соответствующие разрешению поиска, от подсистемы консенсуса, соответствующей запросу поиска, и возвращает полученные данные транзакции в узел вне консенсуса.

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

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

Технические носители, задействованные в платеже в вариантах осуществления настоящей заявки, могут содержать, например, связь в ближней зоне (NFC), WIFI, 3G/4G/5G, технологии проведения карты в терминале POS, технологии сканирования QR-кода, технологии сканирования штрих-кода, Bluetooth, IR, службу коротких сообщений (SMS), службу мультимедийных сообщений (MMS) и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Система блокчейна, содержащая центр распределения, подсистему вне консенсуса и множество подсистем консенсуса, причем

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

узел вне консенсуса отправляет запрос транзакции в центр распределения;

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

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

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

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

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

5. Система блокчейна по п.4, причем разрешение поиска узла вне консенсуса определяется следующим образом:

для каждого узла вне консенсуса определяется тип узла вне консенсуса и

в соответствии с типом узла вне консенсуса назначается разрешение поиска узлу вне консенсуса.

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

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

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

отправляют запрос транзакции во все узлы консенсуса в подсистеме консенсуса для подтверждения консенсуса;

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

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

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

генерируют сводку транзакции, соответствующую блоку, на основе данных транзакции, соответствующих блоку; и

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

10. Способ по п.7, дополнительно содержащий этапы, на которых:

принимают запрос получения в отношении данных транзакции от подсистемы вне консенсуса; и

возвращают, в соответствии с запросом получения, данные транзакции, соответствующие запросу получения, в подсистему вне консенсуса.

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

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

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

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

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

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

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

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

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

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