Сеть Робономики

Новые сценарии использования

Расширенный Liability

На данный момент Liability Pallet в Робономике предлагает пользователю возможность заказать услуги у роботов. Для этого пользователю и роботу нужно подписать заранее(т.е. offchain) некий набор данных, содержащих спецификацию задачи (technics) и её экономические параметры (economics) Эти параметры записываются в транзакцию и робот приступает к работе.

Данный способ формирования соглашения является не очень удобным с точки зрения пользователей:

• Подписание соглашения сторонами потребует offchain-инструментов и сведётся к некой третьей доверенной стороне;
• Подпись одной стороной не имеет срока действия, что может сделать невыгодным исполнение контракта роботом по прошествию определённого срока.

Предлагается следующее:

• Добавить в паллет Liability дополнительный параметр в раздел Economics, содержащий номер блока. Этот номер блока будет являться временной меткой, после наступления которой данное предложение перестаёт действовать. То есть в DApp пользователь будет указывать время действия.
• В сам паллет Liability добавить проверку номера блока при создании транзакции. Если номер блока меньше, чем номер текущего блока, то отвергать данную транзакцию.

Сценарий использования:

1. Робот публикует спецификацию в топик Digital Twin предложение с указанием Economics(с номером блока) и Technics
2. Контрагент робота выбирает DT и номер топика, где опубликована спецификация, подписывает его и отправляет транзакцию
3. Нода проверяет соответствие номеров блока и записывает транзакцию в блокчейн
4. Робот получает соответствующий Event и начинает исполнения обязательства.

Индексация блокчейна Робономики на базе SubQuery

Быстрый просмотр транзакций конкретных паллет datalog, launch, rws, digital twin. Будет полезно для популяризации Робономики и увеличения скорости отслеживания определённых транзакций. Например, транзакций с запуском определённых роботов - в identity которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов.

Federated learning для роботов-манипуляторов по имеющимся мета-данным

Порядок федеративного обучения для сети передачи навыков

1. Робот или пользователь публикует в Datalog сообщение с initial model hash и другими мета-данными для локального обучения модели
2. Другие подобные роботы отслеживают такого рода сообщения (подобие можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера)
3. Если найдена запись в Datalog с предложением инициировать локальное обучение на своих данных, то робот начинает обучение
4. После завершения обучения в Datalog этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла
5. Робот, запустивший федеративное обучение, отслеживает Datalog других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл

Проверка соответствия робота спецификации производителя

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

1. Для этого производитель прикладывает к каждому выпускаемому роботу уникальный ключ или NFT, известный только производителю и покупателю. При производстве роботов производитель создаёт пул таких ключей и при продаже передаёт их покупателям.
2. Покупатель вводит данный ключ и свой публичный ключ аккаунта в блокчейн на сайте производителя, после чего получает на свой адрес токены для интеграции робота в сеть блокчейн
3. Пользователь робота, если хочет участвовать в сети обмена данными, создаёт identity запись (setIdentity) с указанием конкретной модели робота, версии драйвера и направляет запрос на подтверждение (requestJudgement)
4. Производитель находит событие JudgementRequested, где указана информация о версии робота и его встроенном программном обеспечении, сопоставляет эту информацию с своим приватным реестром ключей/адресов и подтверждает корректность (provideJudgement)
5. С помощью self-hosted или предоставляемого производителем сервиса индексирования блокчейна (SubQuery в Substrate или TheGraph в Ethereum) владельцы роботов могут видеть опубликованные задания на обучение для таких же роботов и принимать участие в программах улучшения.

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

Сеть Робономики как инфраструктура открытых ключей (PKI) для кибер-физических систем

Восстание машин отменяется - всё будет под контролем!

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

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

Блокчейн предлагает новое решение. Теперь узлы кибер-физических систем (CPS) могут взаимодействовать друг с другом без доверенных центров. Предлагается модель управления доступом к автономным CPS через блокчейн Робономики.

Такая схема работы даёт следующие возможности:

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

Сценарий использования

В момент прошивки или ввода в эксплуатацию CPS в аппаратно защищённую от записи ПЗУ оборудования записываются спецификации сети для запуска узла Робономики и идентификационные данные CPS (например, идентификатор NFT как право собственности на робота, чтобы иметь возможность передать это право другим пользователям, не меняя конфигурацию самого робота). Далее отключаются или минимизируются возможности взаимодействия по сети, кроме блокчейн: SSH, последовательный порт и все другие интерфейсы, включая графический. CPS приватно создаёт аккаунт, публикует открытый ключ (либо передаёт его корневому узлу для внесения в конфигурацию Digital twin), подключается к сети и начинает отслеживать команды от владельца или контрагентов.

Для изменения политик управления доступом, заданных в блокчейне, можно использовать пакет ROS2 Security (git, инструкция), добавив в него возможность применять криптографические механизмы Substrate. ROS2 Security позволяет создавать хранилище ключей, привязывать ключи к узлам ROS2 и задавать соответствующие политики доступа к топикам, сервисам и действиям. Хранилище представляет из себя директорию с т.н. enclaves (анклавы безопасности) для задания политик управления - процессов или групп процессов с едиными правилами доступа. enclave может быть задан для каждого отдельного узла ROS2 в момент его запуска. ROS2 Security можно подключить к узлу Робономики, чтобы создавать необходимые для взаимодействия enclave. Транзакция может служить источником данных для формирования сертификата. Тело транзакции преобразовывается в enclave и используется в DDS для защищённого обмена данными с другими узлами ROS2 или иными агентами. Например, чтобы обеспечить безопасное взаимодействие агентов, не подключённых к сети Робономики на постоянной основе. После получения транзакции агенты создают у себя анклавы с параметрами доступа к внутренней информации и сроком действия. Когда агенты обмениваются данными в пределах срока действия сертификата, то могут использовать аутентификацию DDS без необходимости доверять единому удостоверяющему центру и использовать сертификаты с большим сроком действия.