На данный момент `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` которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов.
2. Другие подобные роботы отслеживают такого рода сообщения (подобие можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера)
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](https://github.com/ros2/sros2), [инструкция](https://osrf.github.io/ros2multirobotbook/security.html)), добавив в него возможность применять криптографические механизмы Substrate. ROS2 Security позволяет создавать [хранилище ключей](http://docs.ros.org/en/rolling/Tutorials/Security/The-Keystore.html), привязывать ключи к узлам ROS2 и задавать соответствующие политики доступа к топикам, сервисам и действиям. Хранилище представляет из себя директорию с т.н. [enclaves](https://design.ros2.org/articles/ros2_security_enclaves.html) (*анклавы безопасности*) для задания политик управления - процессов или групп процессов с едиными правилами доступа. `enclave` может быть задан для каждого отдельного узла ROS2 в момент его запуска. ROS2 Security можно подключить к узлу Робономики, чтобы создавать необходимые для взаимодействия `enclave`. *Транзакция может служить источником данных для формирования сертификата*. Тело транзакции преобразовывается в `enclave` и используется в DDS для защищённого обмена данными с другими узлами ROS2 или иными агентами. Например, чтобы обеспечить [безопасное взаимодействие агентов](http://docs.ros.org/en/rolling/Tutorials/Security/Security-on-Two.html), не подключённых к сети Робономики на постоянной основе. После получения транзакции агенты создают у себя анклавы с параметрами доступа к внутренней информации и сроком действия. Когда агенты обмениваются данными в пределах срока действия сертификата, то могут использовать аутентификацию DDS без необходимости доверять единому удостоверяющему центру и использовать сертификаты с большим сроком действия.
