Использование сети Ethereum, как валидатора контрактного обязательства робота

Боб-{42}. Новый уровень автономности сервисных роботов. Оно может самостоятельно взаимодействовать с людьми и обслуживать себя в умном городе.

Алиса — инженер, изучивший спецификацию сервисного робота Боб-{42}. Алиса разработала 4 модели поведения Боба, позволяющие людям получить его услугу — [‘выгул собак’, ‘курьерская доставка по городу’, ‘анализ шума и воздуха по маршруту’, ‘помощь слепому туристу’].

Алиса организует сервис провайдера. Первые 5 купленных Алисой роботов Боб-{42} появляются на улицах умного города. Каждый Боб-{42} определяет порядок интереса к рынкам сервис провайдера и ждёт появления спроса от людей.

При появлении спроса Боб-{42} определяет экономическую возможность выполнения поставленной задачи.

(1) Если предложение экономически возможно, Боб-{42} берётся за исполнение услуги.

(2) Если предложение экономически невозможно, Боб-{42} выставляет собственное предложение на рынке с удовлетворительными параметрами.

После исполнения услуги, Боб-{42} отправляет транзакцию с логом своих действий.

Сеть Ethereum валидирует результат исполнения обязательства роботом и выносит решение в умный контракт.

Сеть Ethereum, как валидатор обязательства робота

Для валидации исполнения роботом обязательства мы можем полагаться на готовность бенефициара беспристрастно провести анализ выполненных роботом операций, или же мы можем использовать третью сторону контракта, которая способна выполнить данное действие с высокой степенью как понимания того, что требовалось сделать, так и независимости данной третьей стороны от предмета договора.

Сеть Ethereum существует за счет исполнения транзакций случайным валидатором, заинтересованным в корректной работе сети. Предлагая экономический стимул, выгодный для участия в валидации умных контрактов с помощью дополнительного протокола, базирующегося на сети Ethereum, мы способны вовлечь как третью сторону контрактного обязательства робота перед человеком, так и децентрализованный арбитраж сети Ethereum.

Данный процесс можно описать следующим образом:

Провайдер сервиса создаёт рынок услуг роботов в соответствии с определенной моделью. Для этого он:

  1. Выполняет создание умного контракта фабрики контрактных обязательств робота в сети Ethereum.
  2. Запускает работу сервера, который принимает запросы от людей и создаёт предложение на рынке.

Пользователь обращается к сервис провайдеру за услугой, сервис провайдер через фабрику создаёт умный контракт обязательства робота:

  1. Указывая программу для исполнения роботом. В нашем случае программой является запись формата rosbag, загруженная в ipfs.
  2. Прикладывает вознаграждение робота в эфирах.

Робот подписывает контракт и начинает исполнение обязательства. Для этого он:

  1. Исполняет программу (rosbag запись), журналируя свои действия по ходу.
  2. По окончании исполнения программы отправляет журнал действий, загруженный в ipfs, с сообщением об исполнении обязательства в умный контракт.
  3. Прикладывает оплату в utility токенах для валидатора.

Валидатор сети Ethereum (майнер), имеющий дополнительно запущенный к Ethereum протоколу Aira протокол, слушает все события от контрактов обязательств и при получении события от сети Ethereum:

  1. Берёт программу сервис провайдера и журнал выполнения операций роботом.
  2. Воспроизводит программу и сверяет полученный результат с журналом операций робота.
  3. Отправляет своё решение в умный контракт обязательства.

Задание для робота в формате записи операций = rosbag file

Робот воспроизводит запись = rosbag play

Робот записывает свои действия во время исполнения = rosbag record

Робот публикует полученную запись исполнения задания = ipfs add

Пример валидации “Hello new world”

Демонстрация: 

Код смарт-контракта: https://github.com/airalab/core/blob/master/contracts/dao/RobotLiability.sol

0:04 — три SSH-консоли с участниками сделки: робот, человек и майнер Ropsten.

0:23 — в каждой консоли запускается приложение aira-proto с соответствующим аргументом-ролью и дополнительными параметрами: адресом контракта обязательства и величиной платежа.

0:39 — человек через rostopic формулирует задачу для робота, в это время aira-proto на его машине записывает лог в rosbag-файл.

0:46 — aira-proto на стороне человека помещает rosbag-лог в IPFS и отправляет транзакцию в контракт обязательства.

0:58 — aira-proto на стороне робота ловит событие из контракта и начинает воспроизведение задания.

1:03 — в параллельной консоли с роботом видно задание, переданное человеком, параллельно робот пишет лог событий в rosbag-файл.

1:09 — aira-proto на стороне робота упаковывает rosbag-файл в IPFS и отправляет транзакцию в контракт обязательства.

1:16 — aira-proto на стороне майнера ловит событие из контракта обязательства и подтверждает его исполнение.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *