Спросить
Войти
Дарья Павловна Иванова - кандидат экономических наук, доцент кафедры логистики и управления цепями поставок Санкт-Петербургского государственного экономического университета
ОСОБЕННОСТИ МЕЖСУБЪЕКТНЫХ ВЗАИМОДЕЙСТВИЙ В СРЕДЕ ЦИФРОВОГО ДОВЕРИЯ ТРАНСПОРТНО-ЛОГИСТИЧЕСКИХ СИСТЕМ
Аннотация. В статье рассмотрены особенности межсубъектных взаимодействий в транспортно-логистических системах в условиях действия смарт-контрактов и технологии блокчейн. Доказана актуальность применения смарт-контрактов в свете стратегических приоритетов экономики Российской Федерации в целом и ОАО «Российские железные дороги» в частности. Предложена общая структура блокчейн-платформы с учётом особенностей межсубъектного взаимодействия её элементов.
Ivanova D.P.
FEATURES OF INTERSUBJECT INTERACTIONS IN THE DIGITAL TRUST ENVIRONMENT OF TRANSPORT AND LOGISTICS SYSTEMS
Abstract. The article is about the inter-object interactions& features in transport and logistics systems with using smart contracts based on blockchain technology. The relevance of the use of smart contracts in the light of the strategic priorities Russian Federation economy as a whole and Russian Railways JSC has been proved. The general structure of the blockchain platform is proposed taking into account the specifics of inter-subject interaction its elements.
Введение
В логистике, где используется сложная система поставок и каждое ее звено должно согласовывать свои действия с другими участниками процесса, сократить время и отслеживать исполнение обязательств контрагентов в режиме реального времени позволит использование смарт-контрактов. Анализ отечественного и зарубежного опыта применения смарт-контрактов на основе технологии блокчейн
ГРНТИ 81.88.01 © Иванова Д.П., 2020
Контактные данные для связи с автором: 191023, Санкт-Петербург, Садовая ул., 21 (Russia, St. Petersburg, Sadovaya str., 21). Тел.: +7 (911) 975-09-72. Е-mail: darpalna@yandex.ru. Статья поступила в редакцию 07.03.2020.
позволил выявить её основные преимущества и недостатки, сильные и слабые стороны, а также сформулировать требования, предъявляемые транспортно-логистическими системами, в том числе ОАО «Российские железные дороги».
В первую очередь, с позиции формировании среды цифрового доверия с применением смарт-контрактов, необходимо определиться: создавать собственную блокчейн-платформу или использовать уже существующую на рынке. Выбор существующего информационно-технологического продукта должен строиться на понимании того, что приобретаемая платформа должна наиболее полно соответствовать запросам компании и возможности интеграции с системами ОАО «РЖД» и его контрагентов в цепочке поставок.
Результаты анализа существующих блокчейн-платформ показывают, что в настоящее время этот рынок огромен и состоит в основном из фрагментированных предложений [14]. Стремление создателей платформ выгодно отличаться от конкурентов на практике приводит к акцентам на токенизации, на конфиденциальности либо на универсальных вычислениях. При этом, отсутствует комплексное решение с исполнением всех этих условий. Большинство блокчейн-платформ, существующих на рынке, не обладает архитектурой, полностью совместимой с современными инструментами управления сетями, и не отвечает соответствующим стандартам безопасности.
Выбор в пользу создания и использования собственной блокчейн-платформы должен основываться на понимании того, что блокчейн не включает все возможности, присущие традиционным системам управления базами данных (СУБД), такие как создание, чтение, обновление и удаление информации. В нём поддерживается только создание и чтение данных, поэтому необходимо заранее детально прописать возможные алгоритмы и последовательность выполнения операций. Также нужно принимать во внимание тот факт, что в настоящее время блокчейн-платформы разрабатываются независимо друг от друга, без учёта возможности взаимодействия с платформами других производителей. Это может привести к несовместимости технологий, применяемых в транспортно-логистических системах, и, как следствие, к возникновению сложностей межсубъектных взаимодействий.
Смарт-контракты, являясь катализатором развития технологии блокчейна, должны позволить не просто вносить и хранить информацию, но и принимать управленческие решения. К сожалению, в настоящее время эта функция смарт-контрактов полностью не реализована [7, с. 335-336]. Для того, чтобы система действовала безошибочно, необходимо выстроить иерархию, изначально при создании алгоритмов обозначив - «за кем последнее слово» на каждом из этапов взаимодействий. Существующие в настоящее время технологии работают в одноранговой сети, где субъекты хозяйственных связей в равной степени могут влиять на изменение содержания каждого этапа взаимодействия.
В связи с этим, первоначально необходимо тестировать работу смарт-контрактов с применением технологии блокчейн не на больших проектах, а поэтапно внедрять в отдельные бизнес-процессы с целью решения частных задач (например, ускорение процесса документооборота). В дальнейшем, когда эти действия приведут к определённым результатам (таким, как сокращение времени на заполнение и сверку документов при осуществлении приёмки/отгрузки), можно будет расширить круг задач.
Кроме того, чтобы выбранная или разработанная ОАО «РЖД» блокчейн-платформа полноценно функционировала и могла в будущем охватывать большинство операций и процессов в цепях поставок, необходимо предусмотреть возможность подключения к ней множества участников рынка, в том числе логистических компаний, морских портов, финансовых организаций, государства в лице Министерства транспорта РФ, Федеральной таможенной службы и пр.
Материалы и методы
Нестабильная экономическая ситуация нашей страны оказывает большое влияние на развитие практики применения смарт-контрактов и технологии блокчейн. В частности, это связано с большими рисками, которые несут компании, инвестирующие в разработку и внедрение блокчейн-платформ, их адаптацию, тестирование и т.д. Между тем, актуальность применения смарт-контрактов и блокчейн-платформ обусловлена стратегическими планами цифровизации экономики РФ в целом и ОАО «РЖД» в частности. В РФ создана Ассоциация «Цифровой транспорт и логистика», одним из учредителей которой является ОАО «РЖД». Цель данной Ассоциации заключается в обеспечении комплексного взаимодействия представителей отрасли, а одной из главных задач является создание и развитие единого мультимодального цифрового транспортного и логистического пространства на территории России на основе отечественных решений и программного обеспечения [8].
Основными направлениями, обозначенными в области цифровой трансформации транспорта, являются оптимизация мультимодальных грузовых перевозок, а также создание платформенных решений для выполнения бесшовных перевозок, быстрого и качественного оформления грузов, в т.ч. в трансграничном сообщении. Кроме того, предусмотрено сопровождение грузов на всех этапах перевозки с использованием систем слежения и электронных товарно-транспортных документов. Решение поставленных задач связывается с созданием цифровой платформы транспортного комплекса (ЦПТК) РФ для формирования доверенной среды взаимодействия всех участников отрасли. Платформа позволит объединить сервисы и массивы данных всех участников транспортного процесса (рисунок 1).
Воздушный транспорт
Автомобильный транспорт
Водный транспорт
Железнодорожный транспорт
Объекты транспортной инфраструктуры
Платформы транспортной отрасли
Рис. 1. Цифровая платформа транспортного комплекса РФ
На этой платформе будут введены единые стандарты, правила и регламенты информационного обмена, в том числе юридически значимые данные о транспортной инфраструктуре и транспортных средствах. Платформа сможет стать своеобразным агрегатором данных о транспорте, который исключит приватизацию этих данных и сможет гарантировать недискриминационный доступ к ним всех заинтересованных участников транспортной отрасли. Кроме того, эта платформа позволит сохранить национальный суверенитет над информационными потоками в транспортном комплексе страны. ЦПТК позволит контролировать качество транспортных услуг и создаст основу цифрового обеспечения безопасности на транспорте [13].
Отдельным проектом Ассоциации планируется объединение существующих цифровых платформ отрасли, систем и инфраструктуры в унифицированную и стандартизированную для обеспечения транспортно-логистических процессов Единую цифровую транспортно-логистическую среду (ЕЦТЛС). Надежная ЕЦТЛС наряду с доступностью юридически значимых данных от подключенных элементов за счёт повышения скорости обмена информацией и её интероперабельности, полной автоматизации административных процедур и обеспечения полноценного электронного документооборота позволят сократить сроки доставки грузов [6].
При организации работ по применению технологии смарт-контрактов необходимо соблюдение главного принципа: система должна быть гибкой, постоянно совершенствующейся, учитывающей особенности межсубъектных взаимодействий в транспортно-логистических системах и сфер деятельности, в которых могут функционировать контрагенты (транспорт, техника и технологии, юридические вопросы и пр.). Общее состоит в том, что смарт-контракты, действующие на основе технологии
блокчейн, могут получить доступ к данным, находящимся за пределами собственной сети. Доступ к информации из внешнего мира, которая имеет отношение к конкретному смарт-контракту, осуществляется с помощью так называемых «оракулов».
Оракулы - это специализированные сервисы, которые являются основным механизмом для связи информационной системы смарт-контракта с внешним миром [1]. Оракулы собирают и проверяют события в реальном мире и отправляют эту информацию в смарт-контракты, вызывая изменения состояния в блокчейне. Эти внешние данные исходят либо из приложений для больших данных, либо из аппаратного обеспечения (Internet-of-Things). Таким образом могут быть получены любые данные (от прогноза погоды до информации о прибытии груза на станцию назначения и успешной оплате). Однако, условие поступления данных необходимо заранее задать в алгоритме исполнения контракта, что вызывает затраты на сетевые транзакции [15, с. 92].
Существуют различные типы оракулов. Software Oracles обрабатывают информационные данные, поступающие из онлайн источников, такие, как температура, цены на товары, задержки рейсов или поездов и т.д.; система извлекает необходимую информацию и помещает её в смарт-контракт. Hardware Oracles поставляют информацию непосредственно из физического мира, например, вагон/ состав пересекает барьер и датчики движения должны его обнаружить и отправить данные в смарт-контракт, или датчики RFID в цепочке поставок. Inbound Oracles предоставляют данные из внешнего мира. Outbound Oracles обеспечивают смарт-контрактам возможность отправки данных во внешний мир; примером может служить смарт-замок в физическом мире, который возможно автоматически разблокировать при получении оплаты. Consensus-based Oracles получают свои данные от человеческого консенсуса, основываясь на рыночных прогнозах [15, с. 92-96].
Важно понимать, что использование одного источника информации может быть рискованным и ненадёжным. Во избежание манипулирования рынком возможно введение рейтинговой системы для оракулов. Для дополнительной безопасности можно использовать комбинацию различных оракулов, где, например, три из пяти оракулов могут определять исход события. Основная проблема с оракулами заключается в том, чтобы этим внешним источникам информации, будь то веб-сайт или датчик, можно было доверять. Оракулы являются сторонними службами по отношению к блокчейн-платформе, не подчиняются базовым механизмам безопасности, которые предоставляет эта инфраструктура, поэтому обеспечение надёжности их функционирования имеет особое значение.
Результаты и обсуждение
В рамках общего механизма межсубъектных взаимодействий необходимо заранее согласовать технические, финансовые, регулятивные вопросы, порядок разрешения споров в случае неисполнения или частичного исполнения одной из сторон принятых на себя договорных обязательств. Каждому из контрагентов необходимо оценивать применимость блокчейна - это касается зрелости технологии, возможности переложить на блокчейн-платформу бизнес-процессы с сохранением уровня их сложности (юридическая составляющая сделок, требования к надёжности и безопасности системы).
С учётом обозначенных выше преимуществ и недостатков, сильных и слабых сторон технологии, может быть рекомендовано создание комбинированной системы, включающей в себя элементы как внутренней среды ОАО «РЖД», так и внешней (интеграция с существующими публичными блокчейн-платформами, базами данных контрагентов, сведениями от оракулов, банковских организаций и т.д.) (рисунок 2).
Рис. 2. Общая структура рекомендуемой платформы и взаимодействие её элементов
Общая структура рекомендуемой платформы, состоит из следующих элементов:
Интересы обеспечения межсубъектного взаимодействия в среде цифрового доверия транспортно-логистических систем требуют того, чтобы определить условия успешной интеграции выбранных технологий в единой платформе, а также выявить явные и скрытые проблемы такой интеграции. Для определения необходимого для реализации платформы функционала можно задать следующие исходные условия: все этапы совершения сделки сопровождаются электронным документооборотом; особенности проведения взаиморасчётов (традиционная система расчёта - вне блокчейн-платформы или централизованно через блокчейн-платформу) на соответствующем этапе; максимально возможное юридическое подтверждение добросовестного исполнения принятых сторонами обязательств по договору, исходя из действующих нормативных документов и регуляторных положений; все операции и сигналы переходов между операциями должны быть максимально автоматизированы.
В каждой конкретной сделке может появиться необходимость в прикреплении документов, не предусмотренных системой заранее, связанных со спецификой тех или иных операций. В таком случае важно предусмотреть возможность их обработки или вручную, или автоматически, но вне системы. Для обеспечения юридической значимости они должны быть подписаны усиленной квалифицированной электронной цифровой подписью (ЭЦП). При этом, на внутреннюю логику смарт-контракта могут быть возложены следующие задачи: обеспечение следования матрице статусов с учётом текущего статуса и инициатора переключающей транзакции; контроль за датой ограничения периода, в рамках которого могут быть представлены документы; обработка наступления опорных событий, приходящих от провайдеров внешних запросов.
При подготовке и исполнении сделки взаимодействие составных элементов структуры платформы происходит следующим образом:
Выбор функциональных компонентов платформы может быть ориентирован на открытые решения (Ethereum, Swarm, Storj), которые обладают следующими преимуществами: развернутая и «самоподдерживающаяся» инфраструктура; открытость и возможность осуществления контроля за операциями не только через предлагаемый интерфейс, но и через альтернативные источники; высокий уровень доверия пользователей из-за наличия конкурентных протоколов консенсуса и качественной «не толерантной» сети независимых узлов.
Практика использования открытых решений позволяет сделать выводы и о существующих в них недостатках. Рассмотрим их:
• Ethereum. Необходимо предоставить возможность выполнения транзакций за счёт «принимающего» смарт-контракта, а не за счёт инициатора транзакции при реализации платных сервисов для смарт-контрактов (при условии, что со стороны смарт-контракта каким-либо образом будет выражено согласие на это - например, за счёт механизма доверенных адресов). Это позволит значительно упростить механизмы расчёта за «услуги», так как не всегда можно заранее определить стоимость исполнения метода смарт-контракта, которое (исполнение) оплачивает инициатор транзакции;
• Ethereum Solidity. Отсутствие встроенных функций работы с некоторыми строками (например, конкатенация, поиск, вырезание фрагмента) осложняет разработку нетривиальных сценариев, взаимодействующих с «внешним миром»;
• Ethereum Swarm. Необходимо наличие механизма подтверждения загрузки файла в Swarm и его раздачи на другие узлы, аналогично основному Ethereum, подобное подтверждению транзакции. Иначе непонятно, сохранен файл в системе или нет. Возникают трудности при работе платформы в Windows, так как разработчики тестировали и готовили документацию только под операционные системы Linux и OSX;
• Storj.io. Сложный для использования инструмент. Для простой интеграции необходимо иметь «укрупненный» Application Programming Interface (API), по аналогии с реализованным в Ethereum Swarm - «положить файл, извлечь файл». Отсутствие возможности организации многопользовательского доступа к файлам приводит к тому, что для осуществления многопользовательского обмена файлами стороны фактически должны «обнародовать» свои учётные реквизиты, что, учитывая платность оказания услуги, нельзя назвать хорошей практикой.
Заключение
В настоящее время блокчейн-платформы не позволяют в полной мере реализовать функционал, необходимый для осуществления межсубъектного взаимодействия в транспортно-логистических системах. Имеются определённые вопросы, решение которых необходимо для реализации крупных проектов в цепях поставок.
Требуют дальнейшей разработки следующие аспекты: во-первых, правовое регулирование сделок, осуществляемых через блокчейн, в том числе определение юридического статуса записи в блокчей-не; во-вторых, из-за запрета на использование криптовалют транзакции вовлекаются в механизм осуществления сделки как способ создания смарт-контрактов и взаимодействия с ними, а не для осуществления взаиморасчётов; в-третьих, необходимо стандартизировать форматы электронных документов для реализации возможности проведения их автоматической проверки; в-четвёртых, для исключения необходимости ввода внешних событий вручную необходимо насыщение блокчейна источниками внешних событий: оракулами на различные реестры, информационные системы банков, страховых, транспортных компаний и т.д., это позволит сделать исполнение смарт-контрактов по-настоящему автоматическим и деперсонализированным.
Очевидно, что для автоматизации проверки содержания электронных документов ОАО «РЖД» необходимо совместно с другими субъектами транспортно-логистической системы сформировать единые подходы к определению унифицированных требований к их (электронных документов) форматам. Это, в частности, может быть реализовано в рамках членства в Ассоциации «Цифровой транспорт и логистика».
Благодарности
Статья подготовлена в рамках договора на выполнение работ по плану научно-технического развития ОАО «РЖД» (НПК) № 3488963 от 20 июня 2019 г.
