От теории к практике: как применяется блокчейн в авиации

    Гражданская авиация — глобальная индустрия, в которой непрерывно происходит синхронизация и обработка огромных массивов данных. В середине 20 века системы бронирования авиабилетов были одними из первых примеров применения компьютерных комплексов и сетей передачи данных. Давайте посмотрим, как сегодня технологии блокчейн могут помочь быстрее и эффективнее решить простую, на первый взгляд, задачу: перевести пассажира из точки «А» в точку «В»?



    Дано


    Большое число организаций – участниц процесса


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

    Усложним задачу


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


    • Данные о времени прибытия борта, назначенное место стоянки воздушного судна;
    • Информацию о проданном билете;
    • Реестр зарегистрированных на рейс пассажиров;
    • Данные о наличии необходимых виз и прохождении паспортного и таможенного контроля;
    • Данные об оказанных услугах в аэропорту, включая питание и топливное обслуживание — объемы услуг и точное время оказания услуг;
    • Информацию о проведении технических контрольных и ремонтных мероприятиях;
    • Информацию о прохождении предполетного контроля экипажа и многое другое.

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


    Обмен данными


    Печатные документы vs Excel vs API vs …?


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


    Экспорт / импорт файлов


    различных форматов (CSV, XML, Excel..)


    Платформы


    В сфере гражданской авиации работают глобальные платформы для взаимодействия организаций в процессе авиаперевозок:


    • BSP (Billing and Settlement Plan);
    • GDS (Global Distribution System);
    • PSS (Passenger Service System).

    О них мы писали в нашей предыдущей статье. Платформы работают как сервис и поддерживаются такими ассоциациями и компаниями как IATA, SITA, Amadeus и др. Все текущие платформы централизованы: есть организация, предоставляющая сервис, все программное обеспечение, серверные мощности находятся под ее управлением. С точки зрения разработки и поддержки систем, обеспечение уровня сервиса — это удобно, однако есть и свои минусы:


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

    API


    Использование API позволяет организовать непосредственное взаимодействие между контрагентами. Одним из стандартов API является NDC (New Distribution Capabilities), предназначенный для прямой продажи билетов и дополнительных услуг. В то же время при взаимодействии с контрагентами при наземном обслуживании подобных стандартов еще нет, фрагментарная реализация сервисов интеграции данных не основывается на общепринятых стандартах.


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


    Блокчейн ?


    Мы имеем:


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

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


    Единая версия данных для множества участников


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


    Основная ценность технологии распределенного реестра основывается на двух ключевых элементах.


    • проверенное происхождение данных (хотя блокчейн НЕ гарантирует достоверность данных, но действительно дает понять, кто какие данные поместил в реестр и когда);
    • контролируемые процессы – все участники могут видеть и понимать, как данные проходят через заранее согласованный, запрограммированный процесс.

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


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


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


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

    Доступ к данным из внешней среды дает возможность автоматизировать выполнение условий сделки, алгоритмов расчета стоимости услуг.


    Выглядит неплохо, как это реализовать ?


    v1.0: Ethereum


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


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


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


    Первая версия блокчейн-платформы была реализована на базе протокола Ethereum, с использованием консенсуса Proof-Of-Authority, в котором на уровне системных смарт-контрактов определялся круг организаций – валидаторов, а также модель доступа. Для этого использовались возможности клиента Parity.


    Архитектура предусматривала развертывание под определенный процесс отдельной сети. Основные роли участников:


    • Организация-участник определенного процесса (например, при продаже билетов, это агент или авиакомпания)
    • Банк, обеспечивающий платежи, инициируемые транзакцией, размещенной в блокчейн.


    On-chain компоненты первой версии платформы (смарт-контракты) были реализованы на Solidity с применением техник обновления смарт контрактов, что в смарт-контрактах на базе EVM (Ethereum Virtual Machine) создает ряд затруднений в разработке и поддержке. Off-chain компоненты были реализованы главным образом на JavaScript / Node.JS, так как наиболее стабильные библиотеки (web3.js, truffle и другие) реализованы именно на этом стеке.


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


    • Транзакции не являются финальными, принимаются простым большинством голосов узлов – валидаторов;
    • Единый реестр операций, доступный всем участникам. Решения на базе Quorum и других расширенных реализаций клиентов Ethereum с поддержкой приватных транзакций в 2017 году были еще нестабильны;
    • Solidity, как язык разработки, имел значительные ограничения на реализуемую логику. Реализовать сложную логику было проблематично: например, при достижении определенного количества используемых переменных в смарт-контракте компилятор выдавал ошибку stack too deep и дальнейшее расширении логики смарт контракта приходилось проводить со значительными технологическими ухищрениями.

    v2.0: Hyperledger Fabric


    Во второй половине 2017 года вышла стабильная версия фреймворка Hyperledger Fabric 1.0 с такими возможностями как:


    • Двухфазный коммит;
    • Изоляция данных на основе каналов;
    • Идентификация на базе PKI;
    • Гибкая модель конфигурирования участников сети (Membership Service Provider);
    • Продвинутая система настройки разрешений на операции (policies);
    • Единая кодовая база на Go.

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


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


    • Отсутствие best practices при разработке и тестировании блокчейн приложений;
    • Отсутствие простого и стабильного SDK на Go;
    • Отсутствие практик поддержания уровня сервиса сети (конфигурация сети, мониторинг узлов, решение нештатных ситуаций и пр.)
    • Сложное изменение конфигурации участников сети.

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


    • Средства развертывания компонент сети в K8S, либо на любых виртуальных серверах / облачных сервисах;
    • Децентрализованное управление сетью и доступом к сети;
    • Средства мониторинга и поддержания уровня обслуживания;
    • Компоненты разработки смарт-контрактов и off-chain приложений, включая шифрование данных;
    • Средства анализа данных в сети (explorer), учитывающие мета-описания модели данных чейнкодов;
    • Шлюзы к банкам для проведения платежных операций.

    Open source


    Часть наших разработок мы выложили в open source:


    cckit


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



    Помимо этого, реализованы следующие возможности:


    • Маршрутизация (routing) обращений к функциям;
    • Функции промежуточной обработки (middleware);
    • Object-state mapping;
    • Расширенная реализация MockStub.

    hlf-sdk-go


    собственный упрощённый SDK:


    • Простые и понятные компоненты;
    • Подключаемые discovery provider и crypto suite;
    • Встроенные GRPC-метрики;
    • Балансировка вызовов GRPC на базе go-grpc;
    • Отдельный пакет для работы с Fabric CA;
    • Трейсинг операций на основе OpenTracing (Jaeger).

    Текущие проекты


    С использованием данного инструментария разработано уже несколько проектов:


    Система взаимодействия между авиакомпаниями и поставщиками топлива


    На основании цифрового смарт-контракта в системе AFSC (Aviation fuel smart contracts) S7 Airlines и поставщик топлива согласовывают предварительный объем топлива и его цену. Эти данные используются для назначения технического задания водителю топливозаправщика в аэропорту. После того как командир воздушного судна запросит у оператора точный объем топлива, необходимый для выполнения рейса, в банк авиакомпании направляется онлайн-заявка для резервирования соответствующей суммы на счете. Моментальное подтверждение из банка дает старт заправке.


    Новая версия платформы взаимодействия с прямыми агентами S7


    которая находится в промышленной эксплуатации (обороты уже превысили 300 млн руб. в месяц). Аналогичная система внедряется также для сторонней крупной транспортной компании.


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


    Трансформация индустрии


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


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


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


    Ценность для бизнеса


    По оценке Building Value with Blockchain Technology: How to Evaluate Blockchain’s
    Benefits
    от Международного экономического форума, индустрия гражданской авиации и сферы путешествий в целом в наибольшей степени могут получить преимущества в части автоматизации взаимодействия с использованием смарт-контрактов, единой версии данных для всех участников процесса и возможностей создавать новые типы продуктов и сервисов. В первую очередь, за счет модернизации технологий, обслуживающих информационные потоки между партнерами.


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


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


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


    Подводные камни


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


    С точки зрения бизнеса:


    • Идентификация процесса взаимодействия контрагентов, при которой действительно требуется децентрализованность. Проработка структуры информационного взаимодействия, условия доступности данных;
    • Корректная оценка влияния изменения парадигмы взаимодействия с контрагентами и стоимости внедрения;
    • Организация работы в консорциуме контрагентов, в том числе прямых конкурентов.

    С точки зрения технологий:


    • Отсутствие в настоящее время «идеальных» алгоритмов работы распределенной сети, сочетающих в себе безопасность, масштабируемость и децентрализацию (выберите 2 из 3);
    • Отсутствие стандартизированных подходов к разработке смарт-контрактов и юридических практик;
    • Отсутствие лучших практик при создании подобных систем.

    Главное, что минусы – это не препятствия, а зоны роста. Тем интереснее будущее, нам есть над чем работать.

    S7 Airlines
    Компания

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

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

      0

      А что в проекте поменялось за последний год-два?
      Давно за ним смотрю и есть некоторое впечатление, что он не развивается.

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

          То есть "стало больше транзакций".

            +1
            + много нового в части реализации платформы, некоторые детали есть выше в статье
              0

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

        0

        Спасибо за информацию!


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


        Exonum не смотрели?

          0
          Exonum смотрели, есть свои преимущества, появляются примеры внедрения. Однако на текущий момент экосистема проектов / знакомство с технологиями Hyperledger Fabric гораздо шире, что имеет значение при взаимодействии с контрагентами в процессе создания распределенных систем.
          0
          Блокчейн — это как хер размером в пятьдесят сантиметров.
          С одной стороны предмет для гордости, а с другой вынуждает постоянно с ним носиться в надежде куда-нибудь приткнуть. Да только кто же в здравом уме на такое согласится?
          А вот с авиацией повезло…

            +1
            Можно раскрыть подробнее, почему конкретно это нельзя было реализовать через АПИ, и надо было заниматься блокчейнами, да еще принуждать к тому же своих поставщиков?
            Особенно, интересно послушать про то, как внедрение АПИ ведет к «усложнению информационного ландшафта организаций» по сравнению с блокчейном?
              0
              Если использовать API при многостороннем взаимодействии — нужно либо делать множество интеграций 1:1, либо использовать доверенную сторону, которая будет хранить и обрабатывать данные (сейчас в большинстве случаев так и происходит). Соответственно значительное количество интеграций и усложняют информационный ландшафт. Блокчейн / DLT — возможность создать распределенную БД без использования посредника.

              Никто никого не принуждает — модели сетей обмена данными на базе блокчейн / DLT прорабатываются с целью выработки схемы взаимодействия, позволяющие всем участвующим сторонам получить для себя определенные выгоды по сравнению с другими решениями. Это непросто, о чем и написано в завершении статьи.
                +1
                Так. И в вашем случае все участники равны, и это похоже на биткоин, где большинство решает, кто прав, а кто нет? Или все же у вас отношения между заказчиком и поставщиками (как в примере с поставщиками топлива)? Что, если все поставщики керосина решат, что вы им много должны, то так оно и есть, потому что их больше?
                Т.е. я понимаю, для чего это делается во в биткоине. Но в данном случае можно четко сказать, кто конкретно должен владеть информацией, кто выступает арбитром, и таким образом централизация является очевидным выбором.
                Далее, я все же не вижу, каким образом АПИ усложнит ландшафт. Количество взаимодействий (интеграций) определяется вашими бизнес процессами. А делать их через АПИ или через распределенную БД на основе блокчейна — это уже детали конкретного решения. И выгода от использования блокчейна вместо централизованного ресурса (под который на порядок проще все разрабатывать и поддерживать) мне, мягко говоря, не очевидна. Зато вот проблем я на вскидку вижу много. Начать можно с необходимости внедрения всеми участниками блокчейна, просто потому что им надо поставлять вам что-то. Для упрощения этого дела, вы предоставляете SDK. Но это все же какой-то кастомный продукт, в котором шарят только те, неслабые умы, которые его разработали. Вы рассчитываете на достаточный уровень компетенции у всех участников. Это — жестко. Понятно, что S7 может позволить себе айти отдел определенного уровня для подобных дел. Но поставщики? Вангую: дайте им простой и понятный рестфул апи вместо этого наворота — и они будут прыгать от радости. Далее, вопросы инкапсуляции внутренних процессов. Вы делаете все через контракты в чейне — отлично. Вам нужно поменять внутренний процесс не затрагивая остальных участников. АПИ предоставляет эту возможность сразу. В случае же с чейном, вы должны залить ваш контракт в распределенную среду и потом молиться, чтобы это не поломало где-то что-то у кого-то. Проблема версионности. Как решается вопрос, когда у вас разные версии контрактов для разных поставщиков (вот одни внедрили новую версию вашего SDK, а у других цикл побольше)?
                Вообще, в индустрии, как вы очень правильно заметили, есть NDC. S7, если не ошибаюсь, были среди пионеров внедрения. Можно ли сказать, что ваше решение использовать блокчейн было результатом практического опыта по внедрению NDС? Или все же гланым было то, что «при взаимодействии с контрагентами при наземном обслуживании подобных стандартов еще нет»?
                  0

                  Часть вопросов верная. Часть не очень.


                  Вангую: дайте им простой и понятный рестфул апи вместо этого наворота — и они будут прыгать от радости

                  Вот это например. Как я себе вижу — такая АПИха будет достаточно сложной, она из коробки не позволяет проверить идентичность ТОЙ стороны (хотя с наворотами это можно сделать), она не гарантирует доставки сообщения (т.е. мы запулили что-то — а отдельно нужно еще наворачивать логику проверки, что нас запрос обработан или делать идемпотетное АПИ, что не всегда возможно). Здесь же — блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных, единой версии правды. С контролируемым и верифицируемым доступом для агентов.
                  Дополнительно — я больше вижу проблему в том, что блокчейне есть очень много технических аспектов, которые нужно продумать. Насколько равноправны будут участники сети? Что делать, если участник сети скомпрометирован или у него вышел из строя узел? Какова скорость нарастания блокчейна. Понятно, что если он "весит" 1 ТБ, то первоначальная синхронизация = боль. И т.д. Вот очень интересно как это все решено, без маркетинговой шелухи.


                  /с S7 не связан/

                    +1
                    Что значит не позволит проверить идентичность? Есть проверка SSL сертификата. Можно более подробно про сценарий, который вы считаете проблемным?
                    Насчет гарантирует доставку сообщений и т.д. Во-первых, это стандартная задача для архитектур на апи. Есть проверенные годами решения для кучи сценариев и ответы на большинство ваших вопросов уже давно даны. Опять же, не настаиваю на REST. Есть желание все делать через эвенты, gRPC и протобуф — пожалуйста, это не принципиально. Но блокчейн здесь как собаке пятая нога, IMHO.
                    Теперь, вот это утверждение: «блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных» хоть чем-то подкреплено? Какой-то малоизвестный в узких кругах фреймворк недавно зарелизили и он надежнее проверенных годами продуктов? Вот секюрити аудит этого фреймворка проводился кем-то? Какой-то наработанный годами опыт применения?
                    Я могу сразу сказать, что секюрити аудит блокчейна и контрактов в нем — это качественно более сложная и дорогая задача, чем проаудитить и запинтестить апи.
                    Опять же, обращаю внимание, это ведь по сути внутренняя закрытая система одной организации. Там нет десятков разных авиакомпаний. S7 просто поставила перед фактом своих поставщиков ну и договорилась с альфой. Что мешало им просто согласовать АПИ и соответствующим образом его оформить? Это было бы на порядки проще, быстрее и дешевле. Ведь по сути, они всем раздали тот же самый стандартизированный апи, просто под ним прячется еще один уровень на протобуфе, а в глубине, все работает на каком-то блокчейновском фреймворке, который, думаю, понимают только несколько самых продвинутых людей в айти команде S7.
                      0
                      Что значит не позволит проверить идентичность? Есть проверка SSL сертификата. Можно более подробно про сценарий, который вы считаете проблемным?

                      Что Вы под этим понимаете? Настраивать свой УЦ? Или доверять let's encrypt? Вангую, что первое в hyperledger уже внутри есть, а доверять в финансовых вопросах сертификатам, которые получены от внешних УЦ… Такое себе.


                      Теперь, вот это утверждение: «блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных» хоть чем-то подкреплено?

                      Логика. А Ваших сообщениях ничего, кроме негатива в духе "блокчейн не нужен" или "блокчейн — сырая технология", я не вижу. Абстрагируйтесь вообще от этого слова. Оно вызывает негативные ассоциации с криптовалютами и их пузырем. Просто представьте что это по сути распределённая база данных append only (это ключевое!!!) типа с возможностью выполнения поверх нее определенных скриптов. Все. И сразу вся шелуха спадает. Нет никакого вау эффекта.

                        0
                        Гхм. Я даже затрудняюсь комментировать мысли насчет сертификатов, потому что не понятно, что конкретно не устраивает. Вы можете использовать тот УЦ, который подходит для вашей задачи. Вплоть до использования законодательно предписанных УЦ, криптографических алгоритмов и сертифицированного софта.
                        Конкретно у S7 уже есть вся необходимая инфраструктура и процедуры, которые они используют для своего агентского АПИ.
                        Насчет абстрагироваться от блокчейна в данном случае вообще не понятно. Распределенная БД? А зачем S7 «распределять» свою БД? Это сразу серьезнейшим образом усложняет решение и создает просто массу проблем на пустом месте.
                        Короче говоря, возвращаясь к статье, хочется сказать автору следующее.
                        Без более развернутой информации о том, какую проблему вы пытаетесь решить, какие варианты рассматривались, почему выбрали именно этот, совершенно не понятно, зачем блокчейн вообще нужен в вашей архитектуре.

                        В статье по этому поводу лишь два утверждения о том что использование АПИ ведет к
                        1. "централизации сервисов, через которые идет взаимодействие". И что? Это плохо? Чем? (не вообще, а в рамках конкретной задачи).
                        2. "к росту количества и типов интеграций и усложнению информационного ландшафта организаций". Причем, под этим понимается сложность АПИ. В замен предлагается перенести ту же самую «сложность» в блокчейн и завести там множество контрактов для поддержки тех же сценариев. Кроме того, АПИ все же придется создать, причем на двух уровнях. Не понятно.
                          0

                          Ну, кхм, смотрите. Давайте возьмем более простые примеры.


                          1. Сам по себе блокчейн не будет выполняться везде. Очевидно, что будут какие-то клиентские АПИ, через которые с ним будут взаимодействовать конкретные клиенты. Например, вряд ли конкретному продавцу билетов нужно разворачивать полноценную ноду — он вполне может ходить через API в ноду авиакомпании и там будет происходить магия. А вот банку — да, нужна нода.
                          2. Я думаю, что вне сомнения, что наличие копии блокчейна у каждого участника сети дает возможность проверить всю цепочку операций. Это организационный вопрос, не технический, вопрос доверия. Потому что доверие у нас везде не абсолютное. И, условно, потребляя чей-то API — ты полностью доверяешь этому контрагенту, его наполнение для тебя является черным ящиком. Сегодня оно одно, а завтра оно другое. Конечно, можно изобрести нечто подобное на коленках… но зачем?
                          3. Вот предположим как сейчас. Есть банк-клиент, есть агент. Агенту нужно сделать вручную перевод через банк-клиент. Это медленно и полуавтоматизированно. Либо у него должна быть какая-то специфическая интеграция с софтом для покупки/продажи билетов с банк-клиентом. Или вообще нужно заводить свой виртуальный счет со своими виртуальными деньгами (как во многих интернет-магазинах) — ну, вообще дичь, надо же морозить свои деньги, потом пополнять счет. Сам по себе блокчейн это все не решает. Это действительно так, но он может стать платформой, которая под конкретную задачу предоставляет как бы единую точку входа. Он позволяет сделать шаг к автоматизации этих процессов (в частности, когда участником будет банк). А может быть вообще поверх одной сети реализовано несколько разных задач из разных сфер с разными наборами агентов.
                          4. Блокчейн прекрасно решает задачи вроде акцуионов, или когда требуется подтверждение некоей операции от двух и более сторон. Сколько придется напилить интеграций и API, чтобы реализовать это в "классическом" подходе? Но это все к п.2

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

                            0
                            Агенту нужно сделать вручную перевод через банк-клиент. Это медленно и полуавтоматизированно.
                            Ну, я не могу с этим согласиться. У банка есть АПИ. И переводы в банке через этот апи осуществляются если не мгновенно, то уж во всяком случае, быстрее чем через блокчейн в том же банке.
                            Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае. Множество ролей не значит автоматически множества сценариев где требуется такое подтверждение. Я так полагаю, для каждого процесса в их бизнесе уже четко определен владелец. И он будет вести процесс через транзакции и отвечать за прохождение.
                              0
                              Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае.

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


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

                                0
                                Так это стандартная вообще ситуация. При чем тут БД, если линия разграничения — АПИ? Просто все важные транзакции подписываются. При каких-то вопросах, всегда можно поднять подписанный запрос или подтверждение о получении.
                                  0

                                  Эм… И получается черный ящик для потребителя АПИ?
                                  Касательно ключей — да, вариант с подписями возможен, но они они должны быть сгенерированы 3-й стороной, которой доверяют и поставщик API, и потребитель. Но опять же подписи (в частности клиент-серверных решений) не гарантируют того, что запись вдруг не исчезнет из базы. Блокчейн — гарантирует (в определенных рамках).

                    +1
                    И выгода от использования блокчейна вместо централизованного ресурса (под который на порядок проще все разрабатывать и поддерживать)

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


                    проблемы обновления логики смарт-контрактов, версионности — они безусловно есть, над этим ведется работа ( в распределенных сетях используется термин governance)


                    NDC — проработанный стандарт API для поиска / продажи билетов, взаимодействие 1:1 агент — авиакомпания. При использовании NDC остается вопрос со стоком и финансовыми гарантиями, вариант решения которого мы сейчас прорабатываем.


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

                      +1
                      Понимаете, когда весь процесс не раскрыт, на общих словах трудно представить. Вот взять схему с топливозаправщиками. Этот процесс начинается у вас, где-то в системе через которую ваш персонал запрашивает заправку. Дальше, есть поставщик. У него, наверное, есть апи, куда ваша система посылает запрос, а он отвечает ценой (упрощенно). Потом, вы подтверждаете заявку — он подтверждает выполнение. Еще есть банк. У которого свой апи. От банка вам нужно две функции: зарезервировать деньги и осуществить перевод. Вот собственно и все. И зачем здесь блокчейн, можно пожалуйста объяснить?
                        0

                        Согласен, думаю, чтобы принять и осознать схему, нужно получить ее детализированное описание. Это снимет многие вопросы. vitiko такое возможно?

                          +1

                          детализированное описание — возможно, тема для отдельной статьи

                          +1

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


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

                            0
                            А для кого нужна эта «единая информационная картина»?
                            Банку вряд ли интересно знать детали процесса заправки. Более того, ему и не нужно этого знать, чтобы обеспечить гибкость изменения процессов, которые банк непосредственно не касаются. То же и с заправщиком. А у s7 и так все есть, потому что там происходит оркестрация, и точно известно сколько запросили топлива, во сколько подтвердили, когда оплатили и т.д.
                            Кроме того, вы же сами пишите, что стоит задача четко ограничить доступ к данным. Так не лучший ли способ это сделать, скрыв внутренние детали за API и именно на этом рубеже контролировать, какие данные отдаются и кому? Если использовать предложенную выше аналогию с распределенной ДБ, то как раз к блокчейну больше вопросов по доступу к данным.
                              +1

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


                              провести оркестрацию вызовов API ( и создать все необходимые API) будет не проще чем сделать систему на DLT / смарт контрактах. Для ограничения доступа к данным в HLF есть несколько решений — каналы, приватные коллекции, шифрование данных, которые позволяют создавать модели с необходимыми разграничениями.

                                +1
                                Я кажется начинаю понимать логику. Вы ходите контролировать не только свои процессы, но, и внутренние процессы ваших поставщиков, т.е., условно говоря, как ваши топливозаправщики взаимодействуют с банком (протокол этого взаимодействия, используемый софт, банк). А для достижения цели, вы вводите единую среду, которая позволяет вам все это видеть. В принципе, преимущества понятны — это преимущества плановой организации.
                                По сути, вы вводите ту же самую централизацию управления и мониторинга процессов, только в качестве среды хранения и исполнения используется блокчейн. На самом деле, ничего нового. В СССР в таком случае все транзакции проходили бы в одном «министерском» ВЦ, четко по единым процедурам, нормативам и т.п.
                                Проблема в том, что в условиях рынка, такая система не слишком хорошо работает. Я участвовал в подобных проектах, и могу по опыту сказать результаты.
                                Итак, вы предпишете как ваши подрядчики должны организовать свою работу, завязав все в единый процесс детально описанный в виде смарт контрактов.
                                В результате, получится следующее:
                                1. Вы потеряете гибкость в выборе поставщиков из-за высоких требований по вхождению. Т.е. грубо говоря, если в случае с АПИ, новому поставщику для взаимодействия с вами необходимо будет внедрить лишь ваш АПИ, без изменения внутренних процессов и процессов взаимодействия с их банком, поставщиками и т.д., то при вашем подходе, им придется полностью переделывать взаимодействие с банком, с водителями и т.д.
                                2. Навязывание одинаковых процессов всем поставщикам. А у каждого могут быть свои особенности, ну, вот связанные с регионом, например. И т.о. единые процессы могут быть неоптимальны. В случае с АПИ вы вообще эти проблемы не чувствуете — каждый региональный поставщик организует работу наиболее оптимально для своих условий.

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

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

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


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


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

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

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