Эволюция оракулов
Перевод
Это вольный перевод важной для меня заметки: https://andrecronje.medium.com/oracle-evolution-ab7ce23da15b.
Суть
Богатые источники данных — то, благодаря чему развивался Интернет.
Статические страницы превратились в динамические данные благодаря API (оракулам). По мере развития API (оракулов) в традиционном интернете они позволили создавать совершенно новые приложения, которые раньше были невозможны.
Это стало ключевым фактором эволюции веба от Web 1.0 (статического) к Web 2.0 (динамическому).
Личное замечание (автора статьи, а не перевода): 3-4 года назад мои мысли на эту тему были гораздо более двусмысленными [прим. Menaskop: хотя для тех, кто в теме, тут подошло бы слово «бинарными»]. Я считал, что существует традиционный централизованный веб (Web 2.0) и децентрализованный веб (Web3.0 [хотя мне не нравится этот термин, но буду использовать его в статье, хотя считаю, что deWeb 1.0, вероятно, более подходящее название]). (Итак) считал, что эти два понятия должны быть полностью разделены, без смешения. Тогда децентрализованный веб был сродни ранним статическим страницам Web 1.0, они могли существовать отдельно друг от друга. За последние 4 года децентрализованный веб превратился в гораздо более интерактивную систему. Получение Web 2.0 «оффчейн» данных (погода, полёты, цепочки поставок и т.д.) не уменьшило его силу, а экспоненциально увеличило её.
То же самое справедливо и для Web3.0.
Oracle v1:
Соль: запрос — ончейн, поставщик — оффчейн; пример Oraclize.
Процесс:
- Пользователь инициирует ончейн транзакцию (депозит/ вывод средств/ покупка/ продажа/ ликвидация/ и т.д.) смарт-контракту;
- Смарт-контракт отправляет HTTP-запрос ончейн смарт-контракту Оракула;
- Централизованный оффчейн-сервис принимает событие HTTP-запроса и анализирует HTTP-запрос (тоже) оффчейн, получая данные;
- Централизованный (одобренный/заапрувленный) сервис записывает полученные данные обратно в смарт-контракт (смарт-контракт может, опционально, вызвать функцию обратного вызова (callback) инициирующего смарт-контракта).
Плюсы такого подхода:
- Можно использовать произвольные данные оракула;
- Данные предоставляются только по запросу (нет ненужного хранения данных или платы за газ).
Минусы:
- Централизованный сервис;
- Асинхронная задержка ответа ((что влияет на) отзывчивость приложения);
- Стоимость (нужно платить за инициирование транзакции и газовые сборы за обратный вызов (call)).
Oracle v2
Суть: ончейн-провайдер; пример — Chainlink.
Процесс:
- Dapp (децентрализованное приложение) запрашивает данные (преимущественно — цену) у Оракула (оффчейн);
- Распределённая сеть добавляет канал данных на свои узлы;
- Централизованный авторизатор (authorizer) периодически записывает данные ончейн.
Плюсы:
- Доступность данных (данные находятся ончейн, когда они требуются, нет задержки отклика).
Минусы:
- Нет произвольных данных;
- Запрос — (только от) предварительно одобренных каналов;
- Централизованный авторизатор ((что тоже работает лишь через) доверие);
- Стоимость (субсидирование платы за газ за каждую ончейн-запись).
Oracle v3
Суть: данные — оффчейн, авторизатор (верификатор) — ончейн; пример Chainlink (в новой альфа-версии). И да, мы в 2023 году именно в этой точке.
Процесс:
- Dapp и/или пользователь запрашивает у авторизованного сервиса доказуемые оффчейн-данные;
- Централизованный авторизатор (верификатор) запрашивает оффчейн-данные и подписывает их (через собственный ключ авторизации): возвращаемое значение, метка времени, источник данных;
- Dapp инициирует ончейн-транзакцию (депозит/ вывод средств/ покупка/ продажа/ ликвидация/ и т.д.), как часть транзакции;
- Смарт-контракт проверяет, что подписант является ожидаемым проверяющим, проверяет источник данных, проверяет временную метку и проверяет данные;
- Если все данные проверены, набор данных обновляется новыми данными и выполняется остальная часть транзакции.
Плюсы:
- Можно запрашивать произвольные данные;
- Данные предоставляются только по запросу;
- Доступность данных (они доступны по мере обработки транзакции);
- Низкая стоимость (нужно платить только за дополнительные sig verify и SSTORE);
Минусы:
- Централизованный орган/проверяющий ((минус, опять же) — доверие);
- Контракт требует предварительного знания открытого ключа (проверяющего).
Oracle v4
Суть: доказываемые данные с ZK-механиками, TBD.
Процесс:
- Dapp и/или пользователь запрашивает доказываемые оффчейн-данные у программы-”верификатора” (prover);
- Программа-верификатор (специально созданные zk-схемы для TCP [примечание: мы далеки от этого]), которую может запустить любой (в том числе — в самом dapp), которая принимает в качестве аргументов целевую конечную точку (HTTP/ SSL/ TCP/ etc.) и предоставляет доказательство и данные: возвращаемый набор данных, метка времени и источник (целевая конечная точка);
- Dapp инициирует ончейн-транзакцию (депозит/ вывод средств/ покупка/ продажа/ ликвидация/ и т.д.), как часть транзакции она включает доказательство и данные;
- Смарт-контракт проверяет доказательство, проверяет источник данных, проверяет временную метку и проверяет данные;
- Если все данные проверены, набор данных обновляется новыми данными и выполняется остальная часть транзакции.
Плюсы:
- Можно запрашивать произвольные данные;
- Данные предоставляются только по запросу;
- Доступность данных (они доступны по мере обработки транзакции);
- Низкая стоимость (нужно платить только за проверку доказательства и SSTORE);
- Отсутствие централизованной структуры (нет доверия);
Минусы:
- Контракт нуждается в предварительном знании программы (схемы) доказательства;
- Очень сложные схемы и вряд ли будут доступны в ближайшее время.
Примечание Menaskop
В целом согласен с автором, но только не с последней фразой: “очень сложные схемы и вряд ли будут доступны в ближайшее время”, — возможно, если брать рынок в целом, то ответ будет положительным для перспективы в 3-5 и даже 7-10 лет, но решения подобного уровня в виде MVP уже есть и скоро можем увидеть их, особенно — в аспекте развития рынка программируемых активов.
На этом всё и
До!
Comments