51 lines
9.1 KiB
Markdown
51 lines
9.1 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` с предложением инициировать локальное обучение на своих данных, то робот начинает обучение
|
|||
|
|
3. После завершения обучения в `Datalog` этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла
|
|||
|
|
4. Робот, запустивший федеративное обучение, отслеживает `Datalog` других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл
|
|||
|
|
|
|||
|
|
### Проверка соответствия робота спецификации производителя
|
|||
|
|
|
|||
|
|
Для корректного обмена навыками между роботами необходимо обеспечить механизм подтверждения, что программно-аппаратное обеспечение роботов соответствует друг другу и передача данных между ними имеет смысл. В этом фреймворке предлагается способ проверки соответствия с помощью подтверждения производителем робота. Производитель оборудования является наиболее осведомлённой стороной в вопросах спецификации выпускаемого робота. В рассматриваемом сценарии производитель робота предоставляет покупателю робота возможность самостоятельно создать identity запись под своим аккаунтом.
|
|||
|
|
1. Для этого производитель прикладывает к каждому выпускаемому роботу уникальный ключ, известный только производителю и покупателю. При производстве роботов производитель создаёт пулл NFT и при передаче прав на роботов передаёт этот NFT покупателю. По владельцам данного NFT можно индексировать блокчейн.
|
|||
|
|
2. Покупатель вводит данный ключ и свой публичный ключ акканута в блокчейн на сайте производителя и получает на свой адрес токены для интеграции робота в сеть блокчейн
|
|||
|
|
3. Пользователь робота, если хочет участвовать в сети обмена данными, создаёт identity запись (`setIdentity`) с указанием конкретной модели робота и версии драйвера и направляет запрос на подтверждение (`requestJudgement`)
|
|||
|
|
4. Производитель находит событие JudgementRequested, где указана информация о версии робота и его встроенном программном обеспечении, сопоставляет эту информацию с своим приватным реестром ключей/адресов и подтверждает корректность (`provideJudgement`)
|
|||
|
|
5. С помощью self-hosted или предоставляемого производителем сервиса индексирования блокчейна (SubQuery в Substrate или TheGraph в Ethereum) владельцы роботов могут видеть опубликованные задания на обучение для таких же роботов и принимать участие в программах улучшения.
|
|||
|
|
|
|||
|
|
Таким образом производитель может легко запускать программы лояльности и улучшения качества обслуживания для тех клиентов, которые предоставляют возможность совершенствовать обучаться с помощью их данных.
|