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