Новое решение для off-chain агрегирование данных Oracle

В экосистеме DeFi кредитование, деривативы и даже торговля неотделимы от оракулов. Без них невозможно поддерживать экосистему DeFi. Однако нынешняя популярность DeFi вызвала аномальную перегрузку в сети Ethereum. Да и стоимость использования оракула очень высока, что делает его непрактичным в использовании.

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

На приведенном выше рисунке показана плата за агрегирование данных от оракула. Комиссия за каждую транзакцию достигает 13–25 долларов США, что серьезно влияет на доступность оракула.

Для более высокого уровня рабочий процесс оракула запрос/ответ (сетевой) показан на рисунке выше:

-Пользователи, которым нужны данные из off-chain, отправляют запросы данных через smart contract

-Оракул (сеть) отправляет запрос к внешнему источнику данных после получения запроса данных

-Оракул (сеть) агрегирует результаты данных

-Оракул (сеть) наконец-то отвечает на смарт-контракт пользователя данными

В ответ на эту ситуацию, чтобы позволить Oracle реализовать потенциал смарт-контрактов, мы предлагаем схему агрегации данных вне сети, основанную на VRF (проверяемая случайная функция) и BBFT (BBFT Bytom Byzantine Fault Tolerant).

Процесс работы

1. пользователи отправляют запрос

Когда пользователи отправляют запрос в сеть Oracle, им необходимо развернуть смарт-контракт со стандартным шаблоном.

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

Хэш-значение вышеуказанной информации запроса будет использоваться в качестве RequestID в качестве доказательства последующего процесса.

2. комитет консенсуса получает запрос

Сеть оракулов на начальном этапе состоит из 42 нод,
10 из которых формируют комитет по консенсусу, и они по очереди возглавляют консенсус по данным; остальные 32 - это ноды оракула. Ноды оракула и узлы консенсусного комитета в сети оракулов генерируются децентрализованно, и конкретный механизм может быть разработан отдельно.

Комитет по консенсусу сети оракулов будет отслеживать запросы данных, отправляемые в singularity network на каждый blockchain.

3. Комитет консенсуса назначает задачи на основе VRF (проверяемая случайная функция)

Узел Leader в комитете по консенсусу будет случайным образом выбирать определенное количество узлов Oracle на основе запросов пользователей (по сравнению с количеством требований пользователя, можно учитывать избыточность в 1,2 раза) и распределять им запросы данных. В этом процессе другие члены консенсусного комитета несут ответственность за проверку случайности выбора узла и контента, транслируемого Лидером, и выражают свое мнение в последующем процессе консенсуса. См. Подробный план в следующих главах.

4. Консенсусный комитет собирает ответы

После получения запроса данных нода oracle запрашивает данные у источника данных. Можно предположить, что нода оракула должен иметь разные источники данных для одних и тех же данных и предоставлять соответствующие доказательства, которые улучшат конкурентоспособность по сравнению с другими нодами оракула.

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

5.Комитет по консенсусу собирает данные и достигает консенсуса

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

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

Комитет консенсуса наконец отправляет агрегированные уникальные данные в контракт запроса пользователя (мультиподпись/пороговая подпись) и распределяет вознаграждение за эту услугу.

Резюме

В течение всего рабочего процесса комитет по консенсусу наблюдает за всем процессом от запроса данных до агрегирования данных. Каждый член комитета может составить собственное суждение о конечном результате данных. Следовательно, пока не более 1/3 узлов консенсуса совершают ошибку, они, наконец, пройдут консенсус BBFT (Bytom Byzantine Fault Tolerance). Также будет эффективен механизм достижения консенсуса по результатам агрегирования данных.

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

Keep MOVing! Full throttle, Bytom!

Оригинал статьи: https://medium.com/bytomofficial/a-new-solution-for-off-chain-oracle-data-aggregation-2e7a2c21c978