В конце сентября 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 (по материалам «The trend of exploring the use of DLT in Capital market», Japan Exchange Group, September 14, 2017)
В отличие от публичных платформ вроде Bitcoin или Ethereum, в Hyperledger Fabric v.1.0 есть две специальные роли:
Чтобы достичь консенсуса при проверке транзакций, используются политики валидации (endorsement policy) — это набор правил, определяющих, какой из узлов может быть валидатором, и сколько подписей валидаторов достаточно для того, чтобы транзакция считалась подтвержденной. При этом политика валидации задаётся отдельно для каждого смарт-контракта, создаваемого в блокчейн-сети. Например, в политике можно прописать, что транзакция будет валидной, если её подтвердят два из трёх заданных узлов.
Как создаётся и исполняется транзакция:
В структуре блокчейн-сети было три участника:
Каждый участник развернул у себя собственный узел сети, а также дополнительные компоненты, предусмотренные архитектурой Hyperledger Fabric v.1.0:
В сети были созданы реестры, доступ к которым разграничивался внутренним механизмом каналов Hyperledger:
Также в реестрах балансов Райффайзенбанка и Мегафона было создано по одному смарт-контракту Position, в контексте которого отражались остатки по счетам участника.
Если бы сделка проводилась и легализовалась только через блокчейн, то всё происходило бы так:
Есть утверждённый порядок регулирования торговли ценными бумагами, при котором сделка считается юридически значимой, если она проведена через штатную систему учета ценных бумаг НРД «Аламеда». Чтобы соблюсти это условие, в процесс проведения сделки добавили специальные стадии формирования, подписания и обработки поручений действующего формата, с использованием «боевых» ЭЦП участников сделки. Кроме того, чтобы передача поручений через блокчейн считалась легитимной, НРД подписало с участниками сделки лицензионное соглашение и дополнительное соглашение к Договору по электронному документообороту.
В результате процесс заключения сделки стал выглядеть так:
Всех участников проекта в первую очередь интересовала проработка юридических вопросов, связанных с проведением сделок через блокчейн, и выявление технических и организационных трудностей, которые могут возникнуть при развертывании блокчейн-сети в реальных условиях. Тем более, что организации разные, каждая со своей инфраструктурной и сетевой политикой, правилами взаимодействия внешних и внутренних сетей, и так далее и тому подобное.
Мы столкнулись с первыми трудностями еще до начала развертывания платформы: оказалось, что Райффайзенбанк и Мегафон не готовы дать прямой доступ к своим действующим ключам ЭЦП «чужому загадочному» ПО. Так что пришлось разработать специальную утилиту по выгрузке/загрузке файлов поручений, чтобы их можно было подписывать вне ПО платформы.
Дальнейшие затруднения были связаны с тем, что платформа разрабатывалась и отлаживалась в Amazon Web Services, а теперь ей предстояло вместо стерильно-гомогенной среды облака работать в суровом гетерогенном мире.
К счастью, реализация платформы предполагала использование Docker-контейнеров, поэтому различия, связанные с использованием участниками разных ОС (RHEL и Ubuntu) не повлияли на работу узлов сети.
Основные проблемы были связаны с внутренними особенностями Hyperledger Fabric и тем, что в обеих компаниях по-разному построена сетевая инфраструктура:
На развёртывание и настройку платформы ушло примерно три дня (27-29 сентября) и 20 часов в Webex. Как водится в IT-среде, не обошлось и без шаманских бубнов — «… теперь ждем ровно семь минут...»
Но в итоге первая сделка прошла без единого сбоя и зависания.
Ниже приведены исторические скриншоты — поручение Райффайзенбанка на покупку облигаций Мегафона и итоговый баланс по результатам сделки.
Проект проводился НРД под руководством Александра Яковлева, программная реализация была разработана компанией 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) — это набор правил, определяющих, какой из узлов может быть валидатором, и сколько подписей валидаторов достаточно для того, чтобы транзакция считалась подтвержденной. При этом политика валидации задаётся отдельно для каждого смарт-контракта, создаваемого в блокчейн-сети. Например, в политике можно прописать, что транзакция будет валидной, если её подтвердят два из трёх заданных узлов.
Как создаётся и исполняется транзакция:
- Клиент направляет транзакцию валидаторам (endorsers).
- Валидаторы исполняют транзакцию и возвращают её клиенту вместе с результатами исполнения и своей подписью.
- Клиент собирает необходимое количество подписей валидаторов и направляет транзакцию с набором ответов валидаторов на Orderer.
- Orderer комбинирует транзакции в последовательность блоков и рассылает их.
- Каждый из узлов проверяет, соответствует ли транзакция политике валидации, и «проигрывает» её в своём экземпляре реестра.
Топология блокчейн-сети пилотной сделки
В структуре блокчейн-сети было три участника:
- НРД — оператор сделки и администратор платформы.
- Мегафон — участник сделки.
- Райффайзенбанк — участник сделки.
Каждый участник развернул у себя собственный узел сети, а также дополнительные компоненты, предусмотренные архитектурой Hyperledger Fabric v.1.0:
- НРД развернул Orderer, обеспечивающий формирование упорядоченного потока транзакций, и
- установил клиентскую часть с UI, обеспечивающую функциональность оператора сделки.
- Мегафон и Райффайзен установили клиентские части с UI, обеспечивающие функциональность участника сделки.
В сети были созданы реестры, доступ к которым разграничивался внутренним механизмом каналов Hyperledger:
- Реестр ценных бумаг (доступен всем участникам сети). Здесь был создан единственный смарт-контракт SecurityMaster, в контексте которого вёлся перечень ценных бумаг.
- Сводный реестр балансов счетов всех участников (доступен только НРД). Здесь был создан единственный смарт-контракт Book, в контексте которого отражались остатки по счетам всех участников.
- Реестр балансов счетов Райффайзенбанка (доступен только НРД и Райффайзенбанку).
- Реестр балансов счетов Мегафона (доступен только НРД и Мегафону).
- Реестр сделок между Райффайзенбанком и Мегафоном (доступен только НРД, Райффайзенбанку и Мегафону). Здесь был создан единственный смарт-контракт Instruction, в контексте которого регистрировались и обрабатывались все сделки данной пары участников.
Также в реестрах балансов Райффайзенбанка и Мегафона было создано по одному смарт-контракту Position, в контексте которого отражались остатки по счетам участника.
Если бы сделка проводилась и легализовалась только через блокчейн, то всё происходило бы так:
- В Реестре сделок оба участника создают транзакции инструкций покупки и продажи, которые сохраняются в контексте смарт-контракта Instruction.
- При поступлении второй инструкции из пары «покупка-продажа» они сопоставляются друг с другом в смарт-контракте Instruction и получают статус «matched».
- Когда клиент НРД получает уведомление о сопоставлении, то по Сводному реестру балансов проверяет балансы на счетах участников сделки.
- Если проверка балансов прошла успешно, то клиент НРД:
- Создаёт в смарт-контракте Instruction транзакции, которые меняют статус соответствующих инструкций на «execute».
- А затем создаёт транзакции по изменению балансов счетов для смарт-контракта Position.
Подготовка и проведения сделки
Есть утверждённый порядок регулирования торговли ценными бумагами, при котором сделка считается юридически значимой, если она проведена через штатную систему учета ценных бумаг НРД «Аламеда». Чтобы соблюсти это условие, в процесс проведения сделки добавили специальные стадии формирования, подписания и обработки поручений действующего формата, с использованием «боевых» ЭЦП участников сделки. Кроме того, чтобы передача поручений через блокчейн считалась легитимной, НРД подписало с участниками сделки лицензионное соглашение и дополнительное соглашение к Договору по электронному документообороту.
В результате процесс заключения сделки стал выглядеть так:
- Мегафон и Райффайзенбанк, каждый на своем узле, создают встречные инструкции на продажу и покупку соответственно, и передают их в смарт-контракт Instruction.
- В смарт-контракте Instruction инструкции сопоставляются друг с другом.
- Если сопоставление прошло успешно, то:
- НРД на своём узле создаёт и «прикрепляет» к инструкции каждого из участников соответствующий файл поручения для последующей загрузки в «Аламеду».
- В Реестры балансов участников сделки (смарт-контракт Position) отправляются соответствующие транзакции об изменении учета бумаг на счетах.
- Участники сделки:
- Извлекают из блокчейна файлы поручений для «Аламеды».
- Подписывают их своими «боевыми» ЭЦП на соответствующих рабочих местах.
- Помещают обратно в блокчейн.
- НРД извлекает подписанные участниками файлы поручений и загружает в «Аламеду».
- «Аламеда» обрабатывает сделку и создаёт файлы отчетности, которые затем отправляет участникам сделки.
Как всё было
Всех участников проекта в первую очередь интересовала проработка юридических вопросов, связанных с проведением сделок через блокчейн, и выявление технических и организационных трудностей, которые могут возникнуть при развертывании блокчейн-сети в реальных условиях. Тем более, что организации разные, каждая со своей инфраструктурной и сетевой политикой, правилами взаимодействия внешних и внутренних сетей, и так далее и тому подобное.
Мы столкнулись с первыми трудностями еще до начала развертывания платформы: оказалось, что Райффайзенбанк и Мегафон не готовы дать прямой доступ к своим действующим ключам ЭЦП «чужому загадочному» ПО. Так что пришлось разработать специальную утилиту по выгрузке/загрузке файлов поручений, чтобы их можно было подписывать вне ПО платформы.
Дальнейшие затруднения были связаны с тем, что платформа разрабатывалась и отлаживалась в Amazon Web Services, а теперь ей предстояло вместо стерильно-гомогенной среды облака работать в суровом гетерогенном мире.
К счастью, реализация платформы предполагала использование Docker-контейнеров, поэтому различия, связанные с использованием участниками разных ОС (RHEL и Ubuntu) не повлияли на работу узлов сети.
Основные проблемы были связаны с внутренними особенностями Hyperledger Fabric и тем, что в обеих компаниях по-разному построена сетевая инфраструктура:
- Из-за особенностей смарт-контрактов Hyperledger Fabric пришлось полностью «выравнивать» узлы как по релизу (потому что хэш коммита использовался внутренними алгоритмам), так и по пользователю ОС, под которым запускались компонены платформы (он тоже участвовал в идентификации смарт-контракта).
- Узел Райффайзенбанка не видел самого себя по своему внешнему адресу, поэтому некоторые стадии скриптов установки и настройки приходилось пропускать по <Ctrl+C>.
- Возникали загадочные «залипания» сервиса, отвечавшего за выгрузку/загрузку файлов, от которых удавалось избавиться только перезапуском сервиса.
На развёртывание и настройку платформы ушло примерно три дня (27-29 сентября) и 20 часов в Webex. Как водится в IT-среде, не обошлось и без шаманских бубнов — «… теперь ждем ровно семь минут...»
Но в итоге первая сделка прошла без единого сбоя и зависания.
Ниже приведены исторические скриншоты — поручение Райффайзенбанка на покупку облигаций Мегафона и итоговый баланс по результатам сделки.
