company_banner

Блокчейн-платформа R-chain: общая архитектура и эволюция

  • Tutorial

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



Данная статья довольно объемная и вместе с этим информативная. Поэтому надеемся на вашу вовлеченность и предупреждаем о формате tutorial.

В 2016-2017 годах мы выполнили ряд исследовательских проектов по построению децентрализованной платформы для торгового финансирования. Использовали тестовый Ethereum (Rinkeby) как базовую платформу распределенного реестра и Ethereum Swarm как средство децентрализованного обмена файлами. Кроме общих вопросов построения децентрализованной платформы испытывали возможности смарт-контрактов, применения оракулов и арбитражных смарт-контрактов. Некоторые из этих результатов есть


На базе этих исследовательских проектов претворились в жизнь


Итогом этой достаточно длительной работы стал, как говорят военные, «прием на снабжение» IT Райффайзенбанка штатной децентрализованной платформы R-Chain. Теперь она предлагается как элемент клиентского обслуживания для корпоративных групп разного размера.

Делимся основными особенностями построения данной платформы, а также рассказываем о процессе эволюции использования в ней различных «технических» компонентов — блокчейн-платформ и распределенных файловых систем.

Содержание



Особенности корпоративных и межкорпоративных систем


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

  • У платформы должен быть оператор — юридическое лицо, несущее перед участниками ответственность за её функционирование. Вариант — каждый за себя, всё решит консенсус участников и прочее, характерное для публичных блокчейн-платформ, здесь не пройдет.
  • Использование платформы участником должно иметь достаточно простую юридическую обвязку, максимально близкую к существующему электронному документообороту. Поверьте, описание математических основ алгоритма консенсуса много-ранговой блокчейн-сети на 15 страницах — это не то, что ожидают увидеть ваши юристы.
  • Система должна удовлетворять требованиям регуляторов и «обычаям документооборота» по криптографии, используемой для защиты данных и подтверждения юридической значимости действий. Например, предлагая свой продукт российским клиентам, вы не раз убедитесь, что после слов «мы используем ГОСТ» количество вопросов заказчика волшебным образом сокращается, а его желание использовать вашу платформу пропорционально возрастает.
  • Компоненты узла платформы, устанавливаемые у участника, должны хорошо ложиться в принятую в корпоративных системах сетевую сегментацию. Нахождение в ДМЗ коммерческой тайны или ключей ЭЦП, обеспечивающих юридическую значимость — и всё.
  • Возможность «форсмажорного» изменения состояния сделок в нарушение заложенной ролевой модели. Не секрет, что в жизни что-то может пойти не так — пути бизнеса подчас неисповедимы, а регуляторы и решения суда делают их еще более кучерявыми, причем нередко задним числом. И в один далеко не прекрасный момент сделка может оказаться в состоянии, из которого ее нельзя по ролевой модели перевести в состояние, предписанное судьбой — для этого платформа должна предусматривать соответствующие механизмы, которые позволят установить сделку в нужное состояние при условии надлежащего консенсуса участников этой сделки.

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

Общая архитектура платформы


Архитектура программных компонентов


Приложения, использовавшиеся нами в исследовательский проектах 2016-2017 годов, были написаны на основе прямой интеграции диалоговых интерфейсов с «техническими» компонентами распределенной платформы — geth и swarm. Но, проанализировав возможности и последствия такого подхода, мы пришли к выводу о необходимости введения между бизнес-бэкендом и «техническими» компонентами еще одного слоя — адаптера унифицированных бизнес-объектов. Данный прием относится к достаточно стандартным шаблонам построения программной архитектуры, что, тем не менее, не снижает его эффективности. В результате, программная архитектура узла нашей платформы стала выглядеть примерно следующим образом:



В такой архитектуре бизнес-приложение работает не непосредственно с абстракциями DLT-компонентов, а с неким условным «универсальным бизнес-процессом» (далее — процесс) — создает процесс, меняет состояние процесса. Приведение структуры данных универсального процесса и операций над ним к данным и операциям, используемым в DLT-клиенте, осуществляет набор компонентов, обозначенный как «Зеркало бизнес-процессов». «Зеркало» же выполняет и обратное преобразование полученной от DLT-клиента информации, а также отфильтровывает информацию по процессам, не относящимся к участнику — владельцу узла. Таким образом, на каждом узле поддерживается в синхронном состоянии база данных по бизнес-процессам, в которых этот узел принимает участие, причем в максимально удобном для бизнес-приложения формате. Бизнес-приложение взаимодействует с этой базой — базой данных бизнес-процессов, получая информацию о состоянии процессов и передавая операции по изменению этих состояний.

Универсальный бизнес-процесс


Естественно встал вопрос, какими именно свойствами следует наделить универсальный бизнес-процесс, чтобы он обеспечивал, с одной стороны, максимальное использование преимуществ блокчейн-платформ, а с другой, — максимальную гибкость и функциональность для применения в Бизнес-приложении. Дополнительным условием была возможность реализации выбранных свойств на большинстве из распространённых DLT-платформ, функциональные возможности которых в некоторых аспектах существенно отличаются (Ethereum/Quorum/Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Базируясь на опыте своих и чужих проектов, мы пришли к следующим выводам.

Универсальный бизнес-процесс должен иметь следующий атрибутивный состав:

  • Параметры процесса (вид процесса, статус, контекстные атрибуты Процесса)
  • Ролевой список участников процесса
  • Перечень связанных с процессом электронных документов
  • Карта переходов процесса

При этом платформа должна на уровне блокчейн-компоненты обеспечивать следующие условия распространения процесса в сети:

  • Полнота и целостность информации
  • Конфиденциальность электронных документов за пределами круга участников процесса
  • Контроль следования карте переходов процесса
  • Хранение истории изменения состояний процесса

Для реализации этих возможностей были разработаны «рамочные» смарт-контракты с соответствующими наборами свойств и методов.

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

Параметры процесса — носят условно открытый характер, так как передаются непосредственно через смарт-контракт. Для некоторых блокчейн-платформ они являются принципиально публичными (Ethereum/Masterchain), для других могут быть закрыты штатными средствами обеспечения приватности данных (Quorum — приватные смарт-контракты, Hyperledger Fabric — каналы и приватные данные). Наверное, важнейшим из параметров «ядра» процесса в нашей реализации является «вид процесса», так как он несёт не только смысловую, но и функциональную нагрузку — в зависимости от «вида процесса» адаптер DLT выбирает шаблон смарт-контракта, которым данный процесс будет представляться. Зачем это нужно? Очевидно, что существует бесчисленное количество видов сделок и столь же многообразны бизнес-процессы, обеспечивающие их реализацию. В достаточно большом количестве случаев бизнес-процессы по сути отличаются только картой переходов (с точки зрения платформы) и могут быть реализованы одним единственным смарт-контрактом, поддерживающим произвольную карту переходов (об этом ниже). Но с конкретным бизнес-процессом могут быть связаны и достаточно уникальные моменты:

  • Обращения к оракулам (например, для сделок связанных с курсом валют)
  • Обращение к другим сделкам или к виртуальным счетам (например, для автоматического резервирования средств или проверки наличных остатков)
  • Контроль времени события (например, проверка срока подачи документов по аккредитиву или требования по гарантии)
  • и так далее

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

В число «атрибутов ядра» нашего процесса входят также «статус» и «примечание»: первое — это кратное описание состояния процесса («New», «Canceled», «Closed», «OnАpproval»), второе — «длинная» строка с более подробным описание к «статусу». Мы ограничиваем длину примечания где-то до 1000 символов (например, «Недостаточно средств на счете»), так как для передачи значительных объемов информации (тем более конфиденциальной) предназначены электронные документы, прикрепляемые к процессу.

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

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

История изменения состояния процесса — последовательность «кадров», каждый из которых соответствует одной операции изменения состояния процесса. В нашей реализации мы храним для каждого «кадра» истории следующие данные:

  • статус
  • примечание
  • идентификатор инициатора транзакции изменения состояния

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

Обеспечение юридической значимости — очень важный вопрос, отмеченный нами в разделе «Особенности корпоративных и межкорпоративных систем». Мы изначально исходили из концепции, что юридическая значимость должна обеспечиваться не средствами блокчейн-платформы, а за счет использования внешнего PKI, имеющего регуляторную поддержку или соответствующий уровень доверия у участников платформы. Грубо говоря, электронный документ, обеспечивающий юридическое обоснование ваших действий (платежный документ, контракт, требование и так далее) и прилагаемый к процессу, должен быть подписан на базе «кошерного» PKI (в России — ГОСТ, где-то за рубежом, например, SSL или PGP/GPG ). Бизнес-приложение проверит «внешнюю» подпись и выполнит соответствующее действие. Или не выполнит — в зависимости от результата. Кто-то скажет, что это не «по-евангелистски» и «надо убеждать юристов в юридической значимости блокчейн-транзакций». Мы прошли много шагов этого путешествия и результат всегда был один. Впрочем, в случае с Россией сертификация Мастерчейн открывает определенные возможности в этом плане — как говорится «Удачной охоты!»

Преимущества использования универсального бизнес-процесса


Что же в итоге нам дал такой подход?

  • Расширение круга потенциальных разработчиков децентрализованных бизнес-приложений. Так как при предложенной «зеркальной» архитектуре от разработчика собственно бэкенд-приложения не требуется какой-либо работы непосредственно с децентрализованными компонентами, то появляется возможность привлечь к разработке без каких-либо ограничений самый широкий круг «обычных» разработчиков, знающих толк в необходимых продуктовых областях. Это значительно снижает сроки и стоимость разработки и повышает ее качество. В наших проектах из четырех разработчиков бэкендов трое вообще никогда ранее не работали с блокчейн-системами, а еще один имел опыт разработки на Corda, в то время как приложение работало через «Зеркало» с Ethereum, а затем с Quorum. С другой стороны, квалифицированные блокчейн-разработчики вместо рутинной работы по раз за разом выполняемой переделке «упаковки» бизнес-данных в блокчейн могут заняться действительно сложными вопросами связанными с развитием децентрализованных платформ.
  • «Зонирование» ошибок. Не секрет, что в сложных программных системах, а децентрализованные приложения мы можем, без сомнения, отнести к таковым, время от времени что-то идет не так. Если учесть, что многие из используемых децентрализованных компонентов крайне «молоды» и «сыры» (просто в силу этой молодости и условий своего создания), то риск этого «что-то не так» очень сильно возрастает. И ситуация, когда на глаза изумленного пользователя выплывает багровое сообщение «Ваша транзакция ёк, потому что...», никого не радует. В случае разделения программных слоев на «зеркало» и бизнес-приложение, «зеркало» перенаправляет ошибки технологической части от конечного пользователя на техническую поддержку. Это снимает ненужную психологическую нагрузку с пользователя, которому «достаются» только бизнес-ошибки, соответствующие его пониманию и возможности исправления. Если пользователь надлежащим образом выполнил свою часть работы, то дальнейшая забота о правильной реализации бизнес-процессов переходит с его плеч на службу технической поддержки, располагающей соответствующими навыками и инструментами. При возникновении технологических проблем у поддержки имеется несколько десятков минут, а то и часов, на то, чтобы обнаружить и исправить ошибку, и если поддержка не забывает о своих обязанностях, то пользователь может так никогда и не узнать о том, что к нему «стучались» страшные insufficient funds for gas * price + value или gas required exceeds allowance or always failing transaction.
  • Возможность «подкапотных» модернизаций блокчейн-базиса. Отсутствие прямой зависимости бизнес-приложения от конкретной реализации блокчейн-базиса позволяет произвести необходимые изменения в этом базисе, не затрагивая само бизнес-приложение. А трудозатраты на бизнес-приложение, особенно с развитым диалоговым интерфейсом, может составить 75-95% от общих трудозатрат на программный комплекс. Разумеется, грамотный лид уже внутри приложения выделит интерфейсные классы и предпримет прочие меры обеспечения модульности, а подход «лучше не пересобирать то, что еще работает» жизнь не раз подтверждала. Таким образом, вы можете:

    >>> Заменить блокчейн-базис или DFS, если, например, вы изначально ошиблись в оценке производительности и сориентировались на недостаточно «мощную» блокчейн-платформу. Или для простоты начинали на Ethereum, но решили перейти на более «взрослое» решение. Или вдруг появилась новая убойная блокчейн-платформа (TON!), а вы начали чуток раньше. Или выбранный изначально компонент оказался неработоспособен в условиях конкретной сложной топологии, а вы до этого только в гомогенном облаке. Или… в общем, мало ли что может произойти в период быстрого развития всех компонентов децентрализованных систем, который сейчас имеет место.

    >>> Создавать в качестве блокчейн-базиса сложные комбинированные решения. Например, в одном из исследовательских проектов в качестве базиса использовалось два параллельных блокчейна Ethereum — это давало возможность, с одной стороны, выделить канал для высокоприоритетных неблокируемых операций, оставив пакетные и неспешные в своем канале, а с другой, — просто создавало возможность кратного увеличения пропускной способности.
  • Возможность смены юридически значимой криптографии. В определенной степени это подпункт предыдущего пункта. Но опыт нашего проекта с международной гарантией заставляет вынести его отдельно. И, трактуя этот опыт более широко, при трансграничном применении, особенно во многих юрисдикциях, желательно, чтобы ваша платформа не только могла менять криптографию, но и могла работать одновременно в разных криптографиях с разными участниками. Здесь, безусловно, возникает много интересных и сложных технических и юридических вопросов, например, возможность введения в состав сети доверенных узлов перешифровывания и заверения подписей — будем их решать.
  • Потенциальная возможность стандартизации и межсетевого обмена на уровне состояний процессов. На нынешнем этапе развития корпоративных децентрализованных приложений данный пункт, наверное, из разряда «космических кораблей, бороздящих просторы Вселенной». Но плох тот минометчик, который не умеет кидать мину за холм. Выделение абстрактных объектов и их формализация — неотъемлемый этап процессов стандартизации и обязательное условие широкой интеграции блокчейн-сетей. Очевидно, что одним универсальным бизнес-процессом (или его аналогом) здесь дело не обойдется — сложные связи и процессы физического мира и потребности бизнес-приложений наверняка приведут к введению и других абстрактных объектов со своими наборами свойств и возможностей.

Недостатки использования универсального бизнес-процесса


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

  • Где разводить бизнес-логику — в хранимых процедурах БД или в коде бизнес-приложений?
  • Что лучше — универсальная ЭВМ или спецвычислитель?
  • Вы уверены, что выбранный вами базис сохранит совместимость при последующих жизненных обновлениях? И вообще переживет следующие 2 года?

Ответ достаточно прост, если:

  • У вас куча денег, времени и свободных специалистов по блокчейн-технологиям
  • Вы уверены, что выбранный вами блокчейн-базис не придется менять от слова «никогда»
  • Вам действительно надо «отжать» возможности платформы на 101%

Ну, тогда — спецвычислитель… в смысле Hyperledger Fabric или Corda с зашивкой на чейнкод и прочим «вырубанием долотом в камне». Если нет — думайте сами…

Мониторинг сети узлов


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

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

Исходя из вышесказанного с самого начала разработки нашей платформы в нее была встроена система проактивного мониторинга. Опишем принцип ее действия:

  • В блокчейн-базисе платформы устанавливается специальный смарт-контракт, отвечающий за сбор и распространения данных мониторинга (для краткости будем обозначать этот смарт-контракт как СКМ)
  • В составе узлов сети назначается один, а лучше несколько узлов Центрального мониторинга (ЦМ), ответственных за раздачу по сети «зондирующих посылок», а также сбор и анализ мониторинговой информации, поступающей с других узлов. Этот функционал может быть как основным, так и использоваться в качестве нагрузки к бизнес-функционалу узлов.
  • Для блокчейн-базиса с заданной периодичность узлы ЦМ формируют «зондирующие транзакции», переключающие соответствующий элемент СКМ в новое состояние — это может быть просто метка текущего времени.
  • Для DFS-компоненты аналогичным образом формируется и передается «контрольный файл», ссылка на который также заносится в СКМ.
  • Каждый из узлов сети периодически обращается к СКМ, извлекает контрольные данные и контрольный файл из DFS и проверяет актуальность контрольных меток.
  • Кроме того, каждый из узлов сети передает на СКМ информацию о своем состоянии, включая:
    > контрольную временную метку
    > последнее принятое значение «зондирующей» метки ЦМ по блокчейн-каналу
    > последнее принятое значение «зондирующей» метки ЦМ по каналу DFS
    > номер последнего обработанного блока блокчейн-канала (для Ethereum-семейства или аналогичный показатель)
    > наличие ошибок в очередях операций «Зеркала»
    > наличие задержек в очередях операций «Зеркала» — то есть операций, не завершенных за определенное «контрольное» время
    > число операций в очередях операций «Зеркала»
    > наличие ошибок работы с базой данных со стороны «Зеркала»
    > контрольная информация от бизнес-приложений

При определенном значении или сочетании значений показателей мониторинга «Зеркало» автоматически приостанавливает обработку своих очередей операций, блокирует появление потенциальных нежелательных последствий, например:

  • При критическом отставании контрольной метки блокчейн-канала, что интерпретируется как выпадение узла из блокчейн-сети или полное нарушение ее функционирования
  • При критическом отставании контрольной метки DFS-канала, что интерпретируется как выпадение узла из DFS-сети или полное нарушение ее функционирования
  • При ошибках в очереди операций — блокируются все последующие операции, связанные с этим бизнес-объектом (универсальным бизнес-процессом)

Отдельное внимание было уделено обработке ошибок базы данных, используемой «Зеркалом». Данная БД используется не только как интерфейсная с бизнес-приложениями, но и как статусный стек для конечного автомата очередей операций «Зеркала». Как показал опыт, при наличии специфичных ошибок при изменении данных в таблицах БД может произойти зацикливание операций с массовой повторной отправкой транзакций и прочими удовольствиями. Однажды мы из-за подобной ошибки за два дня «сделали» полугодовой объем цепочки на Quorum. Поэтому при обнаружении ошибки такого рода «Зеркало» полностью выключается и ждет ручного реагирования службы поддержки.

Узлы Центрального мониторинга извлекают из СКМ информацию от всех узлов сети (включая себя, кстати) и анализируют ее, позволяя своевременно обнаружить такие опасные или потенциально опасные состояния как, например:

  • Полное нарушение функционирования блокчейн- или DFS-сети
  • Выпадение отдельных узлов из блокчейн- или DFS-сети
  • Отставание отдельных узлов в обработке данных блокчейн-канала
  • Наличие ошибок в очередях обработки «Зеркала»
  • Наличие зависания операций и чрезмерного роста очередей в «Зеркале»

На картинке ниже — пример простейшего монитора одной из наших тестовых сетей:



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

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

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

Ибо как говорится в одной из трактовок закона Мерфи: «Ошибка обычно кроется в положении, которое ни у кого не вызывает сомнения».

Эволюция использования различных технических компонентов


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

Первым был проект выпуска международной гарантии, в котором нашими партнерами были коллеги из Белоруссии — март-декабрь 2018 года.

Начинали мы с конфигурации Ethereum — Ethereum Swarm — Крипто-Про (DLT-DFS-криптография), хорошо зарекомендовавшей себя в исследовательских проектах. Вместо использовавшейся публичной тестовой PoA-сети Ethereum Rinkeby была поднята приватная сеть Ethereum PoA и приватная сеть Ethereum Swarm. Каких-либо технических проблем изначально не выплыло, но мы столкнулись с «криптографической» неприятностью — один из белорусских участников наотрез отказывался использовать предлагаемые нами средства криптографии, ссылаясь на локальный закон об электронном документообороте. Найти качественное решение «в моменте» тогда не удалось, но появилось устойчивое понимание о непростой и важной роли криптографии в успехе международных проектов.

Уже в процесс прогона контрольных сделок на реальной инфраструктуре сети (каждый участник развернул узел на своих ресурсах) были выявлены сбои в работе Ethereum Swarm — потери файлов составляли на уровне 20%. Было сделано предположение, что потери связанны с проблемами, возникающими в клиенте Swarm при параллельной отправке нескольких файлов. В целом данное предположение подтвердилось: опытным путем удалось подобрать паузу между отправками в Swarm отдельных файлов в 5 секунд. При переходе к совсем боевой конфигурации сети, которая в силу особенностей примененного сетевого сегментирования в инфраструктуре Райффайзенбанка потребовала создания транзитного Swarm-узла, выявилась критическая проблема — Ethereum Swarm допускал при работе через транзитный узел потерю до 30% файлов. «Расслоенная» архитектура и хорошая система мониторинга позволила успешно провести реальный выпуск гарантии в режиме «ручной подкачки бензина», но судьба Ethereum Swarm была предрешена. Надо сказать, что заявленная способность Ethereum Swarm работать в топологиях с отсутствием прямой связи отправитель-получатель была одной из главных причин выбора его в качестве технологической основы DFS, и неспособность его надежно работать в таком режиме создала массу проблем.

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

Следующим проектом стало создание внутригрупповой сети для Группы Компаний Аскона — сентябрь 2018 — текущее время.

С учетом опыта проекта по международной гарантии в качестве технологической основы для DFS была выбрана IPFS (InterPlanetary File System). Она нормально отрабатывала отправку файлов в параллель, и ей не потребовались специальные подстройки режимов. Единственным, пожалуй, слабым местом IPFS является невозможность (оговоренная!) работать в «транзитных» топологиях. При построении сетей с большим числом участников реализация каждым из них «полной звезды» доступов каждого к каждому является, мягко говоря, организационной проблемой. С другой стороны, все участники реализуют доступ между собой и «опорными» узлами оператора. Поэтому для организации беспрепятственной раздачи файлов был реализован следующий механизм:

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

Таким образом, проект Аскона стартовал в конфигурации Ethereum — IPFS — Крипто-Про.

Использование Крипто-Про для шифрования файлов и «внешней» подписи юридически значимых документов обеспечили простоту юридической обвязки, а также отсутствие претензий со стороны подразделений Информационной Безопасности, что в свою очередь крайне положительно сказалось на сроках получения необходимых согласований как со стороны банка, так и со стороны компаний Группы Компаний Аскона. В целом проект развивался в рабочем порядке и пройдя пилотную стадию находился на финишной прямой выхода в прод и тут…

… и тут сразу в двух проектах — условно «чужих», но в которых мы участвовали как эксперты, на аналогичных конфигурациях словили мега-форки размером в тысячи блоков, с потерей транзакций части сети. Анализ логов и толковищ блокчейн-сообщества привел к неутешительному выводу— использование Ethereum PoA (а в некоторых случаях даже и PoW) в компактных сетях с небольшим числом узлов (а корпоративные сети относятся именно сюда) имеет высокий риск появления таких монстров. К тому же в нашей тестовой сети стал периодически показываться загадочный баг, когда узел выпадал из сети и больше не хотел с ней синхронизироваться. Даже после переустановки Ethereum и полной зачистки. Короче, стало ясно, что для прод-сети нужна альтернатива для блокчейн-базиса. И быстро. Очень быстро.

Решением оказался Quorum — практически, родной брат Ethereum. Число доработок в «Зеркале» было минимальным, бизнес-приложение, понятно, доработок вообще не требовало.

На текущий момент переход на Quorum принес только плюсы:

  • Использованный Raft-консенсус исключает форки
  • Отсутствие пустых блоков уменьшает размер цепочки

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

Единственным, пожалуй, неприятным свойством Quorum является возможность генерации при рестарте после длительной паузы мега-блока размером в несколько мегабайт, который просто заклинивает адаптер DLT при попытке разгрести его содержимое. Но, строго говоря, служба поддержки не должна спать настолько долго.

В итоге всей этой драматической эволюции мы пришли к конфигурации Quorum — IPFS — Крипто-ПРО, которую сейчас и используем на внутреннем рынке РФ.

Возможно, кто-то задаст закономерный вопрос: «А что же, раньше вы про Quorum не слышали, что ли?». Слышали — и про Quorum, и при Hyperledger Fabric, и про EOS. Автор данной статьи даже посещал первый воркшоп на русском языке по Corda осенью 2017 года. Наверное, специально для умного ответа на такие вопросы Гегель и придумал свою Диалектику. Начинавшая исследования в 2016 году небольшая команда имела хороший опыт разработки диалоговых приложений под Windows, а публичный Ethereum (тестовый понятно) имел наименьший порог входа из блокчейн-платформ. А так как мы были заинтересованы в проведении исследований именно по блокчейн-тематике, а не в ковырянии разных докеров, без которых запустить «взрослые» Quorum или Hyperledger Fabric просто нереально (да и не на всех виртуальных Windows-платформах возможно), то и выбор был очевиден. По мере того как результаты исследований стали привлекать внимание бизнес-подразделений банка и его партнеров, появилась возможность расширить команду, поручить сапоги — сапожникам, а пироги — пирожникам, разжиться Linux-серверами и так далее. И, естественно, никто не выбрасывал наработанные решения, пока они сохраняли потенциал развития. Диалектика и Эволюция.

Опыт исследования и эксплуатации корпоративных платформ и их дальнейшее развитие


Автор данной статьи принимал участие в достаточно большом числе блокчейн-проектов, проведенных в Райффайзенбанке, в Ассоциации ФинТех и кое-где еще — и в качестве разработчика, и в качестве эксперта по децентрализованным платформам. Часть из них была чисто исследовательскими, часть завершилась пилотами, некоторые доросли до достаточно крупных промышленных сетей в несколько десятков узлов.

Какие же основные выводы можно сделать из всего этого опыта?

1. Существует определенное многообразие блокчейн-платформ, весьма сильно различающихся в своих «потребительских» качествах:

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

Поэтому говорить о том, что какая-то из платформ окажется абсолютно доминирующей, я думаю, нельзя. У каждой есть свой круг потенциальных пользователей и задач, где ее использование наиболее рационально и рентабельно. Это касается и Ethereum, и Quorum, и Hyperledger Fabric, и Corda. Здесь как и с языками программирования — только Вася и Петя, знающие по одному языку будут до одури спорить о том, что лучше — «плюсы» или «жаба». А Семен Петрович и Альберт Иванович, знающие их по десятку, будут мирно рассуждать — когда лучше «плюсы», а когда — «жаба».

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

  • Специализированные децентрализованные файловые системы существуют дольше, лучше отлажены и на текущий момент эффективнее справляются с этой задачей по сравнению с аналогичным функционалом DLT-платформ. Мы проводили оценочные эксперименты. По их результатам при использовании Hyperledger Fabric и Corda файлы размером более 2M имеют высокую вероятность «застрять в канале», в то время, как IPFS без проблем пробрасывает и 100M. А если ваш бизнес-кейс предполагает движение каких-либо неформализованных документов типа pdf (контрактов, договоров и прочее), то 50M — минимум, к которому вам надо готовится.
  • Такой подход позволяет достаточно эффективно физически развести блокчейн-канал и канал передачи файлов, что весьма актуально для систем с высоким смешанным трафиком (транзакции + документы), тем более, что операционный приоритет транзакций обычно более высок.
  • В качестве альтернативы децентрализованным файловым системам неплохо смотрятся облачные файловые хранилища, например, стандарта S3. Они, конечно, несколько подрывают «истинную децентрализованность», но с точки зрения безотказности вполне вписываются в распределенные сети, а по скорости обмена и надежности даже превосходят DFS. Тут возможно появление даже неких гибридных решений.
  • Если смотреть немного вдаль, на возможную интеграцию между собой отдельных корпоративных сетей, особенно построенных на разных блокчейн-базисах, то выделение «файлового» канала потенциально упрощает решение.

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

4. Одной из самых мутных юридических областей является формализация отношений оператора и участников сети, которая усугубляется тем, что оператор, с одной стороны, не является владельцем сети и её ресурсов, а с другой, — обязан обеспечить её функционирование, даже если предпринимаемые им для этого меры входят в противоречие с интересами отдельных участников. Баланс между правами и обязанностями оператора, «средствами влияния» его на участников сети, финансовая ответственность оператора — всё это сейчас является предметом очень непростых споров. Простейший вопрос: как обеспечить синхронную смену критического программного обеспечения всеми участниками сети при кажущейся простоте выливается в весьма горячие дискуссии? Появление образцов юридической формализации положения оператора и участников сети на опыте уже вышедших в прод платформ значительно ускорит внедрение децентрализованных сетей как значимого элемента корпоративных и межкорпоративных отношений.

Если вы дошли до конца, есть ещё бонус: некоторые из вопросов о текущем состоянии и путях развития децентрализованных корпоративных платформ нашли свое отражение в материале, подготовленном автором данной статьи для одного из блокчейн-ресурсов (материал рассчитан на широкий круг читателей).
Райффайзенбанк
Развеиваем мифы об IT в банках

Похожие публикации

Комментарии 11

    –1
    Да дела у вас в полной…
    Думаю из -99.7% проекты уже не выбираются
    image
      +1

      Это не тот RChain. У нас нет токенов.

        +2
        Спасибо за подробный и очень интересный материал!
        У меня такой вопрос: почему для Quorum был выбран Raft, а не другой консенсус — IBFT, который также есть в Quorum.
        Поясню свой вопрос, Raft в «классическом» изложении защищает только от падения узла, который формирует «блоки», если такой узел падает, то роль передаётся другому. При этом по составу блока отдельного раунда голосования не проводится, поэтому «лидер» потенциально может рассылать некорректную информацию разным узлам. И в рафте отдельные участники консенсуса могут саботировать работу сети через механизм назначения нового лидера. Как планируется решать эти 2 проблемы?

        Я уверен, что Raft работает быстрее, из-за отсутствия дополнительных раундов голосования. На сколько порядков производительнее чем PoA, PoW?
          +1

          Спасибо за интересный вопрос.


          1. Raft обеспечивает отсутствие точки отказа в сети (что для корп-сети является одним из важднейших преимуществ децентрализации) при максимальной простоте и, следовательно, надежности механизма консенсуса.
          2. Так как подделать подпись транзакции лидер не может, а ролевая авторизация на смартах связана с аккаунтом отправителя, то максимально, что он может — не рассылать какую-то информацию. Так как все "макрооперации" на "зеркале" обязательно содержат верификацию результата исполнения после отправки транзакции, а блоки имеют сквозную связь, то с выборочной рассылкой незаметно не получится.
          3. По той же причине — верификации плюс наличия централизованного "зондирующего" мониторинга факт нарушения работы сети из-за саботажа будет быстро выявлен, а виновный — наказан (т.к. это всё-таки корп-сеть)
          4. Безусловно, даже располагая только возможностью временно саботировать работу сети, возможно проведение результативных атак для определенных видов сделок (например, для сделок, чувствительных ко времени). Поэтому при выборе используемого в сети механизма консенсуса необходимо учитывать подобные риски — то, что для платежного сервиса не играет существенного значения (как в нашем конкретном случае), для брокерского может оказаться весьма критическим.

          К сожалению, конкретную причину, по которой нами для Асконы был выбран именно Raft, а не IBFT, я, честно говоря, уже точно не помню, но мне кажется, что основой для него послужила беседа с одним из блокчейн-экспертов на тему мега-форков, в которой он упомянул, что была информация о возможности схожих с Clique проблемах в реализованной на тот момент в Quorum версии IBFT. Учитывая ситуацию, мы просто решили не рисковать.
          Собственно, каких-либо объективных причин совсем отказываться от IBFT я не вижу — надо просто его как следует погонять в реальной инфраструктуре, что мы вполне можем провести в рамках Ассоциации Финтех :-)


          Относительно быстродействия Raft- и IBFT-сетей каких-либо специальных исследований мы не проводили, так как ни разу не упирались в техническую производительность собственно Quorum и объективной надобности в этом не было.

          +2
          MadJackal,
          Давно читаю о решениях Райффайзенбанка. Сэкономили массу времени, благодарю.
          Решил задать вопрос здесь, т.к. ответ может быть полезен др. читателям:
          — что посоветуете в начале проектирования Blockchain решения, чтоб с одной стороны прототип не оброс на взлете лишним балластом, затрудняющим маневры, а с другой — не упустить важные детали, без которых возможно придется пересматривать решение?

          Краткий контекст:
          Команда MISMO (банковские стандарты США).
          Разрабатываем прототип Blockchain для банковского кредитования США.
          Задача — протестировать полезность, определить проблемы, привлечь пилотов, совместно сформировать рекомендации и стандарты.

          На первых порах отказались от технических деталей, типа выбора Blockchain платформы, consensus algorithm, а сконцентрировались на прикладном функционале:
          — выявление банковских процессов, которые выигрывают от imutable ledger of mortgage transactions.
          — выявление функционала, который открывает доп. возможности. Типа smart contracts для запуска regulatory compliance проверок, или запуск обязательных процессов в рамках BPMN индустрии.
          — симуляция управления хостами (регистрация, симуляция отказов), симуляция транзакций и т.п. рабочие процессы в рамках прикладной задачи.

          Буду благодарен за любые советы «что делать и не делать» при создании и тестировании прототипа Blockchain решения.
          Надеюсь, похожие задачи встречаются не только у меня и ответы будут полезны многим.
            0
            Не претендую на роль «советчика», но вам стоит уделить немного времени и изучить блокчейн платформы, чтобы понять их свойства и особенности. Чтобы уже с этой информацией формировать своё ценностное предложение, т.к. «блокчейн платформа» подразумевает иную модель взаимодействия и у каждой платформы она своя, что может повлиять на ФТТ бизнес приложения.
              0

              У вас очень интересный случай, быстро и коротко ответить на него проблематично, но если брать общую канву, то я бы рекомендовал следующее.
              Первый вопрос который надо решить в таких проектах — кто будет владельцем узлов и почему они захотят ими быть. Именно про него многие забывают, а потом не могут ответить на вопрос — а зачем оно всё вообще?
              Второе — это безусловно выделение бизнес-процессов и выявление "точек конкуренции" — мест связанных с гонкой приоритетов, чувствительных к времени и так далее. Эти точки затем должны особенно внимательно анализироваться на предмет безопасной и надежной реализации в смарт-контрактах.
              Третье — выделение абстрактных объектов/процессов для максимальной унификации работы с ними. Скажем, кроме нашего Процесса могут потребоваться другие абстракции, например для построения сложных связей и так далее.
              Четвертое — выявление специальных общих сервисов, которые могут быть полезны всем участникам — они могут быть оформлены в виде оракулов и, кстати, могут представлять одну из "плюшек" для участников.
              Пятое — максимально быстро выйти на реальную инфраструктуру и хотя бы простейший, но реальный процесс. Как показывает опыт, картинка мира в голове разработчика и в реальности всегда расходятся и необходимо максимально быстро привести "голову" к реальности. Иначе многие сложные построения окажутся бесполезны из-за ошибки в базисе, иногда просто "технической".


              Я попрошу поделится своим мнением Марину gelbplaneten, с которой мы вместе поднимали блокчейн в Райфе и которая сейчас активно участвует в крупнейшем российском межкорпоративном блокчейн-проекте Факторин, и, насколько мне известо, в организации международного проекта по "демократизации" блокчейн-решений. Многие эти вопросы она проходила на практике и весьма успешно.


              P.S. И я был бы не против получать новости с вашего проекта :-)

                0
                Благодарю за ответ.

                По рекомендациям:

                1. Мы определились (MBA — Mortgage Bankers Association, если интересно)

                2.а. «выделение бизнес-процессов» — работаем.
                За основу взят «Processes of Loan Lifecycle» (продукт другой группы MISMO, порядка 300 этапов) и анализ каждого процесса жизненного цикла кредита на получение преимуществ от blockchain.

                2.б. выявление «точек конкуренции» — слабое понимание, боюсь мы протабанили.
                Уточните пож., если не сложно, что означает этот термин. Гугл особо не помог.

                3. над абстрактными объектами/процессами еще не работали и не размышляли.
                Можно ли предположить что объекты/процессы проявятся в процессе прототипирования?

                4. есть ли связь «специальных общих сервисов» с №№ 2.а и 3, или это что-то иное?

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

                Еще раз благодарю за советы.

                P.S. И я был бы не против получать новости с вашего проекта :-)
                Прототип в открытом доступе, но процессы у нас движутся крайне медленно. :)
                Страничка с прототипом и обвязкой в этой секции меню:
                image
                +1
                Василий, хороший вопрос)
                Одна из главных ошибок стартапов — потратить время на освоение нескольких блокчейнов и выбор лучшего. Мой совет: если нужен POC и понятен кейс для тестирования, лучше сделать MVP в «песочнице» с готовой блокчейн-инфраструктурой.
                — За относительно небольшие деньги: QuickNode , Settlemint
                — Бесплатно, с поддержкой Ethereum, Quorum и Hyperledger Fabric: Kekker.

                Любой блокчейн будет иметь порог вхождения, а его преодоление отнимет время от разработки бизнес-приложения.
                Самые распространенные проблемы:
                — На первых этапах — не так просто развернуть сеть даже из трех узлов и поддерживать ее живой дольше одного рабочего дня. Нужен мониторинг, как правильно писал Павел. А потом — разбор проблемы.
                — Кратное усложнение обновлений: количество установок примерно равно числу узлов в сети.
                — Даже у зрелых технологий (Ethereum, Quorum, Hyperledger Fabric и пр.) встречаются ошибки, полезной информации по решению которых нет. Сейчас стало чуть легче, официальная документация заметно пополнилась. Но иногда единственным решением остается пересоздание узла.

                По опыту — 20% времени POC займет бизнес-логика и 80% — написание своего мониторинга, логики отработки ошибок и пр.

                Желаю вам удачи, держите в курсе!
                +1
                Спасибо за материал! Будем надеяться, что Райффайзенбанк продолжит делиться своим опытом внедрения блокчейн. Подскажите, а в какой конфигурации используется IPFS? Если файлы нарезаются на куски, нет ли каких-то юридических особенностей (например, филиал 1 хранит банковскую тайну филиала 2)?
                  +1

                  В данном случае это не имеет значения, так как по сути IPFS используется не как децентрализованное ХРАНИЛИЩЕ ФАЙЛОВ, а как средство децентрализованного ОБМЕНА ШИФРО-КОНТЕЙНЕРАМИ. То есть:


                  1. В самом IPFS файлы присутствуют только в зашифрованном виде.
                  2. Механизм "зеркал" работает таким образом, что как только на одном из узлов к сделке прикрепили файл (который выкладывается в IPFS в виде шифро-контейнера), узлы других участников сделки узнают об этом, выкачивают шифро-контейнер из IPFS, расшифровывают его и сохраняют на своем локале в защищенной зоне. Таким образом, когда бизнес-приложение захочет обратится к файлу — он уже находится в локальном доступе.
                  3. Так как шифро-контейнеры создаются на сертификаты участников сделки, то другие участники сети даже получив их из IPFS не смогут их расшифровать
                  4. Так как процесс "раздачи" файлов достаточно кратковременный — даже для больших файлов он не превышает десятков минут от момента формирования шифро-контейнера на узле-источнике до его расшифровывания на узлах-приемниках, то отсутствует проблема с истечением срока действия сертификатов, используемых для формирования шифро-контейнера.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое