Технічне шоу наслідування: амбіції та реальність Solana

Нещодавно в екосистемі 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. Цього разу вони домінують у наданні ринків збору блоків (BAM) та інших схем впорядкування транзакцій.

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

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

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

потрібно вирішити основну проблему

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

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

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

) Три етапи ICM

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

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

• Ринок Block Assembly від Jito Labs)BAM( модуль запущено на основній мережі. Цей модуль до запуску Ultimate ACE надає тимчасову зовнішню систему, що дозволяє смарт-контрактам на Solana мати автономне право на сортування угод.

• Команда Anza оптимізувала ймовірність "входу в одну Slot" для зменшення сліпу та втрат 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( функція: надає справжню владу смарт-контрактам на ланцюгу контролювати порядок виконання транзакцій.

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

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

Дорожня карта ICM пропонує концепцію ACE)Application Controlled Execution(, що передбачає делегування прав на сортування транзакцій на різні ланцюгові застосунки, де застосунки самостійно вирішують, як сортувати та виконувати транзакції, пов'язані з цим застосунком. У майбутньому на Solana, що реалізує ACE, контракти 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 більше орієнтовані на постачальників ліквідності, вже на рівні ланцюга реалізовано багато дизайнів для захисту маркет-мейкерів, наприклад:

• Пріоритет захисту для тих, хто виставляє ордери: скасування ордерів і ордери, які виконують лише роль 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 (: валідатори, отримавши кандидатний блок, що транслюється Пропозером, проводять швидку перевірку. Якщо перевірка проходить успішно, кожен валідатор голосує за цей блок однією "попередньою голосом" ) Prevote ( і транслює його в мережу. Цей голос представляє: "Я попередньо переглянув, цей блок в порядку."

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

• Коли валідатор отримує Precommit від більш ніж двох третин валідаторів для одного й того ж кандидатного блоку, консенсус досягається! Цей блок вважається остаточно затвердженим )Finalized(. Він буде назавжди, незворотно доданий до блокчейну.

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

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

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

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