Різка оцінка дорожньої карти "інтернет-ринку капіталу" Solana: шоу наслідування Hyperliquid

🚀 Передмова: SOLANA про зустріч.

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

Проте цікаво, що, читаючи всю дорожню карту, хоча Hyperliquid не згадується безпосередньо, дизайн практично в кожному місці націлений на сильні сторони Hyperliquid. Це як Солана говорить: “Те, що маєте ви, 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 місяці): основна мета - оптимізувати існуючий досвід торгівлі на блокчейні, зробити застосунки типу order book більш зручними, зменшити негативний вплив MEV. Конкретні заходи включають:

• Модуль Block Assembly Marketplace (BAM) від Jito Labs запущено в основній мережі. Значення цього модуля полягає в тому, щоб забезпечити тимчасову систему сторонніх програм до запуску остаточного ACE (Application Controlled Execution), дозволяючи смарт-контрактам на Solana мати автономні права на сортування угод.
• Команда 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, стверджуючи, що повинні відтворити у Drift всі основні навички Hyperliquid, щоб допомогти йому знову змагатися на ринку DEX. Але “про” також сказали, що ця технічна модернізація є надзвичайно складною, тому технічний план розділений на три етапи, і найближчим часом Drift зможе отримати лише обладнання Jito’s BAM, щоб Drift міг пристосуватися і спробувати конкурувати з Hyperliquid.

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

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

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

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

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

• Оновлення ціни Oracle: Додатки DeFi можуть перед великою угодою вставити угоду для отримання останньої ціни від оракула, щоб забезпечити виконання замовлення за останньою справедливою ціною, запобігаючи арбітражу на основі застарілих цін, які пропонують маркет-мейкери.
• Пріоритет виконання скасування замовлення: Додаток може налаштувати, щоб “запит на скасування” мав пріоритет над новою “торгівлею на купівлю”, що дає можливість maker своєчасно скасувати ордер у ненависному ринковому середовищі.
• Аукціон на хвості команди: наприклад, коли з’являється велика заявка на покупку, що підвищує ціну, DeFi-додаток виставляє на аукціон можливість “слідувати за нею”, і хто готовий повернути найбільше вигоди протоколу (або користувачу), той отримує можливість виконання свого交易 поруч з великою заявкою. DeFi-додатки можуть повернути доходи від аукціону користувачам, перетворюючи токсичний MEV-трафік на благополучний дохід.

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

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

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

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

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

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

Звернення до HYPERLIQUID

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

• Пріоритет захисту замовлень на продаж: Скасування замовлень та лише створення maker-замовлень обробляються в першу чергу, щоб уникнути несприятливих угод для маркет-мейкерів без їх відома. “Пріоритетне виконання скасувань”, згадане Solana ACE, Hyperliquid вже практикує багато років.
• Гарантія найновішої ціни: Процес ліквідації та матчинг в Hyperliquid підкреслює використання найновіших цінових даних та статусу маржі для “подвійної перевірки”. Наприклад, коли є угода на виконання ордера, система знову запитує найновішу ціну з оракула для оцінки маржі обох сторін, щоб забезпечити, що ризик не виникає через затримку ціни. Це подібно до того, як ACE вставляє оновлення оракула перед виконанням угоди.
• Захист від самостійних угод: якщо одна й та ж адреса купує та продає, Hyperliquid автоматично скасовує, а не здійснює угоду, щоб запобігти маніпуляціям з обсягом або непотрібним витратам.

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

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

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

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

HyperBFT є консенсусним алгоритмом, розробленим Hyperliquid, натхненим консенсусом HotStuff, який використовує двохраундне голосування для підтвердження блоку, забезпечуючи “миттєву фінальність”.

• Перший раунд: попереднє голосування (Prevote): валідатор отримує кандидатний блок, розповсюджений Proposer, і проводить швидку перевірку. Якщо перевірка пройшла, кожен валідатор голосує за цей блок однією “попередньою голосувальною” (Prevote)票 і розповсюджує його по всій мережі. Ця голосування представляє: “Я попередньо переглянув, цей блок в порядку.”
• Другий раунд: попереднє подання ( Precommit ): Як тільки якийсь валідатор зібрав більше двох третин голосів валідаторів за один і той же кандидатний блок Prevote, він отримує достатньо впевненості, вважаючи, що більшість учасників мережі визнає цей блок. Отже, цей валідатор подає більш значущу “попередню заяву” ( Precommit ) і розповсюджує її. Ця заява представляє: “Я бачив, що більшість мережі згодна, я готовий офіційно записати цей блок у реєстр.”
• Коли валідатор збирає більше ніж дві третини валідаторів з приводу одного й того ж кандидатного блоку Precommit, досягається консенсус! Цей блок вважається остаточно затвердженим (Finalized). Він буде назавжди, незворотно доданий до блокчейну.

Це означає, що кожен блок Hyperliquid є остаточним блоком, немає можливості для відкату розгалужень, затримка видачі блоків по всьому ланцюгу дуже низька — офіційно розкрито середню затримку підтвердження близько 0,2 секунди, у 99% випадків не перевищує 0,9 секунди. Така мілісекундна остаточна визначеність є дуже ідеальною для високочастотної торгівлі, оскільки після відправлення угоди вона швидко підтверджується і не може бути перепризначена, що значно підвищує ефективність капіталу.

ALPENGLOW реалізує миттєву остаточність

Alpenglow - це новий консенсусний протокол, який Solana готує до запуску, метою якого є прискорення остаточного підтвердження блоків до 1-2 слота (приблизно 150 мс), досягнення подібної до HyperBFT миттєвої остаточності. Компонент, що відповідає за консенсус в Alpenglow замість TowerBFT, називається Votor, це набір двохсмугової системи голосування:

• Швидкий прохід: Якщо на першому раунді голосування блоку більше або дорівнює 80% мережевого “права” (можна розуміти як вага голосування, що представляє кількість SOL токенів, які закладені валідаторами), проголосують за те, що цей блок є дійсним, то цей блок буде негайно підтверджений як “остаточний” (Finalize).
• Повільний канал: Якщо в першому раунді голосування частка згоди не досягла 80%, але становить 60% або більше, Votor розпочне другий раунд голосування. Якщо після завершення другого раунду голосування частка згоди щодо цього блоку залишається на рівні 60% або вище, цей блок також буде остаточно підтверджено.

Votor рівноцінно говорить: “Ми за замовчуванням підтверджуємо голосування в один тур, але якщо умови не ідеальні, ми запускаємо процес голосування в два тури, майже такий же, як HyperBFT, як страхування.” насправді це просто імітація механізму голосування Hyperliquid.

Вартість та заходи щодо миттєвої остаточності

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

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

• У Alpenglow є ще один компонент Rotor, який замінює старий протокол розподілу даних Turbine. На відміну від Turbine, який потребує багаторівневої пересилки, Rotor використовує режим “одноступеневої ретрансляції”, що дозволяє блокам даних досягати цільового валідатора з більшою швидкістю, що значно зменшує затримку передачі. Крім того, у поточному механізмі Turbine позиція вузлів у дереві розподілу даних в основному визначається за вагою stake, причому вузли з більшою stake розташовуються на вищих рівнях і отримують пріоритет у отриманні фрагментів даних (shreds), але через це їм також доводиться виконувати більше завдань з подальшої пересилки, що призводить до більшого споживання пропускної здатності. Припущення, яке стоїть за таким дизайном, полягає в тому, що вузли з великим stake зазвичай є “багатими людьми”, які, напевно, мають більш потужне обладнання та більш достатні ресурси пропускної здатності. Rotor оновлює цю логіку, більше не покладаючись лише на розмір stake, а всебічно оцінюючи реальну пропускну здатність та комунікаційні характеристики кожного вузла. Ті вузли, які демонструють кращі результати в реальних мережах, будуть динамічно розміщені на ключових позиціях, тим самим забезпечуючи оптимальний шлях розповсюдження даних для всієї мережі, реалізуючи швидку та стабільну “доставку”.
• DoubleZero швидкісна мережа базується на спеціалізованій волоконно-оптичній мережі + технології мультикасту, забезпечуючи комунікацію з низькою затримкою, що швидша на порядок порівняно з публічним Інтернетом. Це зменшує затримку та джиттер повідомлень між географічно розподіленими вузлами, роблячи фізичну мережу для швидкого консенсусу більш надійною.

Навіть незважаючи на це, Solana досягти “високої децентралізації + мілісекундної фінальності” одночасно все ще є надзвичайно складним завданням. Саме тому Alpenglow очікує, що знадобиться ще понад рік на розробку, і рішення має бути запущене на початку 2026 року (залишається лише сподіватися на це).

🔄 Імітація три: асинхронне виконання конвеєра

Асинхронний конвеєр HYPERLIQUID

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

А Hyperliquid, навпаки, впроваджує багатопоточність, розділяючи робочий процес на дві паралельні лінії: “сортування (консенсус)” та “виконання”. Його процес виконання виглядає так:

1. Часова точка T1:

   • Консенсусний конвеєр: Верифікатори досягають згоди щодо змісту та порядку транзакцій блоку N-1.

2. Часова точка T2 ( Місце, де починається магія ):

   • Консенсусний конвеєр: Починає обробку блоку N. Він пакує, сортує транзакції у мережі і голосує за цей порядок, досягаючи консенсусу. Йому абсолютно не цікаві результати виконання блоку N-1.
   • Виконання конвеєра: Отримати блок N-1, по якому вже досягнуто консенсусу на момент T1, і почати виконання його транзакцій.

3. Часова точка T3 (безперервна робота конвеєра):

   • Консенсусний конвеєр: Завершено досягнення консенсусу по блоку N і передано результати консенсусу (упорядкований список транзакцій) до виконавчого конвеєра. Потім він без зупинок починає обробку блоку N+1.
   • Виконання конвеєра: Завершено виконання блоку N-1 та остаточно підтверджено його статус. Потім, безшовно з’єднавшись, він негайно отримує щойно завершений консенсусом блок N, починає виконувати його транзакції.

У цьому режимі Pipeline різні ядра ЦП можуть бути ефективно використані. Деякі ядра можуть спеціально обробляти мережеві повідомлення та голосування за консенсусом (сортування), в той час як інші ядра можуть повністю займатися обчисленнями стану (виконанням), обидві конвеєри працюють одночасно, максимізуючи ефективність апаратного забезпечення.

План APE від ICM

виконання

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

Асинхронна конвеєрна схема змогла досягти успіху в Hyperliquid, оскільки Hyperliquid є однією з функціонально однозначних appchain, а модель стану є простою і зрозумілою (в основному, це книги замовлень торгових ринків і позиції користувачів). Команда розробників може чітко розділити, які операції можуть виконуватися паралельно, а які мають залежності, і на основі цього розробити ефективний конвеєр.

Проте, Solana як універсальна ланцюгова система має залежності в транзакціях, які значно складніші, ніж у системі order book. Тому, щоб відтворити продуктивність Hyperliquid в універсальному середовищі, Solana потрібно буде подолати значні інженерні виклики, переробити багато коду, що в короткостроковій перспективі неможливо, тому в дорожній карті ICM це також віднесено до середньострокового планування. Навіть так, для справжнього запуску APE потрібно подолати ряд труднощів:

• Екстремальна складність коду: Щоб розподілена система підтримувала асинхронне паралельне виконання, необхідно здійснити значні зміни на нижньому рівні. Як тільки впроваджується багатопотокова паралельність, програмна складність клієнта валідаційного вузла Solana зросте експоненціально, а ризик невідомих помилок також різко зросте. Неправильна обробка однієї умови гонки може призвести до помилки консенсусу, що матиме катастрофічні наслідки.
• Підвищення апаратних вимог: Паралельне виконання потребує потужного багатоядерного процесора та більше пам’яті для одночасного запуску кількох виконуваних потоків, підтримки кількох тимчасових станів та контрольних точок. Вимоги до вузлів Solana вже досить високі, і якщо їх ще підвищити, це вплине на децентралізацію мережі.
• Обробка найгірших випадків: Найгірший випадок при паралельному виконанні – це велика кількість транзакцій, які змагаються за один і той же стан. Наприклад, коли виникають деякі популярні контракти (як популярні DEX або контракти на покупку), всі транзакції читають і записують в один і той же рахунок, тоді паралельний планувальник постійно перевірятиме конфлікти, скасовуватиме, відтворюватиме, що може бути повільніше, ніж послідовне виконання. Як елегантно знижувати продуктивність у найгірших випадках, не дозволяючи системі потрапити в живу блокаду або різке зниження продуктивності, є складним завданням у проектуванні архітектури.
• Складність розробки та аудиту: Безпечність верифікації в умовах асинхронності та багатопоточності є дуже складною. Спільноті Solana потрібно витратити додаткові ресурси на аудит нової моделі виконання, щоб запобігти зловживанню вразливостями консенсусу, викликаними паралельністю.

🤔 Чи зможе цей імитаційний шоу бути успішним?

З огляду на наведений аналіз, дорожня карта Solana ICM насправді є глибоким “імітаторським шоу” технологічної архітектури Hyperliquid. Основна команда Solana планує відтворити всі фірмові вміння Hyperliquid і надати їх Drift, щоб допомогти йому в DEX ринку знову змагатися з Hyperliquid. Проте, автор не є оптимістом щодо перспектив цього шоу імітації.

Технічна складність зростає експоненційно

Успіх Hyperliquid у великій мірі ґрунтується на його сприятливих природних умовах:

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

З іншого боку, Solana, щоб досягти рівня Hyperliquid, зберігаючи універсальність загального публічного блокчейну та рівень децентралізації, стикається з експоненціально зростаючими технологічними труднощами. Наприклад, консенсус HyperBFT від Hyperliquid здатний працювати з затримкою 0,2 секунди за допомогою 5 або менше вузлів, тоді як Solana, щоб досягти такої ж затримки з 2000 вузлами, змушена подолати межі мережевої комунікації; механізм угод Hyperliquid обслуговує тільки логіку власної біржі, тоді як ACE/BAM Solana має адаптуватися до різноманітних DeFi протоколів.

Можна сказати, що Solana заповнює прогалини Hyperliquid, і складність курсу значно вища, ніж те, що Hyperliquid пережив на початку “не знаю, наскільки високо”. Дорожня карта ICM розподіляє ці завдання до 2027 року, що свідчить про те, що офіційні особи також розуміють, що це не справа одного дня.

Конфлікт між децентралізацією та ефективністю

Інша відмінність між Solana та Hyperliquid полягає в управлінні та темпі оновлень. Команда Hyperliquid має невеликий склад, централізоване ухвалення рішень, відсутні зовнішні механізми контролю, тому дії здійснюються дуже швидко. У березні цього року, коли Hyperliquid зіткнувся з маніпуляцією контрактом JELLY, команда негайно протягом кількох годин зняла з торгів відповідні ринки, що забезпечило безпеку коштів і наочно продемонструвало, що централізоване ухвалення рішень, хоча “політично неправильне”, в критичний момент дійсно є ефективним і корисним.

А Solana як публічна мережа має фонд, ядро розробників і багатосторонні ігри громади, процеси оновлення відносно повільні та консервативні. Наприклад, довгоочікуваний Firedancer (високопродуктивний клієнт Solana, розроблений Jump) з моменту запуску в 2022 році досі (середина 2025 року) перебуває на етапі тестування і вдосконалення, і ще не повністю запущений; будь-які зміни, що стосуються консенсусу, потребують тривалого аудиту та роботи тестової мережі. А зміни в дорожній карті ICM ще більш значні: потрібно змінити основний алгоритм консенсусу, ввести нову паралельну обробку, делегувати ключову владу, що створює труднощі та ризики, які лише зростають. Можна передбачити, що в наступні два-три роки команда Solana повинна поступово просувати ці оновлення, і на кожному кроці можуть виникнути несподівані технічні проблеми або опір з боку громади.

Наприклад, щоб користувачі дійсно отримали вигоду від BAM, розробленого Jito, більшість валідаторів повинні перейти на клієнт, що підтримує BAM. Інакше, транзакції користувачів іноді проходять через BAM, а іноді ні, що призводить до непослідовного досвіду і навіть до арбітражних вразливостей. Але проблема в тому, що Solana не може примусити валідаторів оновити клієнт. Тому навіть якщо BAM буде успішно розроблено, його швидкість впровадження буде важко передбачити. Тому графік у ICM є лише оптимістичним планом, і його реалізація, ймовірно, буде постійно затягуватись, а досягнення всіх цілей може зайняти невизначений час.

Навіть якщо все пройде гладко, до 2027 року Solana реалізує ACE та інші, це буде лише “успішне надолуження” — наздоганяння функцій, які Hyperliquid вже запропонувала у 2023-2024 роках. А сам Hyperliquid не зупиниться: наприклад, пропозиція HIP-3 буде запущена в другій половині 2025 року, що дозволить спільноті самостійно запускати ринок постійних контрактів. Різні інновації ще більше розширять покриття ринку Hyperliquid. Коли Solana нарешті досягне функцій, які має зараз Hyperliquid, можливо, Hyperliquid вже відкриє нові переваги лідера.

Перевага в конкурентній боротьбі за технології

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

• Наприклад, в токеноміці Hyperliquid немає венчурного фінансування, понад 76% токенів розподіляється серед спільноти. Прибутки від зборів платформи можуть бути використані для викупу токенів HYPE, що дійсно забезпечує розподіл вигод з користувачами, без проблем з надмірним експлуатацією з боку капітальних учасників. Це принесло Hyperliquid багато відданих користувачів.
• Крім того, команда Hyperliquid надзвичайно чутлива до ринкових запитів: коли NFT були на піку популярності, вони запустили індекс NFT; коли SocialFi став популярним, вони запустили індекс FriendTech; HIP-2 вирішив проблему “холодного старту нових токенів, нестачі початкової ліквідності”; Hyperps вирішив проблему надання ф’ючерсної торгівлі для активів, які ще не були офіційно запущені; заплановане цьогорічне оновлення HIP-3 підтримує можливість випуску постійних контрактів для будь-якого проекту. Інновації в продуктах з’являються одна за одною, і ці різноманітні торгові категорії та інноваційні ігри значно підвищують привабливість Hyperliquid як торгової платформи — користувачі приходять сюди не лише через швидкість, але й через можливості заробітку, яких немає в інших місцях.

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

Отже, якщо просто слідувати шляху Hyperliquid, то можна назавжди залишитися позаду, їдучи по сліду. Справжня можливість дорожньої карти Solana ICM не в сфері ф’ючерсних контрактів або ордерних книг. В екосистемі Solana є багато сфер, в які Hyperliquid ще не заглиблювався, таких як MEME-майданчик, кредитні протоколи та інші, які також можуть використовувати покращення, які приносить ICM, для створення більш плавного користувацького досвіду. Якщо Solana зможе інноваційно підходити до цих сфер, вирішуючи болі користувачів, то навіть якщо на ринку ф’ючерсних контрактів не вдасться одразу повернути позиції, це все ще зможе зміцнити реалізацію її бачення “інтернет-капітальних ринків”. Адже, незважаючи на всю силу Hyperliquid, це всього лише додаток у вертикальній області, а Solana має широкий і різноманітний спектр застосування, що є її найбільшим капіталом у довгостроковій перспективі.

🏁 Заключення: імітувати легко, перевершити важко

Дорожня карта Solana ICM підкреслює рішучість спільноти Solana не здаватися і наздоганяти. Від ACE до Alpenglow і до APE, кожен з них відповідає характерним функціям Hyperliquid, дійсно має значення “цілеспрямованого наслідування”.

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

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

Дорожня карта ICM малює привабливе майбутнє, але чи зможе воно реалізувати “обхідні маневри”, ще належить перевірити часом. Як звичайні користувачі, ми все ж можемо очікувати, що ця конкуренція принесе кращий досвід угод на блокчейні — незалежно від того, хто врешті-решт переможе, користувачі завжди будуть вигравати.

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

Якщо вам сподобалася ця стаття, будь ласка, підписуйтесь, ставте лайки та діліться на підтримку!