Комментарии 29
А что в проекте поменялось за последний год-два?
Давно за ним смотрю и есть некоторое впечатление, что он не развивается.
Спасибо за информацию!
Интересуюсь направлением распределенных реестров, и реальные бизнес кейсы очень ценны, для понимания применимости технологии. Вы открыли новую грань)
Exonum не смотрели?
С одной стороны предмет для гордости, а с другой вынуждает постоянно с ним носиться в надежде куда-нибудь приткнуть. Да только кто же в здравом уме на такое согласится?
А вот с авиацией повезло…
Особенно, интересно послушать про то, как внедрение АПИ ведет к «усложнению информационного ландшафта организаций» по сравнению с блокчейном?
Никто никого не принуждает — модели сетей обмена данными на базе блокчейн / DLT прорабатываются с целью выработки схемы взаимодействия, позволяющие всем участвующим сторонам получить для себя определенные выгоды по сравнению с другими решениями. Это непросто, о чем и написано в завершении статьи.
Т.е. я понимаю, для чего это делается во в биткоине. Но в данном случае можно четко сказать, кто конкретно должен владеть информацией, кто выступает арбитром, и таким образом централизация является очевидным выбором.
Далее, я все же не вижу, каким образом АПИ усложнит ландшафт. Количество взаимодействий (интеграций) определяется вашими бизнес процессами. А делать их через АПИ или через распределенную БД на основе блокчейна — это уже детали конкретного решения. И выгода от использования блокчейна вместо централизованного ресурса (под который на порядок проще все разрабатывать и поддерживать) мне, мягко говоря, не очевидна. Зато вот проблем я на вскидку вижу много. Начать можно с необходимости внедрения всеми участниками блокчейна, просто потому что им надо поставлять вам что-то. Для упрощения этого дела, вы предоставляете SDK. Но это все же какой-то кастомный продукт, в котором шарят только те, неслабые умы, которые его разработали. Вы рассчитываете на достаточный уровень компетенции у всех участников. Это — жестко. Понятно, что S7 может позволить себе айти отдел определенного уровня для подобных дел. Но поставщики? Вангую: дайте им простой и понятный рестфул апи вместо этого наворота — и они будут прыгать от радости. Далее, вопросы инкапсуляции внутренних процессов. Вы делаете все через контракты в чейне — отлично. Вам нужно поменять внутренний процесс не затрагивая остальных участников. АПИ предоставляет эту возможность сразу. В случае же с чейном, вы должны залить ваш контракт в распределенную среду и потом молиться, чтобы это не поломало где-то что-то у кого-то. Проблема версионности. Как решается вопрос, когда у вас разные версии контрактов для разных поставщиков (вот одни внедрили новую версию вашего SDK, а у других цикл побольше)?
Вообще, в индустрии, как вы очень правильно заметили, есть NDC. S7, если не ошибаюсь, были среди пионеров внедрения. Можно ли сказать, что ваше решение использовать блокчейн было результатом практического опыта по внедрению NDС? Или все же гланым было то, что «при взаимодействии с контрагентами при наземном обслуживании подобных стандартов еще нет»?
Часть вопросов верная. Часть не очень.
Вангую: дайте им простой и понятный рестфул апи вместо этого наворота — и они будут прыгать от радости
Вот это например. Как я себе вижу — такая АПИха будет достаточно сложной, она из коробки не позволяет проверить идентичность ТОЙ стороны (хотя с наворотами это можно сделать), она не гарантирует доставки сообщения (т.е. мы запулили что-то — а отдельно нужно еще наворачивать логику проверки, что нас запрос обработан или делать идемпотетное АПИ, что не всегда возможно). Здесь же — блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных, единой версии правды. С контролируемым и верифицируемым доступом для агентов.
Дополнительно — я больше вижу проблему в том, что блокчейне есть очень много технических аспектов, которые нужно продумать. Насколько равноправны будут участники сети? Что делать, если участник сети скомпрометирован или у него вышел из строя узел? Какова скорость нарастания блокчейна. Понятно, что если он "весит" 1 ТБ, то первоначальная синхронизация = боль. И т.д. Вот очень интересно как это все решено, без маркетинговой шелухи.
/с S7 не связан/
Насчет гарантирует доставку сообщений и т.д. Во-первых, это стандартная задача для архитектур на апи. Есть проверенные годами решения для кучи сценариев и ответы на большинство ваших вопросов уже давно даны. Опять же, не настаиваю на REST. Есть желание все делать через эвенты, gRPC и протобуф — пожалуйста, это не принципиально. Но блокчейн здесь как собаке пятая нога, IMHO.
Теперь, вот это утверждение: «блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных» хоть чем-то подкреплено? Какой-то малоизвестный в узких кругах фреймворк недавно зарелизили и он надежнее проверенных годами продуктов? Вот секюрити аудит этого фреймворка проводился кем-то? Какой-то наработанный годами опыт применения?
Я могу сразу сказать, что секюрити аудит блокчейна и контрактов в нем — это качественно более сложная и дорогая задача, чем проаудитить и запинтестить апи.
Опять же, обращаю внимание, это ведь по сути внутренняя закрытая система одной организации. Там нет десятков разных авиакомпаний. S7 просто поставила перед фактом своих поставщиков ну и договорилась с альфой. Что мешало им просто согласовать АПИ и соответствующим образом его оформить? Это было бы на порядки проще, быстрее и дешевле. Ведь по сути, они всем раздали тот же самый стандартизированный апи, просто под ним прячется еще один уровень на протобуфе, а в глубине, все работает на каком-то блокчейновском фреймворке, который, думаю, понимают только несколько самых продвинутых людей в айти команде S7.
Что значит не позволит проверить идентичность? Есть проверка SSL сертификата. Можно более подробно про сценарий, который вы считаете проблемным?
Что Вы под этим понимаете? Настраивать свой УЦ? Или доверять let's encrypt? Вангую, что первое в hyperledger уже внутри есть, а доверять в финансовых вопросах сертификатам, которые получены от внешних УЦ… Такое себе.
Теперь, вот это утверждение: «блокчейн выступает и как надежная шина, среда передачи данных и как хранилище данных» хоть чем-то подкреплено?
Логика. А Ваших сообщениях ничего, кроме негатива в духе "блокчейн не нужен" или "блокчейн — сырая технология", я не вижу. Абстрагируйтесь вообще от этого слова. Оно вызывает негативные ассоциации с криптовалютами и их пузырем. Просто представьте что это по сути распределённая база данных append only (это ключевое!!!) типа с возможностью выполнения поверх нее определенных скриптов. Все. И сразу вся шелуха спадает. Нет никакого вау эффекта.
Конкретно у S7 уже есть вся необходимая инфраструктура и процедуры, которые они используют для своего агентского АПИ.
Насчет абстрагироваться от блокчейна в данном случае вообще не понятно. Распределенная БД? А зачем S7 «распределять» свою БД? Это сразу серьезнейшим образом усложняет решение и создает просто массу проблем на пустом месте.
Короче говоря, возвращаясь к статье, хочется сказать автору следующее.
Без более развернутой информации о том, какую проблему вы пытаетесь решить, какие варианты рассматривались, почему выбрали именно этот, совершенно не понятно, зачем блокчейн вообще нужен в вашей архитектуре.
В статье по этому поводу лишь два утверждения о том что использование АПИ ведет к
1. "централизации сервисов, через которые идет взаимодействие". И что? Это плохо? Чем? (не вообще, а в рамках конкретной задачи).
2. "к росту количества и типов интеграций и усложнению информационного ландшафта организаций". Причем, под этим понимается сложность АПИ. В замен предлагается перенести ту же самую «сложность» в блокчейн и завести там множество контрактов для поддержки тех же сценариев. Кроме того, АПИ все же придется создать, причем на двух уровнях. Не понятно.
Ну, кхм, смотрите. Давайте возьмем более простые примеры.
- Сам по себе блокчейн не будет выполняться везде. Очевидно, что будут какие-то клиентские АПИ, через которые с ним будут взаимодействовать конкретные клиенты. Например, вряд ли конкретному продавцу билетов нужно разворачивать полноценную ноду — он вполне может ходить через API в ноду авиакомпании и там будет происходить магия. А вот банку — да, нужна нода.
- Я думаю, что вне сомнения, что наличие копии блокчейна у каждого участника сети дает возможность проверить всю цепочку операций. Это организационный вопрос, не технический, вопрос доверия. Потому что доверие у нас везде не абсолютное. И, условно, потребляя чей-то API — ты полностью доверяешь этому контрагенту, его наполнение для тебя является черным ящиком. Сегодня оно одно, а завтра оно другое. Конечно, можно изобрести нечто подобное на коленках… но зачем?
- Вот предположим как сейчас. Есть банк-клиент, есть агент. Агенту нужно сделать вручную перевод через банк-клиент. Это медленно и полуавтоматизированно. Либо у него должна быть какая-то специфическая интеграция с софтом для покупки/продажи билетов с банк-клиентом. Или вообще нужно заводить свой виртуальный счет со своими виртуальными деньгами (как во многих интернет-магазинах) — ну, вообще дичь, надо же морозить свои деньги, потом пополнять счет. Сам по себе блокчейн это все не решает. Это действительно так, но он может стать платформой, которая под конкретную задачу предоставляет как бы единую точку входа. Он позволяет сделать шаг к автоматизации этих процессов (в частности, когда участником будет банк). А может быть вообще поверх одной сети реализовано несколько разных задач из разных сфер с разными наборами агентов.
- Блокчейн прекрасно решает задачи вроде акцуионов, или когда требуется подтверждение некоей операции от двух и более сторон. Сколько придется напилить интеграций и API, чтобы реализовать это в "классическом" подходе? Но это все к п.2
Да, Вы верно заметили, что это не решает вопрос доверия к тем же чейнкодам, но это, я думаю, тоже вопрос решаемый, т.к. их появление в сети и модификация должны каким-то образом протоколироваться. Т.е. какие-либо злоупотребления будут зафиксированы.
Ну, я не могу с этим согласиться. У банка есть АПИ. И переводы в банке через этот апи осуществляются если не мгновенно, то уж во всяком случае, быстрее чем через блокчейн в том же банке.
Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае. Множество ролей не значит автоматически множества сценариев где требуется такое подтверждение. Я так полагаю, для каждого процесса в их бизнесе уже четко определен владелец. И он будет вести процесс через транзакции и отвечать за прохождение.
Насчет подтверждения от «двух и более сторон», я вот не вижу кейса в данном случае.
Смотрите. У нас же часто бывают ситуации, когда есть поставщик и потребитель услуги. И (иногда) бывают конфликтные ситуации. Когда один утверждает, что, например, поставил, а второй — не получил. Причем ладно, когда есть документальные подтверждения, все происходит в реале, а если все происходит в электронном виде? Подделать запись в электронной БД вообще не проблема. Или может быть просто ошибка (да-да, такое тоже бывает даже и у крупных и уважаемых компаний).
Либо давайте… предложите кейсы, когда, по Вашему мнению, блокчейн будет идеально вписываться в процесс.
Эм… И получается черный ящик для потребителя АПИ?
Касательно ключей — да, вариант с подписями возможен, но они они должны быть сгенерированы 3-й стороной, которой доверяют и поставщик API, и потребитель. Но опять же подписи (в частности клиент-серверных решений) не гарантируют того, что запись вдруг не исчезнет из базы. Блокчейн — гарантирует (в определенных рамках).
И выгода от использования блокчейна вместо централизованного ресурса (под который на порядок проще все разрабатывать и поддерживать)
централизованный ресурс однозначно проще разрабатывать и поддерживать. Другой вопрос что контрагенты, при многостороннем взаимодействии, все меньше хотят отдавать свои данные централизованному ресурсу. Распределенная сеть позволяет создать схему минимально необходимого раскрытия данных для тех сторон, которым они нужны.
проблемы обновления логики смарт-контрактов, версионности — они безусловно есть, над этим ведется работа ( в распределенных сетях используется термин governance)
NDC — проработанный стандарт API для поиска / продажи билетов, взаимодействие 1:1 агент — авиакомпания. При использовании NDC остается вопрос со стоком и финансовыми гарантиями, вариант решения которого мы сейчас прорабатываем.
В случае, например, обслуживания рейса контрагентов, предоставляющих данных уже больше, при этом важны количественные характеристики операций, временные метки операций ( контроль Технологического графика обслуживания). Да, можно сделать централизированную систему на стороне аэропорта, авиакомпании, поставщика топлива, но при этом всегда будет оставаться вопрос кто контролирует эти данные. Применение DLT в данном случае ставит цель создания среды взаимодействия контрагентов с прозрачными правилами, а так же с возможностью автоматизации платежных операций, который выполняются при достижении заранее оговоренных условий по предоставленным контрагентами данным.
Согласен, думаю, чтобы принять и осознать схему, нужно получить ее детализированное описание. Это снимет многие вопросы. vitiko такое возможно?
Про топливозаправку: вы уже описали достаточно много взаимодействий, а их на самом деле еще больше, также больше и сторон взаимодействия.
Зачем блокчейн — то, что мы можем всю логику взаимодействия множества сторон описать в виде правил (смарт-контракты), в которых также есть и логика выполнения платежей. При этом топливо для авиакомпании — не единственная статья расходов по рейсу, а для топливозаправщика S7 не единственный клиент. И вместо множества взаимодействий через API (которые сейчас в данном процессе не покрывают все взаимодействие сторон) мы получаем единую информационную и платежную картину для всех сторон.
Банку вряд ли интересно знать детали процесса заправки. Более того, ему и не нужно этого знать, чтобы обеспечить гибкость изменения процессов, которые банк непосредственно не касаются. То же и с заправщиком. А у s7 и так все есть, потому что там происходит оркестрация, и точно известно сколько запросили топлива, во сколько подтвердили, когда оплатили и т.д.
Кроме того, вы же сами пишите, что стоит задача четко ограничить доступ к данным. Так не лучший ли способ это сделать, скрыв внутренние детали за API и именно на этом рубеже контролировать, какие данные отдаются и кому? Если использовать предложенную выше аналогию с распределенной ДБ, то как раз к блокчейну больше вопросов по доступу к данным.
банку действительно не нужно знать детали заправки, но для того чтобы инициировать платеж нужно знать что получатель услуги подтвердил ее получение.
провести оркестрацию вызовов API ( и создать все необходимые API) будет не проще чем сделать систему на DLT / смарт контрактах. Для ограничения доступа к данным в HLF есть несколько решений — каналы, приватные коллекции, шифрование данных, которые позволяют создавать модели с необходимыми разграничениями.
По сути, вы вводите ту же самую централизацию управления и мониторинга процессов, только в качестве среды хранения и исполнения используется блокчейн. На самом деле, ничего нового. В СССР в таком случае все транзакции проходили бы в одном «министерском» ВЦ, четко по единым процедурам, нормативам и т.п.
Проблема в том, что в условиях рынка, такая система не слишком хорошо работает. Я участвовал в подобных проектах, и могу по опыту сказать результаты.
Итак, вы предпишете как ваши подрядчики должны организовать свою работу, завязав все в единый процесс детально описанный в виде смарт контрактов.
В результате, получится следующее:
1. Вы потеряете гибкость в выборе поставщиков из-за высоких требований по вхождению. Т.е. грубо говоря, если в случае с АПИ, новому поставщику для взаимодействия с вами необходимо будет внедрить лишь ваш АПИ, без изменения внутренних процессов и процессов взаимодействия с их банком, поставщиками и т.д., то при вашем подходе, им придется полностью переделывать взаимодействие с банком, с водителями и т.д.
2. Навязывание одинаковых процессов всем поставщикам. А у каждого могут быть свои особенности, ну, вот связанные с регионом, например. И т.о. единые процессы могут быть неоптимальны. В случае с АПИ вы вообще эти проблемы не чувствуете — каждый региональный поставщик организует работу наиболее оптимально для своих условий.
В результате, вас будут заправлять дольше и дороже, чем ваших конкурентов.
На нашем случае, вся идея выродилась в трех крупных поставщиков (из десятков возможных), которые очень быстро поделили делянки и стали выставлять завышенные условия. При том что вокруг куча боле мелких и дешевых, работающих быстрее и качественнее, но они не готовы переделывать свои внутренние системы и процессы под условия заказчика, и по причине стоимости и по той причине, что в этих «ноу хау» организации работы заключаются их конкурентные преимущества.
А дальше пошел следующий круг ада. Большие поставщики сообразили, что им выгоднее перепродавать контракты мелким контакторам (естественно без навязывания им внедрения всех процессов и айти архитектуры), а самим просто снимать маржу на том, что у них есть интерфейс разработанный согласно вашим требованиям (взаимодействие через блокчейн и т.д.).
А дальше, в кругу третьем. Посредники, уволившие всех ребят в оранжевых жилетах, и ставшие исключительно менеджерами, лойерами и финансистами, очень жадные ребята. В результате мелкие фирмы, фактически выполняющие всю работу, стали хронически недофинансироваться, что привело к серьезному падению качества услуг. Опытные работники стали уходить. Обновление оборудования, тех процессов не проводилось.
А дальше наступает катарсис. Если кратко, головное предприятие решает похерить всю эту пирамиду, сделать открытый, легкий и понятный апи, который качественно снизит порог вхождения для поставщиков и позволит создать конкурентную среду. И боже упаси лезть во внутренние дела поставщиков :-).
При проектировании взаимодействия через DLT модель данных включает в себя только те данные, которыми контрагенты обмениваются и без использования блокчейн. Внутренние процессы остаются внутренними, блокчейн-системы всегда работают как middleware между участниками.
Спасибо за подробный анализ, подобных решений мы как раз и не планируем использовать. Цель — это снижение порога входа, а не его повышение, для этого разрабатываются и технические средства.
Уже в комментариях упоминал, модели сетей обмена данными на базе блокчейн / DLT прорабатываются с целью выработки схемы взаимодействия, позволяющие всем участвующим сторонам получить для себя определенные выгоды по сравнению с другими решениями.
От теории к практике: как применяется блокчейн в авиации