Optimistic oracle не пытается постоянно собирать одну цену от множества узлов. Он позволяет участнику опубликовать проверяемое утверждение и считает его истинным, если никто не оспорил его в заданное окно. Спор запускает более дорогой арбитраж.
Такая схема подходит не только для цен. Утверждением может быть результат события, выполнение условия страхового договора, корректность crosschain-сообщения или исход prediction market. Экономия появляется потому, что большинство очевидных ответов не проходит полную процедуру голосования.
Чем optimistic oracle отличается от price feed
Классический price feed регулярно публикует числовое значение, которое приложения читают почти сразу. Optimistic oracle работает по запросу или assertion. Ему нужны текст правила, время, дополнительные данные, срок оспаривания и способ разрешить конфликт.
Поэтому optimistic oracle неудобен для мгновенной котировки в каждом блоке, но полезен там, где факт можно проверить после события. Chainlink и другие feed-сети агрегируют отчёты поставщиков, а оптимистичная модель делает основную ставку на открытый контроль и наказание неверного утверждения.
Слово optimistic означает предположение о корректности при отсутствии возражения. Оно не означает прогноз роста, доверие к proposer или гарантию истины. Если никто не следит за системой, ложное утверждение тоже способно пройти challenge window.
Участники процесса
Requester или integrating contract задаёт, какой факт нужен и что произойдёт после ответа. Asserter предлагает значение или формулирует claim. Disputer проверяет утверждение и оспаривает его до окончания liveness. Oracle хранит статус, bonds и вызывает settlement.
При споре подключается arbitrator. В UMA этой ролью обычно служит Data Verification Mechanism, где участники, связанные с UMA, проходят commit-reveal голосование. В OOV3 интеграция также может задать Escalation Manager и изменить путь спора, whitelist участников или локальную политику.
Settler завершает готовое assertion. Во многих реализациях settlement может вызвать любой адрес после выполнения условий. Затем oracle возвращает результат и при необходимости вызывает callback интегрирующего контракта.
Шаг 1. Формулировка утверждения
Безопасность начинается не с голосования, а с вопроса. Claim должен однозначно описывать факт, временную точку, критерии, допустимые варианты и способ проверки. Фраза «команда выпустила продукт» хуже, чем формулировка с конкретным контрактом, сетью, функцией и deadline.
В модели OOv2 запрос обычно содержит identifier, timestamp и ancillary data, а proposer отвечает значением. В OOV3 asserter передаёт claim и параметры assertion. Identifier задаёт общие правила интерпретации, а ancillary data или claim конкретизируют ситуацию.
Два честных наблюдателя могут по-разному понять расплывчатый вопрос. Тогда bond не создаёт истину – он лишь финансирует конфликт. Перед интеграцией полезно проверить примеры пограничных случаев и вариант «неопределимо».
Шаг 2. Bond и liveness
Asserter блокирует bond в разрешённой валюте. Он показывает экономическую уверенность и создаёт награду за обнаружение ошибки. Disputer при оспаривании тоже вносит предусмотренное обеспечение. После решения средства возвращаются и распределяются по правилам oracle, а часть может уйти в fee.
Размер bond должен соотноситься с возможной прибылью от ложного результата и стоимостью проверки. Символическая сумма не остановит атаку на контракт с крупным payout. Но чрезмерный bond ограничит число честных proposer и disputer.
Liveness – challenge window. Короткое окно ускоряет ответ, но наблюдатель может не успеть заметить assertion, получить данные и отправить транзакцию. Длинное окно повышает шанс проверки, одновременно задерживая расчёт и замораживая капитал. Универсального срока нет.
Шаг 3. Оспаривание
Disputer находит активное assertion, читает claim и сверяет факт по предусмотренной методике. Если ответ неверен, он вызывает dispute до истечения liveness и вносит требуемый bond. Транзакция после deadline уже не отменяет оптимистичное принятие.
Кто именно вправе оспаривать, зависит от policy. Базовая схема может быть permissionless. Escalation Manager способен включить whitelist disputers, запретить отдельные assertions, направить спор в собственный арбитраж или игнорировать ответ внешнего oracle. Поэтому слово decentralized в интерфейсе не заменяет чтение policy contract.
Система нуждается в наблюдателях. UMA прямо рекомендует интеграциям запускать собственные monitoring bots для дополнительной устойчивости. Надежда на неизвестного арбитражёра особенно опасна в сети или интеграции без активного мониторинга.
Шаг 4. Арбитраж спора
Если assertion оспорено и policy использует UMA DVM, запрос передаётся в механизм разрешения данных. Участники сначала фиксируют скрытый commitment голоса, а затем раскрывают значение. Commit-reveal уменьшает возможность простого копирования чужого ответа до окончания первой фазы.
DVM выбирает не объективную истину автоматически, а результат экономически защищённого голосования по правилам identifier. Безопасность зависит от стоимости влияния на голосование, стимулов участников, ясности вопроса и потенциальной прибыли от атаки. Спор также занимает дольше, чем бесспорное assertion.
Для другой сети важен relay. DVM UMA находится в Ethereum, а dispute и governance-сообщения могут проходить через канонический bridge либо multisig-маршрут, если подходящего моста нет. Это добавляет latency и отдельные доверительные предпосылки.
Шаг 5. Settlement и callback
Если liveness истекла без спора, assertion становится settleable как истинное. Если dispute был, settlement ждёт ответ arbitrator. После вызова settle oracle фиксирует outcome, распределяет bonds и вызывает callback recipient, если он задан.
Интегрирующий контракт обязан проверить, что callback пришёл от настоящего oracle и относится к ожидаемому assertion ID. Нужно защититься от повторного выполнения, reentrancy и неизвестного ID. Опасно сразу переводить крупный payout по callback без корректного состояния и проверок.
Settlement не всегда происходит автоматически. Если любой адрес может вызвать функцию, кто-то всё равно должен оплатить gas. Приложение должно предусмотреть keeper, пользовательский вызов или другой надёжный способ завершения.
Важное изменение OOV3 после 2025 года
В актуальной документации UMA указано, что с 8 декабря 2025 года для OOV3 предназначен identifier ASSERT_TRUTH2, а первоначальный ASSERT_TRUTH выведен из использования 15 декабря 2025 года. Спецификации совпадают, но изменение разрывает поддержку устаревших проектов.
После этого нельзя использовать assertTruthWithDefaults, потому что функция жёстко содержит старый identifier и должна завершаться revert. Публичная константа defaultIdentifier также возвращает устаревшее значение. Новая интеграция должна явно вызывать настраиваемый путь с поддерживаемым identifier и актуальными параметрами.
Старые tutorials и примеры могут по-прежнему показывать ASSERT_TRUTH или deprecated testnet. Их нельзя копировать без сверки. Это особенно важно для разработчика, а пользователю помогает объяснить, почему прежний контракт больше не создаёт assertions.
Что проверять в конкретной интеграции
- Адрес и версию optimistic oracle в нужной сети.
- Полный claim, identifier, timestamp и ancillary data.
- Bond, валюту обеспечения, final fee и распределение при споре.
- Liveness и точный deadline активного assertion.
- Кто может быть asserter и disputer.
- Escalation Manager, его owner, whitelist и arbitration policy.
- Путь к DVM или другому arbitrator и межсетевой relay.
- Callback recipient и действие, которое он выполнит.
- Наличие независимых monitoring bots.
- Для OOV3 – использование
ASSERT_TRUTH2, а не deprecated defaults.
Основные риски
- Нет наблюдателя. Ложный claim проходит просто потому, что никто не отправил dispute.
- Слабый bond. Прибыль от атаки превышает возможную потерю обеспечения.
- Короткий liveness. У disputer недостаточно времени на проверку и транзакцию.
- Неясный вопрос. Участники спорят о толковании, а не о факте.
- Escalation Manager. Whitelist или owner делает arbitration менее открытым, чем ожидает пользователь.
- DVM. Концентрация voting power и экономическая атака влияют на спорный outcome.
- Crosschain relay. Мост или multisig добавляет собственный риск.
- Callback. Ошибка интеграции превращает правильный oracle result в неправильный payout.
- Устаревший код. Deprecated identifier или адрес приводит к revert либо обращению не к той версии.
Связь с кредитными oracle
В lending-протоколе чаще нужен регулярно обновляемый price feed, потому что collateral ratio меняется постоянно. Optimistic oracle может участвовать в редком спорном событии или служить backstop, но challenge window плохо сочетается с мгновенной ликвидацией.
При займе нужно проверять источник цены, heartbeat, decimals и sequencer status отдельно. Практический чек-лист есть в статье о проверке oracle перед DeFi-займом. Общий обзор UMA и DVM опубликован в материале об UMA.
Итог
Optimistic oracle превращает проверку данных в экономическую игру. Asserter публикует claim и bond, disputer получает challenge window, а спорный результат уходит в DVM или другой arbitration route. Бесспорные утверждения завершаются дешевле, но только при активном мониторинге.
Безопасность определяется не названием oracle, а формулировкой вопроса, размером bond, liveness, полномочиями Escalation Manager, relay и callback-кодом. Для современных OOV3-интеграций нужно учитывать переход UMA на ASSERT_TRUTH2 и не копировать устаревший assertTruthWithDefaults.
