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

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

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

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