Рис. 13. Отправка данных по операции на процедуру подготовки добавления блоков
Как ранее указывалось, в рассматриваемой системе роль формирующих узлов будут выполнять наиболее заинтересованные в прозрачности участники - производители и крупнейшие дистрибьютеры.
Отправка блоков на формирующие узлы. Сформированные на процедуре подготовки добавления блоков в реестр блоки транслируются всех узлам сети. При получении блока, все узлы проверяют его на валидность, происходит проверка того, что все подтверждающие узлы получили одинаковый результат при реализации смарт-контракта, а также проверка того, что исходные значения не изменились с момента проведения операции. (см. рис.14).
Добавление блока в реестр. На следующем этапе происходит добавление операции в локальную копию реестра. При условии валидности операции к текущему состоянию системы применяется Write Set, обновляя текущее значения объектов. Если же произошла проблема двойного расходования, а именно, произошло две операции с одними и тем же объектом в рамках одного блока, то операция признается не валидной, поскольку исходные состояния системы уже были изменены другой операцией. Если же операция валидна, то добавляется вместе со своим блоком в распределенный реестр и пользовательское приложение получает уведомление, что операция добавлена в реестр и является валидной. (см. рис. 15).
Рис. 14. Отправка сформированного блока с операциями на формирующие узлы
Рис. 15. Добавление блока с информацией по операции отгрузки со склада производителя в распределенный реестр
3.4 Принципы идентификации участников блокчейн-системы
В рассматриваемой блокчейн-системе присутствует множество участников с различными статусами и правовыми полномочиями по функционалу. Различные участники сети блокчейн делятся на узлы нескольких типов, заказчиков, клиентские приложения, администраторов и т.д. Каждый из этих участников - активный элементы внутри или вне сети, способный взаимодействовать с системой, - имеет цифровую идентификацию, инкапсулированную в цифровой сертификат. Эти идентичности действительно имеют значение, потому что они определяют точные описания полномочий на ресурсы и доступ к информации, которую субъекты имеют в сети блокчейн.
Чтобы личность участника могла быть проверена, она должна быть определена указанием от доверенного органа. Поставщик услуг членства (в случае рассматриваемой системы это государство) -- это участник, который определяет правила, управляющие действительными удостоверениями для каждого отдельного участника сети.
Так, для безопасного функционирования сеть и безопасного ведения деятельности в ней используется инфраструктура публичных ключей. Элементы инфраструктуры открытых ключей (PKI) представляют из себя центры сертификации, которые выдают цифровые сертификаты участникам системы (например, пользователям услуг, поставщикам услуг), которые затем используют их для аутентификации в операциях в ходе взаимодействия с медицинскими препаратами. Список отозванных сертификатов CA (CRL) представляет собой ссылку на сертификаты, которые больше не действительны. Отзыв сертификата может произойти по ряду причин. Например, сертификат может быть отозван, потому что был раскрыт криптографический закрытый материал, связанный с сертификатом.
Хотя блокчейн система -- это больше, чем сеть связей, она использует стандарт PKI для обеспечения безопасной связи между различными участниками сети и обеспечения надлежащей аутентификации операций, размещенных в блокчейн-системе. Поэтому важно понять основы PKI и понять, почему поставки услуг членства так важны.
В PKI есть четыре ключевых элемента:
Цифровые сертификаты
Публичные и частные ключи
Центры сертификации
Списки отзыва сертификатов
Цифровой сертификат -- это документ, который содержит набор атрибутов, относящихся к владельцу сертификата. Наиболее распространенным типом сертификата является тот, который соответствует стандарту X.509, который позволяет кодировать идентифицирующие детали стороны в его структуре. Проще говоря, сертификат содержит в себе всю необходимую для деятельности в рассматриваемой системе информацию в криптографическом виде.
Криптография позволяет участнику системы представить свой сертификат другим, чтобы подтвердить свою личность, если другая сторона доверяет издателю сертификата, известному как Центр сертификации (роль которого на себя будет брать государственная компания ИС МДЛП, либо специально отдельно созданная для этого структура). До тех пор, пока центр сертификации надежно хранит определенную криптографическую информацию (т.е. его собственный закрытый ключ подписи), любой, кто читает сертификат, может быть уверен, что информация об участнике не была подделана.
Атрибуты, записанные в сертификате участника рассматриваемой системы, будут в себя включать наименование организации, наименование отдела, проводящего операции по внесению данных в реестр, ФИО оператора и т.д.
Традиционные механизмы аутентификации полагаются на цифровые подписи, которые, как следует из названия, позволяют стороне подписывать свои сообщения цифровой подписью. Цифровые подписи также предоставляют гарантии целостности подписанного сообщения.
Технически говоря, механизмы цифровой подписи требуют, чтобы каждая сторона имела два криптографически-связанных ключа: открытый ключ, который является доступным для остальных участников системы и действует как признак аутентификации, и закрытый ключ, который используется для создания цифровых подписей в сообщениях. Получатели сообщений с цифровой подписью могут проверить происхождение и целостность полученного сообщения, проверив, что прикрепленная подпись действительна для открытого ключа ожидаемого отправителя.
Как уже указывалось ранее, участник или узел может участвовать в сети цепочки блоков с помощью цифрового удостоверения, выданного ему органом, которому доверяет система. В наиболее распространенном случае цифровые идентификаторы (или просто идентификаторы) имеют форму криптографически-подтвержденных цифровых сертификатов, которые соответствуют стандарту X.509 и выпускаются центром сертификации (CA).
Центр сертификации выдает сертификаты различным субъектам. Эти сертификаты подписаны ЦС в цифровой форме и связывают участника с его открытым ключом (и с полным списком параметров участника). В результате, если участники доверяют СА (и знают его открытый ключ), они могут доверять тому, что конкретный субъект связан с открытым ключом, включенным в сертификат, и владеет включенными атрибутами, проверяя подпись СА на сертификате субъекта.
В рассматриваемой системе центром сертификации должно стать государство, а именно государственная компания, возможно совместная организация с ИС МДЛП, как уже указывалось ранее.
Список отзыва сертификатов (CRL) прост для понимания -- это просто список ссылок на сертификаты, которые CA помечает как отозванные по той или иной причине.
Когда третья сторона хочет проверить идентификацию другой стороны, она сначала проверяет CRL выдающего ЦС, чтобы убедиться, что сертификат не был отозван. Верификатор не обязан проверять CRL, но, если он этого не делает, он рискует оставить скомпрометированного участника в системе.
3.5 Концепция смарт-контракта по регистрации лекарственного препарата в блокчейн системе
С точки зрения разработки самой системы, смарт-контракт вместе с распределенным реестром составляют основу рассматриваемой блокчейн системы. В то время как распределенный реестр содержит факты о текущем и историческом состоянии набора бизнес-объектов и операций с и между ними, смарт-контракт определяет исполняемую логику, которая генерирует новые операции, которые добавляются в распределенный реестр.
Прежде чем компании смогут заключать сделки друг с другом, они должны определить общий набор договоров, охватывающих общие термины, данные, правила, определения концепций и процессы. Взятые вместе, эти контракты определяют бизнес-модель, которая регулирует все взаимодействия между сторонами сделки.
С каждым смарт-контрактом связана политика одобрения. Эта политика одобрения определяет, какие организации должны одобрить транзакции, сгенерированные смарт-контрактом, прежде чем эти операции могут быть определены как действительные.
Пример процесса одобрения может определять, что три из четырех организаций, участвующих в сети цепочки блоков, должны подписать операцию, прежде чем она будет считаться действительной. Все операции, действительные или недействительные, добавляются в распределенный регистр, но только действительные операции обновляют состояние мира.
В рамках рассматриваемой системы операции должны быть проверены доверенными организациями в сети. Например, производитель, в канале поставок которого происходит реализация лекарственного средства, должен подписать операцию по отгрузке лекарственного препарата со склада участника цепочки, либо по привозу ЛП в определенную аптеку аптечной сети.
Когда происходит исполнение смарт-контракта, он выполняется на одноранговом узле, принадлежащем какой-то организации в блокчейн системе. Смарт-контракт принимает набор входных параметров по рассматриваемой операции и использует их в сочетании со своей программной логикой для чтения и записи в реестр. Изменения состояния мира фиксируются как ответ на предложение верификации операции, который содержит набор для чтения-записи с обоими состояниями, которые были прочитаны, и новыми состояниями, которые должны быть записаны, если операция действительна. Стоит заметить, что состояние системы не изменятся при моменте исполнения смарт-контракта.
В идеале блокчейн-система позволяет организации одновременно участвовать в нескольких отдельных сетях цепочки блоков через каналы. Объединяя несколько каналов, организация может участвовать в так называемой сетевой системе. Каналы обеспечивают эффективное совместное использование инфраструктуры, сохраняя конфиденциальность данных и коммуникаций. Они достаточно независимы, чтобы помочь организациям разделить свой рабочий трафик с разными контрагентами, но достаточно интегрированы, чтобы позволить им при необходимости координировать независимую деятельность.
Канал обеспечивает совершенно отдельный механизм связи между множеством организаций. Когда в канале создается цепной код, для него определяется определенная политика одобрения; все смарт-контракты в цепочке кодов становятся доступными для приложений на этом канале.
Администратор (государство, либо, если это канал какого-либо направления деятельности организации, то крупный производитель) определяет принципы подтверждения для цепного кода, когда он создается в канале, и может изменить его при обновлении. Принципы подтверждения применяется в равной степени ко всем смарт-контрактам, определенным в рамках одного и того же цепного кода, развернутого на определенном канале. Это также означает, что один смарт-контракт может быть развернут на разных каналах с разными политиками одобрения.
При этом каждый канал может содержать свои отдельные состояние системы и распределенный реестр с информацией по операциям в рамках задействованного в канале направления деятельности организации. Более того, у каждого канала могут быть свои уникальные смарт-контракты со своими критериями проведения и проверки.
3.6 Модель структуры блока с информацией по операциям, осуществляемым с лекарственным препаратом
Одной из важнейших сущностей блокчейн системы является распределенный реестр, хранящий в себе всю историю операций между организациями отрасли по лекарственным препаратам. Основной единицей структуры данного реестра является блок с информацией по данным операциям.
В данном разделе будет рассмотрена предлагаемая структура блока в рамках рассматриваемой системы. Итак, блок будет состоять из следующих частей (см. рис. 16):
Заголовок блока: Эта часть состоит из трех полей, формирующихся при создании блока:
Порядковый номер блока: целое число, начинающееся с 0 (блок генеза), и увеличивается на 1 для каждого нового блока, добавляемого в цепочку блоков.
Хэш текущего блока: хэш всех операций по лекарственным препаратам, содержащихся в текущем блоке.
Хэш предыдущего блока: копия хэша из предыдущего блока в блокчейне.
Эти поля получаются путем криптографического хеширования данных блока. Они гарантируют, что каждый блок является неразрывно связанным со своим соседним блоком, что ведет к неизменности реестра. На рисунке 16 эта часть обозначена - H2.
Данные блока. Эта часть содержит список операций, упорядоченных по порядку. Как правило этот порядок определяется с помощью функционала добавления блока и в рассматриваемой системе она будут упорядочены по временному признаку. Это означает, что в начале в блоке будут записываться операции, которые произошли раньше остальных. На рисунке 16 эта часть обозначена - D2.