Глибокий аналіз архітектури та потенційних ризиків Hyperliquid з технічної точки зору

Hyperliquid, як нещодавно відзначена на ланцюговій біржі з ORDER BOOK, має TVL, що перевищує 2 мільярди доларів, і вважається "ланцюговим Binance". У цій статті ми детально проаналізуємо структуру мостового контракту Hyperliquid з технічної точки зору, архітектуру HyperEVM та її потенційні ризики безпеки, щоб допомогти читачам всебічно зрозуміти технічну конструкцію цього зіркового проекту.

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

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

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

Процес депозиту

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

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

Запит на виведення коштів має отримати 2/3 підписів від hotValidatorSet. Після цього є 200 секунд "періоду спірності", протягом якого lockers можуть призупинити контракт або coldValidatorSet може зробити виведення недійсним. Після періоду спірності finalizers підтверджують остаточний стан.

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

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

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

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

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

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

HyperEVM та дволанкової взаємодії архітектура

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

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

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

Преконпілі

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

Події

HyperEVM записує дані в L1 через події. Вузли L1 слідкують за подіями з певних адрес і перетворюють їх на транзакції L1.

HyperBFT консенсус

Розроблено на базі HotStuff, теоретично може обробляти 2 мільйони замовлень на секунду. Використовує метод лідера для підсумовування та трансляції, що знижує складність.

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

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

В цілому, HyperEVM подібний до архітектури другого рівня на базі L1, але забезпечує вищу взаємодію. Розробникам слід звернути увагу на обробку різних особливих випадків, щоб забезпечити безпеку активів користувачів.