Солана: чи зможе наздогнати Hyperliquid?

Нещодавно важливі учасники екосистеми Solana, включаючи Фонд Solana, Anza, Jito Labs та інші, спільно випустили технічну дорожню карту під назвою "Інтернет-капітальні ринки(Internet Capital Markets, ICM)". Основна ідея цієї дорожньої карти - "Контрольована додатками торгівля(Application Controlled Execution, ACE)", що має на меті надати можливість ланцюговим додаткам мати мілісекундний контроль над порядком торгівлі, створюючи децентралізовану "ланцюгову Уолл-стріт".

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

Hyperliquid займає домінуючу позицію на ринку безстрокових контрактів на базі блокчейн, обсяг торгівлі колись становив близько 65% від усього децентралізованого ринку безстрокових контрактів. З огляду на такого конкурента, Solana очевидно не хоче залишатися позаду, тому випустила цю дорожню карту ICM.

Отже, що ж насправді відбувається в цьому "клонуванні"? Чи може Solana насправді наздогнати або навіть перевершити Hyperliquid? Давайте глибше розглянемо це питання.

Фон та зміст ICM

Хто веде цю трансформацію?

Участь у розробці дорожньої карти беруть усі вагомі гравці екосистеми Solana:

• Solana Foundation/Labs: "батько" Solana, відповідальний за загальну координацію та розробку основного протоколу.

• Anza: розробницька компанія, заснована колишніми членами Solana Labs, дещо нагадує ConsenSys з Ethereum. Вони взяли на себе багато ключових технічних завдань у цій дорожній карті, таких як новий консенсусний протокол Alpenglow.

• Jito Labs: Постачальник MEV-інфраструктури на Solana, з величезним впливом, який майже контролює всі MEV-流量 на Solana. Цього разу вони домінують у наданні рішень для сортування транзакцій, таких як Block Assembly Marketplace (BAM).

• Multicoin Capital: відома криптоінвестиційна установа, також один з перших підтримувачів Solana. Завдяки наявності значних обсягів SOL та прав на екосистемні проекти, має значний вплив у технічному напрямку.

• DoubleZero: команда, яка зосереджена на прискоренні мережевої комунікації, пропонує спеціалізовані оптоволоконні мережеві рішення для підвищення швидкості комунікації між верифікаційними вузлами Solana.

• Drift: провідний DEX проект постійних контрактів на Solana. Раніше Drift використовував позамежну модель угод, і в порівнянні з повністю блокчейн Hyperliquid, виглядав дещо важко. Цього разу, беручи участь у розробці дорожньої карти, очевидно, сподівається скористатися оновленням базового рівня, щоб повернутися.

основна проблема, яку потрібно вирішити

Дорожня карта зосереджується на покращенні мікроструктури ринку, простими словами, це означає, що поточний механізм торгівлі на ланцюзі не є достатньо дружнім до маркет-мейкерів, тобто активні учасники торгівлі Taker отримують вигоду, тоді як ті, хто виставляє ордери на виконання, Market Maker ( втрачають. Це пов'язано з тим, що Taker зазвичай володіють актуальною інформацією та активно підвищують торгові комісії, щоб забезпечити пріоритет виконання своїх угод, тоді як Maker часто не встигають відкликати свої ордери і змушені здійснювати угоди за невигідними цінами.

Деякі високочастотні арбітражники використовують цю асиметрію для запуску "отруйних атак". Наприклад, якщо ціна на ланцюзі ще не оновилася, але ціна поза ланцюгом вже змінилася, арбітражники можуть застарілою ціною забрати замовлення у маркет-мейкерів, змушуючи їх нести збитки. В результаті Maker, щоб захистити себе, або збільшує спред між покупкою та продажем, або зменшує обсяг ордерів, що призводить до погіршення ліквідності на всьому ринку.

Дорожня карта ICM має на меті збалансувати цю ситуацію, залучаючи якісну ліквідність назад на блокчейн.

) Три кроки ICM

Solana розділила цей грандіозний план на три етапи:

Короткострокові ###1-3 місяці (: основна мета - оптимізувати існуючий досвід торгівлі в ланцюгу, зробити застосунки для книги замовлень більш зручними, зменшити негативний вплив MEV. Конкретно включає:

• Запуск основної мережі модуля Block Assembly Marketplace)BAM( від Jito Labs. Значення цього модуля полягає в наданні тимчасової системи доповнень, що надає можливість смарт-контрактам на Solana мати автономне право на сортування транзакцій перед запуском фінального ACE)Application Controlled Execution(.

• Команда Anza оптимізувала успішність "входу в одну і ту ж слот", щоб зменшити сліпи та втрати MEV.

Ці покращення, як очікується, будуть реалізовані в період з липня по вересень 2025 року.

Середній )3-9 місяців (: Введення спеціалізованої високошвидкісної мережі та нової версії консенсусу, значне зменшення затримки, підвищення пропускної здатності:

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

• Запровадження консенсусного протоколу Alpenglow, що скорочує час остаточного підтвердження з приблизно 12,8 секунд до приблизно 0,15 секунд.

• Розробка асинхронного виконання програми ) Asynchronous Program Execution, APE (, зменшує блокування виконання транзакцій для консенсусу.

Довгостроковий)9-30 місяців(: Революційне оновлення основної архітектури Solana, мета - реалізувати приблизно до 2027 року:

• Багаторазове паралельне створення блоків )Multiple Concurrent Leaders, MCL(: дозволяє кільком валідаторам одночасно пропонувати транзакції у своїх власних pipeline, а потім об'єднувати та сортувати ці паралельні блоки відповідно до пріоритетних зборів. Це послаблює монополію єдиного пакувальника та підвищує опірність цензурі.

• Нативні додатки контрольованого виконання )Application Controlled Execution, ACE( функція: дійсно надає смарт-контрактам на блокчейні право контролювати порядок виконання транзакцій.

Аналізуючи це, можна сказати, що історія, яка стоїть за пропозицією дорожньої карти ICM, повинна бути такою: старий DEX на Solana, Drift, був перевершений новачком Hyperliquid, який пропонує "чудовий досвід, як у Binance". Drift самостійно не в змозі протистояти, тому змушений звернутися за допомогою до "великих гравців", таких як Solana Labs, Anza, Jito тощо. "Великі гравці" запропонували технічний план реконструкції ICM, стверджуючи, що вони відтворять всі основні навички Hyperliquid для Drift, щоб допомогти йому знову боротися на ринку DEX. Але "великі гравці" також сказали, що ця технічна реконструкція є дуже складною, тому план був розділений на три етапи, і найближчим часом Drift отримає лише обладнання від Jito, щоб пристосуватися і порівняти свої можливості з Hyperliquid.

Чітко визначивши фон історії, у наступних розділах ми детально проаналізуємо, які саме фірмові навички ICM імітує та відтворює з Hyperliquid.

Імітація 1: Механізм сортування торгів

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

) Остаточне рішення ICM: застосування контрольованого виконання ###ACE(

Дорожня карта ICM пропонує концепцію ACE)Application Controlled Execution(, яка передбачає делегування права на сортування транзакцій різним застосункам на ланцюгах, де кожен застосунок самостійно вирішує, як сортувати та виконувати транзакції, пов'язані з цим застосунком. Наприклад, у майбутньому, коли ACE буде реалізовано на Solana, контракти DeFi можуть реалізувати наступні кастомізовані правила сортування транзакцій:

• Оновлення цін Oracle: Додатки DeFi можуть перед великими угодами спочатку вставити угоду для отримання останньої ціни від оркулу, щоб забезпечити виконання замовлення за останньою розумною ціною, запобігаючи арбітражу на основі застарілих цін, які пропонують маркетмейкери.

• Пріоритет скасування замовлення: додаток може встановити пріоритет для "запиту на скасування замовлення" перед виконанням нових "торгових угод", що дозволяє maker мати можливість вчасно скасувати ордер у разі несприятливої ринкової ситуації.

• Аукціон в кінці черги: наприклад, коли з'являється велика купівельна заявка, що підвищує ціну, DeFi додаток виводить можливість "слідом" на аукціон, хто хоче повернути найбільшу вигоду протоколу ) або користувачу (, DeFi протокол дозволяє виконати чиюсь угоду після великої заявки. DeFi додаток може повернути доходи від аукціону користувачам, перетворюючи токсичний MEV трафік на доброчинний дохід.

) BAM JITO: перехідний план

Перед офіційним запуском ACE, Jito Labs представила перехідне рішення під назвою Block Assembly Marketplace ###BAM(. Робочий процес BAM є:

1. Користувач надсилає транзакцію до вузла, що працює на програмному забезпеченні BAM ), а не безпосередньо до поточного Лідера (.

2. BAM-вузли збирають локальні транзакції та виконують різноманітні плагіни )plugin( для повторного впорядкування пакетів транзакцій )Bundle( з захистом конфіденційності ). Плагіни працюють у безпечному середовищі TEE, приховуючи вміст транзакцій ( перед виконанням. Завдяки плагінам розробники додатків можуть налаштовувати різні правила впорядкування для своїх контрактів, наприклад, пріоритет на скасування замовлень, оновлення цін оракулів перед об'єднанням, або навіть виконання складних аукціонів всередині додатку тощо.

3. Відсортований пакет транзакцій знову надсилається лідеру Solana для упаковки в блокчейн.

BAM можна розглядати як дослідницьку площу перед запуском ACE в блокчейн, функціонально вона дуже близька до кінцевого ACE, лише вона працює в незалежній мережі поза блокчейном Solana.

Варто зазначити, що Jito раніше надавала інфраструктуру для вилучення MEV ), таку як Jito Block Engine (, чий бізнес-модель полягала в оптимізації порядку транзакцій для створення можливостей для арбітражників і розподілу прибутку. Це певною мірою стоїть в опозиції до звичайних користувачів і тих, хто підлягає арбітражу, як "спис". Проте, на початку 2024 року Jito закрила функцію публічного мемпулу )mempool (, орієнтовану на арбітражних роботів, щоб зменшити негативні зовнішні ефекти, такі як сандвіч-атаки. Цей крок свідчить про те, що спільнота Solana прагне стримувати шкідливий MEV і підтримувати справедливість для користувачів.

Випуск BAM ще більше відповідає цій ідеї: він по суті перетворює механізм сортування, який спочатку використовувався для арбітражу MEV, на "щит", щоб захистити таких постачальників ліквідності, як маркет-мейкери, наприклад, примусове анулювання заявок першочергово для уникнення збитків маркет-мейкерів, введення конкурсних бонусів для зменшення прибутків від передчасного виконання заявок тощо. Первісні шукачі MEV, якщо хочуть заробити, повинні змінити роль, розробити плагіни BAM для обслуговування DeFi протоколів і заробляти на комісіях за плагіни.

) звернутися до HYPERLIQUID за порадою

Вищезазначена концепція ACE/BAM насправді може бути розглянута як спроба наздогнати механізм угод на Hyperliquid. Hyperliquid є спеціалізованим ланцюгом ###Appchain(, який спочатку створений для обслуговування DEX. Крім того, HLP Vault, що офіційно управляється Hyperliquid, насправді є одним з найбільших маркет-мейкерів цієї платформи, тому не дивно, що правила ланцюга Hyperliquid більше орієнтовані на постачальників ліквідності, вже реалізувавши на рівні ланцюга багато захисних механізмів для маркет-мейкерів, таких як:

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

• Остання цінова гарантія: Процес ліквідації та угоди Hyperliquid підкреслює використання останніх цінових котирувань та стану маржі для "подвійної перевірки". Наприклад, коли є угода з виконаними ордерами, система повторно отримує останню ціну з оракула для оцінки маржі обох сторін, щоб забезпечити, що ризик не виникне через затримку в ціні. Це схоже на ACE, що вставляє оновлення оракула перед виконанням угоди.

• Захист від самостійних угод: якщо одна адреса купує і продає одночасно, Hyperliquid автоматично скасовує угоду, а не виконує її, щоб запобігти маніпуляціям обсягом або непотрібним витратам.

ACE/BAM на Solana ICM безумовно є спробою "вчитися" у Hyperliquid. Hyperliquid, як лідер на ринку CLOB, реалізував різноманітні механізми, дружні до маркет-мейкерів, за допомогою спеціалізованого блокчейну. Тепер Solana сподівається використати універсальний блокчейн і модульні плагіни, щоб відтворити цей ефект------тобто дозволити кожному застосунку мати контроль над порядком торгівлі, подібно до Hyperliquid.

Імітація два: миттєва остаточність

) Існуюче порівняння консенсусу

Solana наразі використовує Tower BFT, підтвердження та фіналізація є ймовірнісними поступовими: блок отримує 2/3 голосів і вважається "підтвердженим ###Confirmed(", але потрібно накопичити приблизно 32 наступних блоки ) зазвичай близько 13 секунд (, щоб бути закріпленим як "остаточно підтверджений )Finalized(". Для деяких застосувань ), таких як високочастотна торгівля (, декілька секунд часу остаточного підтвердження все ще занадто довго.

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

• Перший раунд: попереднє голосування ) Prevote (: валідатори, отримавши кандидатний блок, транслюваний Пропозером, проводять швидку верифікацію. Якщо верифікація пройдена, кожен валідатор голосує за цей блок, віддаючи один "попередній голос" ) Prevote (, і транслює його в мережі. Цей голос означає: "Я попередньо переглянув, з цим блоком все в порядку."

• Другий раунд: попереднє подання ) Precommit (: як тільки певний валідатор збирає більше ніж дві третини голосів валідаторів за той самий кандидуючий блок Prevote, він отримує достатню впевненість, вважаючи, що більшість членів мережі підтримує цей блок. Тому цей валідатор голосує за більш значну "попередню подачу" ) Precommit (, і