Определение вопроса и ответа в оракулах: как избежать споров

Но фраза «событие произошло» сама по себе не является исполнимой спецификацией.

Для рынка предсказаний это прямой финансовый риск. На Polymarket при работе через UMA предложение исхода или его оспаривание требует залога в $750 USDC. Стандартный период оспаривания составляет два часа. Если ответ не оспорен, он считается истинным. Если оспорен — вопрос уходит в Data Verification Mechanism, DVM. Там решение принимают стейкеры UMA.

Следовательно, определение вопроса и ответа должно быть выполнено до деплоя рынка. Не в комментариях после запуска. Не в сообщении администратора. Не в ветке Discord. В тексте условий, на который ссылается механизм разрешения.

В оптимистичном оракуле код фиксирует процедуру. Спор почти всегда начинается раньше: в семантике вопроса.

Семантика против кода: почему возникают споры в оракулах

Optimistic Oracle работает по презумпции корректности предложенного значения. Пропоузер публикует ответ и вносит bond. Если в пределах liveness period никто не отправил dispute, ответ исполняется на уровне смарт-контракта.

Эта модель эффективна, поскольку подавляющая часть запросов UMA — 99,8% — разрешается без спора. Но оставшиеся случаи не сводятся к сбоям EVM, переполнениям или неверному расчету газа. Обычно проблема выглядит иначе:

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

Формулировка «Победит ли кандидат X на выборах?» технически неполна. Неясно, что считать победой: объявление в ночь голосования, официальную сертификацию, вступление в должность, публикацию данных конкретной избирательной комиссии. Неясно и время: до 23:59 UTC в день выборов, до публикации итогового протокола или без ограничения по дате.

Еще один типовой дефект — подмена наблюдаемого факта интерпретацией. Вопрос «Признает ли государство криптоактив платежным средством?» требует определить юридический акт, юрисдикцию и конкретный статус. Закон может быть принят парламентом, но не подписан. Может быть опубликован, но вступать в силу через полгода. Может разрешать расчеты в ограниченном контуре, не устанавливая статус законного платежного средства. Для оракула это разные исходы.

Смарт-контракт не умеет достраивать контекст естественного языка. Он не определяет, что автор рынка «имел в виду». Он исполняет результат, который прошел через процедуру оспаривания и верификации.

Где именно появляется двусмысленность

На практике двусмысленность концентрируется в пяти полях.

В последнем столбце нет литературной ясности. Есть операционная ясность. Это разные задачи.

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

Анатомия запроса к Optimistic Oracle

Запросы к Optimistic Oracle должны строиться как спецификация, а не как заголовок новостного материала. В коротком вопросе допустимо оставить пользовательскую формулировку. В criteria и ancillary data требуется зафиксировать весь контекст.

Рабочая последовательность состоит из шести элементов.

1. Определить бинарное утверждение.

Ответ должен быть приведен к true/false, yes/no или к заранее определенному числовому значению. Формулировка «Какой будет цена ETH?» не подходит. Формулировка «Будет ли индексная цена ETH/USD на источнике X выше $4 000 в момент T?» подходит, если заданы правила цены и времени.

2. Зафиксировать объект наблюдения.

Актив, компания, протокол, блок, адрес, спортивная лига, нормативный акт — все идентификаторы должны быть однозначны. Для токена недостаточно тикера. Тикеры повторяются. Нужны сеть, адрес контракта или ссылка на конкретный реестр.

3. Назначить Source of Truth.

Источник истины указывается до открытия рынка. Это может быть API биржи, официальный сайт регулятора, публикация статистического ведомства, блокчейн-эксплорер с заданной сетью. После запуска менять источник нельзя: такая замена меняет сам предмет ставки.

4. Указать метрику и метод расчета.

«Объем превысит $1 млрд» требует ответить на три вопроса: какой объем, за какой период, в какой валюте и с каким типом сделок. Для TVL нужно определить агрегатор, дату среза, сеть и способ учета обернутых активов. Для цены — pair, тип котировки, интервал и правило при пропуске данных.

5. Закрыть временное окно.

Время без зоны не является временем для глобального рынка. Стандартный выбор — UTC. Следует указать начало и конец окна, а также правило для события, которое началось до дедлайна, но было подтверждено после него.

6. Описать edge cases.

Отмена, перенос, техническая недоступность источника, делистинг, хардфорк, приостановка торгов, пересмотр данных. Если их нет в условиях, они будут обсуждаться только после внесения $750 USDC и старта dispute.

Вопрос о цене, например, следует писать не так: «Достигнет ли BTC $100 000 в июле?»

Исполнимая версия выглядит иначе: «Будет ли последняя совершенная сделка по паре BTC/USD на бирже X иметь цену не ниже $100 000 хотя бы один раз в период с 00:00 UTC 1 июля до 23:59:59 UTC 31 июля? Источник — публичный интерфейс биржи X. При недоступности интерфейса используется архивированный официальный API этой же биржи. Данные иных площадок не применяются».

Такой текст длиннее. Но он отделяет цену сделки от индексной цены, одну площадку от рынка в целом, июль в UTC от локального календаря и резервный доступ к данным от произвольной замены источника.

Чем короче формулировка рынка, тем больше неописанных переменных переносится в процедуру спора.

Отдельная проблема: слова «официально», «запущен», «доступен»

В Web3 эти слова часто не имеют бинарного значения.

«Протокол запущен» может означать публикацию репозитория, деплой контракта, открытие интерфейса, первую транзакцию, появление ликвидности, включение в whitelist или объявление команды. «Токен доступен» может означать TGE, листинг на CEX, начало торгов на DEX или возможность клейма для ранних участников.

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

• контракт считается развернутым после успешной транзакции создания по конкретному адресу сети;
• mainnet считается доступным после появления хотя бы одного публичного RPC endpoint, указанного фондом проекта;
• токен считается торгуемым после первой сделки в заданной паре на заданном пуле;
• governance считается активным после первого успешно исполненного proposal, а не после публикации документации.

Здесь нет универсального стандарта для всех оракулов и всех типов рынков. UMA, другие optimistic-системы и прикладные протоколы используют собственные шаблоны. Универсальной остается только логика: каждый термин, допускающий два разумных прочтения, должен быть определен отдельно.

Как работает эскалация в DVM

Если участник не согласен с предложенным ответом, он подает dispute в пределах периода оспаривания. На Polymarket этот период составляет два часа. Обе стороны работают через финансовый залог. Размер bond — $750 USDC.

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

После эскалации запрос передается в DVM UMA. Держатели стейкнутых токенов голосуют за ответ, который считают точкой Шеллинга: результатом, к которому придет большинство независимых участников при чтении одних и тех же условий и источников. Для принятия решения требуется квалифицированное большинство не менее 65% стейкнутых токенов.

Голосование занимает существенно больше, чем стандартные два часа optimistic-окна: ориентир составляет от 48 до 96 часов. Это меняет профиль риска рынка:

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

Для пропоузера полезно проверять не только собственное прочтение, но и наиболее сильную альтернативную трактовку. Если она возможна без явного нарушения текста, запрос лучше переписать до публикации.

Как снизить риск спора до отправки запроса

Минимизация риска не требует сложной ончейн-логики. Она требует дисциплины при подготовке ancillary data. Ниже — последовательность, которую можно применять к рынку предсказаний, страховой выплате, грантовому голосованию или расчету KPI в DeFi.

1. Отделить заголовок от правил разрешения.

Заголовок может быть кратким: «Будет ли одобрен ETF X?». Условия должны содержать орган, документ, тип решения, дедлайн и источник. Нельзя считать заголовок полной спецификацией.

2. Проверить доступность источника до деплоя.

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

3. Провести тест на двух независимых читателях.

Два человека получают условия и источник. Затем независимо отвечают на вопрос по трем сценариям: обычный исход, пограничный исход, отмена события. Расхождение означает, что текст не готов.

4. Проверить экономику bond.

$750 USDC — не абстрактная цифра. Для малоликвидного или малозаметного рынка она может оказаться слишком высокой ценой оспаривания. Тогда неверный ответ останется без dispute не потому, что он убедителен, а потому, что потенциальная выгода не покрывает стоимость участия.

5. Не смешивать наблюдаемое и оценочное.

«Адрес получил 10 000 ETH» — наблюдаемый факт при указании сети и адреса. «Кит накопил ETH» — интерпретация. «Протокол стал децентрализованным» — оценка, если не задан формальный порог: например, отсутствие upgrade key, число независимых валидаторов или распределение прав голосования.

6. Закрепить порядок приоритета документов.

Если есть rules, документация, API и официальный пост команды, необходимо указать, что имеет приоритет. Иначе поздний пост в социальной сети может конфликтовать с ранее опубликованным реестром.

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

Whitelist пропоузеров не заменяет спецификацию

UMA использует whitelist для снижения числа ошибочных предложений. Для попадания в него требуется не менее пяти успешных предложений за шесть месяцев и точность не ниже 95%.

Это фильтр истории работы. Не гарантия истинности каждого нового ответа.

Пропоузер с безошибочной статистикой может корректно обработать плохо сформулированный запрос только в узком смысле: выбрать одну из трактовок. Но если сама формулировка допускает несколько исходов, даже точный участник не устраняет риск оспаривания. Whitelist снижает вероятность операционной ошибки. Семантический риск остается на уровне автора рынка.

Резервные сценарии: отмена, перенос, отсутствие данных

Наиболее частая неполнота в правилах формулирования вопросов в Web3 — отсутствие условий для несостоявшегося события.

Матч переносится. Голосование отменяется судом. Биржа останавливает торги. Регулятор отзывает документ. Официальный сайт недоступен. Блокчейн делится на две ветви после форка. Если вопрос содержит только «да» и «нет», а реальный мир выдает третий вариант, начинается dispute.

Для таких случаев нужно заранее выбрать один из трех подходов.

В механизме UMA возможен резервный вариант 0.5. Он означает разделение выплаты 50/50: каждая доля рассчитывается по $0.50. Это не «справедливый» результат в бытовом смысле. Это заранее выбранная нейтральная развязка для случая, когда бинарный рынок потерял бинарность.

Использовать 0.5 следует не по умолчанию, а при строго описанных условиях. Например: «Если до дедлайна официальный источник прекращает публикацию метрики и данные невозможно восстановить из предусмотренного резервного канала, рынок разрешается как 0.5». Такая оговорка исключает спор о том, имеет ли право пропоузер искать другой сайт, другой агрегатор или неофициальный архив.

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

Что считать корректным ответом

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

• соответствует буквальному тексту вопроса;
• получен из указанного Source of Truth;
• укладывается в заданное временное окно;
• учитывает предусмотренные крайние случаи.

Если хотя бы один пункт не выполняется, предложение следует оспорить или не публиковать до исправления условий. Газ, TVL, скорость блока и интерфейс рынка здесь вторичны. Они не устраняют дефект в исходной спецификации.

Финальный вердикт бинарный.

Вопрос с источником, метрикой, UTC-дедлайном, порогом и правилами для отмены — безопасно для optimistic-разрешения.

Вопрос вида «произойдет ли событие» без этих параметров — небезопасно.