Глибокий технічний аналіз Hyperliquid: містові контракти, HyperEVM та потенційні проблеми

Hyperliquid, як широко відомий біржовий майданчик з онлайновою книгою замовлень, має технологічну архітектуру та безпеку, які заслуговують на глибоке обговорення. У цій статті буде проведено аналіз з трьох аспектів: структури кросчейн-мосту, особливостей технології HyperEVM та потенційних загроз безпеці.

Аналіз кросчейн-мосту Hyperliquid

Hyperliquid розгорнув контракт крос-чейн мосту на Arbitrum для зберігання активів USDC користувачів. З точки зору розподілу ідентичності вузлів, Hyperliquid має чотири групи валідаторів:

• hotValidatorSet: відповідає за обробку високочастотних операцій, таких як виведення коштів користувачем
• coldValidatorSet: відповідає за зміну конфігурації системи та обробку виняткових ситуацій
• lockers: подібно до комісії з безпеки, можуть голосувати за призупинення мостового контракту
• финалізатори: підтвердження зміни стану міжланцюгового моста

Процедура внесення депозиту

Місткові контракти використовують метод Permit EIP-2612 для обробки депозитів, дозволяючи лише внесення USDC. Операція депозиту є досить простою, в основному обробляється через функцію batchedDepositWithPermit.

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

Процес виведення коштів досить складний:

1. Користувач ініціює запит на виведення
2. підтвердження ваги підписів 2/3 для hotValidatorSet
3. 200 секундний спірний період
4. остаточне підтвердження членів finalizers

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

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

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

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

Оновлення hotValidatorSet та coldValidatorSet через функцію updateValidatorSet вимагає підпису всіх членів hotValidatorSet і має 200-секундний період оскарження.

Основні ризики

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

HyperEVM та архітектура взаємодії з подвійним ланцюгом

Для реалізації програмованості торгівлі наOrder Book, Hyperliquid представив рішення HyperEVM. Його особливості:

1. Можливість читати статус книги замовлень Hyperliquid
2. Можна взаємодіяти з системою книг замовлень Hyperliquid

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

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

Дві ланцюги взаємодіють через Precompiles та Events:

• Препроцесори: попередньо скомпільований код, дозволяє EVM читати стан L1
• Події: EVM викидає події, L1 вузол слухає та виконує відповідні операції

HyperBFT консенсус

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

Зауваження для розробників

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

Підсумок

Hyperliquid поєднує високу продуктивність книги замовлень та програмованість завдяки дволанцюговій архітектурі та інноваційним механізмам взаємодії. Однак його складна механіка валідації та крос-ланцюгова взаємодія також створюють потенційні ризики безпеки, які варто уважніше розглянути та оптимізувати.