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

Рисунок 12. TO-BE модель процесса полуавтоматического сценария рассмотрения заявления на визу

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

Модель автоматического сценария рассмотрения заявки изображена на Рисунке 13.

Рисунок 13 TO-BE модель процесса автоматического сценария рассмотрения заявления на визу

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

В таком случае блокчейн-приложение сможет «начислить» на идентификационную карту клиента готовую визу, по аналогии с переводом средств на банковскую карту.

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

Рисунок 14. TO-BE модель процесса удаленного сценария выдачи документов

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

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

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

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

Модель процесса получения визы с разовым посещением консульства представлена на Рисунке 15.

Рисунок 15. TO-BE модель процесса ручной сценария выдачи документов

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

3.4 Концепция архитектуры блокчейн приложения для сферы визовых услуг

3.4.1 Обзор и сравнительный анализ существующих блокчейн-платформ

На сегодняшний день существует огромное множество блокчейн-платформ, с помощью которых можно построить публичный или приватный блокчейн. Рассмотрим некоторые из них подробнее[66].

Ethereum. Данная платформа уже упоминалась в текущем исследовании. Ethereum - это публичная блокчейн-платформа, обладающая собственной блокчейн сетью для выполнения смартконтрактов с помощью виртуальных машин Ethereum (EVM). Для топлива системы используется эфир - собственная криптовалюта Ethereum, в которой происходит оплата за выполнение транзакций. Ethereum является одной из наиболее известных платформ, партнерами которой являются Microsoft, J. P. Morgan Chase, Intel и другие крупные компании и стартапы.

Ripple. Ripple - еще одна блокчейн-платформа, специализирующаяся на подключении платежных провайдеров, цифровых бирж, банков и корпораций к сети RippleNet без каких-либо платежей. Платформа позволяет осуществлять платежи через криптовалюту XRP, являющуюся третьей по капитализации после биткойна и эфира. Ripple является более масштабируемым и быстрым, чем другие платформы за счет того, что использует вероятностное голосование для достижения консенсуса между узлами сети. В настоящее время платформа имеет более двухсот клиентов (в том числе таких крупных, как American Express, Santander и MoneyGram) и фокусируется на минимизации затрат ликвидности (xRapid), отправке платежей по нескольким сетям (xVia) и трансграничным платежам (xCurrent).

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

Hyperledger Sawtooth. Платформа была запущена Linux Foundation, ее используют в своих BaaS решениях такие компании, как IBM и Digital Asset. Hyperledger Sawtooth представляет собой корпоративную и модульную платформу, предназначенную для создания, развертывания и выполнения распределенных реестров, что позволяет вести цифровые записи без участия центрального органа. Платформа использует механизм консенсуса PoET (Proof of Elapsed Time), которые позволяет Hyperledger Sawtooth интегрироваться с аппаратными решениями, повышающими уровень безопасности системы, известными как “доверенные среды выполнения”. Примером такого приложения является процессор Xeon от Intel.

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

Hyperledger Iroha. Еще одна блокчейн платформа от Hyperledger, предназначенная для создания надежных, безопасных и быстрых децентрализованных приложений. Отличается простой, модульной распределенной система учета, основанной на безопасном и быстром консенсусном алгоритме Yet Another Consensus, защищающим сети Iroha от узлов-злоумышленников и сбоев. Будучи портативной и поддерживающей среды macOS и Linux, платформа высоко применима для автоматизации цепочек поставок и взаимодействия с интернет вещей (IoT).

R3 Corda. Платформа с открытым исходным кодом, построенная в 2015 году консорциумом ведущих мировых финансовых институтов. Позволяет учреждениям напрямую заключать смарт-контракты, устраняя дорогостоящие посредничества в бизнес-транзакциях. Corda не имеет криптовалюты или встроенного токена и не является публичным блокчейном - позволяет получать доступ к данным только авторизованным участникам, что повышает конфиденциальность и обеспечивает детализированный контроль доступа к данным. Первоначально разработанный финансовой отраслью для финансового сектора, Corda в настоящее время применяется в различных отраслях: здравоохранении, цепочках поставок, государственных органах. Более 60 компаний, включая Intel и Microsoft, используют R3 Corda в качестве блокчейн-платформы.

EOS. Блокчейн-платформа, основанная частной компанией Block.one и запущенная в июне 2018 года в качестве программного обеспечения с открытым исходным кодом, предназначена для создания децентрализованных приложений. Целью платформы является обеспечение возможности децентрализованного хостинга приложений, децентрализованного хранения корпоративных решений и выполнения смарт-контрактов, решение проблем масштабируемости Ethereum и Bitcoin. Консенсус в системе достигается за счет многопоточности, а также алгоритма Proof of Stake.

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

OpenChain. Разработанная компанией Coinprism, эта платформа подходит для организаций, желающих управлять цифровыми активами безопасным и масштабируемым способом. В отличие от механизма консенсуса, используемого в Биткойне (Proof of Work), использует разделенный консенсус (Partionned Consensus), где один блок проверяется только одним узлом. Поскольку в данной платформе отсутствуют майнеры, транзакции бесплатны.

NEO. Платформа была разработана для реализации масштабируемых децентрализованных блокчейн-приложений, базовым активом которых является NEO token, использующийся для оплаты транзакционных сборов за запуск приложений в сети. Использует в качестве алгоритма консенсуса Delegated Byzantine Fault Tolerance. Платформа была задумана для создания умной экономики, состоящей из трех компонентов:

· цифровых активов - пользователи могут регистрировать, продавать и передавать различные типы цифровых активов на платформе Neo,

· цифрового удостоверения личности - поддерживает набор совместимых стандартов цифровой идентификации X.509 для соответствия модели выдачи P2P сертификатов,

· смарт-контрактов - платформа предоставляет возможность разработки смарт-контрактов не Java, C# или других языках.

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

Протокол Stellar Consensus Protocol (SCP) позволяет достичь консенсуса независимо от закрытой системы регистрации финансовых транзакций. Обладая набором доказуемых свойств безопасности, SCP оптимизирует безопасность, останавливая прогресс сети в случае неправильного поведения узлов или разделов до тех пор, пока не будет достигнут консенсус.

В сравнении с алгоритмами PoW и PoS, SCP требует незначительных финансовые и вычислительные ресурсов, снижая барьер для входа новых участников.

При выборе платформы стоит рассматривать такие факторы, как:

· отрасль, для которой, в первую очередь, предназначается платформа,

· активность развития платформы,

· тип блокчейна,

· поддерживаемые языки разработки,

· наличие платы за транзакции,

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

· возможность построения смарт-контрактов.

Сравнение описанных платформ по ряду выделенных параметров приведено в Таблице 4.

Таблица 4. Сравнение существующих блокчейн платформ

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

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

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

· Ordering Service - представляет собой распределенный сервис, организованный на нескольких узлах сети и служащий как для формирования новых блоков распределенного реестра, так и для создания очередности исполнения транзакций; при этом добавлением новых блоков в реестр занимается Committing Peer;

· Committer Peer - содержит копию децентрализованного реестра и добавляет, проверяя новые транзакции на валидность, к нему новые блоки, сформированные Ordering Service.

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

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

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

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

В Hyperledger Fabric используется выделенный центр сертификации CA (Certification Authority), работающий на основе стандарта X.509, а также инфраструктуры публичных ключей - PKI. Членство участника сети к той или иной организации, каналу или группе пользователей осуществляется посредством специальной службы Membership Service. Канал (Channel) - это закрытая подсеть Hyperledger Fabric, которая может состоять из двух и более участников и предназначается для выполнения особо конфиденциальных транзакций внутри известного и ограниченного круга пользователей. Каждый канал может обладать отдельным распределённым реестром, смарт-контрактами, Ordering Service, WorldState.

Для подключения к каналу его участник должен иметь право доступа к нему, а также пройти авторизацию, которая реализуйется посредством Membership Service.

3.4.3 Возможная архитектура приложения для визовой отрасли на платформе Hyperledger Fabric

Общая верхнеуровневая схема возможной архитектуры приложения на Hyperledger Fabric изображена на Рисунке 18. Стрелками обозначены инициирующие воздействия:

1. Действия пользователя, выполненные в приложении, созданном с помощью HTML, CSS, JS, первично обрабатываются посредством взаимодейстия с поддерживаемым SDK (в данном случае это Node.js)

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

Рисунок 18. Верхнеуровневая схема возможной архитектуры приложения на Hyperledger Fabric

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

1. Инициация транзакции

2. Выполнение логики смарт-контракта

3. Возврат данных клиентскому приложению

4. Отправка данных на Ordering Service

5. Отправка сформированных блоков на Committer Peer

6. Добавления блока в реестр

Рассмотрим подробнее взаимодействие частей приложения на примере создания транзакции в рамках подачи клиентом консульства заявления на визу (Рисунок 19).

Рисунок 19. Схема взаимодействия частей приложения в рамках подачи пользователем заявления на визу

Приложение (Application), используемое пользователем, посредством Hyperledger Fabric SDK инициирует (1) запрос на транзакцию изменения распределенного реестра (Ledger), определяет политику одобрения (Endorsing policy) и получает в ответ набор узлов (Endorsing peers), на которые необходимо отправить данный запрос на транзакцию (2). Затем происходит вызов смарт-контракта (3) для записи новых данных в распределенный реестр. Для этого Hyperledger Fabric SDK вызывает определенную функцию, API которой передаются параметры транзакции, добавляет клиентскую подпись и отправляет данные по протоколу Protocol buffer over gRPC на Endorsing peers. Транзакция сможет быть записана в распределенный реестр, только когда все узлы, необходимые для одобрения транзакции, успешно и с одинаковым результатом выполнят данный смарт-контракт. При этом обращение к Endorsing peer и дальнейшее выполнение смарт-контракта происходит в рамках выделенного пользователю канала (Channel).

Затем Endorsing peers после проверки клиентской подписи и получения актуальных данных из WorldStateDB (4-5) запускают симуляцию (6) исполнения смарт-контракта с полученными по транзакции данными, в результате которой получают исходные и предполагаемые новые значения WorldState. После проведения симуляции логики смарт-контракта исходные и полученные данные возвращаются Hyperledger Fabric SDK (7).

Далее после проверки подписи Endorsing Peer и выполнения Endorsing policy измененные данные отправляются на Ordering Service (8), обслуживающий несколько каналов одновременно и обеспечивающий в рамках каждого консистентность данных на всех принадлежащих ему узлах. Данный элемент платформы не проверяет транзакции на валидность, а принимает их с учетом идентификатора канала, в рамках которого они поступили, выстраивает их в определенном порядке и формирует из них новые блоки распределенного реестра. Для обеспечения корректной очередности транзакций используется Kafka кластер. Таким образом, Ordering Service формирует новый блок распределенного реестра (9) и передает его Committer peers (10) канала.

Каждый Committer peer при получении нового блока, проверяет его на как на соответствие Endorsing Policy, так и на то, что все Endorsing peers получили одинаковый результат в результате симуляции смарт-контракта и с момента инициации транзакции не изменилось текущее состояние WorldStateDB. При выполнении всех условий транзакция валидируется (11).

Наконец, валидированные транзакции записываются в распределенный реестр (12-13) посредством добавления каждым Committer peer транзакции в его локальную, и обновляется текущее состояние WorldStateDB (14-15). После этого Hyperledger Fabric SDK отправляется нотификация (16) о применении транзакции и пользователь получает возможность увидеть текущий статус своего заявления на получение визы (17).

3.5 Возможные препятствия и способы их преодоления