--- 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) владельцы роботов могут видеть опубликованные задания на обучение для таких же роботов и принимать участие в программах улучшения. Таким образом производитель может легко запускать программы лояльности и улучшения качества обслуживания для тех клиентов, которые предоставляют возможность совершенствовать обучаться с помощью их данных.