Глубокий технический анализ архитектуры и потенциальных проблем Hyperliquid

Недавно привлекшая внимание децентрализованная биржа с ордерной книгой стала одним из самых влиятельных проектов, ее общая заблокированная стоимость (TVL) превысила 2 миллиарда долларов и была охарактеризована как "онлайн-версия известной централизованной биржи". Этот проект даже вернул концепцию Layer3 и приложенческой цепи в общественное сознание. Благодаря выдающимся результатам, достигнутым за месяц после запуска с оценкой в 30 миллиардов долларов, проект получил широкое внимание. На рынке появилось множество исследовательских отчетов, но большинство из них сосредоточено на функциональности продукта и механизме торговли, редко проводя глубокое исследование его технической структуры и потенциальных уязвимостей.

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

Анализ контракта кросс-чейн моста

Проект развернул контракт кросс-цепного моста на определенной сети Layer2 для хранения активов USDC, внесенных пользователями. Из контракта можно увидеть некоторые действия узлов.

Набор валидаторов

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

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

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

• Заблокированные лица аналогичны "комитету по безопасности", могут голосовать за приостановку кросс-чейн моста в экстренных ситуациях. В настоящее время есть 5 адресов, для приостановки контракта моста достаточно 2 голосов.

• Определяющий человек в основном подтверждает изменения состояния кроссчейн-моста, такие как депозиты и снятие средств пользователем.

Депозит

Мостовой контракт обрабатывает депозиты пользователей на основе метода Permit EIP-2612 и позволяет вносить только USDC. Используйте функцию массового депозита для обработки нескольких депозитов, процесс простой и без финансовых рисков.

Вывод средств

Вывод средств - это высокорисковая операция, процесс довольно сложный:

1. После подачи запроса на вывод средств пользователю необходимо собрать 2/3 голосов от группы горячих валидаторов.

2. Есть 200 секунд "спорного периода", в течение которого заблокированные лица могут голосовать за заморозку контракта, а холодные валидаторы могут сделать выводы недействительными.

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

Бридж-контракт заблокирован

Заблокированные лица могут голосовать за блокировку мостового контракта. После голосования двух заблокированных лиц контракт приостанавливает свою работу. Заблокированные лица также могут отозвать свои голоса. После блокировки контракта его может разблокировать только 2/3 холодных валидаторов с подписью. При разблокировке обновляется список валидаторов.

Обновление валидатора

Обновление валидатора требует подписей всех горячих валидаторов, есть 200 секунд на обжалование. По истечении срока необходимо подтверждение завершения обновления от назначенного лица.

Основные риски

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

2. Установитель может отказать в подтверждении транзакции на вывод средств и начать проверку на предмет атак.

3. Злоумышленник заблокировал мостовой контракт, приостановив все выводы.

Двухцепочная интерактивная архитектура

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

Проект использует "двухцепочную схему", узлы одновременно работают с двумя цепями:

1. Специальная цепочка для ордеров: разрешительная, высокая производительность

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

Две цепи распространяют данные через одинаковый консенсусный протокол, но выполняются отдельно. EVM-цепь может читать данные блоков специализированной цепи в прошлом и записывать данные в будущие блоки.

Механизм взаимодействия

1. Предварительная компиляция: добавление специальных контрактов, позволяющих EVM считывать состояние специализированной цепи.

2. Событие: EVM-контракты могут вызывать события, и узлы на основе этого выполняют соответствующие операции в специализированной цепочке.

Консенсусный протокол

Используя протокол HyperBFT на основе HotStuff, теоретически можно обрабатывать 2 миллиона заказов в секунду.

Важные моменты разработки

1. msg.sender может быть адресом системного контракта

2. Неатомарное взаимодействие может привести к потерям активов

3. Адрес EVM-контракта должен быть отображен в специальной цепочке

4. При кросс-цепочном переводе активов баланс может быть временно недоступен для проверки

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