Недавно компания «Ренессанс Страхование» опубликовала статью, в которой рассказала о программном продукте для страхования грузоперевозок. Этот продукт мы разработали на основе платформы Hyperledger Fabric. Вокруг статьи развернулись дискуссии между криптоскептиками и криптоэнтузиастами, люди подняли ряд актуальных вопросов — зачем вообще понадобился блокчейн, имеют ли право на жизнь непубличные блокчейны, чем хорош именно Hyperledger и тому подобное. Эти вопросы я и хочу сегодня прокомментировать.

«Блокчейн здесь только для пиара и хайпа»

Это, наверное, первое, что сегодня услышит от криптокритиков любой разработчик продукта, в котором применён блокчейн:

«Зачем он тут нужен, ведь ту же самую задачу можно решить обычными средствами, без блокчейна».

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

Допустим, участники говорят нам, чтобы у нас не было возможности подменить что-то, ведь участники хотят нам доверять. Кроме того, хорошо бы обеспечить консистентность данных, что называется, «из коробки», устойчивость к сбоям распределенной системы, способы восстановления. Как это можно сделать? Например, берём набор транзакций, подписываем, получаем хэш и используем его для подписи следующего набора транзакций, и так далее. В результате получается цепочка порций данных, внутри которой невозможно что-либо изменить. По большому счету, это и есть тот самый блокчейн.

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

«Непубличный блокчейн — это вообще не блокчейн»

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

• серьезный поставщик
• поддержка сообщества профессиональных разработчиков
• независимость от Ethereum
• отсутствие связи с IСO

Конечно, этот набор критериев несколько провокативен, ведь может показаться, будто бы мы говорим, что в IСO-проектах участвуют непрофессиональные разработчики. Ну и конечно, нам попеняли на то, что, мол, «непубличный блокчейн вообще нельзя считать блокчейном».

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

И к слову — это решение поддерживается Linux Foundation, а там кого попало не поддерживают. В этом смысле Linux Foundation можно считать знаком качества. Конечно, ошибки встречаются в любом продукте, и в исходниках Fabric мы их тоже находили. Но ошибки есть в любом продукте, особенно, развивающемся.

«Нужно использовать проверенные публичные блокчейны»

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



Но реальная ситуация с сетями несколько иная. Сам по себе интернет состоит из больших сегментов, которые соединяются друг с другом не огромным количеством связей, а небольшим количеством магистральных каналов, которые обслуживаются несколькими компаниями. Например, так выглядит сеть «Ростелекома»:



К примеру, Калининград соединяется с миром только двумя каналами, принадлежащими «Ростелекому» и «Балттелекому». И лишь от воли условного «человека с рубильником» зависит, будет ли этот сегмент рунета связан со всей остальной сетью, и в частности — с сетью Ethereum. Представьте ситуацию: обмен трафиком какого-нибудь сегмента Рунета с мастернодами Ethereum выключили, просто заблокировав TCP/UDP 30303 (или даже проще — временно ограничив discovery, а это только UDP), и пока «связи» не было, внутри этого сегмента успели намайнить несколько блоков, заключив сделки: например, Вася купил у Пети машину за 10 eth. Что будет, если достаточное время «подержать» такое состояние для подсети с мастернодами, а затем вернуть всё «как было»? Понятно, что есть публичные эксплореры, но это, скорее, контроль, чем защита.

Кроме того, даже в 2019 году возможна атака 51 %, как, например, недавние случаи атаки BTC.com и BTC на Bitcoin Cache, или, что более опасно, — не подтвержденная атака на Ethereum. Мы понимаем, что для криптосообщества в настоящее время приоритетом является развитие публичной инфраструктуры, а это может расходится с ежедневными интересами реальных компаний. Сети типа «консорциум» используют крупные компании, банки, страховые организации, и для них текущее состояние публичных блокчейн-систем пока что не позволяет их использовать в интересах реального бизнеса, а не для прототипов или дублирующих реальные процессы систем.

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

«А как же пользователям вашего Hyperledger контролировать информацию в блокчейне?»
Ответ очень прост. Любой участник может полностью анализировать все транзакции в доступных ему каналах, как использовав Hyperledger Explorer, так и с помощью нашей системы, получая доступ к содержимому пиров, расположенных в собственной инфраструктуре участника. Делать систему публичной мы не будем по нескольким причинам, среди которых, в основном, требования информационной безопасности участников.

Управление архитектурой

Ещё одна причина, по которой мы использовали именно Hyperledger Fabric, заключается в том, что мы построили архитектуру, состоящую из нескольких каналов (канал, в терминологии Hyperledger — отдельный реестр, блокчейн с различными правами, связывающий только тех участников, которые участвуют в определенном бизнес-процессе). Мы можем управлять системой с точки зрения подключения новых участников, но не можем единолично влиять, например, на правила расчёта страховых тарифов. Тарифы согласуются всеми имеющими доступ участниками.

Альтернативы?

Если говорить об альтернативах Hyperledger, то мы всерьез рассматривали только R3 Corda. Это не совсем блокчейн, а более лёгкое решение, которое сейчас достаточно активно используют банки и другие финансовые организации.

Публичный Ethereum, как альтернатива, не годится по описанным выше причинам. Мы имеем довольно свежий, а потому бедный язык разработки смарт-контрактов Solidity, малое количество библиотек, возможность работать с внешними системами через Oraclize. К тому же возникают очень большие вопросы с точки зрения информационной безопасности: смарт-контракты выполняются на сторонних нодах — например, в Китае. То есть из Китая или Украины должен прийти запрос на сервис в компании, к которому должен быть обеспечен доступ отовсюду. Для безопасников банка или страховой компании это неприемлемо. Кроме того, надо понимать, что деятельность страховых компаний у нас регулируется ЦБ РФ.

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

* * *

Подводя итоги, какие достоинства мы видим у Hyperledger, из-за которых мы применяем это решение в наших проектах для страховых и финансовых компаний?

• Богатый язык для написания чейнкода (смарт-контрактов) (Golang, а теперь и Java).
• Независимость от внешних факторов. По крайней мере, внешние факторы могут находиться под контролем.
• Возможность выбора и использования большого количества внешних библиотек.
• Наличие доступных всем участникам инструментов для просмотра и анализа блокчейна.
• Гибкое управление архитектурой.
• Вхождение проекта в Linux Foundation, как знак качества и обозначение серьезного подхода.