diff --git a/docs/technologies/robonomics.md b/docs/technologies/robonomics.md index e3390a6..f1964b4 100644 --- a/docs/technologies/robonomics.md +++ b/docs/technologies/robonomics.md @@ -25,7 +25,7 @@ title: 'Сеть Робономики' ### Индексация блокчейна Робономики на базе SubQuery -Быстрый просмотр транзакций конкретных транзакций datalog/launch/rws/digital_twin. Будет полезно для популяризации парачейна робономики и увеличения скорости отслеживания определённых транзаций. Например, транзакций с запуском определённых роботов - в `identity` которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов. +Быстрый просмотр транзакций конкретных паллет `datalog`, `launch`, `rws`, `digital twin`. Будет полезно для популяризации Робономики и увеличения скорости отслеживания определённых транзакций. Например, транзакций с запуском определённых роботов - в `identity` которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов. ### Federated learning для роботов-манипуляторов по имеющимся мета-данным @@ -33,18 +33,42 @@ title: 'Сеть Робономики' Порядок федеративного обучения для сети передачи навыков 1. Робот или пользователь публикует в `Datalog` сообщение с initial model hash и другими мета-данными для локального обучения модели -2. Другие подобные роботы отслеживают такого рода сообщения (подобность можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера) +2. Другие подобные роботы отслеживают такого рода сообщения (подобие можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера) 3. Если найдена запись в `Datalog` с предложением инициировать локальное обучение на своих данных, то робот начинает обучение -3. После завершения обучения в `Datalog` этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла -4. Робот, запустивший федеративное обучение, отслеживает `Datalog` других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл +4. После завершения обучения в `Datalog` этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла +5. Робот, запустивший федеративное обучение, отслеживает `Datalog` других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл ### Проверка соответствия робота спецификации производителя -Для корректного обмена навыками между роботами необходимо обеспечить механизм подтверждения, что программно-аппаратное обеспечение роботов соответствует друг другу и передача данных между ними имеет смысл. В этом фреймворке предлагается способ проверки соответствия с помощью подтверждения производителем робота. Производитель оборудования является наиболее осведомлённой стороной в вопросах спецификации выпускаемого робота. В рассматриваемом сценарии производитель робота предоставляет покупателю робота возможность самостоятельно создать identity запись под своим аккаунтом. -1. Для этого производитель прикладывает к каждому выпускаемому роботу уникальный ключ, известный только производителю и покупателю. При производстве роботов производитель создаёт пулл NFT и при передаче прав на роботов передаёт этот NFT покупателю. По владельцам данного NFT можно индексировать блокчейн. -2. Покупатель вводит данный ключ и свой публичный ключ акканута в блокчейн на сайте производителя и получает на свой адрес токены для интеграции робота в сеть блокчейн -3. Пользователь робота, если хочет участвовать в сети обмена данными, создаёт identity запись (`setIdentity`) с указанием конкретной модели робота и версии драйвера и направляет запрос на подтверждение (`requestJudgement`) +Для корректного обмена навыками между роботами необходимо обеспечить механизм подтверждения, что программно-аппаратное обеспечение роботов соответствует друг другу и передача данных между ними имеет смысл. Далее представлен способ проверки соответствия с помощью подтверждения производителем робота. Производитель оборудования является наиболее осведомлённой стороной в вопросах спецификации выпускаемого робота. В рассматриваемом сценарии производитель робота предоставляет покупателю робота возможность самостоятельно создать 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](https://github.com/ros2/sros2), добавив в него возможность применять криптографические механизмы 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 без необходимости доверять единому удостоверяющему центру и использовать сертификаты с большим сроком действия. \ No newline at end of file