Глубокое исследование технологической структуры и угроз безопасности Hyperliquid
Недавно широко обсуждаемая Hyperliquid является одной из самых влиятельных децентрализованных бирж с ордерными книгами на блокчейне, ее общая заблокированная стоимость превышает 2 миллиарда долларов, и в отрасли она оценивается как "блокчейн-версия известной централизованной биржи". Это также вновь вызвало обсуждения о Layer3 и приложенческих цепях. За впечатляющий месяц работы с оценкой проекта в 30 миллиардов долларов, Hyperliquid привлекла широкое внимание. В настоящее время на рынке уже имеется множество аналитических отчетов о Hyperliquid, но большинство из них сосредоточены на функциональных возможностях продукта и механизмах торговли, не уделяя должного внимания ее технической архитектуре и потенциальным угрозам безопасности.
Данная статья направлена на заполнение этого пробела, чисто с технической и безопасностной точки зрения анализируя Hyperliquid, чтобы помочь читателям лучше понять внутреннюю структуру и принципы этого звездного проекта. Мы сосредоточим внимание на анализе дизайна и рисков кросс-чейн моста Hyperliquid, а также на двойной архитектуре HyperEVM и HyperL1, углубленно исследуя способы технической реализации, стоящие за этим.
Анализ кросс-чейн моста Hyperliquid
Поскольку Hyperliquid не опубликовал исходный код своих основных компонентов, но открыл исходный код связанных мостовых контрактов, у нас есть больше информации о рисках, связанных с мостовыми контрактами. Hyperliquid развернул мостовой контракт в одной из сетей Layer2 для хранения USDC-активов, внесенных пользователями, и мы можем наблюдать за частью поведения узлов Hyperliquid через компонент Bridge.
Набор валидаторов
С точки зрения классификации узловых идентичностей, Hyperliquid имеет 4 группы валидаторов: hotValidatorSet, coldValidatorSet, а также финализаторы и локеры, каждая из которых выполняет разные обязанности. hotValidatorSet отвечает за высокочастотные операции пользователей, такие как вывод средств, и обычно использует горячий кошелек для своевременной обработки запросов пользователей.
coldValidatorSet используется в основном для изменения системных конфигураций, таких как обновление списка других валидаторов или управление состоянием блокировки мостового контракта, а также имеет право напрямую аннулировать некоторые запросы на вывод.
lockers — это группа валидаторов с особыми правами, аналогичная "безопасному комитету", часто встречающемуся в Layer2, которые могут голосовать за приостановку работы кросс-чейн моста в экстренных ситуациях. В настоящее время коллекция lockers моста Hyperliquid включает 5 адресов, для приостановки контракта моста достаточно голосования 2 locker.
финализаторы также являются специальной группой валидаторов, которые в основном используются для подтверждения изменений состояния кросс-чейн моста, таких как операции пользователей по внесению и снятию средств. Кросс-чейн мост Hyperliquid использует механизм "представления - подтверждения", после того как пользователь инициирует вывод средств, ему необходимо дождаться "периода оспаривания", по истечении которого финализаторы выполняют транзакцию вывода.
Если возникнут проблемы, например, если запрос на вывод средств превышает фактический баланс пользователя, узлы Hyperliquid могут в течение периода спора голосовать за приостановку контракта моста через lockers или сделать проблемный вывод средств недействительным напрямую с помощью coldValidatorSet.
В настоящее время у Hyperliquid всего 4 узла-валидатора, поэтому hotValidatorSet и coldValidatorSet соответствуют 4 адресам в сети. При инициализации Hyperliquid автоматически регистрирует адреса в hotValidatorSet как членов lockers и finalizers, в то время как coldValidatorSet контролируется официально и использует холодный кошелек для хранения ключей.
Депозит
Мостовой контракт Hyperliquid обрабатывает пользовательские депозиты на основе метода Permit EIP-2612 и поддерживает только один актив - USDC. В отличие от традиционной модели Approve-Transfer, Permit более прост и удобен для пакетных операций.
Контракт моста использует функцию batchedDepositWithPermit для пакетной обработки нескольких депозитов, процесс простой и без рисков для безопасности средств, в основном использует метод Permit для оптимизации пользовательского опыта.
Вывод
По сравнению с депозитами, вывод средств является высокорисковым процессом, поэтому логика более сложная. После того как пользователь инициирует запрос на вывод, узлы Hyperliquid вызывают функцию batchedRequestWithdrawals контрактов моста. В этот момент требуется, чтобы каждый запрос на вывод получил 2/3 веса подписей hotValidatorSet, обратите внимание, что это "2/3 веса подписей", а не "2/3 количество подписей". В настоящее время в Hyperliquid только 4 узла с одинаковым весом, поэтому проверка веса подписей и количества подписей временно совпадает, но в будущем могут быть введены узлы с высоким весом.
После подачи запроса на вывод, кросс-чейн мост не немедленно переведет USDC, а будет 200 секунд "периода спора". В это время могут возникнуть две ситуации:
lockers считают, что в запросе на вывод средств есть серьезные проблемы, могут напрямую голосовать за заморозку контракта;
Узел считает, что с некоторыми выводами есть проблемы, участники coldValidatorSet могут вызвать функцию invalidateWithdrawals, чтобы сделать этот вывод недействительным.
Если в течение периода спора не будет аномалий, члены finalizers могут вызвать функцию batchedFinalizeWithdrawals по истечении срока, чтобы подтвердить окончательное состояние, только тогда USDC будет переведен на адрес кошелька пользователя в Layer2.
С точки зрения модели безопасности, если злонамеренный злоумышленник хочет навредить в процессе вывода средств Hyperliquid, ему необходимо преодолеть три линии защиты:
Овладение весом подписи 2/3 hotValidatorSet, то есть получение достаточного количества приватных ключей или сговора. В настоящее время всего 4 валидатора, вероятность контроля или сговора не мала;
Избегайте обнаружения злонамеренных сделок в течение периода спора, иначе это может привести к блокировке контрактов lockers.
Получите как минимум один личный ключ члена finalizers и подтвердите вывод средств. В настоящее время члены finalizers в основном совпадают с членами hotValidatorSet, выполнение условия 1 также удовлетворяет условие 3.
Блокировка мостового контракта
Hyperliquid установил функцию блокировки кросс-цепочного мостового контракта. В частности, члены lockers должны вызвать функцию voteEmergencyLock для голосования; в настоящее время достаточно голосования 2-х членов lockers, чтобы заблокировать и приостановить мостовой контракт.
Стоит отметить, что мост Hyperliquid также предоставляет функцию unvoteEmergencyLock, позволяющую блокировщикам отозвать голосование. Как только контракт моста будет заблокирован, его можно разблокировать только с помощью функции emergencyUnlock, для чего необходимо собрать более 2/3 подписей участников coldValidatorSet.
emergencyUnlock одновременно разблокирует и обновляет наборы адресов валидаторов hotValidatorSet и coldValidatorSet, которые сразу же вступают в силу.
Обновление набора валидаторов
По сравнению с преодолением барьеров процесса вывода средств, прямое использование функции updateValidatorSet для обновления набора валидаторов является более эффективным средством атаки. Для этого требуется подпись всех членов hotValidatorSet и существует период спора в 200 секунд.
После окончания периода споров члены finalizers должны вызвать функцию finalizeValidatorSetUpdate для завершения окончательного обновления.
Существует несколько рисков, связанных с мостовым контрактом Hyperliquid:
Хакеры, контролирующие coldValidatorSet, могут игнорировать препятствия и похищать активы пользователей. Поскольку coldValidatorSet имеет права emergencyUnlock, это позволяет сделать блокировки неэффективными и мгновенно обновить список узлов. В настоящее время только 4 узла валидаторов, риск кражи приватных ключей высок;
финализаторы отказываются подтверждать транзакции на вывод средств пользователей, осуществляя атаку на проверку. В это время активы пользователей в безопасности, но их может быть невозможно вывести;
lockers злоумышленно блокируют кросс-чейн мост, предотвращая выполнение всех операций вывода, можно только ждать разблокировки coldValidatorSet.
HyperEVM и архитектура взаимодействия двух цепей
Для реализации программируемой торговли на ордерной книге, например, для внедрения сцен, требующих поддержки смарт-контрактов, таких как приватная торговля, Hyperliquid запускает решение HyperEVM. Оно имеет два основных преимущества по сравнению с традиционным EVM: возможность считывания состояния ордерной книги Hyperliquid и возможность внутреннего смарт-контракта взаимодействовать с системой ордерной книги, что значительно расширяет области применения.
Например, если пользователю необходимо обеспечить конфиденциальность ордеров, он может добавить уровень конфиденциальности через контракт, аналогичный Tornado Cash, на HyperEVM, а затем активировать ордер через определенный интерфейс в системе книг заказов Hyperliquid.
Hyperliquid разработал специальную архитектуру для HyperEVM. Учитывая, что производительность настраиваемой системы ордеров значительно превышает производительность среды EVM, чтобы избежать снижения скорости, Hyperliquid использует "двухцепочечную схему": каждый узел одновременно работает с двумя цепочками, локально хранит данные двух цепочек и обрабатывает транзакции отдельно.
Hyperliquid создает специализированную цепочку ( HyperL1 для системы с заказными книгами, с разрешительной системой ), а также добавляет совместимую с EVM цепочку ( HyperEVM, без разрешения ). Данные обеих цепочек распространяются через один и тот же протокол консенсуса, существуя как единое состояние, но работающие в разных средах. Скорость создания блоков в HyperL1 выше, чем в HyperEVM, но блоки по-прежнему выполняются последовательно. Контракты на EVM цепочке могут читать данные из предыдущих блоков L1 и записывать данные в будущие блоки L1.
Взаимодействие HyperL1 и HyperEVM осуществляется в основном через Precompiles и события.
Прекомпиляции
Предварительная компиляция(Precompiles) реализует сложные операции непосредственно на низком уровне, обрабатывая вычисления, неудобные для Solidity, с помощью языков C/C++ и т.д. Предварительная компиляция по сути является специальным смарт-контрактом, к которому могут обращаться другие контракты и получать результаты выполнения. В настоящее время нативный EVM реализовал инструкцию ecRecover( по адресу).
HyperEVM также добавил предкомпилированный код для реализации чтения состояния системы заказов Hyperliquid. Известный адрес предкомпиляции: 0x0000000000000000000000000000000000000800, который может читать позиции бессрочных контрактов пользователей в последних L1 блоках.
События
HyperEVM зависит от Events для записи данных в HyperL1. Events — это родная концепция EVM, позволяющая контрактам отправлять журнальные сообщения внешним системам. Например, при переводе ERC-20 генерируется событие Transfer, что облегчает его отслеживание. Многие кросс-чейн сценарии также используют Events для передачи параметров.
Узел HyperLiquid слушает события, выбрасываемые адресом 0x3333333333333333333333333333333333333333, и на основе информации узнает намерения пользователя и преобразует их в торговые действия, записывая в будущий L1 блок. Если этот адрес предоставляет функцию, при вызове которой выбрасывается событие IocOrder, то когда L1 создает блок, узел извлекает новое событие IocOrder и преобразует его в операцию по размещению лимитного ордера в L1.
ГиперBFT
В области консенсусного протокола Hyperliquid использует протокол HyperBFT, основанный на HotStuff. На начальном этапе использовался алгоритм Tendermint, но он был неэффективен, требуя обмена сообщениями All-to-All на каждом этапе, сложность O(n²).
Чтобы достичь скорости централизованной биржи, команда разработала HyperBFT и реализовала его на Rust. Теоретически он может обрабатывать 2 миллиона заказов в секунду. Все сообщения в HyperBFT сводятся и транслируются Лидером, что устраняет обмен сообщениями между узлами и значительно снижает сложность.
Короче говоря, HyperBFT — это консенсусный протокол, при котором текущий лидер создает блок, все узлы голосуют и отправляют результаты лидеру, после чего происходит смена следующего лидера.
Важные замечания для разработчиков
Механизм чтения данных на основе Precompiles достаточно хорошо развит, но необходимо обратить внимание на проблему msg.sender. Когда пользователь взаимодействует с контрактом L1 и косвенно инициирует транзакцию EVM, msg.sender внутри EVM будет адресом контракта L1, а не адресом пользователя.
Существуют проблемы неатомарности взаимодействия EVM и L1. Если пользователь создает ордер на L1 через EVM, но у него недостаточно средств, сделка не удается, но при вызове функции нет сообщения об ошибке. Разработчику необходимо обработать ситуацию неудачи ордера на стороне контракта EVM и установить функцию возврата средств.
Адрес EVM-контракта на L1 должен иметь сопоставленный аккаунт. После развертывания EVM-контракта необходимо перевести небольшое количество USDC на адрес сопоставления L1 для создания аккаунта.
Обратите внимание на специальные случаи, такие как баланс токенов. L1 имеет специальные адреса для кросс-цепочных активов, но после кросс-цепочки EVM может не успеть создать блок, и пользователи временно не смогут прочитать баланс. Разработчики должны обрабатывать такие ситуации, чтобы избежать паники у пользователей.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
22 Лайков
Награда
22
6
Поделиться
комментарий
0/400
LazyDevMiner
· 07-12 07:14
Так много скрытых опасностей, а 20 миллиардов Закрытая позиция - это просто абсурд.
Посмотреть ОригиналОтветить0
PumpDoctrine
· 07-11 11:56
Когда можно будет покупайте падения его?
Посмотреть ОригиналОтветить0
Web3ExplorerLin
· 07-09 10:39
с технической точки зрения, еще один потенциальный L3 проект на подходе...smh
Посмотреть ОригиналОтветить0
RugResistant
· 07-09 10:38
Жду, чтобы поесть арбуз.
Посмотреть ОригиналОтветить0
WalletInspector
· 07-09 10:32
Слухи, деньги на мистери-бокс действительно не шутка.
Посмотреть ОригиналОтветить0
WalletDoomsDay
· 07-09 10:20
Ты можешь объяснить риски безопасности? Говорить о росте и падении целый день неинтересно.
Глубокий анализ Hyperliquid: Обсуждение безопасности кроссчейн моста и двойной архитектуры HyperEVM
Глубокое исследование технологической структуры и угроз безопасности Hyperliquid
Недавно широко обсуждаемая Hyperliquid является одной из самых влиятельных децентрализованных бирж с ордерными книгами на блокчейне, ее общая заблокированная стоимость превышает 2 миллиарда долларов, и в отрасли она оценивается как "блокчейн-версия известной централизованной биржи". Это также вновь вызвало обсуждения о Layer3 и приложенческих цепях. За впечатляющий месяц работы с оценкой проекта в 30 миллиардов долларов, Hyperliquid привлекла широкое внимание. В настоящее время на рынке уже имеется множество аналитических отчетов о Hyperliquid, но большинство из них сосредоточены на функциональных возможностях продукта и механизмах торговли, не уделяя должного внимания ее технической архитектуре и потенциальным угрозам безопасности.
Данная статья направлена на заполнение этого пробела, чисто с технической и безопасностной точки зрения анализируя Hyperliquid, чтобы помочь читателям лучше понять внутреннюю структуру и принципы этого звездного проекта. Мы сосредоточим внимание на анализе дизайна и рисков кросс-чейн моста Hyperliquid, а также на двойной архитектуре HyperEVM и HyperL1, углубленно исследуя способы технической реализации, стоящие за этим.
Анализ кросс-чейн моста Hyperliquid
Поскольку Hyperliquid не опубликовал исходный код своих основных компонентов, но открыл исходный код связанных мостовых контрактов, у нас есть больше информации о рисках, связанных с мостовыми контрактами. Hyperliquid развернул мостовой контракт в одной из сетей Layer2 для хранения USDC-активов, внесенных пользователями, и мы можем наблюдать за частью поведения узлов Hyperliquid через компонент Bridge.
Набор валидаторов
С точки зрения классификации узловых идентичностей, Hyperliquid имеет 4 группы валидаторов: hotValidatorSet, coldValidatorSet, а также финализаторы и локеры, каждая из которых выполняет разные обязанности. hotValidatorSet отвечает за высокочастотные операции пользователей, такие как вывод средств, и обычно использует горячий кошелек для своевременной обработки запросов пользователей.
coldValidatorSet используется в основном для изменения системных конфигураций, таких как обновление списка других валидаторов или управление состоянием блокировки мостового контракта, а также имеет право напрямую аннулировать некоторые запросы на вывод.
lockers — это группа валидаторов с особыми правами, аналогичная "безопасному комитету", часто встречающемуся в Layer2, которые могут голосовать за приостановку работы кросс-чейн моста в экстренных ситуациях. В настоящее время коллекция lockers моста Hyperliquid включает 5 адресов, для приостановки контракта моста достаточно голосования 2 locker.
финализаторы также являются специальной группой валидаторов, которые в основном используются для подтверждения изменений состояния кросс-чейн моста, таких как операции пользователей по внесению и снятию средств. Кросс-чейн мост Hyperliquid использует механизм "представления - подтверждения", после того как пользователь инициирует вывод средств, ему необходимо дождаться "периода оспаривания", по истечении которого финализаторы выполняют транзакцию вывода.
Если возникнут проблемы, например, если запрос на вывод средств превышает фактический баланс пользователя, узлы Hyperliquid могут в течение периода спора голосовать за приостановку контракта моста через lockers или сделать проблемный вывод средств недействительным напрямую с помощью coldValidatorSet.
В настоящее время у Hyperliquid всего 4 узла-валидатора, поэтому hotValidatorSet и coldValidatorSet соответствуют 4 адресам в сети. При инициализации Hyperliquid автоматически регистрирует адреса в hotValidatorSet как членов lockers и finalizers, в то время как coldValidatorSet контролируется официально и использует холодный кошелек для хранения ключей.
Депозит
Мостовой контракт Hyperliquid обрабатывает пользовательские депозиты на основе метода Permit EIP-2612 и поддерживает только один актив - USDC. В отличие от традиционной модели Approve-Transfer, Permit более прост и удобен для пакетных операций.
Контракт моста использует функцию batchedDepositWithPermit для пакетной обработки нескольких депозитов, процесс простой и без рисков для безопасности средств, в основном использует метод Permit для оптимизации пользовательского опыта.
Вывод
По сравнению с депозитами, вывод средств является высокорисковым процессом, поэтому логика более сложная. После того как пользователь инициирует запрос на вывод, узлы Hyperliquid вызывают функцию batchedRequestWithdrawals контрактов моста. В этот момент требуется, чтобы каждый запрос на вывод получил 2/3 веса подписей hotValidatorSet, обратите внимание, что это "2/3 веса подписей", а не "2/3 количество подписей". В настоящее время в Hyperliquid только 4 узла с одинаковым весом, поэтому проверка веса подписей и количества подписей временно совпадает, но в будущем могут быть введены узлы с высоким весом.
После подачи запроса на вывод, кросс-чейн мост не немедленно переведет USDC, а будет 200 секунд "периода спора". В это время могут возникнуть две ситуации:
lockers считают, что в запросе на вывод средств есть серьезные проблемы, могут напрямую голосовать за заморозку контракта;
Узел считает, что с некоторыми выводами есть проблемы, участники coldValidatorSet могут вызвать функцию invalidateWithdrawals, чтобы сделать этот вывод недействительным.
Если в течение периода спора не будет аномалий, члены finalizers могут вызвать функцию batchedFinalizeWithdrawals по истечении срока, чтобы подтвердить окончательное состояние, только тогда USDC будет переведен на адрес кошелька пользователя в Layer2.
С точки зрения модели безопасности, если злонамеренный злоумышленник хочет навредить в процессе вывода средств Hyperliquid, ему необходимо преодолеть три линии защиты:
Овладение весом подписи 2/3 hotValidatorSet, то есть получение достаточного количества приватных ключей или сговора. В настоящее время всего 4 валидатора, вероятность контроля или сговора не мала;
Избегайте обнаружения злонамеренных сделок в течение периода спора, иначе это может привести к блокировке контрактов lockers.
Получите как минимум один личный ключ члена finalizers и подтвердите вывод средств. В настоящее время члены finalizers в основном совпадают с членами hotValidatorSet, выполнение условия 1 также удовлетворяет условие 3.
Блокировка мостового контракта
Hyperliquid установил функцию блокировки кросс-цепочного мостового контракта. В частности, члены lockers должны вызвать функцию voteEmergencyLock для голосования; в настоящее время достаточно голосования 2-х членов lockers, чтобы заблокировать и приостановить мостовой контракт.
Стоит отметить, что мост Hyperliquid также предоставляет функцию unvoteEmergencyLock, позволяющую блокировщикам отозвать голосование. Как только контракт моста будет заблокирован, его можно разблокировать только с помощью функции emergencyUnlock, для чего необходимо собрать более 2/3 подписей участников coldValidatorSet.
emergencyUnlock одновременно разблокирует и обновляет наборы адресов валидаторов hotValidatorSet и coldValidatorSet, которые сразу же вступают в силу.
Обновление набора валидаторов
По сравнению с преодолением барьеров процесса вывода средств, прямое использование функции updateValidatorSet для обновления набора валидаторов является более эффективным средством атаки. Для этого требуется подпись всех членов hotValidatorSet и существует период спора в 200 секунд.
После окончания периода споров члены finalizers должны вызвать функцию finalizeValidatorSetUpdate для завершения окончательного обновления.
Существует несколько рисков, связанных с мостовым контрактом Hyperliquid:
Хакеры, контролирующие coldValidatorSet, могут игнорировать препятствия и похищать активы пользователей. Поскольку coldValidatorSet имеет права emergencyUnlock, это позволяет сделать блокировки неэффективными и мгновенно обновить список узлов. В настоящее время только 4 узла валидаторов, риск кражи приватных ключей высок;
финализаторы отказываются подтверждать транзакции на вывод средств пользователей, осуществляя атаку на проверку. В это время активы пользователей в безопасности, но их может быть невозможно вывести;
lockers злоумышленно блокируют кросс-чейн мост, предотвращая выполнение всех операций вывода, можно только ждать разблокировки coldValidatorSet.
HyperEVM и архитектура взаимодействия двух цепей
Для реализации программируемой торговли на ордерной книге, например, для внедрения сцен, требующих поддержки смарт-контрактов, таких как приватная торговля, Hyperliquid запускает решение HyperEVM. Оно имеет два основных преимущества по сравнению с традиционным EVM: возможность считывания состояния ордерной книги Hyperliquid и возможность внутреннего смарт-контракта взаимодействовать с системой ордерной книги, что значительно расширяет области применения.
Например, если пользователю необходимо обеспечить конфиденциальность ордеров, он может добавить уровень конфиденциальности через контракт, аналогичный Tornado Cash, на HyperEVM, а затем активировать ордер через определенный интерфейс в системе книг заказов Hyperliquid.
Hyperliquid разработал специальную архитектуру для HyperEVM. Учитывая, что производительность настраиваемой системы ордеров значительно превышает производительность среды EVM, чтобы избежать снижения скорости, Hyperliquid использует "двухцепочечную схему": каждый узел одновременно работает с двумя цепочками, локально хранит данные двух цепочек и обрабатывает транзакции отдельно.
Hyperliquid создает специализированную цепочку ( HyperL1 для системы с заказными книгами, с разрешительной системой ), а также добавляет совместимую с EVM цепочку ( HyperEVM, без разрешения ). Данные обеих цепочек распространяются через один и тот же протокол консенсуса, существуя как единое состояние, но работающие в разных средах. Скорость создания блоков в HyperL1 выше, чем в HyperEVM, но блоки по-прежнему выполняются последовательно. Контракты на EVM цепочке могут читать данные из предыдущих блоков L1 и записывать данные в будущие блоки L1.
Взаимодействие HyperL1 и HyperEVM осуществляется в основном через Precompiles и события.
Прекомпиляции
Предварительная компиляция(Precompiles) реализует сложные операции непосредственно на низком уровне, обрабатывая вычисления, неудобные для Solidity, с помощью языков C/C++ и т.д. Предварительная компиляция по сути является специальным смарт-контрактом, к которому могут обращаться другие контракты и получать результаты выполнения. В настоящее время нативный EVM реализовал инструкцию ecRecover( по адресу).
HyperEVM также добавил предкомпилированный код для реализации чтения состояния системы заказов Hyperliquid. Известный адрес предкомпиляции: 0x0000000000000000000000000000000000000800, который может читать позиции бессрочных контрактов пользователей в последних L1 блоках.
События
HyperEVM зависит от Events для записи данных в HyperL1. Events — это родная концепция EVM, позволяющая контрактам отправлять журнальные сообщения внешним системам. Например, при переводе ERC-20 генерируется событие Transfer, что облегчает его отслеживание. Многие кросс-чейн сценарии также используют Events для передачи параметров.
Узел HyperLiquid слушает события, выбрасываемые адресом 0x3333333333333333333333333333333333333333, и на основе информации узнает намерения пользователя и преобразует их в торговые действия, записывая в будущий L1 блок. Если этот адрес предоставляет функцию, при вызове которой выбрасывается событие IocOrder, то когда L1 создает блок, узел извлекает новое событие IocOrder и преобразует его в операцию по размещению лимитного ордера в L1.
ГиперBFT
В области консенсусного протокола Hyperliquid использует протокол HyperBFT, основанный на HotStuff. На начальном этапе использовался алгоритм Tendermint, но он был неэффективен, требуя обмена сообщениями All-to-All на каждом этапе, сложность O(n²).
Чтобы достичь скорости централизованной биржи, команда разработала HyperBFT и реализовала его на Rust. Теоретически он может обрабатывать 2 миллиона заказов в секунду. Все сообщения в HyperBFT сводятся и транслируются Лидером, что устраняет обмен сообщениями между узлами и значительно снижает сложность.
Короче говоря, HyperBFT — это консенсусный протокол, при котором текущий лидер создает блок, все узлы голосуют и отправляют результаты лидеру, после чего происходит смена следующего лидера.
Важные замечания для разработчиков
Механизм чтения данных на основе Precompiles достаточно хорошо развит, но необходимо обратить внимание на проблему msg.sender. Когда пользователь взаимодействует с контрактом L1 и косвенно инициирует транзакцию EVM, msg.sender внутри EVM будет адресом контракта L1, а не адресом пользователя.
Существуют проблемы неатомарности взаимодействия EVM и L1. Если пользователь создает ордер на L1 через EVM, но у него недостаточно средств, сделка не удается, но при вызове функции нет сообщения об ошибке. Разработчику необходимо обработать ситуацию неудачи ордера на стороне контракта EVM и установить функцию возврата средств.
Адрес EVM-контракта на L1 должен иметь сопоставленный аккаунт. После развертывания EVM-контракта необходимо перевести небольшое количество USDC на адрес сопоставления L1 для создания аккаунта.
Обратите внимание на специальные случаи, такие как баланс токенов. L1 имеет специальные адреса для кросс-цепочных активов, но после кросс-цепочки EVM может не успеть создать блок, и пользователи временно не смогут прочитать баланс. Разработчики должны обрабатывать такие ситуации, чтобы избежать паники у пользователей.