Старт для нового протокола в VIZ

20.01.2021 11:32:51

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

Пользователи (инициаторы) подписывают транзакцию (с помощью криптографии), в которой есть операции (действия), содержащие данные определенной структуры.

Блокчейн ноды (обслуживающие сервера) получают эти транзакции по сетевому p2p протоколу. Делегаты (проверяющие) собирают массив таких проверенных транзакций (подпись криптографически соответствует инициатору) и подтверждают, что они не нарушают консенсус (код есть закон, нет ошибок = закон не нарушен, действия легитимны) — формируют блок который уже подписывают сами (криптографически).

Чтобы сформировать состояние базы данных — достаточно брать данные блок за блоком из блокчейна, искать там действия и применять их в своей базе данных.

Создание нового протокола в VIZ — описательный процесс. Нужно придумать json структуру данных и как оно будет работать. В Виз есть операция custom, внутри которой можно как раз положить любую json структуру, поэтому такие протоколы и называют «кастомными» (настраиваемыми/гибкими).

Давайте представим, как можно было бы создать аналог свободного сервиса для такси?

Нужно описать весь процесс и роли. Начнем с ролей:

  • Провайдер (репутационный посредник между водителем и заказчиком);
  • Водитель (регистрация у провайдера, анонс возможности выполнения заказа, прием заказа);
  • Заказчик (запрос у провайдера доступных водителей в диапазоне по координатам, заказ водителя, перевод залога провайдеру).

Процесс довольно простой (форс мажоры пока не рассматриваем для простоты концепта):

  • Провайдер публикует публичное соглашение, комиссию за свое посредничество, адрес публичного оракула;
  • Водитель оставляет заявку провайдеру на участие;
  • Провайдер подтверждает/отклоняет заявку;
  • Водитель публикует свои координаты раз в X минут;
  • Провайдеры считывают координаты водителей и предлагают клиентам доступ к api по гео-поиску;
  • Заказчик через приложение запрашивает гео-локацию водителей, отправляет залог провайдеру, делает заказ указывая провайдера;
  • Водитель подтверждает получение заказа предварительно проверив через api провайдера о наличие заказа и залога, соглашаясь на комиссию провайдера;
  • Заказчик ждет водителя, после того как сел к водителю, подтверждает начало выполнение заказа;
  • Водитель довозит заказчика (просит подтвердить выполнение заказа);
  • Заказчик подтверждает выполнение заказа в блокчейне + оставляет отзыв у провайдера через api или публичный протокол отзывов;
  • Провайдер видит завершение сделки, отзыв и по своим нормативам распоряжается залогом (забирает свои за посредничество и систему репутации, основное отдает водителю, если необходимо, возвращает клиенту часть залога из-за форс-мажоров или плохой поездки).

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

Данные можно упаковать в протокол T/Taxi, действия назвать соответствующе: provider_anounce, driver_registration, provider_driver_approve, driver_location, driver_off, client_call, client_review, driver_review, provider_review, driver_accept, driver_force_majeure, client_force_majeure.

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

PS Парсинг блоков происходит с помощью JsonRPC запросов к публичным нодам блокчейна (или своей) для разбора данных, которые там находятся.


0
6 наград
81.21689 Ƶ
Отобразить форму комментирования
Комментарии