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

Нещодавно на увагу потрапила певна біржа з книжкою замовлень в блокчейні, яка стала одним з найбільш впливових проєктів, її загальна заблокована вартість (TVL) перевищила 2 мільярди доларів США, і її оцінили як "блокчейн-версію певної відомої централізованої біржі". Цей проєкт навіть повернув концепцію Layer3 та аплікаційних ланцюгів у публічну свідомість. Завдяки блискучим результатам, які призвели до оцінки в 30 мільярдів доларів США протягом місяця після запуску, цей проєкт здобув широку увагу. На ринку з'явилася велика кількість аналітичних звітів, але більшість зосереджені на функціональності продукту та механізмах торгівлі, рідко глибоко досліджують його технічну структуру та можливі ризики безпеки.

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

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

Цей проект розгорнув кросчейн міст на певній Layer2 мережі для зберігання активів USDC, внесених користувачами. З контракту можна побачити частину поведінки вузлів.

Набір валідаторів

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

• Гарячі валідатори використовуються для реагування на часті операції користувачів, такі як виведення, використовуючи гарячий гаманець для швидкого реагування на запити користувачів.

• Холодні валідатори в основному використовуються для зміни конфігурацій системи, таких як зміна списку валідаторів, обробка статусу блокування контрактів моста, можуть безпосередньо робити деякі запити на виведення недійсними.

• Заблоковані особи, подібно до "Комісії з безпеки", можуть голосувати за призупинення крос-чейн мосту в екстрених ситуаціях. Наразі є 5 адрес, для призупинення контракту мосту потрібно лише 2 голоси.

• Уповноважена особа головним чином підтверджує зміни стану кросчейн-мосту, такі як внесення та зняття коштів користувачами.

Депозит

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

Виведення

Виведення коштів є високоризикованою операцією, процес є досить складним:

1. Після того, як користувач ініціює запит на виведення коштів, потрібно зібрати 2/3 підписного ваги від кола гарячих валідаторів.

2. Є 200 секунд "періоду спірності", протягом якого особи, що заморожують, можуть голосувати за заморожування контракту, а холодні валідатори можуть зробити зняття недійсним.

3. Після закінчення періоду спірів, особа, що приймає рішення, може підтвердити остаточний статус, і лише тоді USDC буде переведено до гаманця користувача.

Заблокування мостового контракту

Заблоковані особи можуть голосувати за блокування мостового контракту. Після голосування двох заблокованих осіб контракт припиняє свою роботу. Заблоковані особи також можуть відкликати голосування. Після блокування контракту його можна розблокувати лише за підписом 2/3 холодних валідаторів. При розблокуванні оновлюється список валідаторів.

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

Оновлення валідаторів потребує підпису всіх гарячих валідаторів, є 200-секундний період оскарження. По закінченню терміну необхідно підтвердження від особи, що відповідає за завершення оновлення.

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

1. Хакер, контролюючи холодного валідатора, може ігнорувати блокування та красти активи користувачів.

2. Установник може відмовитися підтвердити операцію з виведення коштів, розпочати перевірку атаки.

3. Зловмисне блокування мостового контракту особою, призупинити всі виведення.

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

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

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

1. Ланцюг спеціально для книг замовлень: дозвільний, висока продуктивність

2. EVM-сумісний ланцюг: без дозволу, можна розгортати смарт-контракти, доступ до даних спеціалізованого ланцюга через попередньо скомпільовані функції

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

механізм взаємодії

1. Попередня компіляція: додати спеціальний контракт, дозволити EVM зчитувати стан спеціалізованого ланцюга.

2. Подія: EVM-контракти можуть викликати події, на основі яких вузли виконують відповідні дії у спеціалізованому ланцюзі.

Протокол консенсусу

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

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

1. msg.sender може бути адресою системного контракту

2. Невзаємодіяна атомність може призвести до втрати активів

3. Адреса EVM-контракту повинна бути відображена на спеціалізованому ланцюзі

4. При кросс-лінейному переміщенні активів баланс може тимчасово бути недоступний для перевірки.

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