Нещодавно в екосистемі Solana відбулася цікава подія. Включаючи Фонд Solana, Anza, деякі відомі лабораторії та інших важливих учасників, вони зібралися разом і випустили технічну дорожню карту під назвою "Інтернет капітальних ринків (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.
Відомий лабораторія: постачальник інфраструктури MEV на Solana, має величезний вплив, майже контролює "владу життя і смерті" всього MEV-трафіку на Solana. Цього разу вони домінують у наданні рішень для впорядкування транзакцій, таких як Block Assembly Marketplace (BAM).
Відомий капітал: знаменитий криптоінвестиційний інститут, а також ранній підтримувач Solana. Завдяки наявності значної кількості SOL та прав на екосистемні проекти, має досить великий вплив у технічному напрямку.
DoubleZero: команда, що зосереджена на прискоренні мережевої комунікації, пропонує спеціалізовані оптоволоконні мережеві рішення для підвищення швидкості зв'язку між вузлами верифікації Solana.
Деяка платформа безстрокових контрактів: провідний DEX проект безстрокових контрактів на Solana. Раніше ця платформа використовувала офлайн-матчинг, і в порівнянні з повністю онлайновим Hyperliquid це виглядало дещо складно, тепер, беручи участь у розробці дорожньої карти, вона очевидно сподівається на поліпшення завдяки оновленню базового рівня.
Основна проблема, яку потрібно вирішити
Дорожня карта зосереджується на покращенні мікроструктури ринку, простіше кажучи, поточний механізм торгівлі в ланцюгу не є достатньо дружнім для маркет-мейкерів, тобто активні учасники торгівлі (Taker) отримують вигоду, а ті, хто ставить ордери в очікуванні виконання (Market Maker), зазнають збитків. Це відбувається тому, що Taker, як правило, володіють останньою інформацією та активно підвищують торгові комісії, щоб гарантувати пріоритет виконання своїх угод, тоді як Maker часто не встигають скасувати ордери та змушені укладати угоди за невигідними цінами.
Деякі високочастотні арбітражники використовують цю асиметрію, ініціюючи "отруйний трафік"-атаки. Наприклад, якщо ціна на ланцюзі ще не оновилась, але ціна поза ланцюгом вже змінилась, арбітражник зможе застарілою ціною забрати замовлення у маркет-мейкерів, змушуючи маркет-мейкерів нести збитки. В результаті Maker, щоб захистити себе, або збільшує спред між купівлею та продажем, або зменшує обсяг замовлень, що призводить до погіршення ліквідності на ринку.
Дорожня карта ICM має на меті збалансувати цю ситуацію, приваблюючи високоякісну ліквідність назад у мережу.
Три кроки ICM
Solana поділила цей грандіозний план на три етапи:
Короткостроковий (1-3 місяці): основна мета – оптимізувати існуючий досвід торгівлі на ланцюгу, зробити застосунки з книжками ордерів більш зручними у використанні, зменшити негативний вплив MEV. Конкретно включає:
На основі відомої лабораторії запущено модуль Block Assembly Marketplace (BAM) в основній мережі. Значення цього модуля полягає в наданні тимчасової системи плагінів до запуску Ultimate ACE (Application Controlled Execution), що дозволяє смарт-контрактам на 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) функціонал: справжнє наділення смарт-контрактів на ланцюгу правом контролю порядку виконання транзакцій.
Аналізуючи це, автор вважає, що історія, що стоїть за представленням маршруту ICM, повинна виглядати так: старий DEX на Solana було обійдено новачком Hyperliquid завдяки "відмінному досвіду певної торгової платформи в мережі". Старий DEX не зміг протистояти цьому і вирішив звернутися по допомогу до "великої риби" Solana Labs, Anza та інших. "Великі риби" запропонували технічну реформу ICM, стверджуючи, що вони повторять всі фірмові навички Hyperliquid для старого DEX, щоб допомогти йому знову вийти на ринок DEX. Однак "великі риби" також зазначили, що ця технічна реформа є надзвичайно складною, тому вони розділили технічний план на триетапну стратегію, і найближчим часом старий DEX може отримати лише обладнання від певної відомої лабораторії BAM, щоб старий DEX міг використовувати його в якихось обмежених масштабах, порівнюючи спочатку з Hyperliquid.
Чітко визначивши фон історії, у наступних розділах автор детально проаналізує, які саме фірмові навички ICM імітує та відтворює з Hyperliquid.
Імітація 1: Механізм сортування угод
Проблема полягає в тому, що, як зазначалося раніше, теперішня мережа схиляється до taker, а maker страждає від "отруйного трафіку". Користувачі, які активно беруть ордери, можуть на основі останніх цін поза мережею миттєво ініціювати угоду з ордерами на мережі та завдяки підвищенню комісії мати пріоритет у виконанні, тоді як маркетмейкери часто не встигають оновити або скасувати ордери. В результаті, маркетмейкери або збільшують спред, або взагалі знімають ліквідність, що погіршує глибину ринку.
Остаточне рішення ICM: застосування контрольованого виконання (ACE)
Дорожня карта ICM пропонує концепцію ACE (Application Controlled Execution), що означає делегування права сортування транзакцій різним додаткам на ланцюгах, які самостійно вирішують, як сортувати та виконувати транзакції, що стосуються цього додатка. Наприклад, у майбутньому на Solana з реалізацією ACE, контракти DeFi можуть реалізувати такі налаштовані правила сортування транзакцій:
Оновлення цін Oracle: DeFi-додатки можуть перед великими угодами спочатку вставити угоду для отримання останньої ціни від оракула, забезпечуючи виконання замовлень за актуальними цінами, запобігаючи арбітражу, коли котирування маркет-мейкерів базуються на застарілій ціні.
Пріоритет скасування замовлення: застосунок може встановити, що "запит на скасування замовлення" має пріоритет перед новим "виконанням замовлення", даючи можливість maker своєчасно скасувати замовлення, коли ринкова ситуація невигідна.
Аукціон в кінці черги: наприклад, коли з'являється великий купівельний ордер, що підвищує ціну, DeFi-додаток "негайно" пропонує можливість для аукціону, і той, хто готовий повернути найбільше вигоди протоколу (або користувачу), отримає можливість виконати свою угоду поруч з великим ордером. DeFi-додаток може повернути доходи з аукціону користувачам, перетворюючи токсичний MEV-трафік на здоровий дохід.
BAM відомої лабораторії: перехідний план
Перед офіційним запуском ACE, одна відома лабораторія представила перехідне рішення під назвою Block Assembly Marketplace (BAM). Робочий процес BAM складається з:
Користувач надсилає угоду вузлу, який виконує програмне забезпечення BAM (а не безпосередньо поточному лідеру).
BAM-узел збирає локальні транзакції та виконує різноманітні плагіни ( plugin ) для перетворення транзакційного пакета (Bundle) з прихистком приватності. (Плагін працює у безпечному середовищі TEE, приховуючи вміст транзакцій перед виконанням). Завдяки плагіну, розробники застосунків можуть налаштовувати різні правила сортування для своїх контрактів, такі як пріоритет скасування замовлень, оновлення ціни оракула перед об'єднанням, або навіть запуск складних внутрішніх аукціонів тощо.
Відсортований торговийBundle відправляється лідеру Solana для упаковки в ланцюг.
BAM можна розглядати як експериментальне поле перед запуском ACE в блокчейн, функціонально воно дуже близьке до остаточного ACE, тільки воно працює в незалежній мережі поза вбудованим протоколом основної ланцюга Solana.
Слід зазначити, що одна відома лабораторія раніше надавала інфраструктуру, орієнтовану на видобуток MEV (таку як певний блокчейн-двигун), її бізнес-модель полягала в оптимізації порядку угод для створення можливостей для арбітражників та поділу прибутку. Це в певному сенсі є "списом", який стоїть на протилежному боці від звичайних користувачів і жертв арбітражу. Однак ця лабораторія на початку 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): валідатор, отримавши кандидатний блок, що транслюється Пропозером, проводить швидку перевірку. Якщо перевірка пройде успішно, кожен валідатор голосує за цей блок однією "попередньою голосувальною" (Prevote) бюлетенем та транслює його по всій мережі. Цей бюлетень представляє: "Я попередньо переглянув
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
5
Репост
Поділіться
Прокоментувати
0/400
TheMemefather
· 2год тому
Краще інноваційно створити щось своє, ніж просто копіювати.
Solana ICM маршрут vs Hyperliquid: у блокчейні бій за торгівлю
Дорожня карта ICM Solana: "імітатор" Hyperliquid
Вступ: Зустріч гуру Solana
Нещодавно в екосистемі Solana відбулася цікава подія. Включаючи Фонд Solana, Anza, деякі відомі лабораторії та інших важливих учасників, вони зібралися разом і випустили технічну дорожню карту під назвою "Інтернет капітальних ринків (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.
Відомий лабораторія: постачальник інфраструктури MEV на Solana, має величезний вплив, майже контролює "владу життя і смерті" всього MEV-трафіку на Solana. Цього разу вони домінують у наданні рішень для впорядкування транзакцій, таких як Block Assembly Marketplace (BAM).
Відомий капітал: знаменитий криптоінвестиційний інститут, а також ранній підтримувач Solana. Завдяки наявності значної кількості SOL та прав на екосистемні проекти, має досить великий вплив у технічному напрямку.
DoubleZero: команда, що зосереджена на прискоренні мережевої комунікації, пропонує спеціалізовані оптоволоконні мережеві рішення для підвищення швидкості зв'язку між вузлами верифікації Solana.
Деяка платформа безстрокових контрактів: провідний DEX проект безстрокових контрактів на Solana. Раніше ця платформа використовувала офлайн-матчинг, і в порівнянні з повністю онлайновим Hyperliquid це виглядало дещо складно, тепер, беручи участь у розробці дорожньої карти, вона очевидно сподівається на поліпшення завдяки оновленню базового рівня.
Основна проблема, яку потрібно вирішити
Дорожня карта зосереджується на покращенні мікроструктури ринку, простіше кажучи, поточний механізм торгівлі в ланцюгу не є достатньо дружнім для маркет-мейкерів, тобто активні учасники торгівлі (Taker) отримують вигоду, а ті, хто ставить ордери в очікуванні виконання (Market Maker), зазнають збитків. Це відбувається тому, що Taker, як правило, володіють останньою інформацією та активно підвищують торгові комісії, щоб гарантувати пріоритет виконання своїх угод, тоді як Maker часто не встигають скасувати ордери та змушені укладати угоди за невигідними цінами.
Деякі високочастотні арбітражники використовують цю асиметрію, ініціюючи "отруйний трафік"-атаки. Наприклад, якщо ціна на ланцюзі ще не оновилась, але ціна поза ланцюгом вже змінилась, арбітражник зможе застарілою ціною забрати замовлення у маркет-мейкерів, змушуючи маркет-мейкерів нести збитки. В результаті Maker, щоб захистити себе, або збільшує спред між купівлею та продажем, або зменшує обсяг замовлень, що призводить до погіршення ліквідності на ринку.
Дорожня карта ICM має на меті збалансувати цю ситуацію, приваблюючи високоякісну ліквідність назад у мережу.
Три кроки ICM
Solana поділила цей грандіозний план на три етапи:
Короткостроковий (1-3 місяці): основна мета – оптимізувати існуючий досвід торгівлі на ланцюгу, зробити застосунки з книжками ордерів більш зручними у використанні, зменшити негативний вплив MEV. Конкретно включає:
На основі відомої лабораторії запущено модуль Block Assembly Marketplace (BAM) в основній мережі. Значення цього модуля полягає в наданні тимчасової системи плагінів до запуску Ultimate ACE (Application Controlled Execution), що дозволяє смарт-контрактам на 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) функціонал: справжнє наділення смарт-контрактів на ланцюгу правом контролю порядку виконання транзакцій.
Аналізуючи це, автор вважає, що історія, що стоїть за представленням маршруту ICM, повинна виглядати так: старий DEX на Solana було обійдено новачком Hyperliquid завдяки "відмінному досвіду певної торгової платформи в мережі". Старий DEX не зміг протистояти цьому і вирішив звернутися по допомогу до "великої риби" Solana Labs, Anza та інших. "Великі риби" запропонували технічну реформу ICM, стверджуючи, що вони повторять всі фірмові навички Hyperliquid для старого DEX, щоб допомогти йому знову вийти на ринок DEX. Однак "великі риби" також зазначили, що ця технічна реформа є надзвичайно складною, тому вони розділили технічний план на триетапну стратегію, і найближчим часом старий DEX може отримати лише обладнання від певної відомої лабораторії BAM, щоб старий DEX міг використовувати його в якихось обмежених масштабах, порівнюючи спочатку з Hyperliquid.
Чітко визначивши фон історії, у наступних розділах автор детально проаналізує, які саме фірмові навички ICM імітує та відтворює з Hyperliquid.
Імітація 1: Механізм сортування угод
Проблема полягає в тому, що, як зазначалося раніше, теперішня мережа схиляється до taker, а maker страждає від "отруйного трафіку". Користувачі, які активно беруть ордери, можуть на основі останніх цін поза мережею миттєво ініціювати угоду з ордерами на мережі та завдяки підвищенню комісії мати пріоритет у виконанні, тоді як маркетмейкери часто не встигають оновити або скасувати ордери. В результаті, маркетмейкери або збільшують спред, або взагалі знімають ліквідність, що погіршує глибину ринку.
Остаточне рішення ICM: застосування контрольованого виконання (ACE)
Дорожня карта ICM пропонує концепцію ACE (Application Controlled Execution), що означає делегування права сортування транзакцій різним додаткам на ланцюгах, які самостійно вирішують, як сортувати та виконувати транзакції, що стосуються цього додатка. Наприклад, у майбутньому на Solana з реалізацією ACE, контракти DeFi можуть реалізувати такі налаштовані правила сортування транзакцій:
Оновлення цін Oracle: DeFi-додатки можуть перед великими угодами спочатку вставити угоду для отримання останньої ціни від оракула, забезпечуючи виконання замовлень за актуальними цінами, запобігаючи арбітражу, коли котирування маркет-мейкерів базуються на застарілій ціні.
Пріоритет скасування замовлення: застосунок може встановити, що "запит на скасування замовлення" має пріоритет перед новим "виконанням замовлення", даючи можливість maker своєчасно скасувати замовлення, коли ринкова ситуація невигідна.
Аукціон в кінці черги: наприклад, коли з'являється великий купівельний ордер, що підвищує ціну, DeFi-додаток "негайно" пропонує можливість для аукціону, і той, хто готовий повернути найбільше вигоди протоколу (або користувачу), отримає можливість виконати свою угоду поруч з великим ордером. DeFi-додаток може повернути доходи з аукціону користувачам, перетворюючи токсичний MEV-трафік на здоровий дохід.
BAM відомої лабораторії: перехідний план
Перед офіційним запуском ACE, одна відома лабораторія представила перехідне рішення під назвою Block Assembly Marketplace (BAM). Робочий процес BAM складається з:
Користувач надсилає угоду вузлу, який виконує програмне забезпечення BAM (а не безпосередньо поточному лідеру).
BAM-узел збирає локальні транзакції та виконує різноманітні плагіни ( plugin ) для перетворення транзакційного пакета (Bundle) з прихистком приватності. (Плагін працює у безпечному середовищі TEE, приховуючи вміст транзакцій перед виконанням). Завдяки плагіну, розробники застосунків можуть налаштовувати різні правила сортування для своїх контрактів, такі як пріоритет скасування замовлень, оновлення ціни оракула перед об'єднанням, або навіть запуск складних внутрішніх аукціонів тощо.
Відсортований торговийBundle відправляється лідеру Solana для упаковки в ланцюг.
BAM можна розглядати як експериментальне поле перед запуском ACE в блокчейн, функціонально воно дуже близьке до остаточного ACE, тільки воно працює в незалежній мережі поза вбудованим протоколом основної ланцюга Solana.
Слід зазначити, що одна відома лабораторія раніше надавала інфраструктуру, орієнтовану на видобуток MEV (таку як певний блокчейн-двигун), її бізнес-модель полягала в оптимізації порядку угод для створення можливостей для арбітражників та поділу прибутку. Це в певному сенсі є "списом", який стоїть на протилежному боці від звичайних користувачів і жертв арбітражу. Однак ця лабораторія на початку 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 і використовує двохраундне голосування для підтвердження блоків, досягаючи "миттєвої остаточності".