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

КРИВАЯ ГАРТНЕРА

Как правило, основные ассоциации, которые возникают у большинства людей со словом «блокчейн», — это криптовалюты, майнинг, сети Bitcoin, Ethereum, и, конечно же, ICO — краудфандинговые проекты, собиравшие заоблачные суммы в криптовалютах. Криптолихорадка привлекла внимание к технологиям, которые лежат в основе криптовалютных проектов, вызвав сначала завышенные ожидания, а затем волну скептицизма, которую мы сейчас и наблюдаем.

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

барьерЫ ДЛЯ внедрения

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

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

Использование удостоверяющих центров закрывает возможность свободного, бесконтрольного подключения к сети. Поэтому, в принципе, все сети делятся на публичные, сети, доступ к которым не контролируется, и частные (или закрытые).

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

Мы имеем сделку между поставщиком и покупателем о поставке партии товаров на определенных условиях. В сделке кроме них участвуют банки, логистические и транспортные операторы, страховщики и регуляторы. Финансирующий торговую операцию банк должен иметь доступ только к той информации о транзакциях между покупателем и продавцом, которая ему необходима для выполнения своих обязательств и управления рисками. Логистическим и транспортным операторам необходимы и достаточны данные об условиях поставки, соблюдении технических условий транспортировки и хранения грузов. Регуляторам — о соблюдении нормативных процедур, например таможенного оформления грузов.

Если мы принимаем ограничения, что (1) пользователи сети должны быть авторизованы и (2) доступ к данным должен быть ограничен рамками бизнес-процессов, то сразу же теряют смысл как криптовалюты, так и их майнинг. Криптовалюты изначально были предложены как средство мотивации участников к обработке транзакций других пользователей, т. к. участник публичной сети вынужден обрабатывать и хранить данные, подавляющая часть которых ему не требуется. Но если каждый участник хранит и обрабатывает только те данные, в которых он заинтересован прямо или косвенно, то это уже по определению является необходимой и достаточной для него мотивацией, чтобы расходовать ресурсы на обработку данных. Отметим, что в принципе нет никакой проблемы запрограммировать валюту с необходимыми свойствами в рамках частного блокчейна. В финансовом сегменте есть ряд хорошо известных проектов, которые используют блокчейн в качестве транспорта для межбанковских расчетов — например Ripple или WorldWire. Тем не менее на корпоративном рынке пока все сводится, как правило, к интеграции реестра с автоматизированными системами (АБС) банков, которые обслуживают участников той или иной сети. Да, это скучно, но зато работает и не создает рисков для бизнеса.

Майнинг как механизм достижения консенсуса Proof of Work рассчитан на использование в публичных блокчейнах. Изначально этот подход был предложен для решения проблемы, известной как «атака Сивиллы» — обеспечения корректного голосования анонимных (или псевдонимных) участников за счет их вычислительных мощностей. Однако все свелось к гонке мощностей, их концентрации в руках считаных участников и эпическому росту вычислительной мощности (hashrate) популярных сетей на волне популярности биткоина. Теперь вместе с популярностью закономерно падает и хешрейт.

В случае если участники авторизованы, то проблема «атаки Сивиллы» отпадает по определению. Нам достаточно правильно посчитать голоса участников. Как следствие, мы можем использовать гораздо более эффективные, с точки зрения затрат, алгоритмы. Как правило, в частных сетях используются множественные вариации алгоритма Proof of Authority.

Отдельной проблемой является готовность платформ к эксплуатации в корпоративном IT-ландшафте, их зрелость с точки зрения документации, качества и безопасности кода, наличия квалифицированной технической поддержки. Бизнес, как правило, привязан к определенному технологическому стеку как в части системных решений (операционные системы, СУБД, интеграционные решения), так и в части прикладных — учетных систем, сервисов и приложений. Каждый новый экземпляр в технологическом зоопарке увеличивает стоимость обслуживания, усложняет обеспечение требуемого уровня сервиса (SLA) со стороны IT-провайдеров. И едва ли можно ожидать поддержки экзотических блокчейн-протоколов со стороны таких вендоров, как SAP, а ее отсутствие в конечном итоге увеличивает стоимость владения решением для бизнеса.

технические проблемы

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

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

Та же проблема и с производительностью. Смарт-контракты в Эфириуме, например, выполняются всеми узлами сети, и в итоге производительность сети равна производительности телефона начала века. Как следствие, во время проведения популярных ICO или пика популярности «криптокотиков» сеть перестает справляться с обработкой транзакций, что ведет к скачкам стоимости транзакций. Механизм саморегуляции вроде бы и работает, но не позволяет рассчитывать, прогнозировать стоимость обработки транзакций, что критично для коммерческих и тем более государственных организаций.

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

целесообразность использования

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

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

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

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

Такая автоматизация взаимодействия между контрагентами позволяет минимизировать транзакционные издержки — затраты, не ведущие к созданию добавленной стоимости. Обычно речь идет об:

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

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

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

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

Во-первых это, безусловно, финансовые рынки, прежде всего операции с ценными бумагами. В России пилотные проекты уже реализованы Московской Биржей, Сбербанком и рядом менее крупных банков. В торговле и промышленности — это проекты в области торгового финансирования, управления цепочками поставок и прослеживания продукции. Здесь можно отметить факторинговый пилот М. Видео совместно с рядом банков, проекты Газпромнефти в области снабжения и логистики, пилот-системы управления семеноводством российского Минсельхоза.

Отдельной строкой проходит медицинская отрасль. На западе — в Европе и США — таких проектов довольно много, в России же пока особых успехов нет. Это связано с большой долей государственной медицины и слабым развитием медицинского страхования. Вообще надо сказать, что сильное государственное регулирование и административное давление существенно ограничивают возможности для внедрения технологии. Несмотря на то, что многие госорганы и госкорпорации экспериментируют с ее внедрением, большинство из них не заинтересованы в реальном изменении модели регулирования своего сегмента рынка и в реальности преследуют цель сохранения или даже усиления контроля. Например, пилотный проект по автоматизации топливозаправочного комплекса, который в 2018 году был реализован компаниями Газпромнефть, S7 и Альфа-банком.

Решение позволяет минимизировать финансовые риски для нефтяной компании, осуществлять оперативное выставление счетов и контролировать денежную задолженность, а авиакомпанию избавляет от необходимости резервировать предоплату на счетах поставщика. Надо отметить, что проект идет параллельно с модернизацией АСУТП и самих топливозаправочных комплексов. Автоматизация внешних взаимодействий приобретает смысл только при определенном уровне зрелости в части автоматизации внутренних процессов. Если внутри организации процессы не оцифрованы, то говорить о внедрении блокчейна просто бессмысленно.

Другим интересным проектом является TradeLens. Это глобальная система управления контейнерными перевозками, которая инициирована компанией Maersk. Система автоматизирует обмен данными между всеми участниками процесса — грузоотправителями, грузополучателями, таможенными и портовыми службами, операторами контейнерных линий и судовладельцами. В результате 12-месячного пилотного проекта сроки транзита контейнеров были сокращены на 40%. В итоге внедрения таких решений бизнес получает и ряд других преимуществ.

преимущества бизнеса при внедрении решений

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

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

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

типовая архитектура

Технологическая архитектура распределенных систем включает несколько основных уровней. Во-первых, это IT-инфраструктура, формируемая узлами участников с учетом особенностей существующих технологических платформ, в первую очередь — учетных систем и систем обеспечения информационной безопасности предприятия. На уровне инфраструктуры используется практически весь существующий сегодня технологический стек, иногда требуются и весьма специфические решения. Так, например, для высоконагруженных узлов может потребоваться использование специальных аппаратно-программных комплексов для криптографических преобразований (HSM). Инфраструктура обеспечивает функционирование распределенного реестра и смарт-контрактов. Копия локального реестра хранится в СУБД, установленной на узле участника, а смарт-контракты дистрибутируются и выполняются в специальных контейнерах.

Дистрибуция данных и смарт-контрактов между узлами участников может быть организована в рамках так называемых каналов, которые ограничивают распределение данных только между участниками отдельно взятой группы процессов. Разграничение доступа к данным на уровне отдельных организаций также может (и должно) быть организовано в рамках канала.

Взаимодействие с реестром и смарт-контрактами происходит либо через специально разработанные приложения, которые могут быть реализованы в виде веб-сервиса, мобильного приложения или «толстого» клиента, либо через прикладные программные интерфейсы для интеграции с учетными системами и АСУТП. В данном контексте следует отметить, что здесь кроется весьма важное и полезное преимущество распределенной системы перед традиционной централизованной архитектурой — участники могут работать с данными так, как им наиболее удобно: могут реализовать свое приложение или интегрировать решение в свою систему с учетом специфики автоматизации внутренних процессов.

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

выбор платформы

С точки зрения технологической реализации, ключевым является вопрос выбора платформы. На практике, на западном рынке широко представлены решения на базе HyperLedger Fabric и R3 Corda. Fabric является наиболее универсальной и зрелой платформой для создания сервисных блокчейн-решений, но это несколько сложнее, чем Corda, которая применяется в основном в финансовом секторе. Под зонтиком HyperLedger также разрабатывается ряд других платформ и инструментов, которые заслуживают внимания: платформа Sawtooth c рядом интересных технологических возможностей, которая спонсируется Intel, и Iroha — проект японской Suramitsu Corp., который разрабатывается в Иннополисе.

На российском рынке к упомянутым выше платформам можно добавить BitFury Exonum и Vostok Platform. Кроме этого, есть ряд платформ, «выросших» из Ethereum — Quorum и Masterchain, который разрабатывается АФТ.

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

практика внедрения

Внедрение подобного рода систем сопряжено с существенными рисками и затратами, которые связаны как с субъективными, так и объективными причинами. Объективно на данный момент отсутствуют готовые решения и «лучшие практики», которые бы позволили правильно спроектировать решение, спланировать проект и учесть все риски. Поэтому на практике внедрение блокчейна идет итерациями по 6−9−12 месяцев, но, в принципе, не отличается по существу от внедрения любой информационной системы.

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

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

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

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

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

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

Основная сложность на этом этапе — это согласование бизнес-требований к целевому решению со стороны участников. Проблема хорошо известна даже на уровне отдельно взятой организации, когда отдельные подразделения не могут договориться между собой и выдвигают взаимоисключающие требования. К тому же участники имеют разный уровень зрелости с точки зрения автоматизации внутренних процессов, готовности к интеграции блокчейна с собственными учетными системами и АСУТП. И, разумеется, разные финансовые возможности. Поэтому, как правило, лидером внедрения выступают наиболее мощные в финансовом и технологическом отношении организации. В этом кроется известная доля риска: лидер должен не только согласовать ожидания участников, но и предложить жизнеспособную, взаимовыгодную для всех (или хотя бы для ключевых участников) операционную модель. Поэтому, на практике, для реализации таких проектов формируется консорциум, который включает ключевых участников того или иного сегмента рынка.

проверка концепции

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

пилотный проект

На этом этапе разрабатываемое решение обкатывается ограниченным кругом участников: как правило, в пилоте участвуют от 3 до 7 организаций. В отличие от предыдущей стадии проекта решение проверяется на реальных данных с использованием ключевых информационных систем участников, но транзакции проводятся в так называемом теневом режиме. Целью этого этапа является выявление проблемных мест как с технологической реализацией, так и с организационной точки зрения. В результате должна быть сформирована жизнеспособная модель управления сетью, при необходимости выработана модель взаимодействия с существующими регуляторами.

После того, как мы провели пилотный проект, проанализировали его результаты и сформировали требования к целевой системе, можно приступать к разработке ее первой версии и масштабированию решения на более широкий круг участников. На данный момент (конец 2018 года) наиболее продвинувшиеся в реализации консорциумы, такие как TradeLens, включают более сотни участников.

#децентрализованныереесты #технет