Заявление об установлении приоритета
Настоящая заявка испрашивает приоритет китайской патентной заявки № 201710133969.X, поданной 8 марта 2017, полное содержание которой включено в настоящий документ посредством ссылки.
Область техники
Настоящая заявка относится к области компьютерных технологий и, в частности, к способу и устройству бизнес-обработки.
уровень техники
В настоящее время пользователи могут доверять некоторым организациями бизнес-обработки обрабатывать некоторый бизнес для них, и эти организации бизнес-обработки могут обеспечивать профессиональные услуги по бизнес-обработке для пользователей. Организации бизнес-обработки выполняют относительно сложные и утомительные процедуры бизнес-обработки для пользователей, в то время как пользователям нужно всего лишь заплатить определенную плату. Таким образом, бизнес-обработка выполняется легко для пользователей.
Например, при необходимости обрабатывать бизнес через организацию бизнес-обработки, пользователь может отправить бизнес-запрос для организации бизнес-обработки с использованием удерживаемого в связи с этим терминала. Организация бизнес-обработки может получить соответствующий бизнес-результат в соответствии с бизнес-запросом, отправленным пользователем, и возвратить бизнес-результат пользователю.
Однако, в реальных приложениях, некоторые организации бизнес-обработки могут иметь некоторые режимы фальсификации в процессе обработки бизнесов для пользователей, и возвращать некорректные бизнес-результаты пользователям, тем самым нанося урон выгодам пользователей.
Принимая оценку активов в качестве примера, при обработке бизнеса оценки активов через организацию оценки активов (то есть организацию бизнес-обработки), пользователь может отправлять данные активов, подлежащие оценке, и действительный персональный сертификат в организацию оценки активов способом бизнес-запроса. После приема бизнес-запроса, организация оценки активов может намеренно обеспечить ложный отчет об оценке активов и возвратить отчет об оценке активов пользователю в качестве бизнес-результата. В этом случае, пользователь не сможет затем выполнить передачу права собственности, возмещение убытков страхования, расчет активов, а также другие виды поведения согласно отчету, об оценке активов, вызывая тем самым потери собственности пользователя в некоторой степени.
Как видно из приведенного выше примера, процесс выполнения бизнес-обработки пользователем посредством организации бизнес-обработки испытывает недостаток гарантии доверия, и поэтому некоторые потери могут быть вызваны во время бизнес-обработки. Как построить надежный механизм доверия между пользователем и организацией бизнес-обработки, чтобы защитить пользователя от потерь при бизнес-обработке, является актуальной проблемой, которую необходимо решить.
сущностЬ изобретения
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при обработке бизнеса через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки, включающий в себя:
прием, первым узлом цепочки блоков (блокчейна), бизнес-информации, отправленной пользователем;
генерацию соответствующего бизнес-запроса в соответствии с бизнес-информацией, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный в соответствии с бизнес-информацией; и
отправку бизнес-запроса в сеть консенсуса, так что третий узел блокчейна в сети консенсуса получает соответствующий бизнес-результат в соответствии с бизнес-запросом, и исполнение первой назначенной операции путем запуска первого смарт-контракта, когда определено, что второй узел блокчейна в сети консенсуса верифицирует бизнес-результат как допустимый (легальный).
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при обработке бизнеса через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки, включающее в себя:
модуль приема, выполненный с возможностью принимать бизнес-информацию, отправленную пользователем;
модуль генерации, выполненный с возможностью генерировать соответствующий бизнес-запрос в соответствии с бизнес-информацией, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный в соответствии с бизнес-информацией; и
модуль отправки, выполненный с возможностью отправлять бизнес-запрос на сеть консенсуса, так что третий узел блокчейна в сети консенсуса получает соответствующий бизнес-результат в соответствии с бизнес-запросом, и исполнять первую назначенную операцию путем запуска первого смарт-контракта, когда определено, что второй узел блокчейна в сети консенсуса верифицирует бизнес-результат как легальный.
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при обработке бизнеса через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки, включающий в себя:
получение, вторым узлом блокчейна из сети консенсуса, бизнес-информации обратной связи, отправленной третьим узлом блокчейна;
получение бизнес-результата из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, причем бизнес-результат генерируется третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна на сеть консенсуса; и
когда бизнес-результат верифицирован как легальный, разрешение первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при бизнес-обработке через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки, включающее в себя:
модуль получения информации, выполненный с возможностью получать, из сети консенсуса, бизнес-информацию обратной связи, отправленную третьим узлом блокчейна;
модуль получения результата, выполненный с возможностью получать бизнес-результат из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, причем бизнес-результат генерируется третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна на сеть консенсуса; и
модуль верификации, выполненный с возможностью, при верифицировании бизнес-результата как легального, разрешать первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при бизнес-обработке через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают способ бизнес-обработки, включающий в себя:
получение, третьим узлом блокчейна, бизнес-запроса, отправленного первым узлом блокчейна с использованием сети консенсуса, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный первым узлом блокчейна в соответствии с бизнес-информацией, отправленной пользователем;
получение бизнес-результата и бизнес-информации обратной связи в соответствии с бизнес-запросом; и
отправку бизнес-информации обратной связи на сеть консенсуса, так что второй узел блокчейна в сети консенсуса получает бизнес-результат из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, и когда бизнес-результат верифицирован как легальный, разрешение первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки, для решения проблемы в предшествующем уровне техники, состоящей в том, что пользователь может нести потери при бизнес-обработке через организацию бизнес-обработки.
Варианты осуществления настоящей заявки обеспечивают устройство бизнес-обработки, включающее в себя:
модуль получения запроса, выполненный с возможностью получать бизнес-запрос, отправленный первым узлом блокчейна, с использованием сети консенсуса, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный первым узлом блокчейна в соответствии с бизнес-информацией, отправленной пользователем;
модуль генерации информации, выполненный с возможностью получать бизнес-результат и бизнес-информацию обратной связи в соответствии с бизнес-запросом; и
модуль отправки информации, выполненный с возможностью отправлять бизнес-информацию обратной связи на сеть консенсуса, так что второй узел блокчейна в сети консенсуса получает бизнес-результат из устройства в соответствии с бизнес-информацией обратной связи, и когда бизнес-результат верифицирован как легальный, разрешать первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
По меньшей мере одно вышеприведенное техническое решение, используемое в вариантах осуществления настоящей заявки, может достигать следующих полезных результатов:
В вариантах осуществления настоящей заявки, первый узел блокчейна использует смарт-контракт, который может исполняться автоматически. Следовательно, первый узел блокчейна может исполнять первую назначенную операцию путем запуска первого смарт-контракта, как только бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна, проходит верификацию, выполняемую вторым узлом блокчейна. Назначенная операция во время бизнес-обработки может точно завершаться без ручного вмешательства. Кроме того, поскольку второй узел блокчейна может верифицировать бизнес-результат, полученный третьим узлом блокчейна, вся процедура бизнес-обработки обеспечивается системой беспристрастности, таким образом, значительно улучшая беспристрастность бизнес-обработки и сокращая возможность того, что пользователь несет потери во время бизнес-обработки.
Краткое описание чертежей
Прилагаемые чертежи, описанные в настоящем документе, используются, чтобы обеспечить дополнительное понимание настоящей заявки, и составляют часть настоящей заявки. Примерные варианты осуществления настоящей заявки и их иллюстрации используются для объяснения настоящей заявки, но не предназначены для формирования любого неподходящего ограничения настоящей заявки. На прилагаемых чертежах:
Фиг. 1 является схематичной диаграммой, иллюстрирующей пользователя, выполняющего бизнес-обработку с использованием сети консенсуса блокчейнов в соответствии с вариантом осуществления настоящей заявки;
Фиг. 2 является схематичной диаграммой процедуры бизнес-обработки в соответствии с вариантом осуществления настоящей заявки;
Фиг. 3 является схематичной диаграммой устройства бизнес-обработки в соответствии с вариантом осуществления настоящего изобретения;
Фиг. 4 является схематичной диаграммой второго устройства бизнес-обработки в соответствии с вариантом осуществления настоящей заявки; и
Фиг. 5 является схематичной диаграммой третьего устройства бизнес-обработки в соответствии с вариантом осуществления настоящего изобретения.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Для того чтобы гарантировать эффективную беспристрастность процесса, в котором пользователь выполняет бизнес-обработку через организацию бизнес-обработки, в настоящей заявке, механизм доверия может быть установлен между пользователем и организацией бизнес-обработки с использованием сети консенсуса блокчейнов. То есть, посредством устойчивой к взлому характеристики данных, хранящихся в блокчейнах сети консенсуса, бизнес-запрос, отправленный пользователем, и бизнес-результат, полученный организацией бизнес-обработки в соответствии с бизнес-запросом, оба имеют эффективную беспристрастность. Кроме того, чтобы дополнительно улучшить беспристрастность при бизнес-обработке, отдел аудита дополнительно представляется в качестве узла блокчейна в настоящей заявке, чтобы верифицировать бизнес-запрос, отправленный пользователем, и бизнес-результат, полученный организацией бизнес-обработки. После успешной верификации, смарт-контракт запускается посредством подписания, чтобы автоматически исполнять назначенную операцию, тем самым реализуя процесс автоматического завершения бизнес-обработки без ручного вмешательства. Отношения между пользователем, организацией бизнес-обработки и отделом аудита показаны на фиг. 1.
Фиг. 1 является схематичной диаграммой, иллюстрирующей пользователя, выполняющего бизнес-обработку с использованием сети консенсуса блокчейнов в соответствии с вариантом осуществления настоящей заявки.
На фиг. 1, вся сеть консенсуса включает в себя множество узлов блокчейна. Терминал, на основе которого пользователь отправляет бизнес-запрос, организация бизнес-обработки и отдел аудита все являются узлами (нодами) блокчейна во всей сети консенсуса. Пользователь может отправлять бизнес-запрос на сеть консенсуса с использованием терминала, который служит первым узлом блокчейна. После того, как бизнес-запрос входит в сеть консенсуса, организация бизнес-обработки, в качестве третьего узла блокчейна, может принять бизнес-запрос и получить соответствующий бизнес-результат. После этого, отдел аудита, в качестве второго узла блокчейна, может верифицировать бизнес-результат, полученный третьим узлом блокчейна. После того, как определено, что бизнес-результат прошел верификацию, отдел аудита запускает, через подписание, первый узел блокчейна для исполнения первой назначенной операции с использованием смарт-контракта, то есть, передачи определенной суммы денег на расчетном счете пользователя к организации бизнес-обработки. Дополнительно, бизнес-результат, полученный организацией бизнес-обработки, и бизнес-запрос, отправленный пользователем, могут дополнительно храниться в блокчейне в форме краткого информационного реферата, и это создает основу для последующей аутентификации того, были ли бизнес-результат и бизнес-запрос модифицированы.
В варианте осуществления настоящей заявки, бизнес-запрос, отправленный пользователем на сеть консенсуса, включает в себя первый смарт-контракт. При помощи первого смарт-контракта, первый узел блокчейна может автоматически исполнять первую назначенную операцию с использованием смарт-контракта вслед за тем, как отдел аудита, в качестве второго узла блокчейна, верифицирует бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, как легальный.
Информация о бизнес-результате, сгенерированная третьим узлом блокчейна в соответствии с бизнес-результатом, включает в себя второй смарт-контракт. При помощи второго смарт-контракта, третий узел блокчейна может исполнять вторую назначенную операцию путем автоматического запуска смарт-контракта вслед за тем, как второй узел блокчейна верифицирует бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, как нелегальный (незаконный). Здесь, "первый" и "второй" используются только для различения разных смарт-контрактов друг от друга и не имеют особых значений.
Для того чтобы специалисты в данной области техники лучше поняли технические решения в настоящей заявке, технические решения в вариантах осуществления настоящей заявки будут описаны ясно и полно ниже в комбинации с прилагаемыми чертежами в вариантах осуществления настоящей заявки. Очевидно, что описанные варианты осуществления являются только некоторыми из вариантов осуществления настоящей заявки, а не всеми вариантами осуществления. На основе вариантов осуществления настоящей заявки, все другие варианты осуществления, выведенные специалистами в данной области техники без каких-либо творческих усилий, должны соответствовать объему правовой охраны настоящей заявки.
Фиг. 2 является схематичной диаграммой процедуры бизнес-обработки в соответствии с вариантом осуществления настоящей заявки, конкретно включающей в себя следующие этапы:
S201: Первый узел блокчейна принимает бизнес-информацию, отправленную пользователем.
В действительном применении, когда пользователю необходимо выполнить бизнес-обработку через организацию бизнес-обработки, пользователь может отправить бизнес-запрос на организацию бизнес-обработки через терминал, и бизнес-запрос генерируется терминалом в соответствии с бизнес-информацией, введенной пользователем в терминале. Например, во время оценки активов, при намерении выполнить оценку недвижимости, пользователь может ввести в терминал свою информацию действительного сертификата, информацию о недвижимости и вознаграждение, требуемое для этой оценки недвижимости. После приема информации, терминал может генерировать соответствующий запрос на оценку недвижимости в соответствии с информацией.
На этой основе, в варианте осуществления настоящей заявки, пользователь может вводить соответствующую бизнес-информацию в терминал во время бизнес-обработки. В дополнение к введению некоторой информации в назначенном положении интерфейса терминала, пользователь может также выгружать некоторую информацию на терминал. Терминал, упомянутый здесь, является первым узлом блокчейна в сети консенсуса.
Следует отметить, что, в варианте осуществления настоящей заявки, в дополнение к терминалу, первый узел блокчейна может дополнительно быть клиентским терминалом, назначенным в терминале. Первый узел блокчейна может также быть сервером. То есть, пользователь выгружает бизнес-информацию на сервер с использованием терминала, и сервер может генерировать соответствующий бизнес-запрос в соответствии с принятой бизнес-информацией.
S202: Первый смарт-контракт, согласующийся с бизнес-информацией, и бизнес-запрос генерируются в соответствии с бизнес-информацией.
После приема бизнес-информации, отправленной пользователем, первый узел блокчейна может генерировать, в соответствии с бизнес-информацией, первый смарт-контракт, согласующийся с бизнес-информацией. В варианте осуществления настоящей заявки, функция первого смарт-контракта состоит в следующем: как только второй узел блокчейна верифицирует бизнес-результат, сгенерированный третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна, как легальный, первому узлу блокчейна обычно требуется исполнить первую назначенную операцию путем запуска первого смарт-контракта. Первая назначенная операция является, например, передачей части назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна. Поэтому бизнес-информация, принятая первым узлом блокчейна, обычно включает в себя адрес расчетного счета пользователя и вознаграждение (т.е., назначенные ресурсы), уплачиваемое организации бизнес-обработки (т.е., третьему узлу блокчейна) за обработку этого бизнеса. Поэтому, в варианте осуществления настоящей заявки, первый узел блокчейна может генерировать первый смарт-контракт в соответствии с адресом расчетного счета пользователя и вознаграждением, оплаченным пользователем организации бизнес-обработки, которые включены в бизнес-информацию. Определенно, первый смарт-контракт может также генерироваться на основе другой бизнес-информации.
В варианте осуществления настоящей заявки, первый узел блокчейна может компилировать принятую бизнес-информацию с использованием предустановленного компилятора SOLC, чтобы получить первый смарт-контракт. К тому же, первый узел блокчейна может также генерировать первый смарт-контракт с использованием других методов компилирования, которые не будут поясняться примерами здесь отдельно.
После генерации первого смарт-контракта, первый узел блокчейна может дополнительно генерировать бизнес-запрос, соответствующий бизнес-информации в соответствии с принятой бизнес-информацией и первым смарт-контрактом. Бизнес-запрос может дополнительно включать в себя адрес расчетного счета пользователя в дополнение к первому смарт-контракту. Кроме того, бизнес-запрос может дополнительно включать в себя информацию реферата бизнес-информации. Информация реферата включена, поскольку первому узлу блокчейна необходимо затем отправить бизнес-запрос на сеть консенсуса, и обычно все узлы блокчейна во всей сети консенсуса могут просматривать бизнес-запрос в сети консенсуса, и если бизнес-запрос непосредственно включает в себя бизнес-информацию, выгруженную пользователем в первом узле блокчейна, пользовательская информация может просачиваться, таким образом вызывая неудобство для пользователя.
Например, полагая, что пользователь требует оценку недвижимости, пользователю обычно необходимо отправить свою подробную информацию о недвижимости на первый узел блокчейна (если первый узел блокчейна является платформой обслуживания, платформа обслуживания должна быть квалифицированной платформой, сертифицированной связанным отделом, то есть, платформа обслуживания не вызовет утечки информации, выгруженной пользователем). Если первый узел блокчейна не обрабатывает информацию о недвижимости, отправленную пользователем, но непосредственно добавляет информацию о недвижимости к сгенерированному бизнес-запросу, как только бизнес-запрос входит в полную сеть консенсуса, узлы блокчейна в сети консенсуса неизбежно просмотрят информацию о недвижимости пользователя, таким образом, вызывая утечку пользовательской информации.
Поэтому, чтобы защитить бизнес-информацию, отправленную пользователем, от утечки, в варианте осуществления настоящей заявки, первый узел блокчейна будет генерировать, в соответствии с принятой бизнес-информацией, информационный реферат бизнес-информации (определенно, процесс снижения чувствительности данных может также выполняться над бизнес-информацией), добавит информационный реферат к бизнес-запросу и отправит бизнес-запрос на сеть консенсуса. Таким образом, хотя все узлы блокчейна в сети консенсуса могут просматривать бизнес-запрос, они могут просматривать только информационный реферат в бизнес-запросе и не могут получать реальную бизнес-информацию, действительно соответствующую информационному реферату, тем самым защищая пользовательскую информацию от утечки.
Дополнительно, другая цель информационного реферата состоит в следующем: так как информационный реферат генерируется первым узлом блокчейна с использованием предустановленного алгоритма информационного реферата и принятой бизнес-информации, бизнес-информация и информационный реферат имеют уникальное соответствующее отношение. То есть, как только содержание бизнес-информации изменяется, информационный реферат, сгенерированный с использованием предустановленного алгоритма информационного реферата, определяется иначе относительно предыдущего информационного реферата (то есть, информационного реферата, сгенерированного до того, как содержание бизнес-информации изменилось). Таким образом, может достигаться задача эффективной проверки того, что пользователь или другой человек (или узел блокчейна) активно модифицировал бизнес-информацию в последующей процедуре.
Следует отметить, что, в дополнение к генерации первым узлом блокчейна в соответствии с бизнес-информацией, отправленной пользователем, первый смарт-контракт может дополнительно компилироваться пользователем. Соответственно, пользователь может отправлять компилированный первый смарт-контракт на первый узел блокчейна, так что первый узел блокчейна генерирует бизнес-запрос, включающий в себя первый смарт-контракт в соответствии с бизнес-информацией, отправленной пользователем, и первый смарт-контракт.
S203: Бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания проверки, отправляется на сеть консенсуса.
После получения бизнес-запроса, первый узел блокчейна может отправлять бизнес-запрос на сеть консенсуса. Первый узел блокчейна может отправлять бизнес-запрос на сеть консенсуса в форме транзакции. Например, инициируется транзакция малой суммы, и бизнес-запрос затем выполняется в транзакции и затем отправляется на сеть консенсуса, так что, когда третий узел блокчейна принимает затем эту транзакцию, третий узел блокчейна также принимает бизнес-запрос.
Обобщая, смарт-контракту требуется определенное условие запуска для исполнения различных действий. Условие запуска здесь может быть реализовано путем изменения состояния смарт-контракта. Поэтому, в варианте осуществления настоящей заявки, первый смарт-контракт имеет разные состояния на разных стадиях. Как только состояние изменяется, первый смарт-контракт запускается для преобразования в следующую стадию, то есть, отличающееся действие запускается для исполнения. На этой основе, когда первый узел блокчейна отправляет бизнес-запрос на сеть консенсуса, состояние первого смарт-контракта в запросе на бизнес может изменяться с исходного не-состояния в состояние ожидания проверки, так что второй узел блокчейна верифицирует, в последующей процедуре, легальность бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания проверки.
Определенно, когда первый узел блокчейна генерирует первый смарт-контракт в соответствии с принятой бизнес-информацией, первый смарт-контракт находится в состоянии ожидания проверки. Другими словами, как только первый смарт-контракт сгенерирован, его исходным состоянием является состояние ожидания проверки. После этого, первый узел блокчейна может отправлять бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания проверки, на сеть консенсуса, так что второй узел блокчейна в сети консенсуса верифицирует легальность бизнес-запроса.
S204: Второй узел блокчейна получает, из первого узла блокчейна в соответствии с бизнес-запросом, бизнес-информацию, соответствующую бизнес-запросу.
В варианте осуществления настоящей заявки, узлы блокчейна в сети консенсуса могут иметь множество бизнес-запросов, и разные бизнес-запросы могут находиться в разных стадиях бизнес-обработки. Например, некоторые бизнес-запросы могут только отправляться из первого узла блокчейна на сеть консенсуса, и некоторые бизнес-запросы могут быть исполненными в некоторой степени. Маркировка стадий бизнес-обработки бизнес-запросов может быть реализована с использованием состояний смарт-контрактов, включенных в бизнес-запросы. Следовательно, для некоторых бизнес-запросов, которые только входят в сеть консенсуса, второму узлу блокчейна (то есть, отделу аудита) в сети консенсуса необходимо проверить бизнес-запросы, включающие в себя первые смарт-контракты в состоянии ожидания проверки, и дополнительно верифицировать легальность таких бизнес-запросов в последовательной процедуре.
S205: Верифицируется, легальна ли бизнес-информация, и, если да, выполняется этап S206; или если нет, выполняется этап S207.
S206: Подписание выполняется на бизнес-запросе, так что состояние первого смарт-контракта изменяется из состояния ожидания проверки в состояние ожидания принятия, и первый узел блокчейна замораживает первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя в бизнес-запросе с использованием первого смарт-контракта в состоянии ожидания принятия.
S207: Подписание не выполняется на бизнес-запросе, так что первый узел блокчейна определяет, что бизнес-запрос не удалось принять.
При просмотре бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания проверки из сети консенсуса, второму узлу блокчейна необходимо верифицировать легальность бизнес-запроса. Верификация проводится, поскольку в действительной заявке, организация бизнес-обработки может обмануть пользователя, и пользователь может также обмануть организацию бизнес-обработки. Например, при выполнении оценки недвижимости через организацию бизнес-обработки, пользователь может предоставить ложную информацию о недвижимости, не соответствующую действительности, организации бизнес-обработки, так что организация бизнес-обработки получает отчет об оценке недвижимости (т.е., бизнес-результат), не соответствующий действительности в соответствии с информацией о недвижимости, обеспеченной пользователем. С использованием истинной информации о недвижимости, пользователь может затем подать иск против организации бизнес-обработки за отчет об оценке недвижимости, не соответствующий действительности. Это может неблагоприятно повлиять на организацию бизнес-обработки.
Поэтому, чтобы избежать ситуации, указанной выше, в варианте осуществления настоящей заявки, прежде чем третий второй узел блокчейна примет и обработает бизнес-запрос, отправленный первым вторым узлом блокчейна, второй узел блокчейна (т.е., отдел аудита) может сначала верифицировать бизнес-запрос в целях обеспечения легальности бизнес-запроса.
Более конкретно, при просмотре бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания проверки в сети консенсуса, второй узел блокчейна может получить, из первого узла блокчейна, бизнес-информацию, отправленную пользователем на первый узел блокчейна, и верифицировать легальность бизнес-информации. Если бизнес-информация верифицирована как легальная, второй узел блокчейна может подписать бизнес-запрос в сети консенсуса. Как только бизнес-запрос подписан вторым узлом блокчейна, первый смарт-контракт в бизнес-запросе изменится из состояния ожидания проверки в состояние ожидания принятия. Таким образом, третий узел блокчейна может затем принять бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия. Другими словами, так как второй узел блокчейна осуществляет подписание бизнес-запроса, в некоторой степени гарантируется, что бизнес-запрос, принятый третьим узлом блокчейна, является легальным бизнес-запросом.
В то же самое время, как только второй узел блокчейна подписывает бизнес-запрос, узлы блокчейна во всей сети консенсуса могут установить консенсус о бизнес-запросе. Как только консенсус установлен, бизнес-запрос будет записан в блокчейнах в сети консенсуса, то есть, блокчейнах узлов блокчейнов. Информация, записанная в блокчейнах, устойчива ко взлому, и следовательно, после записи в блокчейнах, бизнес-запрос может использоваться в последующей процедуре для верифицирования того, были ли бизнес-информация, отправленная пользователем, и бизнес-результат, полученный третьим узлом блокчейна (то есть, организацией бизнес-обработки) в соответствии с бизнес-информацией, модифицированы (так как бизнес-запрос включает в себя информационный реферат, сгенерированный первым узлом блокчейна в соответствии с бизнес-информацией), тем самым дополнительно гарантируя беспристрастность всей бизнес-обработки.
Кроме того, как только второй узел блокчейна определяет бизнес-информацию как легальную и подписывает бизнес-запрос, первый узел блокчейна может заморозить первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя с использованием первого смарт-контракта в состоянии ожидания принятия, для использования в последующем расчете бизнеса.
В дополнение к верифицированию того, легальна ли бизнес-информация, полученная из первого узла блокчейна, второму узлу блокчейна дополнительно необходимо верифицировать, является ли бизнес-информация уникально соответствующей информационному реферату в бизнес-запросе, и разумно ли создан первый смарт-контракт в бизнес-запросе. Определенно, второму узлу блокчейна также необходимо проанализировать, с использованием публичного ключа (или приватного ключа), хранимого самим, адрес расчетного счета пользователя, включенный в бизнес-запрос, и определить легальность адреса расчетного счета. Как только второй узел блокчейна верифицирует все вышеуказанные элементы как легальные, выполняется подписание бизнес-запроса, так что узлы блокчейна в сети консенсуса устанавливают консенсус о бизнес-запросе, и состояние первого смарт-контракта в бизнес-запросе запускается для изменения из состояния ожидания проверки в состояние ожидания принятия. То, использует ли второй узел блокчейна публичный ключ или приватный ключ для анализа адреса расчетного счета пользователя, включенного в бизнес-запрос, зависит от того, использует ли первый узел блокчейна приватный ключ или публичный ключ при генерации бизнес-запроса.
Когда второй узел блокчейна верифицирует бизнес-запрос как нелегальный (например, адрес расчетного счета пользователя является нелегальным, бизнес-информация не соответствует информационному реферату в бизнес-запросе, первый смарт-контракт произведен неразумно, и бизнес-информация является нелегальной), не производится подписание бизнес-запроса, так что первый узел блокчейна определяет, что бизнес-запрос не удалось принять, и возвращает сообщение, указывающее неудачу в признании бизнес-запроса, пользователю. Способ определения, первым узлом блокчейна, того, что бизнес-запрос не удалось принять, может быть следующим: когда первый узел блокчейна наблюдает, с использованием первого смарт-контракта в бизнес-запросе, что второй узел блокчейна все еще не подписывает на бизнес-запросе, спустя первую установленную длительность, сообщение, указывающее, что бизнес-запрос не удалось принять, автоматически запускается с использованием первого смарт-контракта для возврата на первый узел блокчейна. Поэтому пользователь узнает, в соответствии с сообщением, принятым первым узлом блокчейна, что бизнес-запрос, отправленный с использованием первого узла блокчейна, не смог пройти аудит, выполняемый вторым узлом блокчейна. Определенно, в варианте осуществления настоящей заявки, после верификации бизнес-запроса как нелегального, второй узел блокчейна может непосредственно отправить на первый узел блокчейна сообщение, указывающее, что бизнес-запрос не смог пройти аудит.
Следует отметить, что, в варианте осуществления настоящей заявки, второй узел блокчейна является отделом аудита, который может проводить аудит бизнес-запроса и бизнес-результата, отправляемого организацией бизнес-обработки. Следовательно, второй узел блокчейна имеет разрешение на получение бизнес-информации из первого узла блокчейна. С учетом того, что необходимо защитить бизнес-информацию пользователя от получения нелегальной организацией и утечки, в варианте осуществления настоящей заявки, когда второй узел блокчейна просматривает бизнес-запрос и должен верифицировать легальность бизнес-запроса, сертификат безопасности, хранимый им самим (т.е., вторым узлом блокчейна), может быть отправлен на первый узел блокчейна, и первый узел блокчейна может верифицировать квалификацию второго узла блокчейна с использованием сертификата безопасности. Как только определено, что второй узел блокчейна имеет право верифицировать легальность бизнес-информации, отправленной пользователем, второй узел блокчейна может быть авторизован, чтобы получать, из первого узла блокчейна, бизнес-информацию, отправленную пользователем; в противном случае, разрешение не предоставляется второму узлу блокчейна.
S208: Третий узел блокчейна получает бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия.
После верифицирования, с использованием бизнес-запроса, бизнес-информации, соответствующей бизнес-запросу, как легальной, второй узел блокчейна может подписать бизнес-запрос, чтобы запустить первый смарт-контракт в бизнес-запросе для изменения из состояния ожидания проверки в состояние ожидания принятия. Бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия, является бизнес-запросом, верифицированным вторым узлом блокчейна (т.е., отделом аудита), и поэтому бизнес-запрос является легальным. В результате, третий узел блокчейна (т.е., организация бизнес-обработки) может затем принять бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия. Как известно из этапа S203 выше, первый узел блокчейна может добавить бизнес-запрос к транзакции и отправить транзакцию на сеть консенсуса. Поэтому третий узел блокчейна может принять транзакцию, отправленную первым узлом блокчейна, что эквивалентно принятию бизнес-запроса.
После того, как третий узел блокчейна принял бизнес-запрос, первый смарт-контракт в бизнес-запросе изменится из состояния ожидания принятия в состояние принятия. Это объясняется тем, что может иметься множество третьих узлов блокчейна во всей сети консенсуса в действительном применении, то есть, может иметься множество организаций бизнес-обработки. Обычно, после того как одна организация бизнес-обработки приняла бизнес-запрос, другая организация бизнес-обработки больше не должна принимать бизнес-запрос. Если бизнес-запрос принимается повторно, в итоге может возникнуть несколько бизнес-результатов, что не только вызывает проблемы для пользователя, но также вызывает разногласия о бизнесе для организаций бизнес-обработки.
Чтобы избежать вышеуказанной ситуации, в варианте осуществления настоящей заявки, как только третий узел блокчейна принимает бизнес-запрос, первый смарт-контракт в бизнес-запросе изменится из состояния ожидания принятия в состояние принятия. Таким образом, другой третий узел блокчейна (т.е., другая организация бизнес-обработки) не примет бизнес-запрос снова, увидев, что первый смарт-контракт в бизнес-запросе находится в состоянии принятия, тем самым исключая повторное принятие бизнес-запроса.
Следует отметить, что, в варианте осуществления настоящей заявки, когда первый узел блокчейна отправляет бизнес-запрос на сеть консенсуса, обычно, узлы блокчейна (включающие в себя второй узел блокчейна и третий узел блокчейна) в сети консенсуса все принимают бизнес-запрос. В варианте осуществления настоящей заявки, состояние первого смарт-контракта необходимо синхронизировать среди узлов блокчейна. Поэтому, при подписании бизнес-запроса, второй узел блокчейна может отправлять сообщение, указывающее, что бизнес-запрос проходит верификацию, другому узлу блокчейна в сети консенсуса. После того, как третий узел блокчейна в сети консенсуса принимает сообщение, первый смарт-контракт в бизнес-запросе, существующий в третьем узле блокчейна, может автоматически запускаться для изменения своего собственного состояния в состояние ожидания принятия. Таким образом, в последовательной процедуре, третий узел блокчейна может обрабатывать бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия.
Дополнительно, в варианте осуществления настоящей заявки, первый узел блокчейна может сначала отправить бизнес-запрос на второй узел блокчейна в сети консенсуса. Когда определено, что бизнес-запрос проходит верификацию, второй узел блокчейна может подписать бизнес-запрос, так что состояние первого смарт-контракта в бизнес-запросе изменяется на состояние ожидания принятия. Бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия, затем дополнительно отправляется на узлы блокчейна в сети консенсуса. В то же самое время, второй узел блокчейна может возвращать на первый узел блокчейна сообщение, указывающее, что бизнес-запрос проходит верификацию, так что первый узел блокчейна изменяет состояние первого смарт-контракта бизнес-запроса, хранящегося в нем, на состояние ожидания принятия. Подобным образом, при приеме бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания принятия, третий узел блокчейна может принимать и обрабатывать бизнес-запрос.
Определенно, в варианте осуществления настоящей заявки, второй узел блокчейна может также синхронизировать состояние первого смарт-контракта путем хеджирования. То есть, первый узел блокчейна может сначала отправить бизнес-запрос на узлы блокчейна в сети консенсуса. В это время, в узлах блокчейна (включающих в себя второй узел блокчейна и третий узел блокчейна), состояния первых смарт-контрактов в запросах на бизнес оба являются состоянием ожидания проверки. При приеме бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания проверки, третий узел блокчейна не будет обрабатывать бизнес-запрос. В то же самое время, при приеме бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания проверки, другие узлы блокчейна не установят консенсус о бизнес-запросе.
После приема бизнес-запроса, второй узел блокчейна верифицирует бизнес-запрос. Как только бизнес-запрос верифицирован как легальный, состояние первого смарт-контракта во втором узле блокчейна может изменяться посредством подписания, то есть, изменяться в состояние ожидания принятия. Второй узел блокчейна может затем отправить бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия, на узлы блокчейна в сети консенсуса. После приема бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания принятия, узлы блокчейна могут покрывать (или удалять) ранее принятый бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания проверки, и установить консенсус о бизнес-запросе, включающем в себя первый смарт-контракт в состоянии ожидания проверки. В то же самое время, третий узел блокчейна может обрабатывать бизнес-запрос, чтобы получить соответствующий бизнес-результат.
S209: Бизнес-результат, соответствующий бизнес-запросу, получают в соответствии с бизнес-запросом.
После получения бизнес-запроса, третьему узлу блокчейна (т.е., организации бизнес-обработки) необходимо получить соответствующий бизнес-результат в соответствии с бизнес-запросом. Бизнес-запрос включает в себя информационный реферат, а не саму информацию, третий узел блокчейна не может получить разумный бизнес-результат в соответствии с кратким изложением информации. Поэтому третьему узлу блокчейна необходимо получить бизнес-информацию, соответствующую информационному реферату, из первого узла блокчейна, тем самым получая соответствующий бизнес-результат в соответствии с бизнес-информацией.
На этой основе, в варианте осуществления настоящей заявки, после получения бизнес-запроса, третий узел блокчейна может отправлять сообщение для принятия бизнес-запроса на первый узел блокчейна. Когда пользователь просматривает сообщение с использованием первого узла блокчейна и разрешает третьему узлу блокчейна принять бизнес-запрос, отправленный пользователем, сообщение для разрешения принятия может возвращаться на третий узел блокчейна с использованием первого узла блокчейна, и первому узлу блокчейна разрешается предоставить разрешение на доступ третьему узлу блокчейна. После приема сообщения для разрешения принятия, возвращенного первым узлом блокчейна (т.е., после наблюдения того, что первый узел блокчейна разрешает третьему узлу блокчейна принять бизнес-запрос), третий узел блокчейна получает, из первого узла блокчейна, бизнес-информацию, соответствующую бизнес-запросу, в соответствии с разрешением на доступ, полученным из узла блокчейна, и бизнес-запросом. Первый узел блокчейна устанавливает разрешение на доступ для первого узла блокчейна, чтобы препятствовать некоторым нелегальным организациям в получении и утечке бизнес-информации пользователя, тем самым избегая потерь для пользователя.
После получения бизнес-информации из первого узла блокчейна, третий узел блокчейна может получить бизнес-результат, соответствующий бизнес-информации, в соответствии с бизнес-информацией. Бизнес-результат может продуцироваться специалистом бизнес-обработки. Специалист бизнес-обработки может выгружать бизнес-результат на третий узел блокчейна, чтобы бизнес-результат был получен.
S210: Бизнес-информация обратной связи, согласующаяся с бизнес-результатом, генерируется в соответствии с бизнес-результатом, причем бизнес-информация обратной связи включает в себя второй смарт-контракт, полученный третьим узлом блокчейна в соответствии с бизнес-запросом.
После того, как третий узел блокчейна получил бизнес-результат, необходимо произвести проверку бизнес-результата вторым узлом блокчейна в сети консенсуса в последующей процедуре. Третий узел блокчейна не может непосредственно отправить бизнес-информацию на сеть консенсуса, так как бизнес-результат, полученный третьим узлом блокчейна, может отражать бизнес-информацию пользователя. Если нелегальная организация получит бизнес-результат, нелегальная операция может выполняться над собственностью пользователя в соответствии с бизнес-результатом, таким образом вызывая потери для пользователя.
Поэтому, в варианте осуществления настоящей заявки после того, как третий узел блокчейна получает бизнес-результат из первого узла блокчейна, необходимо сгенерировать бизнес-информацию обратной связи, согласующуюся с бизнес-результатом в соответствии с полученным бизнес-результатом. Третий узел блокчейна может генерировать реферат результата бизнес-результата с использованием предустановленного алгоритма информационного реферата, добавлять реферат результата к генерируемой затем бизнес-информации обратной связи и отправлять бизнес-информацию обратной связи на сеть консенсуса. В дополнение к эффективному предотвращению утечки бизнес-информации, реферат результата может дополнительно обеспечить мощную основу для последующей верификации того, модифицирует ли третий узел блокчейна полученный бизнес-результат (поскольку реферат результата уникально соответствует бизнес-результату, если содержание в бизнес-результате изменяется, невозможно получить реферат результата, идентичный предыдущему, в соответствии с измененным бизнес-результатом с использованием того же самого алгоритма информационного реферата).
К тому же, в варианте осуществления настоящей заявки, третий узел блокчейна может дополнительно генерировать второй смарт-контракт, согласующийся с бизнес-результатом, в соответствии с полученным бизнес-результатом и добавлять второй смарт-контракт к генерируемой затем бизнес-информации обратной связи. Это объясняется тем, что, в реальном применении, организация бизнес-обработки может обмануть пользователя, то есть, получить ложный бизнес-результат в соответствии с реальной бизнес-информацией, обеспеченной пользователем, таким образом вызывая потери для пользователя. Организация бизнес-обработки может отказаться признать мошенническое поведение в отношении пользователя, и поэтому пользователю может не удаться получить соответствующую компенсацию.
На этой основе, в варианте осуществления настоящей заявки, когда второй узел блокчейна (т.е., отдел аудита) верифицирует подлежащую верификации информацию о бизнес-результате, отправленную третьим узлом блокчейна, если обнаруживается, что бизнес-информация обратной связи не включает в себя второй смарт-контракт, способный автоматически запускать компенсацию для пользователя, если имеет место мошенническое поведение в отношении пользователя (даже если третий узел блокчейна исполняет вторую назначенную операцию с использованием второго смарт-контракта), второй узел блокчейна не принимает бизнес-информацию обратной связи или определяет, что бизнес-информацию обратной связи не удается принять. Поэтому, чтобы бизнес-информация обратной связи, отправляемая затем на второй узел блокчейна, могла пройти верификацию, выполняемую вторым узлом блокчейна, третий узел блокчейна должен сгенерировать второй смарт-контракт, согласующийся с бизнес-запросом в соответствии с бизнес-запросом, добавить второй смарт-контракт к генерируемой затем бизнес-информации обратной связи и отправить бизнес-информацию обратной связи на сеть консенсуса.
В варианте осуществления настоящей заявки, при приеме, от первого узла блокчейна, бизнес-информации, соответствующей бизнес-запросу, третий узел блокчейна компилирует бизнес-информацию с использованием предустановленного компилятора SOLC, чтобы получить второй смарт-контракт. Определенно, третий узел блокчейна может также компилировать второй смарт-контракт другими методами компилирования, которые не будут поясняться здесь отдельными примерами.
Определенно, в варианте осуществления настоящей заявки, бизнес-запрос включает в себя первый смарт-контракт, вознаграждение, оплачиваемое пользователем для этой бизнес-обработки, специфицировано в первом смарт-контракте, и бизнес-запрос записывает бизнес-тип для бизнеса. Поэтому третий узел блокчейна может непосредственно компилировать бизнес-запрос с использованием предустановленного компилятора SOLC, чтобы получить второй смарт-контракт, согласующийся с бизнес-запросом.
Кроме того, третий узел блокчейна может создавать различные вторые смарт-контракты заранее, причем различные вторые смарт-контракты соответствуют разным бизнес-типам и бизнес-уровням. Например, для бизнес-запроса, имеющего высокий бизнес-уровень, второй смарт-контракт, соответствующий такому типу бизнес-запроса, может иметь более высокую степень требований. Бизнес-запросы одного и того же бизнес-уровня, но разных бизнес-типов, будут соответствовать разным вторым смарт-контрактам. Поэтому третий узел блокчейна может конкретно создавать различные вторые смарт-контракты в соответствии с разными бизнес-типами и разными бизнес-уровнями, и созданные вторые смарт-контракты хранятся в третьем узле блокчейна.
На этой основе, в варианте осуществления настоящей заявки, после получения бизнес-запроса, включающего в себя первый смарт-контракт в состоянии ожидания принятия, третий узел блокчейна может дополнительно определить бизнес-уровень и бизнес-тип бизнес-запроса, чтобы определить согласующийся второй смарт-контракт в соответствии с определенными бизнес-уровнем и бизнес-типом, наряду с первым установленным количеством назначенных ресурсов, специфицированных в первом смарт-контракте (например, бизнес-вознаграждение, специфицированное пользователем), затем добавить определенный второй смарт-контракт к сгенерированной бизнес-информации обратной связи и отправить бизнес-информацию обратной связи на сеть консенсуса.
Следует отметить, что, в последующей процедуре, адрес расчетного счета третьего узла блокчейна требуется, когда пользователь оплачивает вознаграждение за бизнес-обработку третьему узлу блокчейна (т.е., организации бизнес-обработки) и когда третий узел блокчейна расплачивается с пользователем. Следовательно, в варианте осуществления настоящей заявки, в дополнение к включению в себя второго смарт-контракта и реферата результата, как описано выше, бизнес-информация обратной связи, сгенерированная третьим узлом блокчейна, дополнительно включает в себя адрес расчетного счета третьего узла блокчейна. Более того, в варианте осуществления настоящей заявки, как только второй узел блокчейна определяет бизнес-результат, полученный третьим узлом блокчейна, как легальный, необходимо подписать бизнес-информацию обратной связи, отправляемую третьим узлом блокчейна, так что второй смарт-контракт в бизнес-информации обратной связи запускается, чтобы запустить первый смарт-контракт в бизнес-запросе для исполнения действия передачи первого установленного количества назначенных ресурсов (например, определенной суммы денег) на расчетном счете пользователя на адрес расчетного счета третьего узла блокчейна в качестве вознаграждения. Поэтому второй смарт-контракт должен быть ассоциирован с первым смарт-контрактом в бизнес-запросе, чтобы второй смарт-контракт мог запустить первый смарт-контракт, чтобы затем исполнять вышеуказанное действие.
S211: Бизнес-информация обратной связи отправляется на сеть консенсуса.
После получения бизнес-информации обратной связи, третий узел блокчейна может отправлять бизнес-информацию обратной связи на сеть консенсуса. Когда бизнес-информация обратной связи отправляется на сеть консенсуса, второй смарт-контракт в бизнес-информации обратной связи будет изменен из исходного не-состояния в состояние ожидания верификации. Таким образом, второй узел блокчейна в сети консенсуса может затем запросить бизнес-информацию обратной связи, включающую в себя второй смарт-контракт в состоянии ожидания верификации, и верифицировать легальность бизнес-информации обратной связи, когда определено, что второй смарт-контракт в бизнес-информации обратной связи находится в состоянии ожидания верификации.
Дополнительно, в варианте осуществления настоящей заявки, как только третий узел блокчейна отправляет бизнес-информацию обратной связи на сеть консенсуса, второй смарт-контракт в бизнес-информации обратной связи запустит, посредством изменения состояния, третий узел блокчейна для заморозки второго установленного количества назначенных ресурсов (т.е., определенной суммы денег для компенсации) в адресе расчетного счета третьего узла блокчейна с использованием второго смарт-контракта. Поэтому гарантируется, что в последующей процедуре, как только бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, верифицирован как нелегальный, третий узел блокчейна передает эту часть замороженных назначенных ресурсов на расчетный счет пользователя путем запуска второго смарт-контракта.
Следует отметить, что, при отправке бизнес-информации обратной связи, третий узел блокчейна может добавить бизнес-информацию обратной связи к транзакции и отправить транзакцию на сеть консенсуса. Транзакция может непосредственно назначать второй узел блокчейна в сети консенсуса в качестве объекта транзакции для транзакции.
S212: Второй узел блокчейна получает, из сети консенсуса, бизнес-информацию обратной связи, отправленную третьим узлом блокчейна.
После приема бизнес-информации обратной связи, которая отправляется третьим узлом блокчейна и включает в себя второй смарт-контракт в состоянии ожидания верификации, второй узел блокчейна может принять бизнес-информацию обратной связи, то есть, принять транзакцию, несущую бизнес-информацию обратной связи, и дополнительно верифицировать легальность бизнес-информации обратной связи в последующей процедуре.
S213: Бизнес-результат, соответствующий бизнес-информации обратной связи, получают из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи.
После получения бизнес-информации обратной связи, второму узлу блокчейна необходимо определить бизнес-результат, соответствующий бизнес-информации обратной связи в соответствии с бизнес-информацией обратной связи. Бизнес-информация обратной связи не включает в себя реальный бизнес-результат, а только включает в себя реферат результата, уникально соответствующий бизнес-результату (определенно, бизнес-информация обратной связи может также включать в себя бизнес-результат, но необходимо выполнить снижение чувствительности данных для бизнес-результата, когда третий узел блокчейна отправляет бизнес-результат, чтобы защитить приватную информацию пользователя). Поэтому второму узлу блокчейна необходимо запросить бизнес-результат, соответствующий бизнес-информации обратной связи, из третьего узла блокчейна и затем верифицировать легальность бизнес-результата в последующей процедуре.
Второй узел блокчейна (т.е., отдел аудита) является отделом, который может верифицировать легальность бизнес-результата, полученного третьим узлом блокчейна. Следовательно, обычно, второй узел блокчейна имеет разрешение непосредственно получать бизнес-результат из третьего узла блокчейна. Третий узел блокчейна может также ограничить разрешение второго узла блокчейна, чтобы более эффективно защищать приватную информацию пользователя от утечки. Соответственно, если третий узел блокчейна ограничивает разрешение на доступ второго узла блокчейна, при приеме и признании бизнес-информации обратной связи, отправленной третьим узлом блокчейна на сеть консенсуса, второй узел блокчейна может отправлять сообщение запроса для принятия бизнес-информации обратной связи на третий узел блокчейна, добавлять его сертификат безопасности к сообщению запроса и отправлять сообщение запроса на третий узел блокчейна. После приема сообщения запроса, третий узел блокчейна может верифицировать сертификат безопасности.
После верификации, если сертификат безопасности имеет квалификацию верифицирования бизнес-информации обратной связи и второму узлу блокчейна разрешено верифицировать бизнес-информацию обратной связи, сообщение обратной связи, указывающее одобрение принятия, может возвращаться на второй узел блокчейна, и разрешение на доступ, разрешающее получение бизнес-результата из третьего узла блокчейна, предоставляется второму узлу блокчейна, так что второй узел блокчейна получает, из третьего узла блокчейна, бизнес-результат, соответствующий бизнес-информации обратной связи на основе разрешения на доступ.
S214: Верифицируется, является ли бизнес-результат легальным, и, если да, выполняется этап S215; или если нет, выполняется этап S216.
S215: Выполняется подписание информации о бизнес-результате, так что третий узел блокчейна запускает второй смарт-контракт, чтобы разрешать первому узлу блокчейна исполнять действие передачи первого установленного количества назначенных ресурсов в адресе расчетного счета пользователя, включенного в бизнес-запрос, на адрес расчетного счета третьего узла блокчейна с использованием первого смарт-контракта.
S216: Не выполняется подписание информации о бизнес-результате, так что третий узел блокчейна передает, с использованием второго смарт-контракта, второе установленное количество назначенных ресурсов в адресе расчетного счета третьего узла блокчейна на адрес расчетного счета пользователя.
Когда второй узел блокчейна получает, из третьего узла блокчейна, бизнес-результат, соответствующий бизнес-информации обратной связи, второй узел блокчейна может верифицировать легальность бизнес-результата. Конкретный метод верификации может быть следующим: верифицирование бизнес-результата в соответствии с бизнес-информацией, когда второй узел блокчейна получил, из первого узла блокчейна, бизнес-информацию, отправленную пользователем на первый узел блокчейна, чтобы подтвердить, верно ли бизнес-результат отображает действительные условия, записанные бизнес-информацией, и выполняет эффективную и объективную оценку над бизнес-информацией. Если да, бизнес-результат определяется как легальный бизнес-результат; или если нет, считается, что бизнес-результат является мошенничеством.
Дополнительно, в варианте осуществления настоящей заявки, второму узлу блокчейна необходимо анализировать бизнес-информацию обратной связи с использованием публичного ключа (или приватного ключа), хранимого им самим, чтобы получить адрес расчетного счета третьего узла блокчейна, включенный в бизнес-информацию обратной связи, чтобы определить, является ли адрес расчетного счета легальным, и верифицировать, является ли второй смарт-контракт, включенный в бизнес-информацию обратной связи, применимым к бизнес-информации, отправленной пользователем в первом узле блокчейна, и первому смарт-контракту, включенному в бизнес-запрос, например, определить, согласуется ли сумма компенсации, включенная во второй смарт-контракт, с бизнес-типом и бизнес-уровнем бизнес-информации и бизнес-вознаграждением, специфицированным в первом смарт-контракте. Если все вышеуказанные аспекты верифицированы как легальные, бизнес-информация обратной связи, отправленная третьим узлом блокчейна, определяется как легальная; в противном случае, бизнес-информация обратной связи определяется как нелегальная.
Когда третий узел блокчейна верифицирует бизнес-информацию обратной связи как легальную, может выполняться подписание бизнес-информации обратной связи, чтобы запустить второй смарт-контракт в бизнес-информации обратной связи для изменения из состояния ожидания верификации в состояние успешной верификации. Поэтому третий узел блокчейна запускает, с использованием второго смарт-контракта, первый смарт-контракт, ассоциированный со вторым смарт-контрактом, для передачи первого установленного количества назначенных ресурсов (т.е., вознаграждения, оплачиваемого организации бизнес-обработки, специфицированной в первом смарт-контракте) в адресе расчетного счета пользователя в бизнес-запросе, на адрес расчетного счета третьего узла блокчейна. В то же самое время, как только второй узел блокчейна подписывает бизнес-информацию обратной связи, узлы блокчейна в сети консенсуса будут устанавливать консенсус о бизнес-информации обратной связи. После того, как консенсус о бизнес-информации обратной связи установлен, бизнес-информация обратной связи записывается в блокчейнах в сети консенсуса. Другими словами, узлы блокчейна могут записывать бизнес-информацию обратной связи, в отношении которой установлен консенсус, в соответственные блокчейны. Информация о данных, записанная в блокчейны, устойчива к взлому. Поэтому может быть эффективно верифицировано, с использованием реферата результата, включенного в бизнес-информацию обратной связи, записанную в блокчейны, модифицирует ли затем пользователь или организация бизнес-обработки в качестве третьего узла блокчейна соответствующий бизнес-результат, тем самым обеспечивая мощную основу для верификации того, модифицирован ли бизнес-результат.
Когда второй узел блокчейна верифицирует бизнес-информацию обратной связи как нелегальную, не производится подписание бизнес-информации обратной связи. Таким образом, когда наблюдается, с использованием второго смарт-контракта, что второй узел блокчейна все еще не подписывает бизнес-информацию обратной связи спустя первую установленную длительность, третий узел блокчейна может автоматически запускать, с использованием второго смарт-контракта, действие передачи второго установленного количества назначенных ресурсов (т.е., денег для компенсации) в адресе расчетного счета третьего узла блокчейна на расчетный счет пользователя.
Дополнительно, когда второй узел блокчейна не выполняет подписание бизнес-информации обратной связи, узлы блокчейна в сети консенсуса не могут установить консенсус о бизнес-информации обратной связи, то есть, бизнес-информация обратной связи эквивалентно отбрасывается.
Следует отметить, что состояния второго смарт-контракта, проиллюстрированные выше в узлах блокчейна в сети консенсуса, требуется синхронизировать. Конкретный метод синхронизации аналогичен методу синхронизации состояний первого смарт-контракта, что не описывается подробно. Как только второй узел блокчейна определяет бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-информацией, как легальный и подписывает бизнес-информацию обратной связи, состояние второго смарт-контракта бизнес-информации обратной связи в третьем узле блокчейна изменится, то есть, изменится на состояние успешной верификации. В этом случае, узел блокчейна может отправлять сообщение, указывающее, что бизнес-результат верифицирован как легальный, на первый узел блокчейна с использованием второго смарт-контракта в состоянии успешной верификации. После приема сообщения, первый узел блокчейна может передать, с использованием первого смарт-контракта, первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна. Другими словами, сообщение, отправленное третьим узлом блокчейна на первый узел блокчейна, может рассматриваться как условие для запуска первого узла блокчейна для передачи назначенных ресурсов с использованием первого смарт-контракта.
Определенно, когда определено, что бизнес-результат проходит верификацию, второй узел блокчейна может отправлять сообщение, указывающее, что бизнес-результат проходит верификацию, на первый узел блокчейна. При наблюдении, с использованием первого смарт-контракта, того, что второй узел блокчейна отправляет на него сообщение, первый смарт-контракт может запустить передачу первого установленного количества назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна с использованием первого смарт-контракта.
После того, как определено, что бизнес-результат проходит верификацию, выполняемую вторым узлом блокчейна, третий узел блокчейна может уведомить первый узел блокчейна о сообщении, указывающем, что бизнес-результат проходит верификацию. Следовательно, после приема сообщения, первый узел блокчейна может получить бизнес-результат из третьего узла блокчейна. Определенно, третий узел блокчейна может также активно рассылать бизнес-результат, который проходит верификацию, выполняемую вторым узлом блокчейна, на первый узел блокчейна.
Дополнительно, в варианте осуществления настоящей заявки, после того, как определено, что бизнес-результат проходит верификацию, второй узел блокчейна может также отправлять сообщение, указывающее, что бизнес-запрос проходит верификацию, на первый узел блокчейна, так что первый узел блокчейна получает бизнес-результат из второго узла блокчейна после приема сообщения. Определенно, второй узел блокчейна может также активно рассылать бизнес-запрос, который проходит верификацию, на первый узел блокчейна.
Можно видеть из вышеописанного способа, что первый узел блокчейна и третий узел блокчейна автоматически выполняют оплату вознаграждения или компенсации с использованием смарт-контракта, ручное вмешательство не требуется. Кроме того, весь процесс бизнес-обработки реализуется при наблюдении и верификации второго узла блокчейна, тем самым эффективно гарантируя беспристрастность всего процесса бизнес-обработки. Дополнительно, как только бизнес-запрос, отправленный первым узлом блокчейна на сеть консенсуса, и бизнес-информация обратной связи, отправленная третьим узлом блокчейна на сеть консенсуса, верифицированы как легальные вторым узлом блокчейна, узлы блокчейна в сети консенсуса дополнительно установят консенсус о бизнес-запросе и бизнес-информации обратной связи. После того, как консенсус установлен, бизнес-запрос и бизнес-информация обратной связи записываются в блокчейны в сети консенсуса, таким образом, обеспечивая мощную основу для верификации того, модифицированы ли бизнес-информация, отправленная пользователем, и бизнес-результат, полученный третьим узлом блокчейна.
Следует отметить, что, в варианте осуществления настоящей заявки, верификация легальности бизнес-запроса и бизнес-информации обратной связи может быть реализована одним вторым узлом блокчейна или множеством вторых узлов блокчейна. Эти вторые узлы блокчейна могут толковаться как некоторые отделы или организации, обладающие доверием. Эти вторые узлы блокчейна могут образовывать сеть консенсуса цепи регионального консорциума. Соответственно, при просмотре бизнес-запроса, отправленного первым узлом блокчейна во всей сети консенсуса, вторые узлы блокчейна в сети консенсуса цепи регионального консорциума могут запросить бизнес-информацию, соответствующую бизнес-запросу, из первого узла блокчейна, соответственно, и верифицировать легальность бизнес-информации. Каждый второй узел блокчейна может затем транслировать полученный результат верификации на другие вторые узлы блокчейна, так что узлы блокчейна устанавливают консенсус о результате верификации, и получить общий итоговый результат верификации. Дополнительно, второй узел блокчейна, в настоящее время служащий ведущим узлом, определяет, в соответствии с итоговым результатом верификации, следует ли подписать бизнес-запрос.
Подобным образом, после того, как третий узел блокчейна отправляет бизнес-информацию обратной связи на сеть консенсуса, второй узел блокчейна, служащий ведущим узлом в сети консенсуса цепи регионального консорциума, может принять бизнес-информацию обратной связи и предписывает вторым узлам блокчейна получать, из третьего узла блокчейна, бизнес-результаты, соответствующие бизнес-информации обратной связи. После получения бизнес-результатов, вторые узлы блокчейна могут верифицировать легальность бизнес-результатов соответственно, чтобы получить соответственные результаты верификации. Вторые узлы блокчейна могут затем транслировать соответственные результаты верификации друг на друга, так что вторые узлы блокчейна в сети консенсуса цепи регионального консорциума устанавливают консенсус о результатах верификации и получают итоговый результат верификации. Дополнительно, второй узел блокчейна, в текущее время служащий ведущим узлом, определяет, в соответствии с итоговым результатом верификации, следует ли подписать информацию о бизнес-результате.
В варианте осуществления настоящей заявки, после просматривания бизнес-запроса, отправленного первым узлом блокчейна, второй узел блокчейна может не верифицировать легальность бизнес-запроса в первую очередь. Вместо этого, второй узел блокчейна верифицирует легальность бизнес-информации, соответствующей бизнес-запросу, как и легальность бизнес-запроса в то же самое время после того, как третий узел блокчейна получил соответствующий бизнес-результат в соответствии с бизнес-запросом.
В варианте осуществления настоящей заявки, второй узел блокчейна может принимать бизнес-запрос, включающий в себя первый смарт-контракт и адрес расчетного счета пользователя, от первого узла блокчейна и может принимать бизнес-информацию обратной связи, включающую в себя второй смарт-контракт и адрес расчетного счета третьего узла блокчейна, от третьего узла блокчейна. Поэтому, когда второй узел блокчейна верифицирует бизнес-результат как легальный, первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя может передаваться на адрес расчетного счета третьего узла блокчейна с использованием первого смарт-контракта. Подобным образом, когда второй узел блокчейна верифицирует бизнес-результат как нелегальный, второе установленное количество назначенных ресурсов в адресе расчетного счета третьего узла блокчейна может передаваться на адрес расчетного счета пользователя с использованием второго смарт-контракта.
В процессе верифицирования легальности бизнес-запроса и бизнес-информации обратной связи, если бизнес-информация, соответствующая бизнес-запросу, и бизнес-результат, соответствующий бизнес-информации обратной связи, являются слишком сложными, второй узел блокчейна может попросить юриста или другой отдел аудита вмешаться, чтобы реализовать верификацию легальности, описанную выше. Вмешивающемуся юристу или другому отделу аудита необходимо подписать соответствующее положение об ответственности, и второй узел блокчейна записывает положение об ответственности в блокчейн сети консенсуса путем инициирования транзакции для использования, когда затем возникают разногласия о легальности.
В варианте осуществления настоящей заявки, первая назначенная операция, исполняемая первым узлом блокчейна с использованием первого смарт-контракта, может передавать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя в бизнес-запросе на адрес расчетного счета третьего узла блокчейна, и может дополнительно быть другой назначенной операцией. Например, первая назначенная операция может использоваться для разрешения первому узлу блокчейна автоматически получать бизнес-результат из третьего узла блокчейна или второго узла блокчейна. В качестве другого примера, первая назначенная операция может использоваться для разрешения первому узлу блокчейна определять ограничение времени передачи ресурсов передачи первого установленного количества назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна, и после того, как ограничение времени передачи ресурсов истекло, первый узел блокчейна может передать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна. Определенно, первая назначенная операция может также быть в других формах, которые не будут поясняться здесь примерами отдельно.
Подобным образом, вторая назначенная операция, описанная выше, не ограничена только разрешением третьему узлу блокчейна передавать второе установленное количество назначенных ресурсов в расчетном счете третьего узла блокчейна на адрес расчетного счета пользователя. Например, вторая назначенная операция может также использоваться для разрешения третьему узлу блокчейна изменять состояние первого смарт-контракта в бизнес-запросе (т.е., бизнес-запросе, принятом и обработанном третьим узлом блокчейна) на состояние ожидания принятия и отправлять бизнес-запрос на сеть консенсуса, так что другой узел блокчейна, способный обрабатывать бизнес-запрос, может принимать и обрабатывать бизнес-запрос. Определенно, вторая назначенная операция может также быть в других формах, которые не будут поясняться здесь примерами отдельно.
Следует дополнительно отметить, что процедура бизнес-обработки, описанная выше, выполняется в случае оценки активов. Например, первый узел блокчейна может быть терминалом, удерживаемым пользователем, бизнес-информация, принятая первым узлом блокчейна, может быть информацией оценки активов и информацией о действительном персональном сертификате пользователя, которые отправлены пользователем. Бизнес-запрос, сгенерированный первым узлом блокчейна в соответствии с информацией, отправленной пользователем, может быть запросом на оценку активов. Второй узел блокчейна может быть отделом аудита, который может выполнять аудит и наблюдение за оценкой активов. Третий узел блокчейна может быть организацией оценки активов, которая может обрабатывать оценку бизнес-активов для пользователя. Бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-информацией, полученной из первого узла блокчейна, может быть отчетом об оценке активов. Бизнес-информация обратной связи, отправленная на второй узел блокчейна, может быть информацией отчета об оценке активов.
Способ бизнес-обработки, описанный выше, может использоваться для оценки активов и может дополнительно использоваться для обработки других бизнесов. Например, в реальной жизни, бухгалтерская фирма обычно имеет дело с бизнесами применения для распорядительных лицензий на работу предприятия от имени некоторых предприятий или частных лиц. Обычно, частное лицо или предприятие может представить на рассмотрение свой действительный сертификат и данные предприятия бухгалтерской фирме. Бухгалтерская фирма получит связанные материалы в соответствии с этими данными и представит на рассмотрение материалы связанному отделу (например, промышленному и коммерческому бюро) для исследования и одобрения. Если определено, что материалы согласуются с действительными ситуациями частного лица или предприятия, связанный отдел может предоставить лицензию на работу предприятия частному лицу или предприятию. В этом процессе, частное лицо или предприятие оплачивает вознаграждение доверенной бухгалтерской фирме, так что бухгалтерская фирма заполняет связанную заявку для лицензии на работу предприятия от имени частного лица или предприятия.
Способ бизнес-обработки, обеспеченный в варианте осуществления настоящей заявки, также применим к сценарию, в котором бухгалтерская фирма применяет лицензию на работу предприятия от имени частного лица или предприятия. То есть, частное лицо или предприятие, в качестве клиента, может отправлять данные предприятия и их действительный сертификат на первый узел блокчейна. Первый узел блокчейна может генерировать соответствующий первый смарт-контракт и бизнес-запрос в соответствии с принятыми материалами и отправлять бизнес-запрос на сеть консенсуса. После просматривания бизнес-запроса, связанный отдел (например, промышленное и коммерческое бюро) в качестве второго узла блокчейна может получить, из первого узла блокчейна, связанные данные, соответствующие бизнес-запросу, и верифицировать легальность связанных данных. Как только данные верифицированы как легальные, может выполняться подписание бизнес-запроса, так что бухгалтерская фирма в качестве третьего узла блокчейна может принять подписанный бизнес-запрос, получить из первого узла блокчейна связанные данные, отправленные частным лицом или предприятием, и получить соответствующие связанные материалы в соответствии с полученными связанными данными.
Бухгалтерская фирма в качестве третьего узла блокчейна может генерировать соответствующий второй смарт-контракт и заявление о декларации в соответствии с полученными связанными материалами и отправлять заявление о декларации на сеть консенсуса. Таким образом, после просматривания заявления о декларации из сети консенсуса, второй узел блокчейна может получить связанные материалы из третьего узла блокчейна и верифицировать связанные материалы в соответствии со связанными данными, полученными из первого узла блокчейна.
При верифицировании связанных материалов как легальных, второй узел блокчейна может подписать заявление о декларации, отправленное третьим узлом блокчейна, так что третий узел блокчейна запускает, с использованием второго смарт-контракта, первый узел блокчейна для исполнения автоматической передачи определенной суммы денег в адресе расчетного счета частного лица или предприятия в качестве вознаграждения на адрес расчетного счета бухгалтерской фирмы в качестве третьего узла блокчейна с использованием первого смарт-контракта в бизнес-запросе. В то же самое время, связанный отдел в качестве второго узла блокчейна может предоставить лицензию на работу предприятия частному лицу или предприятию. При верифицировании связанных материалов как нелегальных, второй узел блокчейна не подписывает заявление о декларации. Таким образом, при наблюдении, с использованием второго смарт-контракта в ходатайстве о декларации, того, что второй узел блокчейна не подписывает ходатайство о декларации спустя установленную длительность, третий узел блокчейна автоматически запускает, с использованием второго смарт-контракта, передачу определенной суммы денег в адресе расчетного счета бухгалтерской фирмы в качестве компенсации на адрес расчетного счета частного лица или предприятия.
Сценарий, в котором бухгалтерская фирма применяет лицензию на работу предприятия для частного лица или предприятия, использован выше, чтобы дополнительно проиллюстрировать диапазон применения варианта осуществления настоящей заявки. К тому же, способ бизнес-обработки, обеспеченный в настоящей заявке, также применим к сценарию, аналогичному двум сценариям выше, и конкретные используемые сценарии не поясняются здесь на примерах отдельно.
Способ бизнес-обработки, обеспеченный в варианте осуществления настоящей заявки, описан в предшествующем описании, и на основе той же самой идеи, варианты осуществления настоящей заявки дополнительно обеспечивают три типа устройств бизнес-обработки, как показано на фиг. 3, фиг. 4 и фиг. 5.
Фиг. 3 является схематичной диаграммой устройства бизнес-обработки в соответствии с вариантом осуществления настоящей заявки, конкретно включающего в себя:
модуль 301 приема, выполненный с возможностью принимать бизнес-информацию, отправленную пользователем;
модуль 302 генерации, выполненный с возможностью генерировать соответствующий бизнес-запрос в соответствии с бизнес-информацией, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный в соответствии с бизнес-информацией; и
модуль 303 отправки, выполненный с возможностью отправлять бизнес-запрос на сеть консенсуса, так что третий узел блокчейна в сети консенсуса получает соответствующий бизнес-результат в соответствии с бизнес-запросом, и исполнять первую назначенную операцию путем запуска первого смарт-контракта после того, как определено, что второй узел блокчейна в сети консенсуса верифицирует бизнес-результат как легальный.
Модуль 302 генерации выполнен с возможностью компилировать бизнес-информацию с использованием предустановленного компилятора SOLC, чтобы получить первый смарт-контракт.
Модуль 302 генерации выполнен с возможностью генерировать, в соответствии с бизнес-информацией, бизнес-запрос, включающий в себя первый смарт-контракт и адрес расчетного счета пользователя, первая назначенная операция используется для передачи первого установленного количества назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна.
Модуль 303 отправки выполнен с возможностью отправлять бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания проверки, на сеть консенсуса.
Модуль 303 отправки выполнен с возможностью, когда определено, что второй узел блокчейна верифицирует бизнес-запрос как легальный, замораживать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя с использованием первого смарт-контракта.
Модуль 303 отправки выполнен с возможностью принимать сообщение запроса, отправленное третьим узлом блокчейна, для обработки бизнес-запроса; предоставлять разрешение на доступ третьему узлу блокчейна, когда определено, что бизнес-запрос обрабатывается третьим узлом блокчейна, так что третий узел блокчейна получает бизнес-информацию из устройства и получает бизнес-результат в соответствии с бизнес-информацией.
Модуль 303 отправки выполнен с возможностью отправлять бизнес-запрос на узлы блокчейна в сети консенсуса, чтобы установить консенсус.
Модуль 303 отправки выполнен с возможностью записывать бизнес-запрос в блокчейн устройства, когда определено, что консенсус о бизнес-запросе установлен узлами блокчейна в сети консенсуса.
Модуль 303 отправки выполнен с возможностью получать бизнес-результат из третьего узла блокчейна или второго узла блокчейна, когда определено, что второй узел блокчейна верифицирует бизнес-результат как легальный.
Следует отметить, что, в действительном применении, вариант осуществления устройства может иметь различные улучшения при необходимости или может выбирать конкретную структуру реализации функционального модуля, тем самым получая лучший технический эффект.
Например, модуль 303 отправки может включать в себя модуль 304 записи. После того, как модуль 303 отправки определяет, что консенсус о бизнес-запросе установлен узлами блокчейна в сети консенсуса, модуль 304 записи может записать бизнес-запрос в блокчейн устройства. В качестве другого примера, модуль 303 отправки может включать в себя модуль 305 получения. После того, как модуль 303 отправки определяет, что второй узел блокчейна верифицирует бизнес-результат как легальный, модуль 305 получения получает бизнес-результат из третьего узла блокчейна или второго узла блокчейна.
Фиг. 4 является схематичной диаграммой второго устройства бизнес-обработки в соответствии с вариантом осуществления настоящей заявки, конкретно включающего в себя:
модуль 401 получения информации, выполненный с возможностью получать, из сети консенсуса, бизнес-информацию обратной связи, отправленную третьим узлом блокчейна;
модуль 402 получения результата, выполненный с возможностью получать бизнес-результат из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, причем бизнес-результат генерируется третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна на сеть консенсуса; и
модуль 403 верификации, выполненный с возможностью, при верифицировании бизнес-результата как легального, обеспечивать возможность первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
Модуль 403 верификации выполнен с возможностью подписывать бизнес-информацию обратной связи; подписание используется для разрешения второму смарт-контракту, включенному в бизнес-информацию обратной связи, изменять свое собственное состояние из состояния ожидания верификации в состояние успешной верификации, и второй смарт-контракт получается третьим узлом блокчейна в соответствии с бизнес-запросом. Второй смарт-контракт в состоянии успешной верификации используется для разрешения второму смарт-контракту запускать первый узел блокчейна для исполнения первой назначенной операции с использованием первого смарт-контракта.
Модуль 403 верификации выполнен с возможностью, при верифицировании бизнес-результата как легального, предписывать узлам блокчейна в сети консенсуса устанавливать консенсус о бизнес-информации обратной связи, и когда определено, что консенсус о бизнес-информации обратной связи установлен, записывать бизнес-информацию обратной связи в блокчейн устройства.
Модуль 403 верификации выполнен с возможностью, при верифицировании бизнес-результата как нелегального, отказываться подписывать бизнес-информацию обратной связи. Отказ подписывать используется для разрешения третьему узлу блокчейна исполнять вторую назначенную операцию путем запуска второго смарт-контракта.
Модуль 401 получения информации выполнен с возможностью получать бизнес-запрос, отправленный первым узлом блокчейна на сеть консенсуса, причем бизнес-запрос включает в себя первый смарт-контракт в состоянии ожидания проверки; получать, из первого узла блокчейна в соответствии с бизнес-запросом, бизнес-информацию, соответствующую бизнес-запросу; верифицировать, является ли бизнес-информация легальной; и если да, подписывать бизнес-запрос, чтобы запустить первый смарт-контракт для изменения из состояния ожидания проверки в состояние ожидания принятия, первый смарт-контракт в состоянии ожидания принятия используется для разрешения первому узлу блокчейна замораживать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя с использованием первого смарт-контракта; или если нет, отказываться подписывать бизнес-запрос, так что первый узел блокчейна определяет, что бизнес-запрос не удалось принять.
Модуль 403 верификации выполнен с возможностью, при верифицировании бизнес-информации как легальной, уведомлять узлы блокчейна в сети консенсуса, чтобы установить консенсус о бизнес-запросе, и записывать бизнес-запрос в блокчейн устройства, когда определено, что консенсус о бизнес-запросе установлен.
Следует отметить, что, в действительном применении, вариант осуществления устройства может иметь различные улучшения при необходимости или может выбирать конкретную структуру реализации функционального модуля, тем самым получая лучший технический эффект.
Например, модуль 401 получения информации может включать в себя модуль 404 верификации запроса. После того, как модуль 401 получения информации получает бизнес-запрос из первого узла блокчейна, бизнес-информация, соответствующая бизнес-запросу, может быть получена из первого узла блокчейна. Модуль 401 получения информации может затем верифицировать, является ли бизнес-информация легальной, с использованием модуля 404 верификации запроса.
Фиг. 5 является схематичной диаграммой третьего устройства бизнес-обработки в соответствии с вариантом осуществления настоящей заявки, конкретно включающего в себя:
модуль 501 получения запроса, выполненный с возможностью получать бизнес-запрос, отправленный первым узлом блокчейна посредством сети консенсуса, причем бизнес-запрос включает в себя первый смарт-контракт, сгенерированный первым узлом блокчейна в соответствии с бизнес-информацией, отправленной пользователем;
модуль 502 генерации информации, выполненный с возможностью получать бизнес-результат и бизнес-информацию обратной связи в соответствии с бизнес-запросом; и
модуль 503 отправки информации, выполненный с возможностью отправлять бизнес-информацию обратной связи на сеть консенсуса, так что второй узел блокчейна в сети консенсуса получает бизнес-результат из устройства в соответствии с бизнес-информацией обратной связи, и когда бизнес-результат верифицирован как легальный, обеспечивать возможность первому узлу блокчейна исполнять первую назначенную операцию путем запуска первого смарт-контракта.
Модуль 501 получения запроса выполнен с возможностью получать бизнес-запрос, включающий в себя первый смарт-контракт в состоянии ожидания принятия.
Первая назначенная операция используется для разрешения первому узлу блокчейна передавать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя, включенного в бизнес-запрос, на адрес расчетного счета устройства.
Модуль 502 генерации информации выполнен с возможностью получать второй смарт-контракт и бизнес-результат в соответствии с бизнес-запросом.
Модуль 502 генерации информации выполнен с возможностью генерировать, в соответствии с бизнес-результатом, бизнес-информацию обратной связи, включающую в себя второй смарт-контракт, информационный реферат бизнес-результата и адрес расчетного счета устройства.
Модуль 502 генерации информации выполнен с возможностью определять бизнес-уровень и бизнес-тип бизнес-запроса; и определять второй смарт-контракт в соответствии с бизнес-уровнем, бизнес-типом и первым смарт-контрактом.
Модуль 502 генерации информации выполнен с возможностью отправлять, в соответствии с бизнес-запросом, сообщение запроса для обработки бизнес-запроса на первый узел блокчейна; получать разрешение на доступ от первого узла блокчейна, когда принимается сообщение обратной связи, которое возвращается первым узлом блокчейна и разрешает устройству обрабатывать бизнес-запрос; получать, из первого узла блокчейна, бизнес-информацию, соответствующую бизнес-запросу в соответствии с бизнес-запросом, и разрешение на доступ; и получать бизнес-результат и бизнес-информацию обратной связи в соответствии с бизнес-информацией.
Модуль 502 генерации информации выполнен с возможностью компилировать бизнес-информацию с использованием предустановленного компилятора SOLC, чтобы получить второй смарт-контракт.
Модуль 502 отправки информации выполнен с возможностью отправлять бизнес-информацию обратной связи на сеть консенсуса и замораживать второе установленное количество назначенных ресурсов в адресе расчетного счета устройства путем запуска второго смарт-контракта.
Модуль 502 генерации информации выполнен с возможностью отправлять бизнес-информацию обратной связи на узлы блокчейна в сети консенсуса, чтобы установить консенсус, и записывать бизнес-информацию обратной связи в блокчейн устройства, когда определено, что консенсус о бизнес-информации обратной связи установлен узлами блокчейна в сети консенсуса.
Модуль 502 отправки информации выполнен с возможностью исполнять вторую назначенную операцию путем запуска второго смарт-контракта, когда определено, что второй узел блокчейна верифицирует бизнес-информацию обратной связи как нелегальную.
Вторая назначенная операция используется для разрешения устройству передавать второе установленное количество назначенных ресурсов в адресе расчетного счета устройства на адрес расчетного счета пользователя, включенный в бизнес-запрос.
Следует отметить, что, в действительном применении, вариант осуществления устройства может иметь различные улучшения при необходимости или может выбирать конкретную структуру реализации функционального модуля, тем самым получая лучший технический эффект.
Например, модуль 502 отправки информации может включать в себя модуль 504 записи. После того, как модуль 502 отправки информации определяет, что консенсус о бизнес-информации обратной связи установлен узлами блокчейна в сети консенсуса, модуль 504 записи может записать бизнес-информацию обратной связи в блокчейн устройства.
В варианте осуществления настоящей заявки, первый узел блокчейна может отправлять бизнес-запрос, сгенерированный в соответствии с бизнес-информацией, отправленной пользователем на сеть консенсуса, так что когда второй узел блокчейна в сети консенсуса верифицирует бизнес-результат, полученный третьим узлом блокчейна в сети консенсуса в соответствии с бизнес-запросом, как легальный, первому узлу блокчейна разрешается исполнять первую назначенную операцию с использованием первого смарт-контракта в бизнес-запросе. Первый узел блокчейна использует смарт-контракт, который может исполняться автоматически, так что как только бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна, проходит верификацию, выполняемую вторым узлом блокчейна, первый узел блокчейна может исполнять первую назначенную операцию путем запуска первого смарт-контракта, и назначенная операция в процедуре бизнес-обработки может выполняться просто без ручного вмешательства. Кроме того, второй узел блокчейна может верифицировать бизнес-результат, полученный третьим узлом блокчейна, так что вся процедура бизнес-обработки обеспечивается системой беспристрастности, тем самым значительно улучшая беспристрастность бизнес-обработки и уменьшая вероятность того, что пользователь понесет потери во время бизнес-обработки.
В 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, оптическую память и тому подобное), включающих в себя используемый компьютером программный код.
Настоящая заявка может быть описана в общем контексте исполняемой компьютером инструкции, исполняемой компьютером, например, программным модулем. Обычно, программный модуль включает в себя стандартную программу, программу, объект, ассемблированную программу, структуру данных и тому подобное, используемые для исполнения конкретной задачи или реализации конкретного типа абстрактных данных. Настоящая заявка может также быть реализована в распределенных вычислительных средах и в распределенных компьютерных средах, задача исполняется с использованием удаленных устройств обработки, соединенных через сеть связи. В распределенной компьютерной среде, программный модуль может быть расположен в локальных и удаленных компьютерных носителях хранения, включающих в себя устройство хранения.
Варианты осуществления в спецификации описаны в развитии, идентичные или аналогичные части вариантов осуществления могут быть получены со ссылкой друг на друга, и каждый вариант осуществления акцентируется на части, отличающейся от других вариантов осуществления. Особенно, вариант осуществления системы в основном аналогичен варианту осуществления способа, так что в описании, для связанных частей, может быть просто сделана ссылка на описание частей в варианте осуществления способа.
Описание выше является только вариантами осуществления настоящей заявки и не предназначено для ограничения настоящей заявки. Для специалистов в данной области техники, настоящая заявка может иметь различные модификации и варианты. Любая модификация, эквивалентная замена, улучшение или тому подобное, произведенное без отклонения от сущности и принципов настоящей заявки, должно соответствовать объему формулы изобретения настоящей заявки.
Варианты осуществления и операции, описанные в этой спецификации, могут быть реализованы в цифровой электронной схеме, или в компьютерном программном обеспечении, прошивке или аппаратных средствах, включая структуры, раскрытые в этой спецификации, или в комбинациях одного или более из них. Операции могут быть реализованы как операции, выполняемые устройством обработки данных над данными, хранящимися на одном или более считываемых компьютером устройствах хранения или принятыми от других источников. Устройство обработки данных, компьютер или вычислительное устройство может объединять в себе устройство, приборы и машины для обработки данных, включая в качестве примера программируемый процессор, компьютер, систему на чипе или их множество, или комбинацию вышеизложенного. Устройство может включать в себя специализированную логическую схему, например, центральный процессор (CPU), программируемую вентильную матрицу (FPGA) или специализированную интегральную схему (ASIC). Устройство может также включать в себя код, который создает среду исполнения для рассматриваемой компьютерной программы, например, код, который составляет прошивку процессора, стек протоколов, систему управления базой данных, операционную систему (например, операционную систему или комбинацию операционных систем), межплатформенную рабочую среду, виртуальную машину или комбинацию одного или более из них. Устройство и среда исполнения могут реализовывать различные инфраструктуры модели вычислений, такие как веб-службы, распределенные вычисления и инфраструктуры вычислительных сетей.
Компьютерная программа (также известная, например, как программа, программное обеспечение, приложение программного обеспечения, модуль программного обеспечения, единица программного обеспечения, скрипт или код) может быть записана в любой форме языка программирования, включая компилированные или интерпретируемые языки, декларативные или процедурные языки, и она может быть развернута в любой форме, включая отдельную программу или модуль, компонент, подпрограмму, объект или другой блок, подходящий для использования в вычислительной среде. Программа может храниться в части файла, который содержит другие программы или данные (например, один или более скриптов, сохраненных в документе на языке разметки), в одном файле, специализированном для рассматриваемой программы, или во множестве координированных файлов (например, файлов, которые хранят один или более модулей, подпрограмм или частей кода). Компьютерная программа может исполняться на одном компьютере или на множестве компьютеров, которые расположены в одном месте или распределены по множеству мест и взаимосвязаны сетью связи.
Процессоры для исполнения компьютерной программы включают в себя, в качестве примера, как универсальные, так и специализированные микропроцессоры и любой один или более процессоров любого вида цифрового компьютера. Обычно, процессор будет принимать инструкции и данные от постоянной памяти или памяти с произвольной выборкой или их обеих. Существенными элементами компьютера являются процессор для выполнения действий в соответствии с инструкциями и одно или более устройств памяти для хранения инструкций и данных. Обычно, компьютер будет также включать в себя или будет операционно связан, чтобы принимать данные и/или передавать данные от/на одно или более устройств хранения большой емкости для хранения данных. Компьютер может быть встроен в другое устройство, например, мобильное устройство, персональный цифровой ассистент (PDA), игровую консоль, приемник глобальной системы позиционирования (GPS) или портативное устройство хранения. Устройства, подходящие для хранения компьютерных программных инструкций и данных, включают в себя энергонезависимую память, носители и устройства памяти, включая, в качестве примера, устройства полупроводниковой памяти, магнитные диски и магнитно-оптические диски. Процессор и память могут быть дополнены специализированной логической схемой или встроены в нее.
Мобильные устройства могут включать в себя телефонные гарнитуры, пользовательское оборудование (UE), мобильные телефоны (например, смартфоны), планшеты, носимые устройства (например, смарт-часы и смарт-очки), устройства, имплантируемые в человеческое тело (например, биодатчики, кохлеарные импланты) или другие типы мобильных устройств. Мобильные устройства могут осуществлять связь беспроводным образом (например, с использованием радиочастотных (RF) сигналов) с различными сетями связи (описаны ниже). Мобильные устройства могут включать в себя датчики для определения характеристик текущей среды мобильного устройства. Датчики могут включать в себя камеры, микрофоны, датчики близости, датчики GPS, датчики движения, акселерометры, датчики освещения окружающей среды, датчики влажности, гироскопы, компасы, барометры, датчики отпечатков пальцев, системы распознавания лиц, RF датчики (например, Wi-Fi и сотовые радио), датчики температуры или другие типы датчиков. Например, камеры могут включать в себя камеру переднего вида или заднего вида со съемными или фиксированными линзами, вспышку, датчик изображения и процессор изображения. Камера может быть мегапиксельной камерой, способной захватывать детали для распознавания по лицу и/или радужной оболочке глаза. Камера совместно с процессором данных и информацией аутентификации, хранящейся в памяти или доступной удалено, могут образовывать систему распознавания лиц. Система распознавания лиц или один или более датчиков, например, микрофонов, датчиков движения, акселерометров, датчиков GPS или RF датчиков, могут использоваться для аутентификации пользователя.
Чтобы обеспечить взаимодействие с пользователем, варианты осуществления могут быть реализованы на компьютере, имеющем устройство отображения и устройство ввода, например, жидко-кристаллический дисплей (LCD) или дисплей на органическом светоизлучающем диоде (OLED)/виртуальной реальности (VR)/дополненной реальности (AR) для отображения информации пользователю и тачскрин, клавиатуру и координатно-указательное устройство, при помощи которого пользователь может обеспечить ввод в компьютер. Другие виды устройств также могут использоваться, чтобы обеспечивать взаимодействие с пользователем; например, обратная связь, обеспечиваемая пользователю, может быть любой формой сенсорной обратной связи, например, визуальной обратной связью, прослушиваемой обратной связью или тактильной обратной связью; и ввод от пользователя может приниматься в любом виде, включая акустический, речевой или тактильный ввод. Кроме того, компьютер может взаимодействовать с пользователем путем отправки документов и приема документов на/от устройства, которое используется пользователем; например, путем отправки веб-страниц на веб-браузер на клиентском устройстве пользователя в ответ на запросы, принятые от веб-браузера.
Варианты осуществления могут быть реализованы с использованием вычислительных устройств, взаимосвязанных посредством любой формы или среды проводной или беспроводной цифровой связи данных (или их комбинации), например, сетью связи. Примерами взаимосвязанных устройств являются клиент и сервер, обычно удаленные друг от друга, которые обычно взаимодействуют через сеть связи. Клиент, например мобильное устройство, может выполнять транзакции самостоятельно, при помощи сервера или через сервер, например, выполняя транзакции покупки, продажи, оплаты, выдачи, отправки или займа или авторизуя их. Такие транзакции могут происходить в реальном времени, так что действие и отклик близки по времени; например, человек воспринимает действие и ответ, происходящие по существу одновременно, разница во времени для отклика, следующего за действием человека, меньше, чем 1 миллисекунда (мс) или меньше, чем 1 секунда (с), или отклик происходит без преднамеренной задержки, учитывая ограничения на обработку системы.
Примеры сетей связи включают в себя локальную сеть (LAN), сеть радиодоступа (RAN), городскую сеть (MAN) и сеть широкого охвата (WAN). Сеть связи может включать в себя весь или часть Интернета, другой сети связи или комбинации сетей связи. Информация может передаваться по сети связи в соответствии с различными протоколами и стандартами, включая Долговременное развитие (LTE), 5G, IEEE 802, Интернет-протокол (IP) или другие протоколы или комбинации протоколов. Сеть связи может передавать голосовые, видео, биометрические данные или данные аутентификации или другую информацию между соединенными вычислительными устройствами.
Признаки, описанные как отдельные реализации, могут быть реализованы, в комбинации, в одной реализации, в то время как признаки, описанные как одна реализация, могут быть реализованы во множестве реализаций, отдельно или в любой подходящей под-комбинации. Операции, описанные и заявленные в конкретном порядке, не должны пониматься ни как требующие этого конкретного порядка, ни как то, что все проиллюстрированные операции должны выполняться (некоторые операции могут быть необязательными). По необходимости, может выполняться многозадачность или параллельная обработка (или комбинация многозадачности и параллельной обработки).
| название | год | авторы | номер документа |
|---|---|---|---|
| УСЛУГА СМАРТ-КОНТРАКТА ВНЕ ЦЕПОЧКИ НА ОСНОВЕ ДОВЕРЕННОЙ СРЕДЫ ИСПОЛНЕНИЯ | 2018 |
|
RU2729700C1 |
| СПОСОБ УДАЛЕННОЙ ВЕРИФИКАЦИИ ДОКУМЕНТОВ | 2019 |
|
RU2707700C1 |
| СПОСОБ И ОБОРУДОВАНИЕ БИЗНЕС-ВЕРИФИКАЦИИ | 2018 |
|
RU2722392C1 |
| СПОСОБ И УСТРОЙСТВО ОБРАБОТКИ УСЛУГ | 2018 |
|
RU2725690C1 |
| ОТОБРАЖЕНИЕ ФИЗИЧЕСКИХ ОБЪЕКТОВ НА СТРУКТУРУ БЛОКЧЕЙНА | 2018 |
|
RU2786646C2 |
| СПОСОБ И УСТРОЙСТВО ОБРАБОТКИ ЗАПРОСОВ ТРАНЗАКЦИИ | 2018 |
|
RU2730439C1 |
| СПОСОБ И УСТРОЙСТВО ОБРАБОТКИ ТРАНЗАКЦИИ НА ОСНОВЕ БЛОКЧЕЙНА | 2018 |
|
RU2751447C2 |
| СПОСОБ И УСТРОЙСТВО ХРАНЕНИЯ ДАННЫХ И ЗАПРОСА НА ОСНОВЕ ЦЕПОЧКИ БЛОКОВ | 2018 |
|
RU2729960C1 |
| СПОСОБ ОБРАБОТКИ ДАННЫХ И УСТРОЙСТВО ОБРАБОТКИ ДАННЫХ | 2019 |
|
RU2782581C1 |
| БЕЛЫЕ СПИСКИ СМАРТ-КОНТРАКТОВ | 2018 |
|
RU2744827C2 |
Настоящее изобретение раскрывает способ и устройство бизнес-обработки. В способе первый узел блокчейна может отправлять на сеть консенсуса бизнес-запрос, сгенерированный в соответствии с бизнес-информацией, отправленной пользователем, так что когда второй узел блокчейна в сети консенсуса верифицирует бизнес-результат, полученный третьим узлом блокчейна в сети консенсуса в соответствии с бизнес-запросом, как легальный, первый узел блокчейна исполняет первую назначенную операцию путем запуска первого смарт-контракта в бизнес-запросе. Первый узел блокчейна использует смарт-контракт, который может исполняться автоматически, так что первый узел блокчейна может выполнять первую назначенную операцию автоматически с использованием первого смарт-контракта, как только бизнес-результат, полученный третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна, проходит верификацию, выполняемую вторым узлом блокчейна. Кроме того, второй узел блокчейна может верифицировать бизнес-результат, полученный третьим узлом блокчейна. Поэтому вся процедура бизнес-обработки обеспечена системой беспристрастности, таким образом, значительно улучшая беспристрастность бизнес-обработки. 2 н. и 16 з.п. ф-лы, 5 ил.
1. Компьютерно-реализуемый способ обработки бизнес-запросов на основе сети консенсуса блокчейнов, содержащий этапы, на которых:
принимают посредством первого узла блокчейна бизнес-информацию, отправленную пользователем;
генерируют посредством первого узла блокчейна соответствующий бизнес-запрос в соответствии с бизнес-информацией, причем бизнес-запрос содержит первый смарт-контракт, сгенерированный в соответствии с бизнес-информацией; и
отправляют посредством первого узла блокчейна бизнес-запрос в сеть консенсуса, причем при данной отправке бизнес-запроса отправляют в сеть консенсуса бизнес-запрос, содержащий первый смарт-контракт в состоянии ожидания проверки, с тем чтобы третий узел блокчейна в сети консенсуса получил соответствующий бизнес-результат в соответствии с бизнес-запросом, и автоматически выполняют посредством первого узла блокчейна первую назначенную операцию путем запуска первого смарт-контракта, когда определено, что второй узел блокчейна в сети консенсуса верифицирует бизнес-результат как легальный.
2. Способ по п.1, в котором этап генерации первого смарт-контракта в соответствии с бизнес-информацией содержит этап, на котором компилируют бизнес-информацию с использованием предустановленного компилятора Solidity Commandline (SOLC), чтобы получить первый смарт-контракт.
3. Способ по п.1, в котором
этап генерации соответствующего бизнес-запроса в соответствии с бизнес-информацией содержит этап, на котором генерируют бизнес-запрос, содержащий первый смарт-контракт и адрес расчетного счета пользователя в соответствии с бизнес-информацией; и
при этом первая назначенная операция используется для переноса первого установленного количества назначенных ресурсов в адресе расчетного счета пользователя на адрес расчетного счета третьего узла блокчейна.
4. Способ по п.3, при этом после этапа отправки бизнес-запроса в сеть консенсуса способ дополнительно содержит этап, на котором замораживают первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя с использованием первого смарт-контракта, когда определено, что второй узел блокчейна верифицирует бизнес-запрос как легальный.
5. Способ по п.1, при этом после этапа отправки бизнес-запроса в сеть консенсуса способ дополнительно содержит этапы, на которых:
принимают сообщение запроса, отправленное третьим узлом блокчейна, для обработки бизнес-запроса; и
предоставляют разрешение на доступ третьему узлу блокчейна, когда определено, что бизнес-запрос обрабатывается третьим узлом блокчейна, так что третий узел блокчейна получает бизнес-информацию из первого узла блокчейна и получает бизнес-результат в соответствии с бизнес-информацией.
6. Способ по п.1, в котором этап отправки бизнес-запроса в сеть консенсуса содержит этап, на котором отправляют бизнес-запрос на узлы блокчейна в сети консенсуса, чтобы установить консенсус, при этом способ дополнительно содержит этап, на котором записывают бизнес-запрос в блокчейн первого узла блокчейна после того, как определено, что узлы блокчейна в сети консенсуса устанавливают консенсус о бизнес-запросе.
7. Способ по п.1, дополнительно содержащий этап, на котором получают бизнес-результат из третьего узла блокчейна или второго узла блокчейна, когда определено, что второй узел блокчейна верифицирует бизнес-результат как легальный.
8. Способ по п.1, дополнительно содержащий этапы, на которых:
получают, посредством второго узла блокчейна из сети консенсуса, бизнес-информацию обратной связи, отправленную третьим узлом блокчейна;
получают бизнес-результат из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, причем бизнес-результат сгенерирован третьим узлом блокчейна в соответствии с бизнес-запросом, отправленным первым узлом блокчейна в сеть консенсуса; и
когда бизнес-результат верифицирован как легальный, разрешают первому узлу блокчейна выполнять первую назначенную операцию путем запуска первого смарт-контракта.
9. Способ по п.8, при этом
этап разрешения первому узлу блокчейна выполнять первую назначенную операцию путем запуска первого смарт-контракта содержит этап, на котором подписывают бизнес-информацию обратной связи;
данное подписание используется для разрешения второму смарт-контракту, включенному в бизнес-информацию обратной связи, изменять свое собственное состояние из состояния ожидания верификации в состояние успешной верификации, причем второй смарт-контракт получен третьим узлом блокчейна в соответствии с бизнес-запросом, и второй смарт-контракт в состоянии успешной верификации используется для разрешения второму смарт-контракту запускать выполнение первым узлом блокчейна первой назначенной операции с использованием первого смарт-контракта.
10. Способ по п.8, дополнительно содержащий этап, на котором предписывают узлам блокчейна в сети консенсуса установить консенсус о бизнес-информации обратной связи, когда бизнес-результат верифицирован как легальный, и записывают бизнес-информацию обратной связи в блокчейн второго узла блокчейна, когда определено, что консенсус о бизнес-информации обратной связи установлен.
11. Способ по п.10, дополнительно содержащий этап, на котором отказываются подписывать бизнес-информацию обратной связи, когда бизнес-результат верифицирован как нелегальный; при этом отказ подписать используется для разрешения третьему узлу блокчейна выполнять вторую назначенную операцию путем запуска второго смарт-контракта.
12. Способ по п.8, при этом до этапа получения, вторым узлом блокчейна из сети консенсуса, бизнес-информации обратной связи, отправленной третьим узлом блокчейна, способ дополнительно содержит этапы, на которых:
получают бизнес-запрос, отправленный первым узлом блокчейна в сеть консенсуса, причем бизнес-запрос содержит первый смарт-контракт в состоянии ожидания проверки;
получают, в соответствии с бизнес-запросом, бизнес-информацию, соответствующую бизнес-запросу, из первого узла блокчейна;
верифицируют, является ли бизнес-информация легальной; и
по определению того, что бизнес-информация является легальной, подписывают бизнес-запрос, чтобы запустить первый смарт-контракт для изменения из состояния ожидания проверки в состояние ожидания принятия; причем первый смарт-контракт в состоянии ожидания принятия используется для разрешения первому узлу блокчейна замораживать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя с использованием первого смарт-контракта; или
по определению того, что бизнес-информация не является легальной, отказываются подписывать бизнес-запрос, при этом первый узел блокчейна определяет, что принятие бизнес-запроса не удалось.
13. Способ по п.12, дополнительно содержащий этап, на котором предписывают узлам блокчейна в сети консенсуса установить консенсус о бизнес-запросе, когда бизнес-информация верифицирована как легальная, и записывают бизнес-запрос в блокчейн второго узла блокчейна после того, как определено, что консенсус о бизнес-запросе установлен.
14. Способ по п.8, дополнительно содержащий этапы, на которых:
получают посредством третьего узла блокчейна бизнес-запрос, отправленный первым узлом блокчейна с использованием сети консенсуса, причем бизнес-запрос содержит первый смарт-контракт, сгенерированный первым узлом блокчейна в соответствии с бизнес-информацией, отправленной пользователем;
получают бизнес-результат и бизнес-информацию обратной связи в соответствии с бизнес-запросом; и
отправляют бизнес-информацию обратной связи в сеть консенсуса, так что второй узел блокчейна в сети консенсуса получает бизнес-результат из третьего узла блокчейна в соответствии с бизнес-информацией обратной связи, и, когда бизнес-результат верифицирован как легальный, разрешают первому узлу блокчейна выполнять первую назначенную операцию путем запуска первого смарт-контракта.
15. Способ по п.14, в котором этап получения третьим узлом блокчейна бизнес-запроса, отправленного первым узлом блокчейна с использованием сети консенсуса, содержит этап, на котором получают бизнес-запрос, содержащий первый смарт-контракт в состоянии ожидания принятия.
16. Способ по п.14, в котором первая назначенная операция используется для разрешения первому узлу блокчейна передавать первое установленное количество назначенных ресурсов в адресе расчетного счета пользователя, включенного в бизнес-запрос, на адрес расчетного счета третьего узла блокчейна;
при этом этап получения бизнес-результата в соответствии с бизнес-запросом содержит этап, на котором получают второй смарт-контракт и бизнес-результат в соответствии с бизнес-запросом;
при этом этап получения бизнес-информации обратной связи в соответствии с бизнес-запросом содержит этап, на котором генерируют, в соответствии с бизнес-результатом, бизнес-информацию обратной связи, содержащую второй смарт-контракт, информацию реферата бизнес-результата и адрес расчетного счета третьего узла блокчейна.
17. Способ по п.16, в котором этап получения второго смарт-контракта в соответствии с бизнес-запросом содержит этапы, на которых:
определяют бизнес-уровень и бизнес-тип бизнес-запроса; и
определяют второй смарт-контракт в соответствии с бизнес-уровнем, бизнес-типом и первым смарт-контрактом.
18. Система для обработки бизнес-запросов на основе сети консенсуса блокчейнов, содержащая первый узел блокчейна, второй узел блокчейна и третий узел блокчейна, причем второй узел блокчейна и третий узел блокчейна – среди множества узлов блокчейна, которые содержатся в сети консенсуса,
при этом первый узел блокчейна выполнен с возможностью:
принимать бизнес-информацию, отправленную пользователем,
генерировать соответствующий бизнес-запрос в соответствии с бизнес-информацией, причем бизнес-запрос содержит первый смарт-контракт, сгенерированный в соответствии с бизнес-информацией, и
отправлять бизнес-запрос в сеть консенсуса, причем при данной отправке бизнес-запроса отправляется бизнес-запрос, содержащий первый смарт-контракт в состоянии ожидания проверки, в сеть консенсуса,
при этом третий узел блокчейна выполнен с возможностью получать соответствующий бизнес-результат в соответствии с бизнес-запросом,
при этом второй узел блокчейна выполнен с возможностью верифицировать бизнес-результат, и
при этом первый узел блокчейна дополнительно выполнен с возможностью автоматически выполнять посредством первого узла блокчейна первую назначенную операцию путем запуска первого смарт-контракта, когда определено, что бизнес-результат верифицирован вторым узлом блокчейна как легальный.
| Автомобиль-сани, движущиеся на полозьях посредством устанавливающихся по высоте колес с шинами | 1924 |
|
SU2017A1 |
| Автомобиль-сани, движущиеся на полозьях посредством устанавливающихся по высоте колес с шинами | 1924 |
|
SU2017A1 |
| СПОСОБ КОНТРОЛЯ ТОВАРООБОРОТА, ОСНОВАННЫЙ НА ИНТЕРНЕТ | 2010 |
|
RU2485590C1 |
| US 5832089 A, 03.11.1998. | |||
