Глибокий аналіз 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 може обробляти кілька депозитів одночасно, процес є досить простим.

Процес виведення коштів

Запит на зняття коштів повинен відповідати таким умовам:

1. Отримати 2/3 ваги підписів hotValidatorSet
2. Після 200 секунд спірного періоду
3. Остаточне підтвердження членами фіналізаторів

Протягом спірного періоду lockers можуть голосувати за призупинення мостового контракту, а coldValidatorSet може анулювати запити на виведення.

Механізм блокування мостового контракту

2 голоси lockers достатньо, щоб заблокувати міст контракт. Для розблокування потрібно 2/3 підписів coldValidatorSet, а також можна оновити адресу валідатора.

Оновлення валідаторів

Функція updateValidatorSet може оновити hotValidatorSet та coldValidatorSet, для цього потрібні підписи всіх учасників hotValidatorSet, а також проходження 200-секундного періоду оскарження.

Потенційні ризики

1. coldValidatorSet, який контролюється, може обійти всі лінії захисту, щоб вкрасти активи користувачів.
2. фіналізатори можуть відмовити в підтвердженні транзакції на виведення коштів
3. lockers можуть зловмисно заблокувати містовий контракт

HyperEVM та дволанкова архітектура

Hyperliquid використовує "подвійну ланцюгову схему", одночасно працюючи на двох ланцюгах:

1. Hyperliquid L1: спеціально для системи книги замовлень, ліцензійна
2. HyperEVM: EVM-сумісний ланцюг, без дозволу

Дві мережі поширюють дані через один і той же консенсусний протокол, але працюють в різних середовищах виконання. HyperEVM може читати стан L1 і записувати дані в L1.

Прекомпіляції

HyperEVM читає стан L1 через попередньо скомпільований код. Відомий адреса попередньо скомпільованого коду 0x800 може зчитувати позиції користувацьких безстрокових контрактів з останнього блоку L1.

Події

HyperEVM пише дані на L1 через події. Вузли L1 слухають певну адресу (0x3333...3333) для подій, перетворюючи наміри користувачів на транзакції L1.

HyperBFT консенсус

Hyperliquid використовує алгоритм консенсусу HyperBFT на основі HotStuff, який теоретично може обробляти 2 мільйони замовлень на секунду.

Поради щодо розробки

1. msg.sender може бути адресою контракту системи L1
2. Нев атомарність взаємодії EVM з L1 може призвести до втрати активів
3. Адреса EVM-контракту повинна мати відображення облікового запису в L1
4. Під час крос-чейн трансакцій можуть виникати тимчасові проблеми з перевіркою балансу.

Загалом, HyperEVM подібний до другого рівня на основі Hyperliquid L1, але пропонує вищу взаємодію.