- PVSM.RU - https://www.pvsm.ru -
22 июня 2017 года на Blockchain & Bitcoin Conference в Санкт-Петербурге [28] наш аналитик направления блокчейн, Марина Сманцер, сделала доклад о результатах исследовательского проекта по созданию комплексной платформы для сделок торгового финансирования на основе смарт-контрактов.
20-минутный формат доклада не позволял подробно осветить технические аспекты. Поэтому выход Райффайзенбанка на habrahabr – прекрасная возможность рассказать о наших результатах во всех подробностях.
Отмечу, что статья рассчитана на понимание читателем основных аспектов технологии блокчейн и принципов работы смарт-контрактов. Так как обзор по каждой теме – это объем для отдельной статьи, мы рассчитываем на понимание хабрасообщества.
Первая часть расскажет о кейсе с аккредитивами, который мы использовали, и про то, как происходило проектирование платформы на блокчейн.
Вторая часть наиболее насыщена техническими деталями: будет подробно рассмотрена реализация платформы (выбор и интеграция ее компонентов) и смарт-контрактов для аккредитива. В ней же будет пошагово описан процесс проведения расчетов по аккредитиву через смарт-контракты.
В третьей части много кода: отдельные методы смарт-контрактов, спецификация собственного провайдера внешних запросов (оракула) и бонус для сообщества: открытый API для его тестирования. Подводя итоги этого раздела, расскажем о проблемах с компонентами платформы, которые нам приходилось преодолевать.
В финале остановимся на результатах проекта с аккредитивом, и на том, что показало исследование развития децентрализованных технологий относительно их применения в банковской деятельности.
Мы приняли решение максимально подробно осветить наш опыт с блокчейном. Блокчейн – это история про взаимодействие и сотрудничество. Множество проектов появилось и развивается благодаря усилиям энтузиастов. Все технологии новые, и при их использовании возникает достаточно трудностей. Мы будем рады, если наша история станет полезным источником знаний.
В подготовке статьи активно участвовала gelbplaneten [29]
В конце 2016 года блокчейн попал в зону интересов нашего отдела R&D. Некоторое время заняло погружение в теорию, после которого мы решили, что имеет смысл сделать практическую реализацию.
У нас в рассмотрении было несколько сфер банковского бизнеса в качестве потенциальных вариантов: от оптимизации внутренних бизнес-процессов до управления залогами по сделкам. В области торгового финансирования мы обнаружили немедленный интерес со стороны корпоративного бизнеса и клиентов, поэтому было решено проработать детально именно его.
Конкретно мы решили остановиться на аккредитиве. В своем наиболее простом виде он реализует довольно простую для понимания логику, при этом охватывает множество аспектов сделок из выбранной области.
В этом описании многие моменты упрощены.
Цель проекта – исследовать, насколько блокчейн технологически готов к реальным бизнес-кейсам из области торгового финансирования. Это касается и зрелости технологии в чистом виде, и возможности переложить на блокчейн процесс из корпоративного бизнеса с сохранением его уровня сложности. Второе включает как юридическую составляющую для проведения сделок, так и требования к надежности и безопасности системы.
Мы ориентировались на открытые решения, в частности, в качестве блокчейна был выбран публичный Ethereum. О других технологиях будет подробно рассказано далее в статье.
В результате нами была разработана программная платформа, объединяющая в комплексное решение блокчейн, децентрализованные хранилища, источники внешних данных и уровень API к внутренним системам банка. Подробный анализ самых разных областей применения блокчейна в банке, который мы проводили перед запуском проекта, помог спроектировать модульную и легко адаптируемую систему. И хотя разработку мы вели, ориентируясь на вполне конкретный бизнес-кейс (аккредитив), модульность платформы позволяет применять ее для других бизнес-решений, использующих стандартизированные условия сделок (акции, облигации, регистрация залогов, биржевые производные финансовые инструменты).
Как уже было сказано, перед исследованием была поставлена задача определить возможность реализации сделок торгового финансирования в существующей блокчейн-экосистеме. Под экосистемой мы понимаем набор технологий, включающий в качестве базы как реализации самого блокчейна, так и всевозможные надстройки к ним: протоколы взаимодействия и файлового обмена, библиотеки, распределенные хранилища и пр.
При этом предполагалось использование решений, вышедших в стабильной версии или находящихся на близкой к реализации стадии готовности. В процессе исследования предполагалось определить условия успешной интеграции выбранных технологий в единой платформе совместно с учетными системами банка, а также выявить явные и скрытые проблемы такой интеграции.
Для определения необходимого для реализации платформы функционала были заданы следующие исходные условия:
Из анализа исходных условий вытекает необходимость использования следующих функциональных компонентов:
Учитывая, что основные расчеты и анализ документов в реалиях сегодняшнего дня выполняются вне смарт-контрактов, непосредственно в смарт-контракты передаются только данные, которые те в состоянии обработать. Остальная информация (обосновывающие и распорядительные документы) прикрепляется в виде обычных (для ручной обработки) или формализованных (для автоматической обработки) документов, подписанных усиленной квалифицированной ЭЦП для обеспечения юридической значимости.
При этом на внутреннюю логику смарт-контракта могут быть возложены следующие задачи:
С каждым из пользователей платформы связывалась следующая регистрационная информация:
Наиболее простое объяснение концепции оракулов: blockchainhub.net/blockchain-oracles [30]
По DFS не нашлось хорошей статьи, оставлю ссылку на документацию Swarm: swarm-guide.readthedocs.io/en/latest/introduction.html [31]
И Storj: storj.io [32]
На рисунке ниже представлена общая схема платформы и основных потоков обмена данными между ее функциональными компонентами (при этом зеленым выделены «чужие» компоненты, фиолетовым — сертифицированные, белым — ПО Банка):
В процессе подготовки и исполнения сделки компоненты платформы взаимодействуют следующим образом:
Проектирование платформы было решено начать параллельно с проработкой бизнес-кейса для реализации.
Упрощенно схема процесса на блокчейне представлена на рисунке, а подробное описание процесса приведено ниже
Участники сделки — Покупатель, Продавец и Банк. Покупатель и Продавец заключают контракт на предоставление некоторых услуг или товаров, причем факт их предоставления может быть идентифицирован автоматически. Например, если аккредитив открывается для расчетов при передаче права собственности на недвижимое имущество, долей, акций и т.п., дополнительно будет произведена проверка информации в представленных документах против информации во внешних источниках (например, в едином государственном реестре недвижимости). Дальнейшая операционная поддержка сделки осуществляется через Платформу.
При выборе функциональных компонентов платформы мы ориентировались на открытые решения (Ethereum, Swarm, Storj). Это связано со следующими их преимуществами:
Таким образом, выбор был сделан в пользу следующих реализаций:
Для развертывания необходимых компонентов:
было выделено 2 сервера.
На первом сервере было развернут узел Ethereum базового блокчейна смарт-контрактов. Изначально в качестве базового блокчейна использовалась тестовая сеть Ropsten, но на заключительных этапах мы перешли на более стабильный Rinkeby. Причиной этому стал инцидент в марте с DDOS атакой на Ropsten [33], в ходе которого несколько дней были проблемы с добавлением транзакций.
На втором сервере была развернута инфраструктура, обеспечивавшая работу с файлами:
Кроме того, из соображений удобства взаимодействия там же было развернуто интеграционное ядро платформы.
Провайдер внешних запросов был развернут на каждом из серверов и мог, по необходимости, запускаться на любом из них.
UI-приложение могло запускаться как на любом из серверов, так и использовать специальный прокси-протокол для работы через Интернет.
Интеграция с блокчейном Ethereum осуществлялась с использованием RPC API JSON-RPC [34], Management-APIs [35].
Никаких технических проблем с его использованием не возникало.
В качестве внешнего арбитражного ресурса использовался ropsten.etherscan.io [36] или rinkeby.etherscan.io [37], в зависимости от используемой тестовой сети.
Интеграция со Swarm осуществлялась с использованием HTTP API: Swarm-guide [38], gist.github.com [39].
Для загрузки файла в SWARM использовался HTTP-запрос PUT /bzz: $PATH$ ($PATH$ — путь к загружаемому файлу)
в ответ на который приходил 16-ричный идентификатор манифеста файла, который использовался для его извлечения из SWARM.
Для извлечения файла из SWARM использовался HTTP-запрос GET /bzzi:/$MANIFEST$/ ($MANIFEST$ — 16-ричный идентификатор манифеста извлекаемого файла).
Каких-либо проблем с загрузкой/выгрузкой файлов не возникало.
К сожалению, для Swarm не было найдено внешнего средства мониторинга (типа Etherscan для Ethereum), что определенным образом затрудняло оценку успешности манипуляций с файлами.
Интеграция со Storj с использованием предлагаемого разработчиком API оказалась крайне сложной и неудобной. Вследствие этого для работы с файлами была использована консоль узла Storj.
Для загрузки файла использовалась команда storj upload-file $BUCKET$ $PATH$ (где $BUCKET$ — идентификатор «корзины», а $PATH$ — путь к загружаемому файлу).
При успешной загрузке в ответ отдавался идентификатор загруженного файла.
Для выгрузки файла использовалась команда storj download-file $BUCKET$ $FILE$ $PATH$ (где $BUCKET$ — идентификатор «корзины», $FILE$ — идентификатор файла, а $PATH$ — путь к создаваемой локальной копии файла).
К особенностям Storj следует отнести то, что в в одну «корзину» нельзя положить более одного файла с одинаковым именем, что требует использования механизма формирования уникальных имен при загрузке.
В качестве внешнего арбитражного ресурса можно использовать https://api.storj.io [40], который поддерживает API.
Интеграция с КриптоАРМ осуществлялась с использованием предоставляемого им COM-сервиса. Для быстроты реализации интеграционные скрипты были написаны на vbs.
Взаимодействие смарт-контрактов с Провайдером внешних запросов осуществляется по следующей схеме.
Для использования Провайдера внешних запросов смарт-контракт должен поддерживать специальный интерфейс, состоящий из следующих методов: GetExternalRequest, SetExternalResponse и CheckExternalResponse.
Порядок взаимодействия некоторого Контракта, желающего получить «снаружи» ответ на некоторый запрос, с Провайдером внешних событий следующий:
При необходимости Контракт сам может удалять ставшие ненужными запросы, транзакционно используя метод DeleteRequest смарт-контракта RequestsQueue.
Здесь необходимо обратить внимание на то, что шаблон запроса может использовать достаточно сложную логику для интерпретации события получения ответа. Например, ответ может считаться полученным только в том случае, если запрос дал только определенный результат — и только для этого результата будет направлен ответ на заказавший запрос Контракт. Все прочие результаты будут проигнорированы и запрос будет продолжать исполняться. Аналогичным образом, шаблон может предполагать обращение сразу к нескольким внешним источникам и получение от них определенного сочетания частных ответов.
Для исключения «неправомочных» источников запросов смарт-контракт очереди содержит управляемый список адресов, которые должны быть исходными (txn.origin) адресами транзакций, ставящих запрос в очередь.
AddRequest | Добавить запрос в очередь | Входные параметры:
|
DeleteRequest | Удаление запроса из очереди | Входные параметры:
|
CheckRequest | Проверка наличия запроса в очереди | Входные параметры:
|
GetRequest | Выдать список идентификаторов запросов из очереди | Входных параметров нет. Выходные параметры:
|
AddBank | Добавить адрес в список уполномоченных адресов | Входные параметры:
|
CheckBank | Проверить наличие адреса в списке уполномоченных адресов | Входные параметры:
|
GetExternalRequest | Выдать параметры запроса | Входные параметры:
|
SetExternalResponse | Принять ответ на запрос | Входные параметры:
|
CheckExternalResponse | Проверить факт обработки ответа на запрос | Входные параметры:
Выходные данные:
|
Ниже приведен пример реализации методов в составе контракта.
Приводимый контракт предполагает вызов двух внешних запросов — просрочки даты (шаблон OVERDUE) и проверки регистрации организации (DADATA_EXISTS_WAIT).
Код, непосредственно не относящийся к работе с внешними запросами, исключен.
bytes32 Status ;
bytes32 ExpireDate ;
bytes32 OrgName ;
address Queue ;
bytes32[] Request_1 ;
bytes32[] Request_2 ;
bytes32 Request_id_1 ;
bytes32 Request_id_2 ;
bytes32 Response_id_1 ;
bytes32 Response_id_2 ;
function SomeContract(..., bytes32[] logics)
{
Owner =msg.sender ;
ExpireDate=logics[0] ;
OrgName =logics[1] ;
Status ="New" ;
Queue =0xd9b076d0b559f70782f379582bd3d54b85fc42cb ;
Request_1.length= 3 ;
Request_1[0] ="DAILY 00:10" ;
Request_1[1] ="OVERDUE" ;
Request_1[2] = ExpireDate ;
Request_2.length= 3 ;
Request_2[0] ="PERIOD 10" ;
Request_2[1] ="DADATA_EXISTS_WAIT" ;
Request_2[2] = OrgName ;
}
function SetStatus(bytes32 status_, ...)
{
address self_addr ;
Status=status_ ;
if(status_=="Released_") {
self_addr=this ;
Request_id_1=bytes32(bytes20(self_addr)) | "x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x001" ;
Request_id_2=bytes32(bytes20(self_addr)) | "x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x002" ;
Queue.call.gas(0x30000).value(0)(bytes4(sha3("AddRequest(bytes32)")), Request_id_1) ;
Queue.call.gas(0x30000).value(0)(bytes4(sha3("AddRequest(bytes32)")), Request_id_2) ;
}
}
function GetExternalRequest(bytes32 request_id_) constant returns (bytes32[] retVal)
{
if(request_id_==Request_id_1) return(Request_1) ;
if(request_id_==Request_id_2) return(Request_2) ;
}
function SetExternalResponse(bytes32 response_id_, bytes32 request_id_, bytes32[] response_)
{
if(tx.origin!=Owner) return ;
if(Status!="Released_") return ;
if(request_id_==Request_id_1) {
Response_id_1=response_id_ ;
Status ="Overdue__" ;
}
if(request_id_==Request_id_2) {
Response_id_2=response_id_ ;
Status ="ToBank___" ;
}
}
Для желающих попробовать технологии слежения за внешними событиями и работу с оракулами и провайдерами внешних запросов нами в сети Ethereum Rinkeby развернуты:
Календарный Оракул расположен в тестовой сети Rinkeby по адресу 79548a65e3ce179ec8d208c22ee84435dc34058f и выдает текущую календарную дату по Москве в формате YYYY/MM/DD.
Пример обращения к Оракулу:
contract Check_request
{
Calendar Oracle ; // Оракул-переменная
bytes32 Date ;
function Check_request()
{
// Инициализация Оракул-переменной на адрес Оракула
Oracle=Calendar(0x79548a65e3ce179ec8d208c22ee84435dc34058f) ;
// Получение информации из Оракула
Date=Oracle.GetDate() ;
}
}
//
// Описание абстрактного метода с интерфейсами Оракула
//
contract Calendar
{
function GetDate() constant returns (bytes32 retVal) ;
}
Очередь смарт-контракта Портала внешних запросов расположена в тестовой сети Rinkeby по адресу d9b076d0b559f70782f379582bd3d54b85fc42cb.
Протокол взаимодействия с Порталом внешних запросов описан выше.
На текущий момент публично открыты следующие шаблоны запросов:
Для доступа к очереди Портала внешних запросов необходимо сообщить нам (в комментарии или в личку) адрес счета Ethereum, с которого будут направлены транзакции постановки в очередь.
Желательно прикладывать к транзакции 0.1 Ether (это бесплатно, мы в тестовой сети) для отладки механизма платных услуг. В Rinkeby получить эфир можно только с помощью faucet [42], из-за отсутствия возможности майнинга ввиду протокола PoA.
При реализации платных сервисов для смарт-контрактов крайне полезной была бы возможность выполнять транзакции за счет «принимающего» смарт-контракта, а не за счет инициатора транзакции (естественно, если со стороны смарт-контракта будет каким-либо образом выражено согласие на это — например, за счет механизма доверенных адресов или чего-то в этом роде). Это значительно упростит механизмы расчета за «услуги», так как инициатор транзакции проплачивает еще и исполнение метода смарт-контракта, стоимость которого (исполнения) не всегда может быть определена заранее.
Разработку нетривиальных сценариев, взаимодействующих с «внешним миром» сильно осложняет отсутствие встроенных функций работы со строками — конкатенация, поиск, вырезание фрагмента.
Очень желательно наличие, аналогично основному Ethereum, механизма подтверждения загрузки файла в Swarm (его раздачи на другие узлы) — подобно подтверждению транзакции. Ибо непонятно, сохранен файл где-то за пределами твоего узла или нет.
Сборка из исходников и развертывание узла Swarm под Windows – крайне нетривиальная задача. Разработчики тестировались и готовили документацию только под linux и OSX, о чем честно признаются.
Крайне сложный для использования, слишком детальный API. Для простой интеграции желательно иметь «укрупненный» API, аналогичный реализованному в Ethereum Swarm — положить файл, извлечь файл.
Отсутствует возможность многопользовательского доступа к файлам. То есть, считать файл можно только из под учетных реквизитов, под которыми он был записан. Это приводит к тому, что для организации многопользовательского обмена файлами необходимо фактически «обнародовать» свои учетные реквизиты, что, с учетом платности услуги, не является хорошей практикой.
На текущий момент продуктивные или близкие к выходу в продуктив компоненты блокчейн-экосистемы позволяют в полной мере реализовать функционал, необходимый для поддержки процесса исполнения сделок торгового финансирования.
Конечно, имеются определенные нетехнические вопросы, решение которых необходимо для того, чтобы можно было говорить о реализации крупных проектов для торгового финансирования (да и многих близких к нему по задачам направлений) на блокчейне.
Во-первых, правовые вопросы сделок, осуществляемых через блокчейн, в том числе юридический статус записи в блокчейне.
Во-вторых, сейчас в России использование банками публичных блокчейнов фактически блокировано позицией регулятора в отношении криптовалют: запрет на их использование делает невозможной оплату комиссии за добавление транзакции (transaction fee). Транзакции в этом случае нужны не для осуществления расчетов, а как способ создания смарт-контрактов и взаимодействия с ними.
В-третьих, необходима стандартизация форматов электронных документов для возможности их автоматической проверки.
Наконец, необходимо насыщение экосистемы блокчейна источниками внешних событий: оракулами на различные реестры, в информационные системы банков и транспортных компаний и т.д. Это поможет исключить необходимость ручного внесения внешних событий и сделать исполнение смарт-контрактов по-настоящему автоматическим и деперсонализированным.
Становится очевидно, что в таких проектах техническая сторона представляется не самой значительной частью работ. Сейчас, когда разработка уже завершена, мы продолжаем работу с юристами и прорабатываем совместно с другими банками подходы к определению унифицированных требований к форматам электронным документам для автоматизации проверки их содержания.
Кейс с аккредитивом позволил нам получить как техническую базу, так и опыт реализации децентрализированных приложений в области ТФ. Сейчас мы смотрим несколько направлений, на которых нам интересно сделать пилот, о них мы расскажем позже.
Stay tuned!
Автор: MadJackal
Источник [43]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/260298
Ссылки в тексте:
[1] Кратко о целях и результатах: #Example
[2] Задачи исследовательского проекта: #Example1
[3] Общая схема платформы и взаимодействие её элементов: #Example2
[4] Архитектура и взаимодействие компонентов платформы: #Example3
[5] Практическая реализация: #Example4
[6] Реализация смарт-контрактов для аккредитива: #Example5
[7] Выбор компонентов платформы: #Example6
[8] Инфраструктура: #Example7
[9] Интеграция компонентов: #Example8
[10] Ethereum : #Example9
[11] Swarm : #Example10
[12] Storj.io: #Example11
[13] КриптоАРМ : #Example12
[14] Провайдер внешних запросов: #Example13
[15] Подробное описание реализации Провайдера запросов: #Example40
[16] Описание методов контракта Requests Queue : #Example41
[17] Описание необходимых интерфейсных методов Контрактов: #Example42
[18] Пример реализации: #Example15
[19] На пользу сообщества : #Example24
[20] Календарный оракул: #Example25
[21] Портал внешних запросов: #Example26
[22] Некоторые замечания по опыту интеграции сторонних компонентов: #Example18
[23] Ethereum: #Example19
[24] Ethereum Solidity: #Example20
[25] Ethereum Swarm : #Example21
[26] Storj.io: #Example22
[27] Выводы исследования : #Example23
[28] Blockchain & Bitcoin Conference в Санкт-Петербурге: https://spb.blockchainconf.world/ru
[29] gelbplaneten: https://habrahabr.ru/users/gelbplaneten/
[30] blockchainhub.net/blockchain-oracles: https://blockchainhub.net/blockchain-oracles/
[31] swarm-guide.readthedocs.io/en/latest/introduction.html: https://swarm-guide.readthedocs.io/en/latest/introduction.html
[32] storj.io: https://storj.io/
[33] инцидент в марте с DDOS атакой на Ropsten: http://coinews.io/ru/category/2-ethereum/article/322-ddos-ataki-jefiriuma-vernulis%27---teper%27-v-testovoj-seti
[34] JSON-RPC: https://github.com/ethereum/wiki/wiki/JSON-RPC
[35] Management-APIs: https://github.com/ethereum/go-ethereum/wiki/Management-APIs
[36] ropsten.etherscan.io: http://ropsten.etherscan.io
[37] rinkeby.etherscan.io: http://rinkeby.etherscan.io
[38] Swarm-guide: https://swarm-guide.readthedocs.io/en/latest/usage.html#the-http-api
[39] gist.github.com: https://gist.github.com/lmars/a37f3eaa129f95273c8c536e98920368
[40] https://api.storj.io: https://api.storj.io
[41] api.openweathermap.org: http://api.openweathermap.org
[42] faucet: https://faucet.rinkeby.io/
[43] Источник: https://habrahabr.ru/post/332756/
Нажмите здесь для печати.