Соответствие вопросов и ответов в оракулах: разбор фактов
Оракулы в крипте давно обещают пользователю одну простую вещь — «объективную истину из блокчейна». Формулировка из тех, что отлично продаются на конференциях и крайне плохо перевариваются смарт-контрактом.
Когда разработчик интегрирует оракул, его контракт не получает никакой «истины»: он получает ответ, привязанный к конкретному идентификатору, с заранее заданной структурой, залогом, таймаутом и арбитром. Соответствие вопросов и ответов в блокчейне — это не магия и не самостоятельный ИИ, а набор формальных правил, нарушение которых смарт-контракт замечает быстрее, чем вы успеваете сказать «rug pull». Разберём механику на двух протоколах с разной философией — Reality.eth и UMA — и посмотрим, где маркетинг заканчивается и начинается инженерия.
Идентификатор, JSON и типы: что вообще считается «вопросом»
В Reality.eth каждый вопрос получает собственный идентификатор формата bytes32, и на один и тот же question_id может существовать только один соответствующий ответ. Звучит как техническая мелочь, но именно на этом держится вся конструкция: смарт-контракт проверяет не смысл ответа, а хеш условий, при которых этот ответ был выдан. Если кто-то попытается выдать ответ на «похожий» вопрос с другим набором параметров — контракт просто не примет выдачу.
Сам вопрос задаётся JSON-объектом с двумя обязательными полями — title и type. Без них запрос не пройдёт валидацию. Дополнительно можно указать category, lang, outcomes (для типов single-select и multiple-select) и decimals (для числового uint). То есть, прежде чем кто-то вообще попытается дать ответ, разработчик должен зафиксировать: это «да/нет», число, конкретный вариант из списка, набор вариантов или абсолютная дата-время. Никакой свободной формы — оракул не чат-бот и не интерпретатор естественного языка.
Набор встроенных типов вопросов в Reality.eth закрывает большинство практических сценариев, но не претендует на всеобъемлемость:
- bool — классическое «да/нет» для парных исходов;
- uint — числовое значение с заданным количеством знаков после запятой через поле
decimals; - single-select — выбор одного варианта из заранее заданного массива
outcomes; - multiple-select — выбор набора вариантов из того же массива;
- datetime — абсолютная дата и время, не «через полгода» и не «до конца квартала».
Оракул — это не гарантия правды. Это процедура: кто внёс залог, кто не успел оспорить, какой арбитр указан в вопросе. Если эти параметры не совпадают с тем, что ожидает ваш контракт, никакой «истины» не происходит — происходит отказ системы.
Параметр timeout задаётся в секундах прямо при вызове askQuestion. Документация Reality.eth называет типичным значением около суток, а верхний предел контракта — 365 дней. Интерфейс dapp обычно подсказывает 24 часа на исправление неверного ответа, но это рекомендация, а не закон: разработчик интеграции волен выставить и 10 минут, и месяц. Удобство имеет обратную сторону — короткий timeout уменьшает окно для оспаривания, длинный затягивает финализацию и удерживает залоги замороженными.
Залоги, таймауты и метод, который всё проверяет
Чтобы соответствие вопросов и ответов в блокчейне действительно работало, одного JSON недостаточно. Нужны экономические стимулы, и Reality.eth использует простую, но рабочую схему с залогом.
Когда пользователь даёт ответ, он размещает залог. Если ответ принимается как окончательный — залог возвращается. Если ответ оспорен и не принят — залог сгорает. Это превращает процесс из «кто громче крикнет» в «кто уверен в своей правоте настолько, что готов заморозить деньги». Тот, кто хочет заменить предыдущий ответ, должен внести залог минимум вдвое больше предыдущего. Чтобы перебить чужой ответ, нужно сначала удвоить ставку, потом удвоить ещё раз, и так далее — пока цена ошибки не отпугнёт спорщиков либо не привлечёт достаточно крупного игрока с глубоким карманом.
Финальная проверка ложится на метод getFinalAnswerIfMatches(). Он отдаёт результат только если одновременно выполняется набор условий:
- финальный ответ существует;
- содержимое вопроса совпадает с тем, что ожидает контракт (тот самый bytes32-хеш);
- залог не ниже минимального, который задал контракт;
timeoutне меньше минимального, который задал контракт;- арбитр совпадает с ожидаемым.
Любое несовпадение — и смарт-контракт получает не ответ, а отказ. Это и есть та самая верификация ответов в смарт контрактах, о которой так любят рассуждать на митапах: не «оракул сказал, что цена равна X», а «оракул сказал, что цена равна X при условиях A, B, C и D, и наш контракт с этими условиями согласен». Разница принципиальная, и интеграторы, которые её игнорируют, потом долго разбираются, почему их контракт «не работает».
Когда вопрос признают недействительным: правила, о которых не расскажут на конференциях
Политика разрешения вопросов в Reality.eth, разработанная совместно с Kleros, формализует сценарии, при которых вопрос списывается в ноль — ответ есть, но юридически он ничтожен. Звучит бюрократично, на практике — спасает от дорогостоящих ошибок и затяжных споров.
К недействительным относят:
- вопросы с относительными датами — «через полгода», «до конца квартала», «к следующему халвингу»;
- моральные и оценочные суждения — «был ли этот проект мошенничеством», «справедлива ли цена»;
- вопросы, где среди предложенных
outcomesнет корректного варианта вообще; - вопросы с несколькими верными ответами при типе, который не поддерживает множественный выбор.
Если ваш вопрос можно прочитать двумя способами, и оба способа — разумные, вы получите не один из них, а отказ системы. Маркетинг про «гибкость» обычно умалчивает именно об этом.
Тонкость, на которой регулярно горят интеграторы — правило интерпретации. Если формулировка допускает несколько толкований и ни одно из них не выглядит явно более разумным — вопрос признаётся недействительным. Если же все разумные интерпретации ведут к одному исходу, должен быть возвращён именно этот исход. То есть арбитр не выбирает «лучший» ответ по ощущениям — он проверяет, существует ли единственный ответ, который выдерживает любую разумную трактовку. Это важно держать в голове ещё на этапе проектирования: вопросы, которые вы кажется сформулировали однозначно, на практике часто таковыми не являются.
UMA: оптимистический оракул и голосование DVM
Reality.eth требует активного участия сторон — кто-то внёс залог, кто-то его перебил, кто-то оспорил. UMA пошла другим путём и построила оптимистический оракул: предложенный ответ считается верным по умолчанию, пока его не оспорили в течение liveness-периода. Для интеграций UMA указывает типичный диапазон liveness от 2 часов до 2 дней. Это значит, что в большинстве случаев ответ финализируется молча — никто не спорит, все довольны, газ не тратится.
Если спор всё-таки возникает, запрос уходит в DVM (Data Verification Mechanism) — систему голосования держателей токенов UMA. По данным FAQ проекта, разрешение спора занимает от 2 до 4 дней. Для принятия единственного варианта голосования требуется согласие не менее 65% застейканных UMA. Это уже не «кто быстрее внёс залог», а полноценное голосование с кворумом и порогом, со всеми плюсами и минусами такой модели.
Минус очевиден: 2–4 дня — это 2–4 дня, в течение которых смарт-контракт, ожидающий ответа, либо заморожен, либо работает на старых данных. Плюс — никто не может «задавить» ответ деньгами, как в схеме с удвоением залога. Чтобы перебить результат, нужно не удвоить ставку, а убедить большинство голосующих, что для этого уже нужны либо реальные аргументы, либо солидная доля стейка UMA. Экономика спора у этих двух протоколов устроена принципиально по-разному.
Reality.eth против UMA: инфраструктура соответствия
| Параметр | Reality.eth | UMA |
|---|---|---|
| Модель ответа | Активный залог и перебивание ставки | Оптимистический по умолчанию |
| Идентификатор вопроса | bytes32 (question_id) | Хеш параметров запроса |
| Типичный срок финализации | ≈ 1 сутки (timeout) | от 2 часов до 2 дней (liveness) |
| Максимальный срок ожидания | до 365 дней | Не ограничен контрактом явно, фактически — 2–4 дня при споре |
| Механизм спора | Перебивание залога (×2 и далее) | Голосование DVM |
| Порог разрешения спора | Любой пользователь с достаточным залогом | 65% застейканных UMA |
| Типы вопросов | bool, uint, single-select, multiple-select, datetime | Свободная формулировка плюс шаблон утверждения |
| Арбитр при неоднозначности | Kleros по заранее оформленной политике | DVM-голосование токен-холдеров |
Что это значит для интегратора и для депозита
Если вы подключаете оракул к смарт-контракту, соответствие вопросов и ответов — это не задача оракула, а ваша задача. Оракул выдаёт ответ с набором параметров, и ваш контракт обязан проверить каждый из них. getFinalAnswerIfMatches в Reality.eth — наглядный пример: даже если ответ «правильный по сути», несовпадение арбитра или короткий timeout делают его непригодным. Один и тот же bytes32 без проверки содержимого — это не «ответ на ваш вопрос», а потенциальный ответ на чужой вопрос, который выдали раньше вашего.
Не стоит переносить параметры одного оракула на другой. 24-часовой timeout, удвоение залога, 365-дневный максимум — всё это особенности Reality.eth. В Chainlink, API3, Band и прочих протоколах свои правила, диапазоны и источники данных. Универсального отраслевого стандарта, который одинаково работал бы везде, на текущий момент нет и в ближайшее время не предвидится: каждая команда проектирует свою модель под собственные допущения о доверии, скорости и стоимости газа. Копировать настройки «как у соседа» — верный способ получить красивую обёртку и пустоту внутри.
И последнее, на десерт. Ни один оракул не «гарантирует истину» — это маркетинговая формулировка, которую проект повторяет, пока пользователь не начнёт задавать неудобные вопросы. Оракулы применяют процедуры верификации, экономические стимулы, источники данных и/или голосование. Это работает — но работает в рамках правил конкретного протокола, с его залогами, таймаутами и порогами. Если правила не описаны в документации или описаны расплывчато, закладывайте в интеграцию запас времени на ручную проверку, читайте исходники контракта и не верьте обещаниям «всё уже продумано за вас». Чтение документации всё ещё бесплатнее, чем разбирательство в суде Kleros по поводу недействительного вопроса на сумму с шестью нулями. Берегите нервы и депозит.