74 lines
No EOL
16 KiB
Markdown
74 lines
No EOL
16 KiB
Markdown
---
|
||
id: robonomics
|
||
title: 'Сеть Робономики'
|
||
---
|
||
|
||
## Новые сценарии использования
|
||
|
||
### Расширенный 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](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 без необходимости доверять единому удостоверяющему центру и использовать сертификаты с большим сроком действия. |