Как смарт-контракт узнает, что в Лондоне шел дождь?

Представьте смарт-контракт с одним очень простым правилом:

Если в центре Лондона сегодня выпадет не менее 10 миллиметров осадков, выплатить Алисе $10,000.

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

Есть только один неловкий вопрос.

Как контракт узнает, что шел дождь?

Он не может посмотреть в окно. Он не может дойти до метеостанции. И во время обычного исполнения в Ethereum он не может просто открыть веб-соединение и спросить у метеорологического API, что произошло.

Самое удивительное — эта слепота не является упущенной функцией. Это часть того, что вообще позволяет системе работать.

Слепая машина

Ethereum — это не один компьютер, исполняющий ваш контракт. Множество независимых узлов должны обработать одни и те же транзакции и прийти к абсолютно одинаковому результату. Имея одинаковое предшествующее состояние и одинаковые входные транзакции, они должны вычислить абсолютно идентичное новое состояние ^[1].

А теперь представьте, что контракт мог бы вызвать обычный веб-API прямо во время исполнения.

Один узел делает запрос в 14:03:01 и получает 9.9 мм. Другой узел делает запрос секундой позже и получает 10.1 мм из-за обновления базы метеоданных. Третий сталкивается с тайм-аутом сети.

Внезапно одинаковые транзакции в блокчейне получают разные входные данные.

Вот почему смарт-контракты не работают как обычные веб-приложения. Виртуальная машина Ethereum (EVM) намеренно изолирована от произвольных сетевых запросов во время исполнения. Внешняя информация должна попадать в блокчейн в форме, которую могут увидеть и согласовать все узлы.

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

Кто-то должен занести факт внутрь

Именно здесь на сцене появляются оракулы (oracles) ^[1].

В самом простом случае внесетевая система (off-chain) может прочитать метеорологический источник, подписать значение вроде 12.4 мм и отправить это значение в контракт. Более сложные системы оракулов могут объединять множество поставщиков данных, источников, подписей, рыночных наблюдений или механизмов оспаривания.

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

Предположим, доверенный оракул отправляет транзакцию:

Количество осадков в Лондоне сегодня: 12.4 мм.

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

Чего он не может доказать на основе одной лишь подписи — это то, что 12.4 мм осадков действительно выпали.

Это различие составляет саму суть проблемы оракулов:

Проверка сообщения — это не то же самое, что проверка реальности.

Взломайте то, во что верит контракт

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

Протокол кредитования — отличный пример. Представьте, что вы вносите $150 в качестве залога, чтобы взять в долг $100. Контракт должен постоянно проверять, сколько стоит этот залог. Если его стоимость упадет слишком сильно, позиция подлежит ликвидации.

Всё зависит от цены.

В октябре 2021 года C.R.E.A.M. Finance потерял около 130 миллионов долларов в результате атаки на механизм оценки залога ^[2]. Злоумышленник использовал огромные объемы временно заемного капитала и сманипулировал значением, использовавшимся для оценки залога в хранилище yUSD.

Важная деталь — не сама сложность сделок. Важно то, что произошло дальше.

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

Контракт не забыл, как работает залоговое обеспечение.

Он поверил числу, которое ему сообщили.

Мгновенные займы (flash loans) делают подобные атаки намного более мощными, поскольку позволяют распоряжаться гигантским капиталом в рамках одной неделимой транзакции. Но сам по себе мгновенный займ не является уязвимостью оракула. Более глубокая уязвимость заключается в том, что протокол принимает цену или учетную стоимость, которой можно сманипулировать достаточно дешево.

Как сделать факт достоверным?

Не существует единого дизайна оракулов, потому что не существует единого вида внешней правды.

Постоянно меняющаяся цена ETH — это совсем не та проблема, что и сумма выпавших осадков. Рыночная цена, уже формирующаяся в сети (on-chain), отличается от отмены авиарейса. А заявление, которое может подождать шесть часов для возможного оспаривания, сильно отличается от ликвидации, которой цена нужна прямо сейчас.

Поэтому различные системы производят приемлемые доказательства разными способами.

Спросите у нескольких посланников — Chainlink

Вместо того чтобы доверять одному источнику, децентрализованная сеть оракулов может объединять отчеты от множества независимых узлов и из нескольких источников данных.

Архитектура Chainlink Offchain Reporting позволяет узлам оракулов обмениваться и агрегировать наблюдения вне сети, а затем отправлять в блокчейн один отчет, подтвержденный кворумом ^[3].

Идея проста: один плохой сервер, один сломанный API или один нечестный поставщик данных не должны единолично принимать решение.

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

Следите за самим рынком — Uniswap TWAP

Иногда блокчейну вообще не нужен внешний посланник.

Uniswap v2 и v3 могут поддерживать средневзвешенные по времени цены (TWAP), рассчитываемые на основе наблюдений за ценами в ходе торговой активности, уже происходящей в сети ^[4].

Вместо того чтобы спрашивать: «Сколько ETH стоит прямо сейчас?», протокол может спросить скорей следующее:

«Какую цену этот рынок показывал на протяжении последних нескольких минут?»

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

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

Приносите свежие доказательства только тогда, когда они нужны — Pyth

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

Некоторые системы оракулов непрерывно отправляют обновления в сеть (push). Это держит данные готовыми для чтения контрактами, но частые обновления стоят газа независимо от того, использует ли кто-то это значение.

Pyth интересен тем, что поддерживает модель pull ^[5]. Свежие подписанные обновления цен могут существовать вне сети до тех пор, пока они не понадобятся приложению. Пользователь или приложение затем включают это обновление в транзакцию, и контракт проверяет его перед использованием.

Вместо постоянного обновления каждой возможной цены приложение фактически говорит:

«Мне нужна свежая цена прямо сейчас. Вот подписанное доказательство.»

Pyth также поддерживает и push-интеграции, так что реальное различие является архитектурным: должны ли данные непрерывно жить в сети или поступать только тогда, когда исполнению действительно это нужно?

Считайте заявление правдой, пока кто-то не возразит — UMA

А есть и удивительно иной подход: не пытаться доказывать каждое заявление заранее.

Оптимистичный оракул UMA позволяет кому-то предложить ответ и подкрепить его финансовым залогом. Затем открывается окно оспаривания. Если никто не оспаривает заявление, система принимает его. Если кто-то оспаривает, вопрос эскалируется в процесс разрешения споров UMA ^[6].

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

Логика здесь почти социальная:

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

Большая часть безопасности оракулов — это изменение стоимости лжи

Посмотрите на эти конструкции, и вы увидите общую закономерность.

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

Вместо этого они делают ложную информацию более сложной, медленной, рискованной или дорогой для принятия.

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

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

Инженерная задача поэтому чаще всего звучит не так:

Как сделать ложь невозможной?

А так:

Как сделать принятую ложь более дорогой в производстве, чем выгода от неё?

Даже идеальной криптографии все равно нужно окно

Здесь проблема становится еще удивительнее.

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

Но предположим, датчик дождя подписывает:

Осадки: 10.2 мм.

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

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

Доказательство может сделать цифровое свидетельство невероятно надежным.

Но какое-то наблюдение все равно должно связать это свидетельство с реальным миром.

Контракт все еще не может посмотреть наружу

Это именно та часть, которую скрывают фразы вроде code is law («код — это закон»).

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

Но код не создает сам факт.

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

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

И это означает, что самый глубокий вопрос об оракулах звучит не так:

Как код на блокчейне получает внешние данные?

А так:

Почему блокчейн должен им верить?

Контракт может доказать, кто отправил число.

Он все еще не может посмотреть наружу и увидеть, идет ли дождь.