Глибоке дослідження технічної конструкції та безпекових ризиків Hyperliquid
Нещодавно широко обговорювана Hyperliquid є однією з найвпливовіших бірж з книжкою ордерів на базі блокчейну, її загальна заблокована вартість вже перевищила 2 мільярди доларів, і в індустрії її оцінюють як "блокчейн-версію відомої централізованої біржі". Це також знову викликало дискусію про Layer3 і застосункові ланцюги. Завдяки вражаючим результатам, коли за місяць після запуску вартість проєкту досягла 30 мільярдів доларів, Hyperliquid отримала широку увагу. На ринку вже є чимало аналітичних звітів про Hyperliquid, але більшість зосереджена на функціональності продукту та механізмі торгівлі, не вистачає глибокого аналізу її технічної архітектури та потенційних ризиків безпеки.
Ця стаття має на меті заповнити цю прогалину, чисто з технічної та безпекової точки зору аналізуючи Hyperliquid, щоб допомогти читачам краще зрозуміти внутрішню структуру та принципи цього зіркового проекту. Ми зосередимося на аналізі дизайну та ризиків контракту міжланцюгового мосту Hyperliquid, а також на подвійній архітектурі HyperEVM та HyperL1, глибоко досліджуючи технологічні реалізації, що стоять за цим.
Розшифровка кросчейн-мосту Hyperliquid
Оскільки Hyperliquid не відкрив свої основні компоненти, але відкрив відповідні місткові контракти, ми маємо більше розуміння ризиків, пов'язаних з містковими контрактами. Hyperliquid розгорнув містковий контракт на певній мережі Layer2 для зберігання активів USDC, внесених користувачами, і ми можемо спостерігати за частковою поведінкою вузлів Hyperliquid через компонент Bridge.
Набір валідаторів
З точки зору поділу за ідентичністю вузлів, Hyperliquid має 4 групи валідаторів: hotValidatorSet, coldValidatorSet, а також finalizers і lockers, кожен з яких виконує різні обов'язки. hotValidatorSet відповідає за реагування на часті операції користувачів, такі як зняття коштів тощо, зазвичай використовує гарячий гаманець для своєчасної обробки запитів користувачів.
coldValidatorSet в основному використовується для зміни конфігурації системи, наприклад, для оновлення списку інших наборів валідаторів або для обробки стану блокування мостового контракту, а також має право безпосередньо анулювати деякі запити на виведення.
lockers є групою валідацій з особливими правами, подібно до "комітету безпеки" в Layer2, які можуть голосувати за те, щоб призупинити роботу міжланцюгового мосту в екстрених ситуаціях. Наразі колекція lockers для моста Hyperliquid містить 5 адрес, і для призупинення контракту моста потрібно лише 2 голоси locker.
фіналізатори також є групою спеціальних валідаторів, які в основному використовуються для підтвердження змін стану крос-чейн мостів, таких як операції користувачів з внесення та зняття. Крос-чейн міст Hyperliquid використовує механізм "подання-підтвердження", після того як користувач ініціює зняття, потрібно почекати певний "період оскарження", по закінченню якого фіналізатори виконують транзакцію на зняття.
У разі виникнення проблем, якщо певний запит на виведення перевищує фактичний баланс користувача, вузли Hyperliquid можуть під час суперечливого періоду через голосування locker'ів призупинити містковий контракт або безпосередньо зробити проблемний вивід недійсним 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, яка дозволяє locker'ам відкликати голосування. Як тільки контракт моста заблоковано, його можна розблокувати лише за допомогою функції emergencyUnlock, для цього потрібно зібрати підписи понад 2/3 членів coldValidatorSet.
emergencyUnlock під час розблокування оновлює адреси колекцій перевіряючих hotValidatorSet та coldValidatorSet і негайно набирає чинності.
Оновлення колекції валідаторів
Порівняно з проривом лінії процесу виведення коштів, безпосереднє використання функції updateValidatorSet для оновлення набору валідаторів є більш ефективним засобом атаки. Це вимагає підпису всіх членів hotValidatorSet і має 200-секундний період оскарження.
Після закінчення періоду оскарження члени finalizers повинні викликати функцію finalizeValidatorSetUpdate для завершення остаточного оновлення.
Підсумовуючи, контракт моста Hyperliquid має такі ризики:
Хакери, які контролюють coldValidatorSet, можуть ігнорувати перешкоди для крадіжки активів користувачів. Оскільки coldValidatorSet має права emergencyUnlock, він може зробити lockers недійсними та миттєво оновити список вузлів. Наразі лише 4 вузли верифікаторів, ризик крадіжки приватного ключа не малий;
фіналізатори відмовляються підтверджувати транзакції на зняття користувачів, розгортаючи перевірку на атаки. У цей момент активи користувача в безпеці, але можуть бути недоступними для зняття;
lockers зловмисно блокують кросчейн мости, заважаючи виконанню всіх транзакцій на виведення, можна лише чекати, поки coldValidatorSet розблокує.
HyperEVM та архітектура взаємодії подвійних ланцюгів
Для реалізації програмування торгівлі на основі ордерів, наприклад, шляхом впровадження приватних угод, що потребують підтримки смарт-контрактів, Hyperliquid запроваджує рішення HyperEVM. Воно має дві основні переваги в порівнянні з традиційним EVM: можливість читання стану ордерної книги Hyperliquid та внутрішні смарт-контракти, які можуть взаємодіяти з системою ордерної книги, значно розширюючи сфери застосування.
Наприклад, якщо користувачеві потрібно забезпечити конфіденційність ордерів, він може на HyperEVM через контракти, подібні до Tornado Cash, додати шар конфіденційності, а потім через спеціальний інтерфейс в системі ордерів Hyperliquid активувати ордер.
Hyperliquid розробив спеціальну архітектуру для HyperEVM. Враховуючи, що продуктивність налаштованої системи order book значно перевищує середовище EVM, щоб уникнути зниження швидкості, Hyperliquid використовує "подвійну ланцюгову схему": кожен вузол одночасно запускає дві ланцюги, локально зберігаючи дані обох ланцюгів та обробляючи транзакції окремо.
Hyperliquid встановлює спеціальний ланцюг для системи ордерів ( HyperL1, з ліцензуванням ), одночасно впроваджуючи EVM-сумісний ланцюг ( HyperEVM, без ліцензування ). Дані обох ланцюгів поширюються через один і той же консенсусний протокол, існуючи як єдиний стан, але працюючи в різних середовищах. Швидкість створення блоків HyperL1 перевищує HyperEVM, але блоки все ще виконуються в порядку. Контракти на EVM-ланцюгу можуть читати дані з попередніх L1 блоків і записувати дані в майбутні L1 блоки.
Взаємодія між HyperL1 та HyperEVM в основному здійснюється через Precompiles та Events.
Преконпіль
Попередня компіляція ( Precompiles ) виконує складні операції безпосередньо на нижньому рівні, використовуючи мови C/C++ для обробки обчислень, незручних для Solidity. Попередня компіляція по суті є спеціальним смарт-контрактом, до якого можуть звертатися інші контракти для отримання результатів виконання. В даний час рідний EVM реалізував інструкцію ecRecover за допомогою попередньої компіляції ( адреси ).
HyperEVM також додав попередньо скомпільований код, що дозволяє читати стан системи замовлень Hyperliquid. Відомо, що одна з попередньо скомпільованих адрес є 0x0000000000000000000000000000000000000800, що дозволяє читати позиції постійних контрактів користувачів у останньому блоці L1.
Події
HyperEVM записує дані в HyperL1 за допомогою Events. Events є рідною концепцією EVM, яка дозволяє контрактам надсилати журнали інформації зовні. Наприклад, при переказі ERC-20 виникає подія Transfer, що полегшує прослуховування. Багато міжланцюгових сценаріїв також використовують Events для передачі параметрів.
HyperLiquid вузол слухає події, що виникають з адреси 0x3333333333333333333333333333333333333333, отримуючи інформацію про наміри користувача і перетворюючи їх у交易动作, записуючи в майбутній блок L1. Якщо ця адреса надає функцію, при виклику якої виникає подія IocOrder, вузол під час формування блоку L1 виявляє нову подію IocOrder і перетворює її в операцію з розміщення ордера в L1.
Технологія HyperBFT
У сфері консенсусних протоколів 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, а також finalizers і lockers, кожен з яких виконує різні обов'язки. hotValidatorSet відповідає за реагування на часті операції користувачів, такі як зняття коштів тощо, зазвичай використовує гарячий гаманець для своєчасної обробки запитів користувачів.
coldValidatorSet в основному використовується для зміни конфігурації системи, наприклад, для оновлення списку інших наборів валідаторів або для обробки стану блокування мостового контракту, а також має право безпосередньо анулювати деякі запити на виведення.
lockers є групою валідацій з особливими правами, подібно до "комітету безпеки" в Layer2, які можуть голосувати за те, щоб призупинити роботу міжланцюгового мосту в екстрених ситуаціях. Наразі колекція lockers для моста Hyperliquid містить 5 адрес, і для призупинення контракту моста потрібно лише 2 голоси locker.
фіналізатори також є групою спеціальних валідаторів, які в основному використовуються для підтвердження змін стану крос-чейн мостів, таких як операції користувачів з внесення та зняття. Крос-чейн міст Hyperliquid використовує механізм "подання-підтвердження", після того як користувач ініціює зняття, потрібно почекати певний "період оскарження", по закінченню якого фіналізатори виконують транзакцію на зняття.
У разі виникнення проблем, якщо певний запит на виведення перевищує фактичний баланс користувача, вузли Hyperliquid можуть під час суперечливого періоду через голосування locker'ів призупинити містковий контракт або безпосередньо зробити проблемний вивід недійсним 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, яка дозволяє locker'ам відкликати голосування. Як тільки контракт моста заблоковано, його можна розблокувати лише за допомогою функції emergencyUnlock, для цього потрібно зібрати підписи понад 2/3 членів coldValidatorSet.
emergencyUnlock під час розблокування оновлює адреси колекцій перевіряючих hotValidatorSet та coldValidatorSet і негайно набирає чинності.
Оновлення колекції валідаторів
Порівняно з проривом лінії процесу виведення коштів, безпосереднє використання функції updateValidatorSet для оновлення набору валідаторів є більш ефективним засобом атаки. Це вимагає підпису всіх членів hotValidatorSet і має 200-секундний період оскарження.
Після закінчення періоду оскарження члени finalizers повинні викликати функцію finalizeValidatorSetUpdate для завершення остаточного оновлення.
Підсумовуючи, контракт моста Hyperliquid має такі ризики:
Хакери, які контролюють coldValidatorSet, можуть ігнорувати перешкоди для крадіжки активів користувачів. Оскільки coldValidatorSet має права emergencyUnlock, він може зробити lockers недійсними та миттєво оновити список вузлів. Наразі лише 4 вузли верифікаторів, ризик крадіжки приватного ключа не малий;
фіналізатори відмовляються підтверджувати транзакції на зняття користувачів, розгортаючи перевірку на атаки. У цей момент активи користувача в безпеці, але можуть бути недоступними для зняття;
lockers зловмисно блокують кросчейн мости, заважаючи виконанню всіх транзакцій на виведення, можна лише чекати, поки coldValidatorSet розблокує.
HyperEVM та архітектура взаємодії подвійних ланцюгів
Для реалізації програмування торгівлі на основі ордерів, наприклад, шляхом впровадження приватних угод, що потребують підтримки смарт-контрактів, Hyperliquid запроваджує рішення HyperEVM. Воно має дві основні переваги в порівнянні з традиційним EVM: можливість читання стану ордерної книги Hyperliquid та внутрішні смарт-контракти, які можуть взаємодіяти з системою ордерної книги, значно розширюючи сфери застосування.
Наприклад, якщо користувачеві потрібно забезпечити конфіденційність ордерів, він може на HyperEVM через контракти, подібні до Tornado Cash, додати шар конфіденційності, а потім через спеціальний інтерфейс в системі ордерів Hyperliquid активувати ордер.
Hyperliquid розробив спеціальну архітектуру для HyperEVM. Враховуючи, що продуктивність налаштованої системи order book значно перевищує середовище EVM, щоб уникнути зниження швидкості, Hyperliquid використовує "подвійну ланцюгову схему": кожен вузол одночасно запускає дві ланцюги, локально зберігаючи дані обох ланцюгів та обробляючи транзакції окремо.
Hyperliquid встановлює спеціальний ланцюг для системи ордерів ( HyperL1, з ліцензуванням ), одночасно впроваджуючи EVM-сумісний ланцюг ( HyperEVM, без ліцензування ). Дані обох ланцюгів поширюються через один і той же консенсусний протокол, існуючи як єдиний стан, але працюючи в різних середовищах. Швидкість створення блоків HyperL1 перевищує HyperEVM, але блоки все ще виконуються в порядку. Контракти на EVM-ланцюгу можуть читати дані з попередніх L1 блоків і записувати дані в майбутні L1 блоки.
Взаємодія між HyperL1 та HyperEVM в основному здійснюється через Precompiles та Events.
Преконпіль
Попередня компіляція ( Precompiles ) виконує складні операції безпосередньо на нижньому рівні, використовуючи мови C/C++ для обробки обчислень, незручних для Solidity. Попередня компіляція по суті є спеціальним смарт-контрактом, до якого можуть звертатися інші контракти для отримання результатів виконання. В даний час рідний EVM реалізував інструкцію ecRecover за допомогою попередньої компіляції ( адреси ).
HyperEVM також додав попередньо скомпільований код, що дозволяє читати стан системи замовлень Hyperliquid. Відомо, що одна з попередньо скомпільованих адрес є 0x0000000000000000000000000000000000000800, що дозволяє читати позиції постійних контрактів користувачів у останньому блоці L1.
Події
HyperEVM записує дані в HyperL1 за допомогою Events. Events є рідною концепцією EVM, яка дозволяє контрактам надсилати журнали інформації зовні. Наприклад, при переказі ERC-20 виникає подія Transfer, що полегшує прослуховування. Багато міжланцюгових сценаріїв також використовують Events для передачі параметрів.
HyperLiquid вузол слухає події, що виникають з адреси 0x3333333333333333333333333333333333333333, отримуючи інформацію про наміри користувача і перетворюючи їх у交易动作, записуючи в майбутній блок L1. Якщо ця адреса надає функцію, при виклику якої виникає подія IocOrder, вузол під час формування блоку L1 виявляє нову подію IocOrder і перетворює її в операцію з розміщення ордера в L1.
Технологія HyperBFT
У сфері консенсусних протоколів 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 може не відразу згенерувати блок, і користувач тимчасово не зможе прочитати баланс. Розробники повинні вирішувати такі ситуації, щоб уникнути паніки у користувачів.