Глубокий анализ Hyperliquid: Техническая архитектура и потенциальные риски
Hyperliquid как широко обсуждаемая биржа с онлайновым ордер-буком, заслуживает глубокого обсуждения своей технологической архитектуры и безопасности. В этой статье будет проведен анализ технической реализации Hyperliquid с двух точек зрения: структуры кросс-цепочных мостов и двойной архитектуры HyperEVM и HyperL1.
Анализ кросс-чейн моста Hyperliquid
Hyperliquid развернула мостовой контракт на Arbitrum для хранения активов USDC пользователей. Этот мостовой контракт включает в себя четыре группы валидаторов: hotValidatorSet, coldValidatorSet, finalizers и lockers, каждая из которых отвечает за разные функции.
Механизм валидаторов
hotValidatorSet: Обработка высокочастотных операций, таких как вывод средств пользователем
coldValidatorSet: Изменение системной конфигурации, может аннулировать запросы на вывод средств
lockers: возможность голосовать для приостановки работы мостового контракта
финализаторы: Подтверждение изменений состояния кросс-цепочного моста
В настоящее время у Hyperliquid только 4 узла-валидатора, hotValidatorSet и coldValidatorSet соответствуют 4 адресам.
Процесс депозита
Мостовой контракт использует метод Permit EIP-2612 для обработки депозитов и позволяет вносить только USDC. Функция batchedDepositWithPermit может обрабатывать несколько депозитов одновременно, процесс довольно прост.
Процесс вывода средств
Запрос на вывод средств должен соответствовать следующим условиям:
Получить 2/3 веса подписей hotValidatorSet
После 200 секунд периода споров
Окончательное подтверждение членами finalizers
В период спора lockers могут голосовать за приостановку моста контракта, coldValidatorSet может аннулировать запросы на вывод.
Механизм блокировки мостового контракта
2 голосующих locker достаточно для блокировки мостового контракта. Для разблокировки требуется 2/3 голосов coldValidatorSet, а также возможность обновления адреса валидатора.
Обновление валидатора
Функция updateValidatorSet может обновить hotValidatorSet и coldValidatorSet, требуется подпись всех членов hotValidatorSet и период спора в 200 секунд.
Потенциальные риски
coldValidatorSet может быть контролируемым, что позволяет обойти все защитные линии и украсть активы пользователей.
финализаторы могут отказать в подтверждении транзакции на вывод средств
lockers могут злонамеренно заблокировать мостовой контракт
HyperEVM и двойная цепочная архитектура
Hyperliquid использует "двухцепочечную схему", одновременно работающую на двух цепочках:
Hyperliquid L1: специализированная для системы ордеров, лицензируемая
HyperEVM: EVM-совместимая цепочка, без разрешений
Две цепи распространяют данные через один и тот же консенсусный протокол, но работают в разных средах выполнения. HyperEVM может читать состояние L1 и записывать данные в L1.
Предкомпиляции
HyperEVM считывает состояние L1 через предварительно скомпилированный код. Известный адрес предварительной компиляции 0x800 может считывать позиции пользователей в вечных контрактах L1 блока.
События
HyperEVM записывает данные в L1 через события. Узлы L1 слушают события по определенному адресу (0x3333...3333), преобразуя намерения пользователей в транзакции L1.
HyperBFT консенсус
Hyperliquid использует консенсусный алгоритм HyperBFT на основе HotStuff, который теоретически может обрабатывать 2 миллиона заказов в секунду.
Важные моменты разработки
msg.sender может быть адресом контракта L1 системы
Невозможность атомарного взаимодействия EVM с L1 может привести к потере активов
Адрес EVM-контракта должен иметь сопоставленный аккаунт в L1
При кросс-цепочной передаче активов может возникнуть временная невозможность проверить баланс.
В общем, HyperEVM похож на уровень второго слоя, основанный на Hyperliquid L1, но предлагает более высокую интероперабельность.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Анализ технологии Hyperliquid: архитектура кроссчейн моста и риски двойной цепной системы HyperEVM
Глубокий анализ Hyperliquid: Техническая архитектура и потенциальные риски
Hyperliquid как широко обсуждаемая биржа с онлайновым ордер-буком, заслуживает глубокого обсуждения своей технологической архитектуры и безопасности. В этой статье будет проведен анализ технической реализации Hyperliquid с двух точек зрения: структуры кросс-цепочных мостов и двойной архитектуры HyperEVM и HyperL1.
Анализ кросс-чейн моста Hyperliquid
Hyperliquid развернула мостовой контракт на Arbitrum для хранения активов USDC пользователей. Этот мостовой контракт включает в себя четыре группы валидаторов: hotValidatorSet, coldValidatorSet, finalizers и lockers, каждая из которых отвечает за разные функции.
Механизм валидаторов
В настоящее время у Hyperliquid только 4 узла-валидатора, hotValidatorSet и coldValidatorSet соответствуют 4 адресам.
Процесс депозита
Мостовой контракт использует метод Permit EIP-2612 для обработки депозитов и позволяет вносить только USDC. Функция batchedDepositWithPermit может обрабатывать несколько депозитов одновременно, процесс довольно прост.
Процесс вывода средств
Запрос на вывод средств должен соответствовать следующим условиям:
В период спора lockers могут голосовать за приостановку моста контракта, coldValidatorSet может аннулировать запросы на вывод.
Механизм блокировки мостового контракта
2 голосующих locker достаточно для блокировки мостового контракта. Для разблокировки требуется 2/3 голосов coldValidatorSet, а также возможность обновления адреса валидатора.
Обновление валидатора
Функция updateValidatorSet может обновить hotValidatorSet и coldValidatorSet, требуется подпись всех членов hotValidatorSet и период спора в 200 секунд.
Потенциальные риски
HyperEVM и двойная цепочная архитектура
Hyperliquid использует "двухцепочечную схему", одновременно работающую на двух цепочках:
Две цепи распространяют данные через один и тот же консенсусный протокол, но работают в разных средах выполнения. HyperEVM может читать состояние L1 и записывать данные в L1.
Предкомпиляции
HyperEVM считывает состояние L1 через предварительно скомпилированный код. Известный адрес предварительной компиляции 0x800 может считывать позиции пользователей в вечных контрактах L1 блока.
События
HyperEVM записывает данные в L1 через события. Узлы L1 слушают события по определенному адресу (0x3333...3333), преобразуя намерения пользователей в транзакции L1.
HyperBFT консенсус
Hyperliquid использует консенсусный алгоритм HyperBFT на основе HotStuff, который теоретически может обрабатывать 2 миллиона заказов в секунду.
Важные моменты разработки
В общем, HyperEVM похож на уровень второго слоя, основанный на Hyperliquid L1, но предлагает более высокую интероперабельность.