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

Привет тем, кто следит за развитием применения децентрализованных платформ в корпоративных и межкорпоративных процессах. Наши публикации на эту тему прервались в начале 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 циклов генерации блоков. Это, в

© Habrahabr.ru