Блокчейн для бизнеса: как он устроен и почему именно так

Привет! Меня зовут Кирилл Небогин, я руковожу разработкой блокчейн-платформы в Waves Enterprise. Мы привыкли, что новости о блокчейне обычно связаны с рынком криптовалют. Но есть и другие интересные сценарии применения блокчейна, на которых мы в компании и фокусируемся. В этой статье на примере истории нашей платформы я расскажу, как блокчейн приходит в бизнес, в государственные проекты и какие технические (и не только) сложности с этим связаны.

В третьем квартале 2018 года вышел первый публичный релиз нашей блокчейн-платформы — тогда она еще не называлась Waves Enterprise. Один крупный российский заказчик оценил ее как перспективную для своего проекта, но ему было важно наличие ГОСТ-сертификации. Так что первым значительным энтерпрайз-обвесом стала для нас поддержка криптографии, сертифицированной по ГОСТу. Без этого ни о каких проектах с госучастием не могло идти и речи, а исключать рынок с таким потенциалом не стоило. На данный момент ГОСТ-криптография реализована у нас по стандарту ГОСТ Р 34.12-2015 для шифрования данных, ГОСТ Р 34.11-2012 — для хеширования и ГОСТ Р 34.10-2012 — для электронных подписей.

Выбор консенсуса

Следующим большим шагом стала разработка собственного консенсуса. Основных исходных моделей здесь три — PoW, PoS и PoA.

В PoW (Proof-of-Work) мы рискуем простоем дорогостоящего оборудования. Это мы отмели сразу как чрезвычайно затратный и энергоемкий вариант.

В PoS (Proof-of-Stake) мы рискуем деньгами. Здесь энергозатратные вычисления не требуются, майнер создает только цифровую подпись, и шанс каждого майнера на успех зависит от того, сколько у него токенов сети. Для публичной сети это рабочая схема, так что в мейннете мы остановились на PoS. Потенциально PoS ведет к централизации, а следовательно, к уязвимости сети и снижению мотивации основного числа участников. Поэтому мы дополнительно реализовали сдачу токенов сети в лизинг за долю в вознаграждении — получился LPoS (Leased-Proof-of-Stake). Так мы сохраняем мотивацию у миноритарных участников. 

Публичные сети развиваются за счет финансовой мотивации. Но нужна ли она в приватных сетях, которые в основном и создаются для бизнес-проектов? Зачем нам какие-то токены, чтобы, например, просто обмениваться хешами документов? Проще установить случайный выбор майнеров, сохранив тем самым децентрализацию сети, и ограничить количество валидаторов, чтобы управлять ее масштабируемостью. Так работает консенсус PoA (Proof-of-Authority), который мы взяли на вооружение в приватных проектах. Здесь мы рискуем только деловой репутацией. 

На этом этапе мы стартовали первые небольшие пилоты — системы автоматизации цепи поставок, хранения медицинских записей, проверки подлинности продукта. Казалось, что время выбрано идеально, в 2018 году прошло первое чтение закона о ЦФА (цифровых финансовых активах), мы сделали вексельную программу на блокчейне, несколько других демопроектов, были готовы к большому будущему, но… закон о цифровых финансовых активах несколько задержался и был принят лишь в середине 2020 года. Что ж, неплохой запас времени для доработки продукта 🙂

Смарт-контракты

Подходим к первому неоднозначному вопросу. Если мы хотим использовать блокчейн в бизнесе, без смарт-контрактов не обойтись. Будет уместно провести аналогию с базами данных, и здесь смарт-контракты выступают как аналоги хранимых процедур. По сути, они связывают логику бизнеса и логику блокчейна. Когда мы говорим о смарт-контрактах, два главных вопроса — на чем писать и как хранить.

Вариант первый: писать на специализированных языках, таких, например, как Solidity, что используется в Ethereum. Так можно делать любые контракты и реплицировать их на все узлы, чтобы каждый из них самостоятельно исполнял контракт и добавлял выходные данные в стейт (или в таблицу, если придерживаться аналогии с БД). Но так мы быстро упираемся в потолок пропускной способности, поскольку корпоративные сценарии обычно требуют контрактов со сложной логикой. Другая, не менее важная проблема со специализированными языками — для них нужны дополнительные специалисты с узкими компетенциями. Обычно же в штате компаний есть только разработчики на Java и других языках, популярных в энтерпрайз-секторе.

Второй вариант реализации смарт-контрактов — компилировать ноду сразу со смарт-контрактом внутри. Это позволяет добиваться сотен транзакций в секунду на тестах и, на первый взгляд, решает проблему. Но посмотрим на два хода вперед: что если нам потребуется изменить логику бизнес-контракта? Вполне обычная в бизнес-сценариях ситуация оборачивается редеплоем всех узлов сети — не самый лучший пользовательский опыт, да и непрерывность под большим вопросом.

Мы выбрали третий вариант: реализовали работу смарт-контрактов внутри докер-контейнеров, с доступом через REST API или gRPC. Это популярный в индустрии подход, который дает возможность писать смарт-контракты на тех языках, в которых привыкли писать в компании. Его же использует, например, Hyperledger Fabric. Пример создания и упаковки простого контракта на Python в докере есть у нас в документации.

Валидация смарт-контрактов

Чтобы результаты выполнения смарт-контракта (майнинга) были добавлены в стейт, их должны завалидировать другие участники сети: выполнить на своей стороне, хешировать результаты и убедиться, что полученный хеш совпадает с хешем майнера. В Hyperledger Fabric политика валидации настраивается в зависимости от конкретного проекта: можно, например, указать, что для валидации необходимо 50%+1 узел компании A, один узел компании B и все узлы компании C.

У нас есть три политики валидации: Any, Majority и Majority with one of.

• Any не требует от других участников сети валидации результатов.

• Majority требует, чтобы валидаторы исполнили контракт и прислали майнеру хэши результатов. Контракт считается исполненным, если совпадают хеши большинства валидаторов, эти доказательства сохраняются в блокчейне.

• MajorityWithOneOf аналогична Majority, но для исполнения контракта необходим хэш/доказательство по крайней мере от одного из участников из заранее созданного списка.

В качестве валидаторов публичной сети Waves Enterprise утвержден ряд наиболее активных узлов сети. Каждый из этих узлов синхронно с основным майнером выполняет на своей стороне смарт-контракты, полученные результаты хеширует и защищает подписью. Майнер сравнивает результаты валидаторов, и если результат от ⅔ валидаторов сходится, майнер включает их в транзакцию по исполнению смарт-контракта. Валидаторы получают за работу вознаграждение в токенах сети.

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

Проблемы корпоративного блокчейна

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

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

Пропускная способность

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

В этом году мы проработали скорость в тяжелых транзакциях — 15 КБ — и при нагрузочном тестировании достигли 500 tps (транзакций в секунду). Под тяжелыми транзакциями подразумеваются вызовы смарт-контракта с бизнес-логикой системы федерального дистанционного электронного голосования, которая по тестам в итоге справилась с нагрузкой в 25 млн избирателей. На базовых трансферах токенов получаем около 2000 tps.

SDK интегратора

Бизнес-логика проектов бывает так непредсказуема, что имеет смысл не множить готовые решения, а развивать инструменты для их самостоятельного создания. Постепенно в составе Waves Enterprise сформировалось отдельное подразделение интегратора и важнейшим результатом его работы стал SDK для автоматизации бизнес-процессов. Он вполне доступен даже для тех, кто не знаком с программированием. Пройдя через этот «мастер создания», вы в итоге получаете готовый смарт-контракт на Kotlin в докере. В позапрошлом году наша команда читала курс по блокчейну в ВШЭ, и для финального проекта многие ребята самостоятельно разобрались с нашим SDK за пару недель, сделали с его помощью рабочие смарт-контракты.

Исходники SDK нашей платформы есть на гитхабе. Устанавливаете по инструкции — и у вас в распоряжении десятидневная триал-версия, с клиентом, дата-сервисом и всем необходимым. Только предварительно нужно установить Docker и Docker-compose. Можно писать контракты, делать транзакции и ни в чем себе не отказывать 🙂 В этом году мы также планируем выложить опенсорсную версию всей платформы. 

Текущий статус

Сочетая описанные выше и другие технологии, мы можем свободно создавать на основе блокчейна масштабные информационные системы для государства и бизнеса. О федеральной системе ДЭГ я упоминал выше; кроме того, на основе нашей сделана блокчейн-платформа ФНС, мы делаем и финтех-сервисы для Альфа-Банка, и корпоративные решения других компаний. В общем, платформа востребована 🙂

Если вы хотите подробней узнать об этих проектах или задать другие вопросы, связанные с использованием блокчейна, — пишите в комментариях, я обязательно отвечу или подготовлю отдельные материалы.