Содействие отказоустойчивости благодаря дизайну Dual Oracle
29 ноября 2022 г.В представленной выше презентации технический директор Liquity Рик Пардоу представляет, как протокол Liquity использует услуги оракула Chainlink и Tellor, чтобы предоставлять своим пользователям наиболее точные ценовые потоки. Прежде чем погрузиться в презентацию Рика, обратите внимание на несколько важных моментов.
https://youtu.be/p4TzbBmZr_8?embedable=true
Что такое ликвидность?
Liquity — это децентрализованный протокол заимствования, основанный на Ethereum. Он позволяет пользователям брать беспроцентные кредиты, используя эфир в качестве залога по кредиту. Кредиты выплачиваются в LUSD, стабильной монете, привязанной к доллару США. Одной из уникальных особенностей протокола является то, что он полностью неизменен и устойчив к цензуре. Это означает, что протокол Liquity создан для работы без вмешательства человека. Ни одно лицо или централизованная организация не имеет возможности каким-либо образом изменить протокол.
Использование DEX в качестве оракула
При принятии решения о том, какие оракулы использовать, Liquity рассматривала возможность использования «DEX», например Uniswap V2. DEX, или децентрализованная биржа, относится к одноранговому рынку, где пользователи могут торговать криптовалютами напрямую друг с другом, не полагаясь на какую-либо централизованную третью сторону или посредника. Примеры популярных децентрализованных бирж включают Uniswap и SushiSwap. При достаточном объеме торгов DEX всегда будет иметь информацию о последней цене, по которой торговалась определенная пара, что делает ее хорошим источником ценовых данных.
Ценовой оракул Uniswap V2, о котором упоминает Рик, использует метод агрегации цен, известный как «средневзвешенные по времени цены» (TWAP). Это метод агрегирования, который берет среднюю цену пары токенов за определенный период времени. Этот тип агрегирования может быть полезен для исключения краткосрочных ценовых колебаний или манипулирования ценами. Хотя использование оракула TWAP, такого как Uniswap V2, может быть привлекательным для протоколов, которым нужны децентрализованные и неизменяемые варианты ценового оракула, нет никаких гарантий ликвидности токенов на DEX из-за свободного потока капитала. Чем меньше ликвидности токена в пуле, тем ниже стоимость атаки.
Это означает, что некоторые пары могут быть «дешевле» для манипулирования из-за небольшого объема, что делает их более уязвимыми для атак, таких как атаки мгновенных кредитов. Для тех, кто может быть незнаком с тем, что именно представляют собой атаки мгновенных кредитов,
Оракул Б: 5 долларов США. Оракул А: $5,49 Oracle C: 5,50 долл. США
Средний результат будет равен 5,49 доллара США, что будет неточным.
Код контракта на получение ценовых данных от Liquity
В своем объяснении кода контракта Liquity с подачей цен Рик подробно описывает компромисс, на который пришлось пойти Liquity при внедрении дизайна с двумя оракулами. По словам Рика, код «выборки ценовой функции», который используется для получения ценовых данных от оракулов, имеет много разных «ветвей», поскольку он должен реагировать на несколько разных сценариев. Наличие большего количества ветвей приводит к увеличению сложности кода. Наличие этого более сложного кода для достижения большей устойчивости всей системы Liquity — это компромисс, на который пришлось пойти при построении протокола. Тот факт, что система Liquity должна учитывать и реагировать на очень специфические сценарии, приводит к увеличению площади поверхности для атак. Хотя дизайн двойного оракула теоретически должен быть более устойчивым, эта устойчивость может быть достигнута только в том случае, если код работает идеально, как задумано. Таким образом, на разработчиков оказывается большее давление, чтобы код был правильным. Из-за более высокой сложности кода общую устойчивость, которую должна обеспечить конструкция Liquity с двойным оракулом, на практике добиться труднее.
Oracle Logic In Liquity
Протокол Liquity вызывает оракулы Chainlink (основной) и Tellor (резервный) для каждой операции пользователя. Каждый раз запрашиваются три цены – Текущая & предыдущая цена от основного оракула и текущая цена от резервного оракула. Таким образом, протокол может отслеживать состояние каждого оракула и переключаться на резервный оракул только в том случае, если основной оракул завис или неисправен.
Было бы нежелательно, чтобы транзакции на Liquity отменялись, даже если один оракул перестал работать или был скомпрометирован. Пользователи по-прежнему должны иметь возможность корректировать свои кредиты на основе лучшей цены, которую можно получить. Это еще одна причина, по которой при каждой операции вызываются три цены.
Liquity использует «операторы try-catch» для всех внешних вызовов оракула. В программировании «оператор try-catch» позволяет выполнять различные внешние вызовы внутри операции и обеспечивать успешное завершение всей операции, даже если один из внешних вызовов завершается сбоем.
Когда Liquity переключится на резервный оракул?
Если основной оракул не работает или зависает, протокол переключается на использование резервного оракула.
Другим сценарием, в котором они переключаются, может быть, если 2 последовательных обновления цены первичного оракула показывают разницу в цене более 50%.
Пример: цена ETH/USD показывает 1500 долларов США в обновлении A, а затем следующая полученная цена составляет 4000 долларов США. Этот огромный скачок цены будет считаться ненормальным, и протокол переключится на резервный оракул для ценовых данных, чтобы гарантировать, что для ликвидности используется наиболее точная цена ETH/USD.
Однако переключение произойдет только в том случае, если вторичный оракул не согласен с первичным оракулом. (Напомним: для каждой операции Liquity получает текущую и предыдущую цены от основного оракула и текущую цену от резервного оракула). Если резервный оракул соглашается с ценой, то это признак того, что изменение цены на самом деле может быть законным движением рынка. Таким образом протокол Liquity гарантирует, что в данных о ценах есть фактическое несоответствие перед переключением на резервный оракул.
Агрегации подписей вне сети
Агрегация подписей вне сети — это тип вычисления данных, который выполняется за пределами цепочки блоков, а не внутри цепочки блоков (в сети). Агрегации подписей вне сети помогают избежать перегрузок сети и намного дешевле, чем агрегации в сети. Это связано с тем, что в каждой цепочке блоков может выполняться определенное количество транзакций в секунду, прежде чем она станет перегруженной и замедлится. Агрегация данных по цепочке является частью этих транзакционных действий. В то же время за каждое действие в блокчейне будет взиматься плата за газ. Чтобы повысить эффективность, масштабируемость и снизить затраты, Chainlink объединяет отчеты с нескольких своих узлов вне сети в один отчет оракула и возвращает его в сеть. В то время как агрегация вне сети дешевле & более эффективен, но и менее прозрачен, чем агрегация в сети, которую гораздо легче отслеживать.
Плата за использование оракула
Во время своей презентации Рик упоминает, что стоимость получения данных оракула составляет около 60 000 единиц. Для сравнения, минимальная цена газа для транзакции Ethereum составляет 21000 единиц. Плата за газ обычно увеличивается пропорционально сложности транзакции. Хотя 60 000 может показаться не слишком большой суммой для такой важной операции, затраты по-прежнему должны нести пользователи протокола для каждой операции. Для получения дополнительной информации о ценах на газ и сборах в Ethereum см. документацию здесь.
Использование Liquity конструкции с двумя оракулами демонстрирует приверженность команды обеспечению высочайшего уровня безопасности протокола. Liquity также получила оценку 97 % на DeFiSafety. Их реализация более чем одного оракула также вызвала дальнейшие дебаты о важности разработки передового опыта и отраслевых стандартов как для сетей оракулов, так и для пользователей, чтобы обеспечить безопасность и долговечность всей экосистемы.
Саммит Blockchain Oracle Summit стал первой в мире конференцией, посвященной исключительно важности оракулов и их конструкции. Несколько экспертов в этой области собрались в Берлине, чтобы поделиться своей работой и опытом создания и использования различных сервисов Oracle.
Дополнительные сведения о дизайне двойного оракула Liquity см. в этой статье.
Также опубликовано здесь
Оригинал