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

Проект проводился НРД под руководством Александра Яковлева, программная реализация была разработана компанией Altoros, архитектор — Олег Абдрашитов.

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

Описание блокчейн-сети

Для проведения пилотной сделки мы развернули блокчейн-платформу на базе Hyperledger Fabric v.1.0. Проект Hyperledger под эгидой The Linux Foundation — это инициатива по созданию разных блокчейн-платформ и вспомогательных инструментов с открытым исходным кодом. В проекте участвует целая россыпь компаний со всего мира: технологические гиганты (IBM, Intel и так далее), консалтинговые компании (Accenture, Altoros и так далее), представители различных отраслей (Сбербанк, Московская биржа, CME, DTCC, Deutche Burse, Daimler, Airbus и так далее) и стартап-команды (Digital Asset Holding, Soramitsu и так далее). Проект запустили в декабре 2015 года, и сейчас активно развивается пять блокчейн-платформ и четыре инструмента для работы с блокчейн-платформами. Hyperledger открыт для всех, его участники равны между собой и придерживаются принципов «чистого» открытого кода.

Поскольку Hyperledger Fabric v.1.0 не так широко известен, как Bitcoin или Ethereum, то чтобы вам было легче понять топологию этой блокчейн-сети и происходящих в ней процессов, я вкратце расскажу об особенностях архитектуры Hyperledger Fabric v.1.0.

Особенности архитектуры Hyperledger Fabric v.1.0

Рассмотрим как выполняются транзакции на блокчейн-платформе Hyperledger Fabric v.1.0 (по материалам «The trend of exploring the use of DLT in Capital market», Japan Exchange Group, September 14, 2017)

В отличие от публичных платформ вроде Bitcoin или Ethereum, в Hyperledger Fabric v.1.0 есть две специальные роли:

• Endorser (валидатор) — узел, проверяющий и исполняющий транзакцию, а потом возвращающий её обратно клиенту с результатами и своей подписью.
• Orderer (упорядочиватель) — узел, устанавливающий последовательность транзакций и рассылающий их другим узлам DLT-сети.

Чтобы достичь консенсуса при проверке транзакций, используются политики валидации (endorsement policy) — это набор правил, определяющих, какой из узлов может быть валидатором, и сколько подписей валидаторов достаточно для того, чтобы транзакция считалась подтвержденной. При этом политика валидации задаётся отдельно для каждого смарт-контракта, создаваемого в блокчейн-сети. Например, в политике можно прописать, что транзакция будет валидной, если её подтвердят два из трёх заданных узлов.

Как создаётся и исполняется транзакция:

1. Клиент направляет транзакцию валидаторам (endorsers).
2. Валидаторы исполняют транзакцию и возвращают её клиенту вместе с результатами исполнения и своей подписью.
3. Клиент собирает необходимое количество подписей валидаторов и направляет транзакцию с набором ответов валидаторов на Orderer.
4. Orderer комбинирует транзакции в последовательность блоков и рассылает их.
5. Каждый из узлов проверяет, соответствует ли транзакция политике валидации, и «проигрывает» её в своём экземпляре реестра.

Топология блокчейн-сети пилотной сделки

В структуре блокчейн-сети было три участника:

• НРД — оператор сделки и администратор платформы.
• Мегафон — участник сделки.
• Райффайзенбанк — участник сделки.

Каждый участник развернул у себя собственный узел сети, а также дополнительные компоненты, предусмотренные архитектурой Hyperledger Fabric v.1.0:

• НРД развернул Orderer, обеспечивающий формирование упорядоченного потока транзакций, и
• установил клиентскую часть с UI, обеспечивающую функциональность оператора сделки.
• Мегафон и Райффайзен установили клиентские части с UI, обеспечивающие функциональность участника сделки.

В сети были созданы реестры, доступ к которым разграничивался внутренним механизмом каналов Hyperledger:

• Реестр ценных бумаг (доступен всем участникам сети). Здесь был создан единственный смарт-контракт SecurityMaster, в контексте которого вёлся перечень ценных бумаг.
• Сводный реестр балансов счетов всех участников (доступен только НРД). Здесь был создан единственный смарт-контракт Book, в контексте которого отражались остатки по счетам всех участников.
• Реестр балансов счетов Райффайзенбанка (доступен только НРД и Райффайзенбанку).
• Реестр балансов счетов Мегафона (доступен только НРД и Мегафону).
• Реестр сделок между Райффайзенбанком и Мегафоном (доступен только НРД, Райффайзенбанку и Мегафону). Здесь был создан единственный смарт-контракт Instruction, в контексте которого регистрировались и обрабатывались все сделки данной пары участников.

Также в реестрах балансов Райффайзенбанка и Мегафона было создано по одному смарт-контракту Position, в контексте которого отражались остатки по счетам участника.

Если бы сделка проводилась и легализовалась только через блокчейн, то всё происходило бы так:

1. В Реестре сделок оба участника создают транзакции инструкций покупки и продажи, которые сохраняются в контексте смарт-контракта Instruction.
2. При поступлении второй инструкции из пары «покупка-продажа» они сопоставляются друг с другом в смарт-контракте Instruction и получают статус «matched».
3. Когда клиент НРД получает уведомление о сопоставлении, то по Сводному реестру балансов проверяет балансы на счетах участников сделки.
4. Если проверка балансов прошла успешно, то клиент НРД:
   
   • Создаёт в смарт-контракте Instruction транзакции, которые меняют статус соответствующих инструкций на «execute».
   • А затем создаёт транзакции по изменению балансов счетов для смарт-контракта Position.

Подготовка и проведения сделки

Есть утверждённый порядок регулирования торговли ценными бумагами, при котором сделка считается юридически значимой, если она проведена через штатную систему учета ценных бумаг НРД «Аламеда». Чтобы соблюсти это условие, в процесс проведения сделки добавили специальные стадии формирования, подписания и обработки поручений действующего формата, с использованием «боевых» ЭЦП участников сделки. Кроме того, чтобы передача поручений через блокчейн считалась легитимной, НРД подписало с участниками сделки лицензионное соглашение и дополнительное соглашение к Договору по электронному документообороту.

В результате процесс заключения сделки стал выглядеть так:

1. Мегафон и Райффайзенбанк, каждый на своем узле, создают встречные инструкции на продажу и покупку соответственно, и передают их в смарт-контракт Instruction.
2. В смарт-контракте Instruction инструкции сопоставляются друг с другом.
3. Если сопоставление прошло успешно, то:
   
   • НРД на своём узле создаёт и «прикрепляет» к инструкции каждого из участников соответствующий файл поручения для последующей загрузки в «Аламеду».
   • В Реестры балансов участников сделки (смарт-контракт Position) отправляются соответствующие транзакции об изменении учета бумаг на счетах.
4. Участники сделки:
   
   • Извлекают из блокчейна файлы поручений для «Аламеды».
   • Подписывают их своими «боевыми» ЭЦП на соответствующих рабочих местах.
   • Помещают обратно в блокчейн.
5. НРД извлекает подписанные участниками файлы поручений и загружает в «Аламеду».
6. «Аламеда» обрабатывает сделку и создаёт файлы отчетности, которые затем отправляет участникам сделки.

Как всё было

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

Мы столкнулись с первыми трудностями еще до начала развертывания платформы: оказалось, что Райффайзенбанк и Мегафон не готовы дать прямой доступ к своим действующим ключам ЭЦП «чужому загадочному» ПО. Так что пришлось разработать специальную утилиту по выгрузке/загрузке файлов поручений, чтобы их можно было подписывать вне ПО платформы.

Дальнейшие затруднения были связаны с тем, что платформа разрабатывалась и отлаживалась в Amazon Web Services, а теперь ей предстояло вместо стерильно-гомогенной среды облака работать в суровом гетерогенном мире.

К счастью, реализация платформы предполагала использование Docker-контейнеров, поэтому различия, связанные с использованием участниками разных ОС (RHEL и Ubuntu) не повлияли на работу узлов сети.

Основные проблемы были связаны с внутренними особенностями Hyperledger Fabric и тем, что в обеих компаниях по-разному построена сетевая инфраструктура:

• Из-за особенностей смарт-контрактов Hyperledger Fabric пришлось полностью «выравнивать» узлы как по релизу (потому что хэш коммита использовался внутренними алгоритмам), так и по пользователю ОС, под которым запускались компонены платформы (он тоже участвовал в идентификации смарт-контракта).
• Узел Райффайзенбанка не видел самого себя по своему внешнему адресу, поэтому некоторые стадии скриптов установки и настройки приходилось пропускать по <Ctrl+C>.
• Возникали загадочные «залипания» сервиса, отвечавшего за выгрузку/загрузку файлов, от которых удавалось избавиться только перезапуском сервиса.

На развёртывание и настройку платформы ушло примерно три дня (27-29 сентября) и 20 часов в Webex. Как водится в IT-среде, не обошлось и без шаманских бубнов — «… теперь ждем ровно семь минут...»

Но в итоге первая сделка прошла без единого сбоя и зависания.

Ниже приведены исторические скриншоты — поручение Райффайзенбанка на покупку облигаций Мегафона и итоговый баланс по результатам сделки.